Two topics for the candidates' consideration and discussion.
First: "The Debian Project is an association of individuals who have made
common cause to create a free operating system." Presumably this means
our primary focus should be on putting together great free software and
getting it out to users. Of the candidates platforms, the only one that
mentioned any changes to the distribution itself was Gergely's [0]. If
the Project Leader is the public face of the project, is the person to
whom developers look for an example, shouldn't the leader's primary focus
also be on technical improvements? If so, why do your platforms instead
focus on process issues? If not, how do you propose that Debian developers
remain focussed on creating a free operating system if you're going to
be focussed on different goals (such as "how to be nice to each other")?
As Gergely was the only candidate to address any technical issues
directly, can you provide those of us who think technical issues are by
far Debian's prime concern any reason to vote for anyone other than him?
Second: Martin and Branden both identify problems with communication:
Furthermore, there is some frustration among some developers that
the core teams are not as transparent as they should be, and that
their inner workings are not documented very well. There have also
been problems with communication. -- Martin
We need improvements to our processes. ... All too often, I
see discussions of these matters devolve into yelling about two
alternatives: "person X is holding us back from progress" vs. "things
are working just fine, and your complaints don't do any good". -- Branden
Of the technical issues that aren't being communicated about well
enough, Branden says "In my opinion, and on balance, we do an adequate
job on these points." and Martin says "While progress is being made,
much remains to be done."
Ignoring the communication and timliness issues, do you think there
are any significant problems in the execution of the tasks under
discussion? Do you think, for example, that any new-maintainers who
have been accepted should have been rejected, or vice-versa? Have any
people applied to join some of the teams in question and been rejected,
whom you think should have been accepted, or vice-versa? On balance, do
you think any of the teams are doing any of these jobs inadequately? In
each case, if so, which and why?
Ignoring the communication issue, do you think any of the relevant tasks
are being done too slowly? For example, do you think the new maintainer
applicants who have been rejected should have been rejected sooner? Or
do you think NEW packages for the archive should be processed quicker? If
you think any of these tasks are not being done in a timely enough manner,
how would you compare the effect of these delays to other work that takes
time, such as development of our installer, or major stable releases,
or packaging new versions of X, or fixing release critical bugs? By what
criteria would you distinguish the tasks above that the project needs to
focus on speeding up, and the ones which are already acceptable -- given
that improving them all would obviously be a win. For those tasks that
the project should focus on speeding up, how do you propose that this
be achieved? Why has it not been achieved already? Given that Debian is
developed by volunteers, and presuming you're not able to fix everything
yourself, how do you propose to get other people to do what's needed,
given they haven't already wanted to do it?
On the communication issue, presuming you were elected unanimously
because everyone agreed with your plans and worked to put them into
effect to the best of their abilities, what would the project look like,
ideally? Would there be more communication than there is at present? From
whom, in what forums, and what activities would be covered? Should
there be "nothing's changed" announcements made, or should that be
implied by a lack of updates on tracking pages? Which announcements
should be made on -announce, -devel-announce, -devel/-project/-user,
-apache/-dpkg/-gtk-gnome/-perl/-qt-kde/etc? Which should be blogged on
debian planet? Should any just be mentioned in passing on irc, or in a
discussion thread on a list without being announced more widely than a CVS
log or a package changelog otherwise? Should there be more discussions
about developments? How do you think people with stupid ideas should
be dealt with? Should they be ignored outright, or have it explained
to them once and too bad if they didn't follow, should it be explained
to them until they're convinced? If they aren't convinced, but are also
unpersuasive in promoting their desired outcome, what should be done?
Do you believe that developers should be (or are) equally willing to have
a dialogue with people who provide criticism consisting of suggestions
of alternatives, discussion of tradeoffs that can and should be made
and helpful bits of code, or people who accompany their complaints with
comments like "This FUCKING SUCKS! The maintainer must be incompetent or
on crack" and requests for dismissal or replacement rather than useful
assistance? If you think that they should be equally willing to do so,
how do you propose to motivate people like myself, who aren't equally
willing, or how do you propose to work around that concern? If you think
that no such equal willingness is required, how do you propose to promote
the former form of reaction and criticism compared to the latter?
Who do you think should be subscribed to -devel, and what sort of
discussions do you think should make up the majority of the traffic? If
reality doesn't match those desires, what, if anything, will you do to
change that?
Cheers,
aj
[0] "I want to get rid of Perl from the base system. Not that I don't like
it, but I prefer shoop. Everything that is written in Perl in our
base system, should be rewritten in shoop instead."
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
Linux.conf.au 2004 -- Because we could.
http://conf.linux.org.au/ -- Jan 12-17, 2004
Attachment:
signature.asc
Description: Digital signature