Hi, On Thu, Aug 27, 2015 at 11:05 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Thu, Aug 27, 2015 at 2:16 AM, Matthew Brett <matthew.brett@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