Proposal for a team of admins

[Julien Bect]

Le 10/01/2017 à 14:58, Julien Bect a écrit :

I am co-maintainer of the (externally hosted !) stk package, and (more or less implicitely) the maintainer of the generate_html and gsl packages.

I vote for option 2.1.

OF is already, and should remain IMHO, a mix of self- and externally hosted packages (with a set of rules to maintain coordination of the OF package ecosystem as a whole).

More on this in a separate thread.

I take this opportunity to propose myself as one member of an "admin team" that would continue and expand the work that was done by Carnë.

I give below some details about my view of OF, and especially the "controversial" (quoting Olaf) issue of externally-hosted packages.  What I propose is in the spirit of option 2.1 in Olaf's email. Should any of the other options prevail, I would obviously not be volunteer for becoming admin anymore.

Concerning decision making, when needed: I think that things should continue to work as they already do: most of the time, decisions are made by reaching a consensus through a discussion on the mailing list.  Whenever a clear consensus can not be reached, the admin team (currently, the "OF leader") makes a decision.

Which is why I believe that the admin team should have odd cardinality.  I propose a number of 3 or 5 people, depending the number of people that will declare themselves interested (and in agreement with what I propose).

Based on the view he expressed in- and off-list, I think that Oliver (Heimlich) shares a similar view of OF, and I hope he will confirm that he wants in.  Who else would be interested?

I think that one of the firsts tasks of the new admin team (beyond handling pending releases ;-) will be to clarify the roles, tasks and permissions in the OF project, which is a prerequisite for a better distribution of the workload among a larger set of people.

Feel free to use this thread to propose your participation or explain why you like/dislike what I propose (some arguments have already been given elsewhere).

@++
Julien

-----

Concerning self- versus externally hosted packages

As I said above, OF already is de facto, and should remain IMHO, a mix of two types of packages:

a) Some of them have their main development repository within the OF project on SourceForge: optim, signal, image, etc.  Any OF dev can participate in their development and has read/write permissions on the main repo.  This is the "central development model".

b) Some of them have their main repository somewhere else (my own stk package, for instance ; or the symbolic package that Colin McDonals develops on github).  For these "externally hosted packages", we keep a clone of the repo on SourceForge, which is synchronized from time to time (at least when releases happens). They have to obey all the rules of the OF project (structure of packages, no duplication of function names, reproduicibility of build from source, etc.).  But if someone wants to truly get involved in their development, he has to go and ask permission wherever the primary repo is (or make a clone and then issue a pull request, demanding on each particular package's workflow).

I am OK with this way of doing things, and would like to push things a little further in this direction.  More precisely, what I propose is:

1) to acknowledge officially this "dual model" on the OF website.  Knowing that they can keep some control over their package while becoming part of OF might make it more attractive for package developers to contribute.

2) to clarify which package follows which model (perhaps will we find that there is a need to distinguish between more than two types of packages, but two is OK for a start);

3) to clarify the rules that OF packages must satisfy and, ultimately, to provide a tool to check these rules. This should help people to provide "OF-compliant packages", and help the admin team (or a larger release team, if need be) in the release process. I'm thinking of something like "R CMD check --as-cran" in R, with the associated documentation (http://r-pkgs.had.co.nz/check.html).

Among the set of OF rules that all package must respect, there should be "coordination rules" such as not having duplicated function names across packages.  Such rules are meant to preserve the coherence of the OF package ecosystem as a whole.

-----

Concerning releases

I am not in favor of giving to *any* package maintainer permission to handle its own releases.

However, should the admin team prove to be too small to handle the releases in a reasonable time, I would propose to create a "release team", which would be composed of the admin team together with a set of confirmed package maintainers.

This team would have the necessary permission to handle releases, and share a set of rules on the wiki (and, ideally, some software tool to check at least some of them automatically).