Re: Proposal for a team of admins

[Olaf Till]

On Fri, Jan 20, 2017 at 10:23:31AM +0100, Julien Bect wrote:
> Le 19/01/2017 à 20:30, Olaf Till a écrit :
> >
> >1. organizing election based decisions, anything which is not item
> >    1., and decisions on:
> >
> >-- access issues
> >
> >-- categorizing packages (accepted/removed to/from controlled
> >    'section' of OF? maintained or unmaintained?)
> >
> >2. (assistance with) reviewing contributions of new controlled
> >    packages,
> >
> >3. at least formally reviewing releases of controlled packages
> >
> >4. formally reviewing releases of externally hosted packages
> >    (licenses, copied repository up-to-date)
> >
> >5. website managing, including backups
> 
> First a thought on shares 3 + 4 : I wouldn't treat these two as separate
> tasks.  I believe that both Octave Forge hosted- and externally
> hosted-packages must be judged according to the same set of rules at release
> time.

Sometimes more than the formal checks may be performed for 3. And
checking symbol name uniqueness (if we want it) would make no sense if
extended to external packages, since controlled packages should not be
prevented from using a symbol name only because an external package
has started using it before.

Even if there were no distinction it would not hurt to distribute
3. and 4. to two different persons. It's a matter of distributing the
workload.

> Another possible "share" would be the coordination of effort towards the
> creation of a database of "fully external" resources, which don't
> necessarily comply with the rules for being distributed as OF packages (as
> proposed in various forms by Carlo, Sebastian, Oliver...).  Even though I
> understand that such a database might become a separate project at some
> point, some initial impulsion would have to be given in the context of OF, I
> think.

This is a major issue and not covered by the previous vote on the
scope of OF. Since it is possible to vote on this later, it's probably
better not to complicate the current decision with it. We need to take
off somehow.

> * I have no intention of taking on my own a task such as "share 1" above.  I
> see this "share" as some sort of replacement for the role of "benevolent
> leader", which would have among other things to organize discussions on
> controversial issues and do this "community management" that Carnë talked
> about.  I am not volunteer for that.

> * It is not clear to me if this idea of a "team of admins" has any chance of
> happening.  Is there support for it in the OF community ? It's not clear to
> me.  Given the current "decisional model", it seems to me that the current
> leader would either to decide it (he is the leader, after all) or to set up
> some sort of vote for it.

I think most were fine with a team of admins. Yet, for any efficiency,
responsibilities should be fixed within the team. Carnë had the same
opinion:
http://lists.gnu.org/archive/html/octave-maintainers/2017-01/msg00088.html
. As for share 1, decision making can be distributed to more than one
member of the team (but 5 seems too much for decisions on package
status or access issues, and further decisions should rather be voted
on by the community (probably only 11 participants, currently!)). And
for everything else in share 1, the work should be assigned to a
certain person, or divided up and the parts assigned to different
persons.

> * If a different structure is proposed and adopted (for instance, along the
> line of what Olaf suggests), I will see then how I can contribute.  Perhaps
> as part of shares 3+4 and/or share 5.

I think we really must fix the responsibilities even for share 1. We
could subdivide it:

1.1. organizing election based decisions,

1.2. decisions on access issues and package categorization.


Share 1.1. is, more than everything else, a service, helping to
facilitate majority decisions. Performing specific votes could be
thought required if either a member of a "decision team" or at least
two package maintainers want them. It would be suitable if share
1.1. is done by someone who probably can implement some web instrument
for votes.

Share 1.2. could be done by a "decision team" of 3 persons.

It could (should?) be fixed that any decision can be superseded by a
vote.

It could be fixed that the team has to perform (after a final
discussion) a vote on the requirements imposed onto the different
kinds of packages. I wouldn't like to do that before choosing an
administration team, because of the delay, but of course that's also
possible.

I'll think about it, and wait a bit for comments, and then probably
propose a new subdivision of tasks ...

Olaf

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc
Description: Digital signature