[Numpy-discussion] Numpy governance update
Thu Feb 16 00:08:57 CST 2012
On Wed, Feb 15, 2012 at 9:47 PM, Dag Sverre Seljebotn
> On 02/15/2012 05:02 PM, Matthew Brett wrote:
>> On Wed, Feb 15, 2012 at 4:27 PM, Dag Sverre Seljebotn
>> <email@example.com> wrote:
>>> On 02/15/2012 02:24 PM, Mark Wiebe wrote:
>>>> There certainly is governance now, it's just informal. It's a
>>>> combination of how the design discussions are carried out, how pull
>>>> requests occur, and who has commit rights.
>>> If non-contributing users came along on the Cython list demanding that
>>> we set up a system to select non-developers along on a board that would
>>> have discussions in order to veto pull requests, I don't know whether
>>> we'd ignore it or ridicule it or try to show some patience, but we
>>> certainly wouldn't take it seriously.
>> Ouch. Is that me, one of the non-contributing users? Was I
>> suggesting that we set up a system to select non-developers to a
>> board? I must say, now you mention it, I do feel a bit ridiculous.
> In retrospect I was unfair and my email way too harsh. Anyway, I'm
> really happy with your follow-up in turning this into something more
Don't worry - thanks for this reply.
>> You believe, I suppose, that there are no significant risks in nearly
>> all the numpy core development being done by a new company, or at
>> least, that there can little benefit to a governance discussion in
>> that situation. I think you are wrong, but of course it's a tenable
>> point of view,
> The question is more about what can possibly be done about it. To really
> shift power, my hunch is that the only practical way would be to, like
> Mark said, make sure there are very active non-Continuum-employed
> developers. But perhaps I'm wrong.
It's not obvious to me that there isn't a set of guidelines,
procedures, structures that would help to keep things clear in this
situation. Obviously it would be good to have more non-Continuum
developers, but also obviously, there is a risk that that won't
> Sometimes it is worth taking some risks because it means one can go
> forward faster. Possibly *a lot* faster, if one shifts things from email
> to personal communication.
Yes, obviously it's in no-one's interest to slow down the Continuum
developers. I wonder though whether there is a way of organizing
things, that does not slow down the Continuum developers, but does
keep the sense of community involvement and ownership.
> It is not like the current versions of NumPy disappear. If things do go
> wrong and NumPy is developed in some crazy direction, it's easy to go
> for the stagnated option simply by taking the current release and
> maintain bugfixes on it.
But we all want to avoid a fork, which is what that could easily become.
More information about the NumPy-Discussion