> 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. NOTE: while x.org, and egcs, Xemacs, and ... may be examples of failures of governance, they are also examples of successes of open source. -Chris _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
