[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Reforming the NM process



(Please CC me on replies as I'm not subscribing the list.)

I'm currently at the "prospective NM" stage, trying to get my work into
Debian.  That should give quite a different view from Marc's on the
whole subject...  Of course, I may say stupid things because of my lack
of experience with the NM process, so please treat me in a friendly way
:)

First of all, I think open source is primarily about two things --
freedom and education.  This is important because in my view, the NM
process should be the _main_ concern of the Debian project, and
currently, it is also the one with least freedom.  Applicants in
different stages of NM are generally unilaterally dependent on other
people's goodwill and available resources.

People in Debian sometimes mention the possibility of the existence of a
cabal (or many such).  They usually attribute cabal-like qualities to
groups that have power and give insufficient information about the way
they work.  But lack of transparency is just the tip of an iceberg.  In
my view, every time somebody is dependent on the attitudes of a given
group of people, there is a "cabal" there.

Take sponsors, for instance.  What does it tell about your package that
there are difficulties finding a sponsor for it?  Well, nothing in
particular: it might be that the people doing sponsoring are busy, or
that there happens not to be overlap between the group of possible
sponsors and the group of people interested in that software.

Open source is about realisation of one's _own_ passions, work done for
one's _own_ ideals, to "scratch a personal itch", as they say.  By
requiring the packaging and making available of open source software to
be a hierarchic, rigid process, we are essentially taking that freedom
away.  One could argue that an OS project like Debian is essentially
different from building software in that everything in Debian should
work together nicely without disrupting each other's operation.  But
similarly, software is build on and around a common set of guidelines,
and distributed freely, without any kind of "pre-approval" community.

The central problem and the only justification for the current
procedures is that of establishing trust.  I just fail to see why we
trust our packagers _less_ than the upstreams they are packaging for.  I
doubt many of those pieces of software ever receive the close scrutiny
that the packaging work does.  Nor do I think that the trouble of
finding a sponsor will encourage people significantly to improve their
packaging, any more than it would help software developers to
significantly improve their software if they had to receive the approval
of a council to upload their software on FTP/WWW sites.  I've received
valuable support and feedback on debian-sponsors@l.d.o but I haven't
been able to find a sponsor (that would also really upload my packages)
yet.

I think the Debian project should adopt a totally different approach to
trust.  The BTS is open to external contributors; why isn't the software
archive?  The documents are open to external commentary; why isn't the
voting process open?  If somebody is interested enough in the Debian
project to get one's key to the ring, why won't we instantly allow that
one to participate in the decision-making of the project?  And if
somebody's abilities are on the P&P and/or licensing front, why do we
require them to make technical contribution in order to get their key to
the ring?

Sometimes it's handy to divide people into two groups, "trusted" and
"not trusted".  But given that DD's are not really trusted after all
(there are a lot of smaller, tighter cabals doing QA, like the
ftpmasters), I'm having trouble seeing the value of this approach.

Furthermore, it seems unfair that NM's have more stringent requirements
than existing DD's.  For instance, NM's must invest their time in pseudo
P&P work, while DD's only need to do "real" P&P work (such as checking
licenses, discussing proposed policy updates, and proposing resolutions
/ amendments to resolutions of the foundational documents).  Also, low
responsiveness is taken to be a right of a DD for granted, while low
responsiveness of a NM is taken to be very bad.  A DD need not get
anybody excited about their software to get it into the archive, while
NM's (and prospective NM's) are instructed on how to "make their
software appeal to potential sponsors".  DD's can be known for their
lack of social skills and still receive a fair amount of respect for
their technical work, whereas NM's will have a very hard time getting
technical work done if they're short on social skills.

On Tue, Apr 11, 2006 at 06:40:34PM +0200, Marc 'HE' Brockschmidt wrote:
> 1.1 Known problems

Let me add that the pre-NM process also has problems.  They are probably
not so much problems from the point-of-view of AM's (since they need not
get involved with that process at all), but when somebody enters the
lengthy NM process, they may already have a lot of frustrating searching
and futile attempts at contacting people.

> 1.2 Already proposed solutions
> 1.2.1 Add more people

I think one of the most important responsibilities of a DD, currently,
is participation in the process of bringing more people in.  Of course,
Debian needs those people, but even more importantly, people need the
technical, political and philosophical expertise of Debian.  The open
source movement (together with its associated, free information /
creative works movements, as well as the political self-organising
communities movements) need new people to prosper, and the only way to
achieve that is to educate people.  The act of teaching not only
benefits the trainee, but also the trainer.  A proper teaching procedure
will deepen the understanding of both parties on the subject matter.

> 1.2.2 Fewer checks

Rather, the gratuitous P&P work should be replaced with real work:
writing guidelines and documentation, checking the compatibility of
licenses and commenting on upcoming changes in laws / broadly used
licenses.

> 2. Possible solutions
> 2.1 Multiple advocates
> 2.2 Requiring (more) work before applying

As both of these just move work from the NM process to the pre-NM
process, I wouldn't say they really "solve" anything but the inordinate
work burden of the AM's.  But because of the core of that problem, in my
opinion, is the passivity of existing DD's, this seems to me the wrong
way to go to solve that.  Even the work spent on people that won't
become DD's is not thrown away; it is valuable for the dropped NM even
if (s)he was dropped, and if the NM process was not so dull for AM's, it
would be valuable for them, too.

> 2.3 Separate upload permissions, system accounts and voting rights

I'm all for this.  Furthermore, every one of these rights should be
examined to come up with a system that would allow granting that right
with minimum effort and risk of abuse to maximum number of people.

For instance, for voting, I think the process of establishing the
identity of one's PGP key should be enough.  If Debian wants to continue
as a technical meritocracy, the votes could be weighed with the "amount
of contribution" that person has done for Debian.

Another example is that there should probably be many archives and/or
the packages in the archive should be tagged for their "in-going stage",
and _anyone_ should be able to upload to the least-trusted stage.  The
packages could be transitioned to next stages (somewhat akin to the
unstable->testing->stable transitioning) automatically or
semi-automatically when they've been used long enough, by enough people,
or a given degree of quality (possibly assessed from bug reports) has
been achieved.

The system accounts, on the other hand, should probably be given only
for people who need them for their Debian-related work.  They should
probably also be further divided into VC accounts, mail accounts, web
page accounts etc.  I, for instance, reckon the only thing I'd need as a
DD would be an @debian.org e-mail alias for my real account, nothing
else.

As a summary, I'd like to eradicate any mechanism that works against
people wanting to contribute to Debian.  The mechanisms of establishing
trust must be there, but they'd better be something else than a binary
separation of people into cabals and outsiders, preferably based on
merit in different areas of expertise.

Panu

-- 
personal contact:	panu.kalliokoski@helsinki.fi, +35841 5323835
technical contact:	atehwa@iki.fi, http://www.iki.fi/atehwa/
PGP fingerprint:	0EA5 9D33 6590 FFD4 921C  5A5F BE85 08F1 3169 70EC



Reply to: