On Tue, Mar 02, 2004 at 08:11:16PM +1000, Anthony Towns wrote:
> 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?
The Project Leader's focus should be on whatever the project needs most.
I think we're fairly sophisticated at managing the technical content of
the distribution. That is, while there's certainly a lot of work that
needs to be done for us to have a high-quality sarge release -- as
you're not doubt personally and painfully aware -- we're pretty good at
knowing and communicating what that work is. We have a highly-developed
(custom-written, even) Bug Tracking System, and interfaces like
packages.qa.debian.org for getting all kinds of good information about
where a technical aspect of the distribution is at.
Our interfaces to non-technical and infrastructural knowledge are
*significantly* less developed. In many cases, as I observed in my
platform, people have to ask humans to get the information they seek.
They often cannot honestly be told to go look at some webpage and get
enlightened that way.
> If so, why do your platforms instead focus on process issues?
As noted above, I focus on process issues because that's where I
perceive us as being most deficient.
> 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")?
How do we remain focussed on creating a free operating system when most
of us have bills to pay, loved ones to care for (or at least keep in
touch with), and/or exams to study for?
I think you're positing a false dilemma. That creating a technically
excellent distribution of 100% Free Software is our primary goal, and
raison d'être, doesn't mean that every activity not in obvious and
direct service of that goal isn't worthless.
I think by improving process infrastructure, we can make support
positions within the project more comprehensible and appealing to fresh
volunteers (not necessarily developers who have just passed NM, either
-- maybe old-timers whose interests have changed as well). That will
both directly serve my goal of reducing the level of friction within the
project (as one doesn't have to pester people for answers to questions
that have been asked "a dozen times today") but indirectly as well,
because I expect some of those volunteers could actually perform those
infastructural taks, distributing our workload more evenly, and getting
support work done faster.
> 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?
Sure. Imagine Debian as simply a collection of bits sitting on a box
somewhere. No Project machines. No mailing lists. No BTS. No
keyring. No master archive. No mirrors. How easy would it be to
pursue our purpose then?
You tell me -- are issues other than technical ones important at all?
> Second: Martin and Branden both identify problems with communication:
[...]
> 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."
I think you're exaggerating the contrast between our statements -- note
the next paragraph after the one you quoted:
Good is good, but we can be better. Adequacy is adequate, but we
should strive for excellence.[1]
> 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?
I'm not willing to point an accusing finger of inadequacy at any of
these, nor to single out some particular decision and deride it --
especially since, as the Constitution notes, if the decision were taken
by a delegate, the delegate cannot be dismissed by the DPL for making
it[2].
One of the reasons I'm setting up a RequestTracker instance is to see if
it can help us to gather more information about these types of issues.
Availability of information is a key point when making assessments of
these tasks. We have some statistical information about how quickly the
NM queue gets processed, but as far as I have been able to determine, we
have no such counterpart for queue/new processing. How can we
intelligently talk about quality or effectiveness when our tools for
measuring them are poor or nonexistent?
As I said above, we simply haven't developed interfaces for much of our
non-technical work that compare favorably to those we've developed or
put in place for our technical work.
> Ignoring the communication issue, do you think any of the relevant tasks
> are being done too slowly?
I'd rather ask the people currently in charge of them some questions:
* Can these tasks be done more quickly?
* What would it require to do so?
* What risks, if any, are there in performing these tasks more quickly
than we do?
In any case, how slowly is too slowly? The answer is subjective, and
depends on who you are. I'm unwilling to make a proclamation as DPL
that "this process is moving too slowly" without the benefit of better
information.
> For example, do you think the new maintainer applicants who have been
> rejected should have been rejected sooner?
I personally am not sure; however, I'm aware of at least one rejected NM
who wishes he had been rejected earlier than he was, since he felt his
rejection was a foregone conclusion.
> Or do you think NEW packages for the archive should be processed
> quicker?
I have seen a fair number of complaints about this, and I confess to
having experienced some personal impatience with NEW processing on
occasion. I suspect that NEW processing is something that could happen
more quickly if we could find the archive administrators some more help.
This doesn't necessarily mean having more archive administrators; for
example, it might instead mean coming up with a way to at least
partially offload analysis of packages in queue/new to an outside team,
much as the archive admins have offloaded a lot of license analysis to
the debian-legal mailing list. Given that packages have sat in
queue/new for a while in the past because some thorny license problem
had to be sorted out, that these things are nowadays discussed on
debian-legal is progress, in my opinion. It's easier for people to
figure out not just *that* a package is stalled in queue/new because of
unresolved questions about licensing, but they can read the list, get up
to speed on the details, and potentially help the matter along.
I think that's a good example to follow, and it's not even terribly
bureaucratic. In fact, it was *so* informal that debian-legal was
recently called upon to be *more* bureaucratic[3]!
> 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?
That's a broad question, so I'll have to give you a broad answer. I'd
compare by saying "it depends". Whether a hold-up in queue/new is
important in effect depends on what's being held up. Whether a hold-up
in the NM process is important in effect depends on what the applicant
can't (or won't) do until he or she is accepted.
Filing bugs against ftp.debian.org begging for processing of a package
stuck in queue/new has been seen to not work, and exasperate the archive
admins. One potential application of an issue tracking system for
non-technical matters is to provide a forum for people aggrieved over
a stall in queue/new to argue that their stalled package requires
special processing. Special processing already happens for d-i udebs.
> 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.
I'd regard as worthy of focus any task which a large number of people
want to help happen faster, but can't because they cannot find out how
to help.
Consider, just as an example, the differences between the answers to the
following questions:
"I'd like to help the RC bug count go down. How can I do that?"
"I'd like to help queue/new get processed faster. How can I do that?"
I think just about any developer can answer the former. Check out the
RC bugs list, identify a bug, hit the corresponding number in the BTS,
apt-get source package, and get crackin'.
How about the latter? "Well, first you need to grab the package out of
queue/new..." Uh-oh!
Now, I don't want anyone to draw the completely unwarranted inference
that all responsiblities are interchangeable. As I noted in my
platform[4], some do require special trust. It would be interesting to
see if we can decouple some of the high-security aspects of a task from
the normal-security ones, however, and thereby improve our potential for
parallelization.
> For those tasks that the project should focus on speeding up, how do
> you propose that this be achieved?
As I said above, I think speed is a consequence of comprehensibility.
Therefore, I refer again to my platform[5][6].
Even if we get *no* new volunteers for *any* infrastructural task, I
think improved availability of information will yield greater
efficiency, because I predict that greater access to information will
cut down on the amount of complaining and personal flamage that cannot
help but demoralize people. And I don't mean just the people who are
targeted for complaint, whose skin has to be pretty thick by now.
Would *you* have been able to work more on your technical and
infrastructural responsibilities if you hadn't needed to author
approximately 49 mails in the "Debian needs more buildds. It has
offers. They aren't being accepted." thread on debian-devel[7]?
Maybe you wouldn't have been able to -- if not, I'd appreciate knowing
it. (And, moreover, I don't blame you for participating in that thread
-- Debian is a community, not a forced-labor camp, and I respect your
right to exercise your citizenship by participating in non-technical
mailing list discussions.)
> Why has it not been achieved already?
That is a question I can only speculate on. I think Martin Michlmayr,
Bdale Garbee, and Ben Collins may be able to offer more insight on this
particular point than I can.
If it's an impossible goal, I'd appreciate them sharing that information
with the rest of us. If I understand Martin's platform correctly, he
shares my feeling that it's *not* an impossible goal.
> 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?
See above. I hope to persuade the developers by example of my thesis
that open and transparent processes cut down on frustration, conspiracy
theories, and the resulting acrimony.
I found, in the process of opening up Debian's XFree86 package
development and maintainership, that the frequency and shrillness of
"why isn't [latest version of upstream XFree86] in unstable yet"?
complaints and nags decreased *dramatically*. People made jokes about
it on Slashot, but they couldn't plausibly argue that the reasons were a
big mystery. The information was there on the Web for the having.
You can be sure it did a lot for *my* morale to not hear as much of that
sort of thing this time around.
> 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?
Doesn't that kind of set me up to be disappointed at the end of my term?
:)
To be honest, I think it would look unlike anything else. Debian is a
unique communities, though it has many similarities to other Free
Software Projects. But we're unique in terms of our size and
non-commercial nature in the OS market. Volunteer groups oriented
around specific technologies tend to organize differently -- take the
GNOME Foundation Board or the GCC Steering Committee, for example.
Debian doesn't closely resemble either of those and there doesn't seem
to me to be much drive among our developers to change that.
Ideally, I think we should continue to evolve in a self-organizing,
mostly non-hierarchical fashion.
> Would there be more communication than there is at present?
Yes, I think so. Keep in mind that interactive, personal conversations
are not the only form of communication. I'm a big fan of the concept of
people having questions about some aspect of the Debian Project and not
*having* to ask someone, because they can just find the information.
> 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?
I think it's outside the scope of the DPL's responsibilities to attempt
to dictate all of these in detail. I'd rather develop strategies for
answering these types of questions intelligently than attempt to
micromanage by decree.
> 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?
I don't think the answers to the above questions can be legislated by
anyone, not even the DPL.
That said, I think it's more instructive to look at trends and
aggregates than to attempt to pre-legislate every scenario.
"Should there be more discussions about developments?" Well, does some
particular area of development see a lot of complaints about
blindsiding? If so, then yes. If not, then no.
"How do I think people with stupid ideas should be dealt with?" Do we
keep hearing the same stupid idea over and over again from many
different people? If so, maybe we should re-evaluate our appellation of
the term "stupid" to it -- there is probably some need that going unmet,
if even it's being articulated poorly. If not, then I guess the usual
thing happens: the person either gets ignored, flamed, or patiently
lectured to -- often all threee simultaneously, since we're a large
community.
"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?" What seems to work best? Some people never seem to
go away no matter which approach you use[8]. Just as we have
interlocutors who try different approaches to asking questions, we have
developers and users who try different approaches in anwering them.
> 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?
I expect the former to work better a majority of cases.
> 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?
I don't expect them to be equally willing to entertain abusive
complaints.
> 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?
By helping to ensure that the former approach *really does* work. As I
said in my platform[4], people get frustrated if they can't see any
progress. If asking nicely works, but it's hard for them to tell,
where's the positive reinforcement for asking nicely? We're plenty good
at negative reinforcement when people ask the wrong way, but the absence
of a negative is not a positive. It's just zero. If no form of
criticism, constructive or otherwise, seems to get results, then people
will despair of offering any perspectives at all. Well, some of them
with howl in a shrill tone anyway because they can get it off their
chest, and they "know" they're not actually making the situation any
worse.
But we'll have successfully silenced those who *would* offer
constructive criticism ("waiting always works", someone once said),
leaving only the irredeemable flamers. I don't think that's good.
> 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?
I'm going to have to refer you to my platform again here.[5][6]
[1] http://people.debian.org/~branden/dpl/campaign/2004/platform.xhtml#s2p1
[2] "The Project Leader may not make the position as a Delegate
conditional on particular decisions by the Delegate, nor may they
override a decision made by a Delegate once made."
-- http://www.debian.org/devel/constitution
[3] I'm using the term "bureaucratic" a little facetiously. But read
the message and make up your own mind! :)
http://lists.debian.org/debian-legal/2004/debian-legal-200401/msg00216.html
[4] http://people.debian.org/~branden/dpl/campaign/2004/platform.xhtml#s2p2
[5] http://people.debian.org/~branden/dpl/campaign/2004/platform.xhtml#s3p1
[6] http://people.debian.org/~branden/dpl/campaign/2004/platform.xhtml#s3p2
[7] http://lists.debian.org/debian-devel/2004/debian-devel-200402/msg00329.html
[8] http://bugs.debian.org/210879
--
G. Branden Robinson | The last time the Republican Party
Debian GNU/Linux | was on the right side of a social
branden@debian.org | issue, Abe Lincoln was president.
http://people.debian.org/~branden/ | -- Kirk Tofte
Attachment:
signature.asc
Description: Digital signature