Governance Ideas - wine-devel

28 Sep 2006

      Alexandre said
=========================================
To be honest, I have no idea what it is that you are suggesting. All I
see is phrases like "community focused process" or "acceptance policy"
which frankly are just meaningless buzzwords. If you expect anything
to happen, you'll need to make much more concrete suggestions, and
provide examples to make us understand how what you are suggesting
would work in practice, and how it would be different from what we are
doing now.
-- 
Alexandre Julliard
julliard@winehq.org
==========================================

To which I said I would respond soon - well here goes. From the outset I want 
to say that I am not going to redefine the wine project or make suggestions 
in the sense of a particular change. I want the communities of developers 
users and others to define that change. What I will do here is suggest ways 
in which we could organise to make a change as a collective.

Firstly the buzzwords

"Community Focused Process" means what it says, develop a process which is 
centred on the community the project serves. This requires the project to 
answer some introspective questions

1. Who "owns"  Wine, does wine belong to A.)  Alexandre, or B) the community 
it serves.

2 If the answer is B then which community. It may surprise some to realise 
that a project like this has many communities. We discovered this when 
setting up the OpenSolaris community process. Some obvious ones are "The 
Developer Community" and "The User Community" and "Developer + User" 
Community. There are other less obvious communities, eg the community of 
distribution maintainers who may be neither developer or user. 

If we decide that the community "Owns" Wine then it needs to be established 
whether the community has a right to direct wine's development. As 
the "Owner" I'd argue the community should have this right.

Second Buzzword

"Patch Acceptance Policy" means the rules by which a patch is deemed 
acceptable or not. 

At the moment this is pretty close to "It's acceptable if Alexandre commits 
it" This is  OK in a community process as long as the community that wine 
serves supports this approach. I think the recent thread throws significant 
doubt on this. This particular patch acceptance policy is not Transparent, 
this is the key reason why dropped patches cause so much argument, why many 
developers leave the project and possibly why Wine doesn't get the major 
backing some projects do (EG Gnome, KDE Xorg) dealing with the wine project 
is risky business.

Now what do I propose...

1. Answer the questions about the "ownership" of wine and identify the 
community it serves. Determine the right of the community to be involved is 
setting wines direction IE The Bill of rights I mentioned before (for each 
community Developers VS Users etc).

2. Alexandre documents the exact logic he uses to determine patch 
acceptability which becomes the patch acceptance policy in the interim. This 
should be done to the point that someone else could take over from Alexandre 
and achieve the same result. This opens the way to multiple maintainers as 
well as allowing Alexandre to take more holidays.

3. The project develops a community process for establishing project direction 
and maintaining the patch acceptance policy which includes stakeholders 
elected from the "owners" IE communities with a stakeholding in wine

4. A community process is run to 

A.) Establish the communities objective for wine - this will actually probably 
be reasonably argumentative, but that is exactly how it should be. If it's 
not there is probably something wrong. It was with OpenSolaris and governance 
was the greatest concern with that project too.

B) review the Patch acceptance policy in line with the community objective. 
For example the policy may be adjusted to favour functionality improvements, 
or loosen gating on changes leading to solutions that wine critically needs 
or even  establish a "must have" application.

5. A mechanism is created to independently review patches (appeal process) for 
acceptability IE Whether a patch meets the acceptance policy. Note that if a 
patch acceptable to the policy is rejected then the policy may need to change 
(Requiring a new community process to review that change) or an architectural 
decision needs to be taken. This is done by the architecture review board in 
the OpenSolaris process. Among other things when a patch is sent to appeal 
the owner of the patch is guaranteed an explanation of how the patch doesn't 
meet the acceptance policy.

Now if we did all this we would

* Have a picture of the needs of the community
* Have a way to direct the project toward meeting that need
* Have a way to demonstrate we intend to meet that need
* Have a consistent review process for patches
* Have a way to multistream patches
* Have an open transparent, trusting and consistent environment in which to 
work
* Have a way to change and grow
* Open ways to allow business to confidently invest in Wine.

Even if we ended up with exactly what we have now we will have improved 
transparency resulting in higher quality of work and less resentment of the 
process, improving developer retention rates and reducing disputes.

Bob