Hi, we have presented our ideas around the new development distribution (new factory) and, in the presented diagram, we included new roles and a brief description of them. I believe any complex process needs govern. I am talking about making sure that the development process as a whole is adaptive, that is evaluated and that serves to the purpose of those who work on it AND those who we work for. We will present some ideas in this area. They will be less elaborate than the ones already presented. We have done this on purpose. But let me be clear about this. I am not talking about a technical committee. That would be, in my opinion, a change in our nature. Again, we are are proposing to base the changes on our strengths. So in our proposal, technical decisions will still be a matter of agreements made by engineers taking as a first/relevant argument "who works decides".... and accept the consequences. On Sunday 01 December 2013 00:42:10 Richard Brown wrote:
On 30 November 2013 23:46, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:
I'm still concerned that we have no "legitimized" board for escalated technical decisions. For non-critical things the community approach probably is enough but there might be situations where a formal transparent traceable process leading to a decision is needed. Which instance in the community is supposed to decide in such situations today? The board is explicitely (as I understood) not meant to do that.
The current logic (as I understand it) goes something like this..and I realise this is simplified, but hopefully illustrative.
1) Contributor A wants to change something technical to the distribution 2) Contributor A suggests it on -factory ML and/or does the changes and submits them to the appropriate devel repo and/or Factory 3a) If no one dislikes Contributor A's changes, and they conform to the few policies/procedures we have changes get accepted, SUCCESS - END
3b) If other Contributors (lets just assume 1 for the sake of this example, Contributor B) dislike/disapprove of the changes, or has an alternative way of tackling the same issue, Contributors A and B are expected to talk it out, and either realise that one of them are wrong and accept the others suggestion on it's technical merits, or work together to find a satisfactory compromise. Then those changes end up accepted, SUCCESS - END
4) If Contributors A and B can't resolve their differences, it could be argued that the 'dispute' at this point is no longer 'technical' but has become personal - in which case the case (the disagreement between A and B) could be escalated to the current Board for mediation - we'd step in to calm waters, build bridges, and try and get the two contributors to find a solution that satisfies them both - The Board would be be motivated to resolve the 'personal disagreement', still leaving the 'technical' side of things to hopefully be resolved by the contributors in question, as they are likely to know far more about the technical topic at hand than the members of the Board
Now, I do realise the picture I paint above is utopian, but I can't think of any cases in the last year where the Board were called in for a scenario like I describe in 4, which leads me to think steps 1-3 are probably 'mostly' working. That's not to say I don't see how a 'technical' escalation point might be a good idea, but that is the logic of our current setup, and I personally think it has its benefits. It places very few barriers infront of our contributors to hold them back from making changes, and encourages team work and collaboration when technical 'clashes' occur. It also places a responsibility on our contributors to find the best technical solution between themselves. There is a bias in this model towards 'change', which I think is a good thing for a 'developing' distribution like current openSUSE and proposed future Factory, but that bias does have the downside of upsetting those (both technical and non-technical) who advocate 'don't change X' and can't offer an alternative/better way of changing X. Of course, if we end up having improving/stabilising Factory cover the 'we want change' crowd and change our openSUSE release schedule to cover the 'change less often' crowd.. then do we really need some group to escalate 'technical' issues too? I'm not so sure..
-- Agustin Benito Bethencourt openSUSE Team Lead at SUSE abebe@suse.com -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org