> >> Linux: Technically, everything you say is true. In practice, good luck >> convincing Linus or a subsystem maintainer to accept your patch when >> other people are raising substantive complaints. Here's an email I >> googled up in a few moments, in which Linus yells at people for trying >> to submit a patch to him without making sure that all interested >> parties have agreed: >> https://lkml.org/lkml/2009/9/14/481 >> Stuff regularly sits outside the kernel tree in limbo for *years* >> while people debate different approaches back and forth. > > To which I'd add: > > "In fact, for [Linus'] decisions to be received as legitimate, they > have to be consistent with the consensus of the opinions of > participating developers as manifest on Linux mailing lists. It is not > unusual for him to back down from a decision under the pressure of > criticism from other developers. His position is based on the > recognition of his fitness by the community of Linux developers and > this type of authority is, therefore, constantly subject to > withdrawal. His role is not that of a boss or a manager in the usual > sense. In the final analysis, the direction of the project springs > from the cumulative synthesis of modifications contributed by > individual developers." > http://shareable.net/blog/governance-of-open-source-george-dafermos-interview >
This is the model that I have for NumPy development. It is my view of how NumPy has evolved already and how Numarray, and Numeric evolved before it as well. I also feel like these things are fundamentally determined by the people involved and by the personalities and styles of those who participate. There certainly are globally applicable principles (like code review, building consensus, and mutual respect) that are worth emphasizing over and over again. If it helps let's write those down and say "these are the principles we live by". I am suspicious that you can go beyond this in formalizing the process as you ultimately are at the mercy of the people involved and their judgment, anyway. I can also see that for the benefit of newcomers and occasional contributors it can be beneficial to have some documentation of the natural, emergent methods and interactions that apply to cooperative software development. But, I would hesitate to put some-kind of aura of authority around such a document that implies the processes cannot be violated if good judgment demands that they should be. That is the basis of my hesitation to spend much time on "officially documenting our process" Right now we are trying to balance difficult things: stable releases with experimental development. The fact that we had such differences of opinion last year on masked arrays / missing values and how to incorporate them into a common object model means that we should not have committed the code to master until we figured out a way to reconcile Nathaniel's concerns. That is my current view. I was very enthused that we had someone contributing large scale changes that clearly showed an ability to understand the code and contribute to it --- that hadn't happened in a while. I wanted to encourage that. I still do. I think the process itself has shown that you can have an impact on NumPy just by voicing your opinion. Clearly, you have more of an effect on NumPy by submitting pull requests, but NumPy development does listen carefully to the voices of users. Best, -Travis > See you, > > Matthew > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
