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 [EMAIL PROTECTED] ========================================== 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
