Questions for DPL candidates: casting the lead to fathom our course
Hi all,
There are some talking points I'd like to hear the candidates talk
more about before deciding who may have the best chance of acting
in ways that improve our project as a whole, so to set the scene:
Recently there have been a number of discussions on the merits of
raising raising the technical requirements for Developers in the
keyring, vs' lowering or otherwise altering them. Likewise there
have been discussions on the level and manner of social skills
that should be expected, even demanded, from that group.
Neither of these are new topics, though the environment they exist
in and the need to assess them more thoroughly is certainly changing.
If the candidates cast their minds back to the time when most of
them first got involved with the project, you'll probably recall
the process was mostly self selecting then. That is to say, that
if you'd: a) discovered Debian, b) discovered it was interesting
to you, c) been able to do something useful for yourself with it,
d) been able to do something useful to others with it, e) survived
the bugs reported against whatever you did. Then you were pretty
much a shoe-in to be welcomed into the keyring and given upload
privileges. Even if there was no-one living remotely near enough
to you to verify your identity in person.
It seems fairly self evident that this system has produced some
extraordinary results. But its likewise clear that we have
outgrown it as a viable mechanism for expanding our developer base.
You could say that the project has had its growth spurt and reached
puberty. For those not fond of anthropomorphisms, we can use this
definition:
2. (Bot.) The period when a plant first bears flowers.
The result of that, and our growing popularity with eligible users,
is that points a, b and c above are no longer really a measure of
anything except perhaps genuine ignorance to the state of the
industry, and the bar for d has been considerably lowered given
the number of 'loose ends' that any software project accrues, which
don't really require the time of a highly skilled developer, and to
be frank, often have a hard time winning the time of such people.
(to be fair, because its usually already spread thin on 'hard' issues)
Some years back now, the DAM's of the day announced they would be
suspending the processing of NM applicants while we figured out how
to deal with this change to our environment, and likewise to the
type of people presenting themselves as applicants.
Rather than listening to that advice, a number of movements were,
well, put into motion, to instead _accelerate_ the number of new
applicants that the project took in.
Causality is always a tricky thing to put your finger on, but since
that time, it seems fairly clear that we've experienced a rise in
both social troubles, and, more importantly IMO, the number of
technical issues that people have tried to force through social
mechanisms (ie. a majority vote on a GR) rather than by building
consensus on the most technically optimal solution for all
interested parties.
So... with some background now in place, and given that some of
the candidates have proposed in their platforms that we further
accelerate the processing of NM applications to include people
in the keyring, and that some have indicated their main reason
for running is to increase the 'clout' of their own personal
opinion on certain matters they don't feel they can manage
through consensus building between equals, I'd like to hear the
opinions of the candidates on what they think is the best way
for us to manage our future growth in a sustainable way, without
sacrificing our original dedication to technical excellence
and developer freedom above all else.
Now that we have collaborative tools such as Alioth, which
allow any developer to allow anyone they deem fit to have
direct commit access to their work -- and leaves the ultimate
responsibility for what happens there to that developer or
team of developers who make signed uploads to the disto,
do we still have the same pressures on filling the keyring
with as many people as we can, as fast as we can -- or should
inclusion in it be perhaps even more limited to people who
have proven their judgement for what belongs in the archive
at any point in a release cycle and what does not?
How do you think that moulding our membership in this way
might effect our ability to better regulate our release
schedules in the future, given that screwing up something
which holds up a release and understanding what and how
you screwed up is the general prerequisite for more reliably
not doing so in future?
Do you think that increasing the number of people who've
never been through a full release cycle for each new release
and having those people actively uploading while we try to
prepare one will make the job of RM as it currently exists
an increasingly intractable one? Or should more of the
responsibility for determining release worthy-ness be
shifted to the developers sanctioning new uploads?
Should we even freeze admission of new people to the keyring
while a release freeze is in progress, assuming (and this is
just an assumption on my part, I'd be interested in seeing
some serious analysis to back this up before it was acted on)
that they are the most likely to be uploading new packages
with new bugs at a time when that is least desirable.
Do you think that (in a somewhat perverse way) this would
encourage more of the people in the queue at that time to
help accelerate the release? Do you think that would in
turn promote a new era of 'self-selection' from some of
those applicants?
Do you think we should be continually raising the bar of
skill required as the project as a whole refines its best
practices, or should we be lowering it to match the average
level of people now interested in contributing as our mass
market appeal grows?
Lastly, and in the context of all this, how do you see that
the role of DPL must change to keep it relevant to an
increasing body of volunteers that cannot in fact be led by
simple proclamation from the top. We've seen numerous times
now that a DPL (or GR) which insists on something that is not
backed up by consensus only leads to increased divisiveness
in the project and less real work being done by those who's
opinion has been ignored or defiled. How can we keep this
role as one which guides us all through the clear water at
the crucial points of navigation and avoid the politics of
casting some people up on the rocks just to find out where
they are? Especially when the role is mostly symbolic and
its holder is only able to make small course changes before
people start falling overboard en-mass or plotting a course
of mutiny...
Ok, that's more than enough from me (perhaps more than some
even put in their own platform ;), so it's your turn now...
Impress me ;-)
Ron
Reply to: