On 12/05/2013 04:27 AM, Richard Brown wrote:
On Thu, 2013-12-05 at 07:30 +0100, Stephan Kulow wrote:
Am 04.12.2013 20:51, schrieb Per Jessen:
Appoint responsibilities? Basically, if something needs to be distributed in a working fashion, we need _something_ to distribute it. The Board doesn't get it's hands dirty, so a steering committee?
A committee can hardly assign tasks to people. And that's where I'm afraid this whole thing collapses.
Just as we had people for 12.3 to distribute $LANGUAGE messages in twitter and then he was gone for 13.1, but registered openSUSE-$LANGUAGE.
I agree. I don't think a 'committee', a group who assigns work to others, can work in a volunteer community.
I do think we could probably do with some 'technical escalation point', some one (or ideally some group.. bus factor > 1) to make decisions to break deadlocks when we have one bunch of contributors wanting to go in one direction (eg. systemd) and another wanting to go in an incompatible other direction (eg. sysVinit.. please don't focus on the example, I'm just being illustrative)
This isn't that dissimilar from the Board, who are 'Decision Makers of Last Resort' for all of the non-technical aspects of the Project.
It is my *personal* opinion that the Board *could*, theoretically assume that role. There are 2 just issues standing in its way
1) The current Board rule that it shouldn't 'direct or control development' would need to be reworded to reflect that, while it wouldn't have day-to-day 'control' of development (ie. it would have no right to tell technical contributors what to do), it would be the group responsible for making technical decisions that are escalated to it
2) We would probably have to have a slightly more formal 'process' for handling those kind of big changes that could end up being escalated to the Board or a different "Technical Decision Maker of Last Resort". An earlier example I gave of the current process highlighted the problem; Currently 'Big New Stuff' can and does end up in the Factory submission queue without any discussion with the wider community.
Our 'good citizens' do a better job, by often raising those 'Big New Stuff' on the -factory mailinglist for discussion and decision making between our contributors.
If we go down the road of having a formal 'Technical Decision Maker of Last Resort' (be it the Board or not), then I think it would need to be a rule that 'Big New Stuff' would have to go through some formal kind of documentation/proposal process, similar in tone to the current -factory list posts but some kind of 'template document' probably wouldn't be a bad idea to make sure all the required information is 'out there' for discussion
These 'Big Change Proposal document' would be the basis of discussion between our family of contributors, just as those -factory threads are now, and only in the result of a deadlock would it be needed to call on a 'Technical Decision Maker of Last Resort' (eg. Board, or some Tech Group). And if and when that is required, having the proposals clearly documented would hopefully provide a much better understanding to those decision makers of last resort - after all, they cant be expected to know about everything, and would regularly be making technical decisions outside of any area of their own expertise.
Lots of good points. I just think we cannot solve everything at once and the discussion of a "technical escalation team" and/or "change process for existing stuff" is a separate discussion we should have when the current flood of proposals and idea discussions has subsided a bit. Possibly also a good topic for a BoF at oSC in April. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org