Governance revisited (Wineconf report)

[Robert Lunnon]

On Thursday 21 September 2006 07:09, Dr J A Gow wrote:
> After having followed this thread for some time, I feel that there is an
> aspect that is often missed in the debate.
>
> As I see it, it would appear that Wine contributors fall into essentially
> two camps. There are those who develop Wine for Wine's sake. This category
> includes the core developers, and others who just feel strongly about a
> particular aspect in order to improve it and perfect it. These people have
> time to spend developing and perfecting their code to meet the necessary
> high standards for acceptance and would not see the current system of
> governance to be an issue. These are the very people that would attend
> Wineconf and discuss the issue!
>
> There is another category, however, and I suspect it is the larger of the
> two. Some people simply need to quickly fix an aspect of Wine in order
> simply to get an application working. These individuals, a category into
> which I fall, are driven by a very different motive. To take an example, my
> (very) small contribution to Wine was driven by the need to get a
> commercial ECAD application running, so that I could continue to use the
> application as a production tool on a production system in order to
> continue to function as an electronics engineer. In my case, I am also a
> software developer who believes in feeding useful fixes back to the
> community, so I used up some of my valuable free time and got the patch
> accepted. It took approximately three times longer to get the patch
> accepted than it did to fix the problem in the first place!
>
> I persevered, but I wonder how many other individuals who fall into this
> category would do the same? Another contractor driven purely by commercial
> pressures may have just got it working and kept the fix in their own tree.
> Such people do not have the free time or the inclination to go through the
> numerous iterations to get the patch accepted. Free time is a rare
> commodity these days, and most software developers will have other
> projects. These are not the people who would attend Wineconf and whose
> opinions can only be solicited through other means. How many Wine trees are
> there out there containing useful small fixes that see the light of day
> outside of the developers's box, simply because they do not have the time
> to struggle through the QA system. A number of these patches could be being
> lost to the community.
>
> How to capture these 'lost' contributions is a difficult issue. Maybe a
> centralized repository for patches could be maintained separate from the
> main Wine tree and with a very loose method of acceptance (maybe just
> ensure that it is clearly indicated what the patch is for and what version
> it can be applied to). This way it would be very easy for a contributor to
> place a patch somewhere where it is easily accessed by the community. A
> developer with more time who is interested in it may pick it up and clean
> it up for inclusion in the tree, but at least the patch is available for
> others to use, saving re-invention of the wheel.
>
> The quality of Wine is important, and a workable QA system is very
> necessary. However there should be a mechanism to enable widespread
> dissemination of contributions that for various reasons do not merit direct
> inclusion in the tree at that time and for which the developer has neither
> the time nor the inclination to do battle with the QA system.
>
> Just my thoughts.
>
> 	John.
>

Thank you Dr Gow, very insightful, but I don't think a technical solution can 
paper over what is actually a structural (and perhaps a behavioural) problem. 
Some Transparency would certainly help, but I don't think this is the whole 
answer.

Rather than harping on about the problem, let me make a few concrete 
suggestions for improvement. These ideas minimally affect Alexandre's status 
as maintainer, but add some structure to avoid the downside of the current 
governance model.

1. Publish the patch acceptance policy - Make sure this is the acceptance 
policy and not the patch acceptance process. The Patch acceptance policy 
should be developed by community process and be subject to change (and change 
control). Perhaps a standing wineconf agenda item here.

2. Adapt the patch acceptance process to create a right of appeal where a 
patch can be proven to be within the Patch Acceptance policy. Appeal should 
be independent of and binding on Alexandre - this eliminates one-to-one 
arguments about patch acceptability while still providing good excellent 
control.  It will also have the effect of reducing Alexandres workload.

2. Have a Wine Developers - Bill of rights - particularly preserve the right 
to dissent and disagree. To develop freely, most importantly It must 
recognise, as Dr Gow has so eloquently said,  that most Wine developers don't 
have any interest in WIne and must be treated as valuable volunteers. This 
has to be respected in the Bill of Rights.
 
3. Have a community process for properly handling process change.

4. Have a similar wine users Bill of rights - The users of wine need a say.

5. Have a community process for handling these requests according to the BOR.

This will do for a start.