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

[Michael Niedermayer]

On Mon, Oct 11, 2010 at 11:32:41AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Mon, Oct 11, 2010 at 7:23 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > 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
> 
> Before I give my opinion I would like the current root team (including
> Mans) and members of our project that have shown significant interest
> to co-root (e.g. Vladimir) to give their opinion on this list of
> requirements and in general what you'd expect the work and rewards of
> this (voluntary) job to be.

Id also like to repeat that this is just a suggestion that we can change based
on comments from people who would like to be / are root. And that
part of the list is roots ability to delegate any of these duties/rights to
other volunteers, that is people who might be deeply involved in the project
but the root behind such delegations is responsible for their actions

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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- 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/c6236f3e/attachment.pgp>