The GenABEL project's governance

by Yurii Aulchenko

At the moment, the GenABEL project effectively follows an open-politics "benevolent dictatorship" model. Who is the dictator? That's me (Yurii). This is not because I like it this way, but rather the way it functions now and how it evolved.

With a growing community, we can shift to different model. My dream is that in a few years time, I could retire from the dictatorship (or even from the project), and the project just goes on very fine -- this is something we stated implicitly in the mission statement ("robust" means no critical dependency on efforts of a single person). Technically, the GenABEL project can already do without me: any information is freely available (e.g. all code) and/or several people have it (passwords, admin privileges). But not really yet -- someone needs to be a driving force pushing the project as a whole, getting funding, paying the hosting bills, etc.

Ok, now from the bigger picture to the details. How decisions are made within the GenABEL project? Any idea I have, I first post at the genabel-devel list to be discussed. Some of my suggestions are supported, usually in modified and much improved (after discussion) form. Also during discussion, a team of volunteers is formed and things get eventually done. Some of my suggestions are ignored -- I never receive feedback. I take this as a sign that people think this is a low priority task and are not interested in whether this happens or not. If I still want this to happen, I post to the list, saying that I am going to do this using my own resources; if no one complains, I just do that. Some times the community does not support the idea. In such case, I summarize this opinion and drop the idea.

The same logic applies to suggestions mailed to the genabel-devel list by any other member. As the project coordinator, I feel responsible to always react, and probably my voice has a heavy weight. Also, I summarize the discussion at the end, and draw the conclusion ("go on", "not yet"). Some waiting time is always allowed for the people to give their opinion on the summary before actions are taken.

In short, I am dedicated to reach a consensus opinion about any idea. As project coordinator, I reserve the right to make a decision in case of split opinion, although I expect we can always arrive to a consensus. I thought of claiming the right of "veto", but the whole logic of the open community driven development makes this a bit of nonsense: if you go against the community, you are excluded from community.

This is it about the governance model.

Of course, not everything is discussed before actions are taken. For example, when I am adding a trivial functionality to the GenABEL package, of which I am the maintainer of, I let the devel-list know of the change post-factum, by commenting on the commit-mail. In contrast, if I intend to change some other package, I definitely need to discuss this with the maintainer and the rest of the community. The same concerns any bigger changes which may affect other packages depending on the GenABEL package.

Disclaimer. This is my personal position, which is open for discussion. In this post, I am not speaking on behalf of the GenABEL project community, but rather seeding the discussion, which will eventually set the project's broad standards.

I would like to thank Dr. Lennart Karssen for valuable and continuous discussion through which many of my views on the GenABEL project have evolved.