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

[Michael Niedermayer]

On Mon, Oct 11, 2010 at 02:09:42PM +0200, Luca Barbato wrote:
> 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.

I think that is a bit off topic in this thread
especially considering the complexity of the subject and as the relations
between leader, maintainer and developers are each projects own private
matters while roots relations to the developers is a matter that affects all.
not to mention you must have written your list below in a few minutes given
the quickness of your reply i dont think thats really such a great idea, i
spent a day on my list about root.
Also the relation between developer/maintainer/leader belongs to each projects
policy. Changes to that should IMHO be proposed on the respective developer
lists

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20101011/348b4e95/attachment-0001.pgp>