Governance revisited (Wineconf report)

[Steven Edwards]

Hello Robert,

I am an employee of CodeWeavers and one of the former project coordinators
of the ReactOS Project though my views do not represent either the position
of my employer or the ReactOS Project of which I am no longer actively
affiliated.

This thread was part of the reason I wanted to chair the governance
discussion at Wineconf so please don't think your point of view and others
are not considered. The question about governance has come up from time to
time in regard to several issues such as design decisions, development
methods and general patch submission processes. These issues collectively
have made me interested in the overall topic of governance and seeing if
there is a way we can streamline and or broaden the process.

On 9/22/06, Robert Lunnon <bobl at optushome.com.au> wrote:

> 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.


I think we all have agreed that Alexandre's rules for patch acceptance
should be more broadly stated on the website or wiki, as well as have a
system for first time contributors to be made aware of the rules and be
mentored on how to become a good Wine contributor. It has always bothered
me, the thought that someone might be submitting a patch for the first time,
only to have that patch go to the void for whatever reason and be turned off
to the project. For all we know that new developer might have turned out to
be a very active member of the project. It is my hope that the new
ambassador system we have proposed will help with this situation of getting
new developers up to speed and get more new patches in to the tree quicker.
In regards to making it a standing item, it already defacto is as we have
had a discussion about the process in one form or another every year. I am
happy to keep trying to tweak the process in the future.


> 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.


I jokingly referred to the discussion as the "off with his head" meeting at
Wineconf however we all came to the conclusion this was unneeded. It was in
fact Jeremy White that proposed having some sort of democratic system to
override Alexandre if we thought he was making some sort of mistake. It was
at this point I asked him and every other developer in the room to name one
time Julliard has been wrong on a technical issue. There are plenty of areas
of disagreement on the patch submission process and even some disagreements
on design decisions from time to time however even when there are
disagreements on design, it has never been shown to me where the situation
comes does to Julliard being wrong and someone else being right. If you can
show a pattern of patches rejected that clearly should have been merged then
I might agree with you and the rest of the Wine developers would also be
chanting "off with his head". As far as I understand the problem with your
Solaris patches recently, your had quite a large number of invasive changes
that were able to be corrected with some minor tweaking of compiler flags.
Clearly this is a disagreement on design rather than the merits of the
patches. If Alexandre were to ever develop a pattern of rejecting
technically sound patches for no damn good reason I assure you we would
revisit this discussion. As it stands right now the only reason technically
good patches have been rejected is due to concerns over reverse engineering
in another project.

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.


The developers have the right to disagree and we do quite often. However we
have mob rule with a benevolent despot and none of us really like to work
any other way. If the project demographics change and the developers decide
they don't like the system then, once again, we would change. Our governance
is ultimately that Alexandre rules at the consent of the governed and while
it can suck to be in the minority of mob rule from time to time, the mob
agrees to keep Alexandre as the benevolent dictator for life. I for one hope
this never changes as it seems to be the best system for making stable FOSS
software. I've been in projects that had full access to everyone to the tree
and seen the types of problems that result from development anarchy. The
Wine model is the best for a project of our size.

3. Have a community process for properly handling process change.


The process is whatever works best of Alexandre. See above. The trick is
finding ways to make him more effective and helping the community to be more
effective with him. His acceptance policies are his to decide as he pleases
as long as the mob has not overthrown him in armed revolution.

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


They do have a say in terms of contribution of time for testing, bug
hunting, donations, supporting companies and projects built around Wine,
etc. As a Wine developer I do not develop for the users. I develop for my
own needs and really don't care what the users have to say other than how it
relates to my job. I know it sounds cold but I am going to work on what I am
interested in when donating my time to Wine. Forcing the FOSS developer to
be beholden to the even greater mob of users is not the answer.

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

By being an active developer, you are a member of the community and well
within your rights to bring these matters up on wine-devel as you have done
or discussing them at Wineconf however if Alexandre disagrees he disagrees.
We have decided to keep the current system of governance and that does not
include a veto of him.

The idea of Dr. Gow in having a totally open forked Wine tree sounds
interesting but having gone through the X11 ReWind fork I do not believe
this will help the project. In fact I believe it would stagnate it and waste
the time of anyone working on such a fork. You would still need someone to
merge and manage conflicts when syncing to winehq which would require a
doppelganger clone of Julliard. I don't know of anyone else that thinks the
current process sucks enough, has the experience needed to do the syncing on
a daily basis and is even 1/10th as capable as Julliard when it comes to the
internals of Wine design.

-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and that is
an idea whose time has come." - Victor Hugo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-devel/attachments/20060922/6f20b1b1/attachment.htm