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

[Matthew Brett]

Hi,

On Thu, Aug 27, 2015 at 11:05 AM, Nathaniel Smith <njs at pobox.com> wrote:
> On Thu, Aug 27, 2015 at 2:16 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
>> So, I speculate, that a good governance model would have:
>>
>> * one 'president' who has to take final responsibility for all decisions;
>> * this president might well have a fixed term, maybe with limits on
>> the number of terms they can serve.
>> * the president would be chosen by community vote and explicitly on
>> the basis that they were good managers as well as coders;
>> * for the presidential election, the candidates should set out what
>> their vision for the project is, and how they plan to achieve that
>> vision;
>
> We actually discussed some variants on this kind of idea at the
> meeting, and I think the general sense of those present was we didn't
> want to go there (for whatever that's worth).
>
> At least personally, I have to admit that the idea of a governance
> model involving elections fills me with creeping horror. The reason is
> that whole point of having a governance model (IMHO) is to (a)
> minimize the rise of interpersonal drama

Right - I think this is key to the problem in this model.  It is
designed not to cause any trouble, and to keep things running as they
are without controversy.  It works OK on average as long as 'no
change' is the desired outcome.  In general the core group know each
other fairly well, and feel a sense of shared loyalty to the group.
This loyalty is exercised when some outside or inside force challenges
the direction of the project.  This was what made it so hard for the
XFree86 core group to pull back from the course they had set.

The question is - is avoiding the potential controversy important
enough to force us into a model that has (in my opinion) a high risk
of tending to conservatism and stagnation?

> As for evidence... there are obviously projects that have had serious
> problems with some variant of core team model, but there are also many
> many successful projects that are also using variants of this model,
> and the document I sent around attempts to incorporate the lessons
> that have been learned in the process. OTOH after wracking my brain I
> think the only project I'm familiar with that has elections at all
> like this is Fedora, which elects... a "core team" (FESCo). Given that
> we don't have the problem of trying to manage thousands of
> contributors, I'm not sure their experience is really relevant. Or I
> guess Debian's use of General Resolutions as a decision-making
> procedure of last resort is kinda relevant, but... pretty different.
> (They also elect the project leader, which is more similar to what
> you're describing, but the project leader has no technical authority;
> in Debian the final authority short of a GR is the CTTE, which is
> explicitly designed as a classic beholden-to-nobody institution -- and
> even overriding the CTTE requires a supermajority.)
>
> I kinda feel like... as a rule of thumb, if your description of your
> governance model starts with the words "I speculate that...", then
> NumPy is probably not a good project to use for your experiment?

So my argument would be that our current data on success (lots of
projects use this model and many of them are OK) is much less useful
than the data from successful forks.

I suppose my question ends up being - do you agree that the core model
does have these risks?   Do they worry you?  What do you think we can
do to guard against them?

Cheers,

Matthew