[Numpy-discussion] Comments on governance proposal (was: Notes from the numpy dev meeting at scipy 2015)

[Sebastian Berg]

On Do, 2015-08-27 at 10:45 +0100, Matthew Brett wrote:
> Hi,
> 
> On Thu, Aug 27, 2015 at 10:35 AM, Bryan Van de Ven <bryanv at continuum.io> wrote:
> >
> >> On Aug 27, 2015, at 10:22 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
> >>
> >> In the case of the 'core' model, we have some compelling testimony
> >> from someone with a great deal of experience:
> >>
> >> """
> >> Much of this early structure (CVS, web site, cabal ["core" group],
> >> etc.) was copied verbatim by other open source (this term not being in
> >> wide use yet) projects -- even the form of the project name and the
> >> term "core". This later became a kind of standard template for
> >> starting up an open source project. [...] I'm sorry to say that I
> >> helped create this problem, and that most of the projects which
> >> modeled themselves after NetBSD (probably due to its high popularity
> >> in 1993 and 1994) have suffered similar problems. FreeBSD and XFree86,
> >> for example, have both forked successor projects (Dragonfly and X.org)
> >> for very similar reasons.
> >> """
> >
> > Who goes on to propose:
> >
> > 7) The "core" group must be replaced with people who are actually
> >    competent and dedicated enough to review proposals, accept feedback,
> >    and make good decisions.  More to the point, though, the "core" group
> >    must only act when *needed* -- most technical decisions should be
> >    left to the community to hash out; it must not preempt the community
> >    from developing better solutions.  (This is how the "core" group
> >    worked during most of the project's growth period.)
> 
> Sure.  I think it's reasonable to give high weight to Hannum's
> assessment of the failure of the core group, but less weight to his
> proposal for a replacement, because at the time, I don't believe he
> was in a good position to assess whether his (apparent) alternative
> would run into the same trouble.
> 
> It's always tempting to blame the people rather than the system, but
> in this case, I strongly suspect that it was the system that was
> fundamentally flawed, therefore either promoting the wrong people or
> putting otherwise competent people into situations where they are no
> longer getting useful feedback.

Maybe so. I do not know much at all about these models, but I am not
sure how much applies here to numpy. Isn't at least FreeBSD a magnitude
larger then numpy?
We do need to have some formality about how to give out commit rights,
and do final decision when all else fails.

One thing I do not know is how a "community vote" could work at all,
considering I do not even know how to count its members. Votes and
presidents make sense to me for large projects with hundrets of
developers on different corners (think of the gnome foundation, debian
probably) [1].

One thing I could imagine adding is that the community should be
encouraged to ask for/propose new members for the "core" team.

Nobody is particularly in love with this model, but maybe out of our own
ignorance, we do not see many alternatives after ruling out a BDFL. Yes,
it is a lot fixing a status quo, but we have to fixate something. Any
alternative suggestions are welcome and would be even after deciding on
this. Though maybe that takes away some momentum.

- Sebastian


[1] If we were to have a central governance for the SciPy stack the
story would seem very different to me.


> 
> It would be great, and very convenient, if the only management we
> needed was getting out of the way, but I doubt very much that that is
> the case.
> 
> Cheers,
> 
> Matthew
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150827/cda4f53c/attachment.sig>