Re: Criteria for a successful DPL board
On Wed, 14 Feb 2007, Anthony Towns wrote:
> Grr. I shouldn't be doing this, but I can't help myself. Here's some
> counterpoint to some of Raphael's points. Please consider them only
> to moderate some of his claims, not necessarily to disagree with them
> in principle.
Heh, you're right. I tend to emphasize some aspects on purpose but I can
give counter-examples myself too. :-)
Given my experience of Debian, this concept of DPL board almost seems
self-evident for me. This discussion requires me to find real reasons why
it would be better, and while I can explain several things, there are
parts of the argumentation that you can only believe once you've tried
(during several years) to understand why we have those spikes of
criticism of key teams and why we don't see much improvements in the
> On Wed, Feb 14, 2007 at 08:55:10AM +0100, Raphael Hertzog wrote:
> > But you're not going to delegate "check out what can be done to increase
> > transparency within the ftpmaster team without scaring away current
> > ftpmasters".
> FWIW, this has happened in the past, more or less exactly as written,
> while Martin was DPL. The result was:
> That text was later reused as part of Branden / the 2005 DPL team's task
I remember that now. It was a good start, it's sad that we didn't go
further. Describing the tasks is only a pre-requesite, it's not really a
solution for the perceived problem as you tell yourself.
> > And that's the kind of problems that many people would like to have
> > tackled.
> Personally, I'd say a bigger problem with tackling that is it's not
> clear what would actually satisfy the request, particularly given that
> there seems to often be an underlying sentiment that the real problem
> isn't communication but the personnel.
Indeed. So on top of the wiki pages above, we should try to go further by
describing "challenges" to overcome for the various teams. The idea is to
have a list of "would be nice to have" things that people can check out
and work on. Hopefully while working on those projects, they'd learn a
lot and become possible additions to the respective teams.
> > The tasks of the DPL are not about coding and reviewing code.
> That's not necessarily true -- there are quite a few potential goals
> a DPL might have for the project that do require code changes or new
> code. Ultimately, the DPL's tasks are whatever the DPL wants them to be,
> and that can just as easily involve all coding as no coding, depending
> on what focus they're interested in.
Indeed. In 2002, when I candidated for DPL several of the projects that I
planned to work on required coding (the PTS in particular), and funnily
while creating new infrastructure I've "lead" the project in new
directions (collaborative maintenance in particular) without ever being
> > Each DPL provided a platform: it ought to be his TODO list because he's
> > elected on that basis. The platform are public, I've yet to see someone
> > who worked on a project of a DPL.
> I didn't propose specific goals in any detail in my platform this
> year; but certainly there have been people who've helped with projects
> throughout the year, including the "debian maintainers" thing (Christoph
> Berg and Marc Brockschmidt in particular)
Did we do something apart from discussing on this topic ? :-)
> , what became dunc-tank (see the board), and there are quite a few
> volunteers waiting for me to tell them what to do for the DSA assistance
> a while ago.
> I'd be remiss of not pointing Steve McIntyre as someone who's worked on
> some of my DPL projects too. Beyond that, others have taken on board
BTW, while Steve posted some news on -devel-announce, we have no clear
idea how he managed to help you. Can you (or Steve) tell us a bit more on
Premier livre français sur Debian GNU/Linux :