Joerg Jaspert wrote:
Developer Status
================
I start loving more this proposal.
Debian is about developing a free operating system, but there's more
in an operating system than just software and packages. If we want
translators, documentation writers, artists, free software advocates,
et al. to get endorsed by the project and feel proud for it, we need
some way to acknowledge that. This is where our proposal comes in.
Debian is mainly software and package, so a full (voting) member
should have some knowledge to our package system.
I have some fear about "free software advocates". We use
"we are technical people" to downgrade flames. In facts we are
technical people. I want more technology and less politics in
Debian. Let other organizations to do the most advocating
and political discussion. I don't want that we do task of EFF,
and I don't hope that OSI will not do distributions. Nobody
forbid us to be member of other organizations.
I think this is a major point to improve Debian: let give
Debian a small and more definite scope, and let do the
other works in upstream and/or activists organization.
Second point.
I don't like changes only to "acknowledge" other people.
Personally I trust some Debian contributors not because
they are DD, but because they are visible contributors
(in facts time to time I see that some of them was not
DD).
We want these changes to acknowledge some contributors, or
to speed up they contributions of such people?
I think that with such proposal we will not increase
contributors, but a better working structure for these people.
A new user can start out in two ways depending on their personal
preference. The first is the non-technical way:
Debian Contributor
------------------
A DC is someone that has a strong relation with Debian through the work
they are doing for/around Debian. Possible examples are translators and
documentation writers.
DC have to pass the ID check, agree to the Social Contract/DFSG and have
successfully answered a set of questions[DCDMQ] similar to the ones used
in the current first P&P step.[TEMPL]
I think this is the step one for all contributors: having a know
key would simplify also sponsoring and mentoring (which is the first
step also for DM).
Instead of a set of questions, I prefer some advocates to relevant
people (e.g. from i18n expert, from sponsoree, from team,...)
The second way is the technical one:
Debian Maintainer
-----------------
They are allowed to upload their own (source) package. The allowed list
of (source) packages to upload can be edited by any member of the NM
committee[NMC], who will do a package check before they add new packages
to the DM's list.
In contrast to current DM this is based on source packages and allows
uploads of new binary components, which have to pass NEW, too.
I agree in general, but I think the "power" should be defined by
ftp-master (type of uploads, NEW uploads, delayed queue, ...).
The NMC will give a "packager license" and eventually further
checks at request of ftp-master for other packagers.
After the 6 months time in Debian Contributor/Maintainer are passed,
applicants can apply to get Debian Developer status. There are now 2
different "classes" of DD status available, one with and one without
upload rights. To not add confusion we selected to name them "Debian
member" (no upload rights) and "Debian Developer" (upload rights).
Both are project members, i.e. with voting and all other constitutional
rights, the term "classes" does not indicate any kind of "first" or
"second" level membership.
Debian Member
-------------
A DME is someone that previously had DC or DM for at least 6 months but
additionally want to have voting rights or needs a login on a debian.org
machine for their work.
A DME can nominate themself as DPL, can be delegated rights from the DPL
and can start any GR, basically do everything our foundation documents
allow project members to do.
DME are not able to freely upload any package, but DME can have the same
upload rights a DM can have, ie. own packages, if they follow(ed) the DM
rules for this.
Following our Constitution ยง8.1.2, DAM declares that Debian Members are
to be treated as "Developers who do not maintain packages" wherever the
term "Developer" is used in one of our documents.
I think we don't need DME. I requires a minimum of packaging skills
(with debhelper it could be very easy, and IMO bugs handling skills are
necessary). We can do simplified tests: at this level we trust that
a person which is not comfortable with programming will not do
complex uploads. Why do we want to forbid a trusted person to do
trivial uploads, binNMU and helping other DD (e.g. without temporary
a working key) to upload packages?
I thyink that voting people must be trusted and responsible,
so no need to distinguish. We could expel the DD which do
frequently completely wrongs uploads.
contributor.debian.org mail
---------------------------
We are considering to implement an @contributor.debian.org mail
forwarding setup which would be open for DC/DM too. Such addresses would
continue to be valid even after a person becomes a DD/DME. If sufficient
support for the idea is found then this will probably be implemented
once the new debian.org mail setup is in place.
I don't like "contributor." we need a short term.
Changes to existing Debian Developers
I think that DD have not to have upload and machine access.
I.e. for sabbatical and MIA DD, I think we could restrict (temporary)
such power. So I think it is up to the ftp-master and admin to choose
relevant policies.
I.e. would it nice to default forbid access to debian machines, and
requiring an maybe automatic mail to allow access.
I use only few debian machines, so for security reason I really prefer
that all other machines are disabled.
Thus uploads and access to machines should be handled by technical
policies, by technical people.
I would also include in this proposal how to expel peoples, or that
project could temporary or definitely suspend some grants.
These points should be clearer, to reduce "discussions".
ciao
cate
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
