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

[L.C. Karssen]

Dear list,

Of course I have my own opinions on the matters that I brought up in my
previous e-mail:

1) Licensing. I prefer to have all packages under the same license,
preferably the GPL. Whether v2 or v3 is something I'll need to look into
a bit deeper. I prefer the GPL because of its copyleft nature, making
money with GenABEL (or a spinoff) is great, but as a return I'd like any
changes to the code to become public and for everyone to enjoy. 

2) Code review of prospective packages: We should take this seriously.
Especially for small packages of inexperienced developers. This is where
the incubator stage together with mentoring will be helpful. 
For larger packages that have survived on their own for some time, this
is more complicated and time consuming. However, also for these packages
I think we should strive for the standards as laid out in the next
item. 

3) Code quality. This is a tricky one. From a management point of view I
want to see clean code that is easy to maintain and well documented,
especially since many of the GenABEL packages are somehow
interconnected. On the other hand, most of the packages in the suite
were not written by professional developers and adhering to strict
standards might scare maintainers of valuable additions away. And let's
not forget that our present code base could benefit from some polishing
here and there.
My proposal is:
- each function (or set of closely related functions) in a separate file
- roxygen documentation for both the package and its functions
- at least one example per package, preferrably more
- (unit) tests for at least the main functions of the package.
- I'd love to see an official release process for each package with
alpha and beta test stages, but I don't think that is feasible at the
moment. Hopefully the unit/regression tests will save us from too much
trouble. 

4) Maintainer responsibilities: We should communicate very clearly on
this point. This can be part of the mentoring process. 

5) Responsibility of maintainers vs. GenABEL core team: At present I
think this is not an issue, so far the community is small enough and
people know each other well enough to resolve any issues. I'm not in
favour of fixed release schedules. 

6) Enforcement of decisions: As in point 5), I think this is not yet an
issue. But I do think that we should communicate clearly that we will
remove packages that are below standards and/or have not received proper
care from their maintainers. 

All in all I think we are in good shape, but writing a set of guidelines
and standards is necessary. Furthermore, I think it is good to set up a
mentoring program and incubator stage for new member packages. 


Best regards,

Lennart.


On do, 2011-10-20 at 18:18 +0200, L.C. Karssen wrote:
> 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.
>