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

Re: Questions for the candidates

On Mon, Mar 04, 2002 at 08:24:01PM +0100, Marcelo E. Magallon wrote:
>     With that as an starting point, do you have any opinions regarding
>     this topic?  Do you regard Debian as an "open enough" organization,
>     or do you think there's room for improvement?

Both.  The level of transparency has to be balanced against the amount
of labor required by the participants to achieve that transparency.  A
lot of times, things get done in our Project just because someone
decides to roll up his sleeves and do it.  I don't want to erect
bureaucratic walls to impede that.

I think that for the most part Debian has earned and deserves its
reputation for openness.

However, there's always room for improvement.  What I think is lacking
is not so much open discussion forums -- or the use thereof -- for the
implementation of technical solutions, but of public, accessible,
advertised, and structured documentation of some of these solutions.

A lot of stuff we do, especially our internal processes, are documented
on an ad-hoc basis in a single email posting on one of several different
lists, or not documented at all.  For example, I had a dispute with the
Technical Committee a while back over whether it was acceptable for an
.orig.tar.gz to be re-uploaded with different contents (a licensing
problem forced me to change it).  A majority of the Technical Committee
felt I was stupid for attempting to do this, because the package pools
system was designed in such a way that you can't (and not without some
justification).  The biggest problem I had was that I couldn't find
where this was written anywhere.  You could do this sort of thing before
we had package pools, and all of a sudden you couldn't.  I was chastised
for taking advantage of an undocumented feature in the past, but I still
perceived this as an interface change -- as a package uploader, I was
putting my packages in the same old place, using the same old
techniques, and had no expectation for formerly legal uploads to be

This is the sort of thing that documentation was born to solve.

So, in my opinion, it's not so much that we don't take advantage of our
open forums to practice brainstorming and development, but that
sometimes we do our fellow developers a disservice by failing to
document what we do, or failing to ensure that our documentation is
known about and accessible.

In turn, this problem can be blamed on a needlessly high amount of
friction involved in making documentation available.  I don't think
people deliberately fail to bring their cool new tools -- including
their caveats -- to people's attention.  I think we're missing a
mechanism to make it easy for them do so.  As I mentioned recently in
debian-devel, I'd like to see more usage of debian-devel-announce for
this purpose.  It might also be a good idea to explore what we can do
with http://www.debian.org/devel/ to make it an even better resource for
our developers.

I think there are people with sufficient talent and motivation to
accomplish the above; there just needs to be a bit of an organizational
effort, and that is one of the primary duties of the DPL, in my
conception of the job.

>  2. Historically Debian has had project leaders varying between two
>     extrema: those who were very vocal and could be seen constantly
>     participating in a productive way in several internal and external
>     fora and those who tended to take part in discussions to make
>     succint statements regarding their opinion of the subject at hand.
>     Between these two cases, what kind of leadership do you foresee
>     yours to be?

I think the DPL should only try to do -- as DPL -- that which the
Project isn't managing to accomplish on its own.  The best thing the DPL
can do is identify the people with sufficient talent and motivation to
accomplish a given task, and encourage (or authorize) them to do so.

Expecting the DPL to single handedly solve several major problems at
once asks too much of the office, and belittles the skills other

I think the DPL should:

A) Match technical/procedural problems with the people that can solve
	1) Identify problems that aren't being solved;
	2) Identify one or more individuals capable of solving that
	3) Invite and empower the people in 2) to handle 1);
	4) Ensure that the people in 3) have what they need to deliver a
	5) Accept and implement that solution unless there is a good
	   reason not to.

B) Identify areas where the Project is stalled due to heavy,
irreconcilable contention: this means drafting and submitting a General
Resolution to break the deadlock.

C) Evangelize and represent Debian to the rest of the world.

I do think the DPL should not hesitate to involve himself in technical
discussions or project teams such as those described in A) above;
however, the DPL should participate in such project teams as a member,
not a leader.  Otherwise, he's not delegating.

There may be a task from time to time that the DPL feels very strongly
personally invested in, and should not delegate; however, he (or she)
needs to be sure that his approach is going to be acceptable to the
majority of developers.  Otherwise he risks provoking dissent, or having
his work overturned by a General Resolution.  This is why I think it's
best if the DPL delegates.  There shouldn't be shortage of people in
this project that the DPL can trust to make good decisions.  If there
is, then I don't think he can be truly representative of Debian.  Being
DPL means having respect for the people who elected you.

G. Branden Robinson                |
Debian GNU/Linux                   |           If ignorance is bliss,
branden@debian.org                 |           is omniscience hell?
http://people.debian.org/~branden/ |

Attachment: pgp7JOy2hefo4.pgp
Description: PGP signature

Reply to: