[GenABEL-dev] GenABEL governance: inclusion of new packages

[L.C. Karssen]

Dear list,

In light of Yurii's recent mail on the possibility of another project
joining the GenABEL ecosystem the following ideas and questions came up,
which I'd like to discuss here. 

The situation:
I) In the past year or so the GenABEL project has moved from a central
management structure around Yurii towards a more community-oriented form
of management. 
II) With the increased openness and visibility of the GenABEL project
more people might become interested in incorporating their package into
the GenABEL project.

My questions:
I think it is in the interest of the GenABEL community to define a
policy on how to deal with projects that want to join GenABEL. Questions
that I think need to be answered are:
1) Which licenses are acceptable?
Only GPLv2 or greater? Apache? LGPL? 
2) What criteria do we use to judge the quality of the code that comes
into the project? 
Most of us are scientists and we are good a solving our immediate
problem, but making a solution that works for everybody is usually not
our kind of thing.
3) Do we enforce certain coding standards and documentation?
What do we expect in terms of formatting of the code, the way to deal
with defaults, a separate file for each R function, etc.? Again, many of
us are scientist and not software developers, so what do we do with
sloppy code that is difficult to debug?
4) How do we ensure that packages are kept up to date by their
maintainers? 
Without a policy it may be too easy to just 'dump' the code in the
GenABEL project. For example, people without a firm understanding of
open source development might be tempted to think that 'the community'
will take care of fixing bugs in their packages so that that burden is
not on their shoulders anymore. This would degrade the overall quality
of the GenABEL brand. 
5) Where does the responsibility of a package maintainer ends and where
does that of the GenABEL core team start? 
For example, do we want to enforce all packages to conform to a common
fixed release schedule? 
6) How do we enforce the decisions that have been agreed upon? 
If a package maintainer does not reply (at all or in a timely manner) to
requests, serious bugs, etc., will the package be removed from the
GenABEL project? What to do with abandoned packages?

One way to deal with points 2,3 and 4 would be to assign mentors to new
project that can help new projects to adapt. 
Points 1, 5 and 6 can be resolved by discussion on this list, but when
the number of active members grows we might want to go for a community
council (with e.g. annual election of the members) to deal with these
issues. Or maybe an agreement can be signed (electronically) which
states both what the GenABEL community expects from the new package
maintainer, but also vice versa, what do we provide to (prospective)
packages. 

I'd love to hear other people's opinions on this. 
Did I forget something, do you consider this a non-issue or a limitation
on the autonomy of the individual package maintainers? 
Would such a formal structure scare them away? 
Would you like to be a mentor?
Would you be in favour of an 'incubator stage' in which a new package
remains until it reaches maturity in terms of our standards?
Or do you think my proposals are too far-fetched and should we leave
these matters to Yurii? 


Hoping for a good discussion,

Lennart.

-- 
-----------------------------------------------------------------
L.C. Karssen
Utrecht
The Netherlands

lennart at karssen.org
http://blog.karssen.org

Stuur me aub geen Word of Powerpoint bestanden!
Zie http://www.gnu.org/philosophy/no-word-attachments.nl.html
------------------------------------------------------------------