> Does it need to be a single person? Could it be a team responsibility like
> a Toyota-style "Stop the Line" button? I think a community can decide how it
> wants to mechanically run a stop process.
> The important thing – if stability is truly important – is making sure that
> people with the right perspectives on aggregate stability are known,
> involved, and heeded.
I think it might be worth going back to frew's suggestion of the
Collective Code Construction Contract and think about whether we can
try to adopt the risk management into the general governance of the
project. We all seem to agree on what stability we want. We are
mostly arguing over how we achieve it.
I would like it to be easy enough that a developer new to the project,
without needing to get deep in irc communication or mailing lists, can
contribute a feature/improvement with a reasonable expectation of it
being accepted. That's actually relatively rare with most open source
projects, but I don't see why it needs to be. If there is clear
documentation regarding what is acceptable from a stability point of
view, how to contact people when you want to ask questions or for
opionions, and explaining what level of tests are required it is quite
possible that they will be able to produce a reasonable change without
much assistance. By having the documented process it should also make
it easier for the reviewers to complain about stability breaking
things without needing to worry too much about how to put it, as the
documentation should have the words.
If we have good core guidelines then the people should mater less, and
it should be easier to encourage other people to chip in time to do
reviews and help with running the project, rather than it simply
being seen as a fight. Having good people is definitely something we
need, but we should consider that they may not be available all the
time forever. Hopefully having things written down will help.
Searchable Archive: http://email@example.com