28 Sep
2006
28 Sep
'06
11:19 a.m.
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