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.
I agree with you, in the end what the openSUSE Team chooses to do or chooses not to do is in principle no different than any other team. It just happens that the team has done a lot of the release work and now if this will no longer be done by the openSUSE Team we have to find other people to do it.
We have to start by understanding "the release work" first. Apart from that, I think we have plenty of capable people.
Being capable is one thing, having time another. I don't see tons of people standing around and asking what to do.
True, but I do think a list of 'Open Tasks' for the Project would be a "Good Thing". Where do people need help? What jobs are currently unhandled by anyone? What jobs are currently handled by people who'd rather be doing something else? Not everyone is proactive, especially less confident new contributors, so might not think of asking 'what can I do to help?' We do regularly see calls for help on the mailinglists, but the success of such calls can be a little hit and miss. However, if we had a list of 'stuff we need people to do', it informs the uninformed about the work being done, enables people to pick off things they have the skills in, or just find interesting, in which case it can also double as a bit of a framework for mentoring. And even if it isn't wildly successful, it at least helps document the current state of play and the areas of work we'd like to improve in -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org