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.. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org