Re: tb's questions for the candidates
* Thomas Bushnell, BSG <email@example.com> [2004-03-03 19:20]:
> A. What do you think is the greatest challenge facing Debian in the
> coming year? What would you do as Project Leader to try and meet
> this challenge?
I think I have covered this pretty thoroughly in the "My goals"
section of my platform
(http://www.debian.org/vote/2004/platforms/tbm). I think that the
first two points in this section are the greatest challenge in the
near future: fixing our release cycle, and improving communication in
the project, adding more transparency and adding more man power to our
core teams. Problems with our release cycle and with communication
led to increased frustration in recent months; people are getting
demotivated, they have the impression that Debian is falling apart.
I think these are the most important problems to tackle in the coming
year which is why I say in my platform that we have to put "extra
emphasis on the internal functions in the coming term".
Feel free to ask more specific questions based on my platform.
> B. What should the Project Leader's role be when Debian comes into
> significant and important conflict with other free software
I think it is very important to work together, and to resolve these
problems and conflicts. We are _one_ community, and we have to make
sure that this remains to be the case. I am also worried about the
"Free Software" and the "Open Source" communities drifting apart
further - there is an increasing number of licenses which are Open
Source compliant, but which fail to meet our DFSG. I think we have to
work together with other organizations, and not just on a technical
basis (where we're doing pretty well).
> C. Being the Project Leader is a major responsibility. What are the
> other Project-related and non-Project-related responsibilities which
> would compete for your time, and how would you manage that conflict?
Project-related: I lead the New Maintainer Front Desk, and I am
involved in various QA activities, mainly in tracking inactive
maintainers. I have shown during my first year as DPL that I can
handle these tasks while being DPL. Also, more QA people are getting
involved so that should reduce some work load.
Non-Project-related: I started a PhD about quality management in free
software in January.
Fortunately, my PhD and my activities in Debian overlap to some
extend. I have shown during the last year that I can work on Debian
basically full-time and yet perform my studies with excellent results.
I therefore see no conflicts or problems with regards to time.
> D. People become Debian Maintainers by a complex administrative
> process, involving three different folks who have to agree on any new
> Maintainer: the Advocate, the Application Manager, and the Accounts
> Managers. I'm not interested in the details of how this process
> works. My question is: Should the Constitution specify at least who
> has the actual formal approval over this process? In other words,
> right now it's not clear what the exact lines of authority are.
I think it's quite clear who the authority has. The constitution
(8.1.2) explicitly grants the rights of "including approving or
expelling Developers" to a delegate, and this delegate is the Debian
Account Manager (DAM). As such, the DAM has the overall
responsibility for the NM process, with assistance from the NM Front
The NM documentation currently available is quite complete, but rather
disorganized and not entirely up-to-date. A complete re-write is on
my TODO list (as NM Front Desk), and this re-write will better
document procedures for advocates, Application Managers and the DAM.
A few months ago, the DAM defined the process for DAM rejections quite
clearly. In summary, some procedures are quite well documented, while
others (mostly AM related tasks) are to some extend "learned by doing"
(under the supervision of the NM Front Desk). However, more
documentation is forthcoming, and a first step were my postings about
preparing good AM reports, see
To summarize: I think the constitution does not need clarification in
this regard, but more documentation about the whole NM process is
> E. Debian does not have a formal process for removing a delinquent
> developer. Should we have one? And if so, what are the sorts of
> things for which it would be appropriate to remove a developer?
Basically, (severe) violations of the DMUP are things which would lead
to the removal of a developer. I think a formal process would be
good, and I suggest it should be developed when there is a concrete
case where the expulsion of a developer is proposed (It would be nice
to formalize it now, but given that expulsions are extremely rare I
don't think the effort should be spent before there is actually a
concrete need for it. If someone is volunteering to do it now, that
would be fabulous, of course!). So far, to my knowledge, about 2
developers have been expelled many years ago. If something like this
comes up again, the first step would be to review how those expulsions
were handled. (I don't know myself since I wasn't around or involved
with this; as DPL, I would first talk to the people who handled those
expulsions, and ideally also talk to the expelled developers to get
their opinion on how to handle expulsions in a human way).