[MPlayer-dev-eng] [RFC] roots duties and rights

[Luca Barbato]

On 10/11/2010 01:23 PM, Michael Niedermayer wrote:
> Hi
>
> Attila asked me to start a discussion about what duties and rights root should
> have.
> What things people have to provide for the various requests. What they expect
> from root and so on.
>
> also please keep both ML in the CC in case of replies

> Heres a quick dump of /dev/brain
> Duties:
> * Keep the system running smoothly so all "users" can do their work.
>    -Keep the system secure so its not hacked
>    -Recognize problems early and take preemtpive action, aka a mail to
>     the MLs with "we only have 100 mb space left in incoming" for example
>    -Replace hardware when it fails, search for possible donations on ML/IRC
>     ask the foundation to fund hw where needed.
>    -Install security updates quickly
>    -Make regular backups and store them off site, keep past backups so
>     undetected corruption does not make them useless
> * Do all the administrative things that normal users dont have the right to
>    and that havnt been delegated to volunteers.
>    - Create mailinglists that are related to the project when requested by the
>      project leader
>    - Open and Close SVN/GIT accounts if requested by the project leader (root can
>      not reject such requests)
>    - Install software that is requested by project members for their work with
>      the FOSS projects
>    - Open SSH accounts for project members when their FOSS-project related work
>      needs such account
>    - help with forgotten passwords after the user proofes his identity
>    - Root shall attempt to work on requests approximately in order and not ignore
>      requests for months
>    - Root shall in case of ambiguity of a request ask instead of guessing.
> * Have plans in place for total hardware failure (fire / earthquake / ...)
> * Have plans in place for the system being successfully hacked
> * Root must not involve itself deeply in any of the hosted projects, that is
>    to ensure roots impartiality and avoid conflict of interest
>    This conflict of interest exists both in form of making decisions as root
>    to favor ones personal preference in a project. As well as participating
>    in project internal discussions while implicating ones authority.
> * Each project shall have its own incoming directory and who has access to
>    move and delete files from this directory shall be the project leaders
>    decission. Its each projects duty to move files out of there.
> * Root must have public GPG keys and they must be published where users can
>    easily find them. These keys checksums must be available in SVN/GIT of the
>    hosted projects so that people who work with the code have means to verify
>    roots (and the developers) public GPG keys.
> * Root must before expiration of the previous SSL key either generate SSL keys
>    signed by an upstream CA or put self signed SSL keys signed with their
>    gpg key on the webpage and ML
>
>
> Rights:
> -Reject software installation when there is risk to the security or stability
>   of the server
> -Root may resign, in which case new candidates shall be found and a vote
>   amongth all developers who had write access prior to the resignation shall be
>   held. The project leader of each project has a veto right against candidates.
>   This veto right is necessary as root is a service provider and not a power
>   position and if one asks for candidates for root the most power hungry people
>   in the projects come forward. And it is also important that root is trusted
>   by all, more so than root being the one with the prettiest face.
> -Like everyone root can be busy with family, military, jail, girls, pizza,
>   flamewar
>   in which case it is understood that root cannot attend to their duties for a
>   while. But its expected that the roots at least try to have 1 person of them
>   reachable by some means of communication within reasonable time intervals
>   who has then some kind of internet access within reasonable distance in case
>   of emergencies.
> -Root may close an account if
>   -(ssh) the account appears unused since a long time and the user doesnt
>          awnser email/ML. For project specific accounts like SVN/GIT the project
>          leader makes the decision about closing.
>   -(any) There is reason to believe that the account is used by someone else
>          than the intended user without his agreement and knowledge.
>   -(any) The account is used for criminal or malicious activity
>   -Root shall if there is no immedeate danger and there is doubt about the
>    malliciousness of someones activities try to contact that person before
>    account closure to confirm that there really is no misunderstanding and a
>    legitimate intent.
> -Root may temporary disable any service if its misbehaving in a way
>   that causes harm like a ML sending hundreads of mails, ftp being used for
>   warez, ...
> -Root may ban any IP, IP range if accesses from these ranges have happened
>   that cause unreasonable stability, security or bandwidth issues.
> -Root may reject requests that are unrelated to the FOSS project from which
>   the request is made. Root of course should not unreasonable do so but be
>   nice unless there is a reason to reject (like bandwidth, space, time ...)
>   root should elaborately explain such rejections to the requesting user
> -Root may reject any request that is missing needed information, that is
>   root does not have to go hunting missing details that the user should have
>   provided.
> -Root may delegate any work/rights to other people of roots choice but root is
>   fully responsible for that persons actions. Such delegations must be made public.
>   root may revoke any such delegation without specifying reasons at any time.
>
>
> Duties of the users
> -If the user has reason to belive that ones pland action could affect other
>   users or the stability or security of the system then he should contact the
>   public mailinglists or root first and or the affected users if its just one
>   user.
> -Shared files (like incoming and samples) should not be moved or deleted
>   without prior public dicsussion on the mailinglists
> -Users shall try to provide all information root needs when making requests
>   -For Mailing list creation ML name and ML admin email are needed
>   -For creating of SSH accounts a public SSH key and wanted username must be
>    submited by secure means
>   -For recovering a forgotten password proof of identity and the username is
>    needed

Given the current list of roles and duties, I found missing the part 
regarding "Leader" and other side roles, given the current discontent 
among volunteers, it might be useful state them as well.

Leader:
- He is a developer, thus ALL the developer rules apply to him
- During discussions if the outcome is uncertain he has the last word.
- He can ask root to do administrative tasks (e.g. manage accounts)

Maintainer:
- He is a developer, thus ALL the developer rules apply to him
- During discussions regarding his area of influence, he has the last word.
- If the Leader and the Maintainer during discussion cannot agree, the 
Maintainer decision takes precedence.
- You can have a hierarchy of Maintainers (e.g. libavcodec -> single codec)

Developer:
- He has commit access to the common trees
- He can be a Maintainer for a specific area of the project
- He can be the Leader for the project
- He agrees to respect the project policies and rules.
- He proposes patches or patchsets that are approved either by the 
Maintainer or the Leader

Agreement Not Reached:
- The discussion lasts more than a week w/out a definite outcome.

Leader and Maintainer roles are agreed by the whole group of developers.

Key ideas: the Leader is a primus inter pares, so the Maintainer within 
his area, Leaders and Maintainers should strive to not to stomp over 
fellow Developers. Root are developers with more duties. A Release 
Officer is a Maintainer. The Maintainer is assumed to have a deeper 
expertise than the Leader within his specific field, thus his opinion 
wins if agreement could not be reached.

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero