[GenABEL-dev] The GenABEL project fundamentals: post #3

[Yurii Aulchenko]

Here is post # 3 about 'fundamentals'.

best wishes,
Yurii

-------------------------------
The GenABEL project's governance

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.