On Wed, Sep 23, 2015 at 9:47 AM, Chris Barker - NOAA Federal < chris.bar...@noaa.gov> wrote:
> > But discussing who is great community leader, etc. is frankly not > obvious to me related to numpy governance. > > Thank you Sebastian. > > Could we please try to get back to the governance issues, without > naming names? There are some specific questions on the table that need > to get hashed out. > > > Numpy does not have a BDFL. BDFLs are not selected, they are naturally > produced, and there is no one that fits that bill now. We *could* > decide to have a single individual executive leader, selected by some > sort of democratic process. But that is not the same as a BDFL. And I > think the almost-consensus now is to not have that. > > So here is what I think is on the table: > > We have the steering council. Which leaves two questions: > > -How big should it be? > -Who will be on the original, "seed" council? > > Note that as I understand the current draft of the governance doc, > once established, the council itself decides who is on the council. So > at this point we really are ONLY deciding how it's going to start. It > has to be bootstrapped somehow. > > However, that had been contentious enough that it would probably be a > good idea to hash out some guidelines about the council membership. > > Personally, I have no idea how big the council should be. Too big, and > there is no point, consensus is harder to reach the larger the group, > and the main (only?) role of the council is to resolve issues where > consensus has not been reached in the larger community. But what is > too big? > > As for make-up of the council, I think we need to expand beyond people > who have recently contributed core code. > > Yes, the council does need to have expertise to make technical > decisions, but if you think about the likely contentious issues like > ABI breakage, a core-code focused view is incomplete. So there should > be representation by: > > Someone(s) with a long history of working with the code -- that > institutional memory of why decisions were made the way they were > could be key. > > Someone(s) that may not have worked on the core code, but is a major > player in the community, perhaps as the leader of a Numpy-dependent > project. This would provide representation for the broad community. > > I do want to note that the governance document as I understand it is > consistent with these suggestions. > > As for conflict of interest issues, etc: > > Chill out people! > > Numpy is an open source project, if it gets hijacked, it can be forked. > > And the council is also democratic -- no one person can drive the > project. If a council member is not acting in the interests of the > community, s/he can be removed. > > Hear, hear. Well put Chris. I don't disagree with any of this. > NOTE: while x.org, and egcs, Xemacs, and ... may be examples of > failures of governance, they are also examples of successes of open > source. > Good point. Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion