[Numpy-discussion] Governance model request

[Charles R Harris]

On Wed, Sep 23, 2015 at 9:47 AM, Chris Barker - NOAA Federal <
chris.barker at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150923/a3f56f06/attachment.html>