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

DPL Debate unasked questions

Okay, so I'm going to ignore the end-of-campaigning thing and answer
the debate questions that didn't get asked 'til later, since I suspect
at least a few of them are probably pretty important at least to whoever
asked them. Or, at any rate, I'll answer some of the ones I have anything
to say about.

On Sat, Mar 18, 2006 at 02:58:13PM +0000, Thaddeus H. Black wrote:
> Please defend your vote in the recent GFDL election, and how you think
> it represents your ideas for freedom in Debian.  For reference, the
> candidates' votes follow:
>     V: 1243 ari      Ari Pollak
>     V: 1144 ajt      Anthony Towns
>     V: 2134 93sam    Steve McIntyre

I don't think people should have to "defend" their vote; but I'm happy
to explain mine. 

Basically, there were two issues that I couldn't decide on: one was
whether I thought it was worth worrying about the detailed flaws in the
GFDL (relating to the "can't chmod a document" and "can't distribute a
transparent copy separately") -- it might be fair to be strict about that,
because we've been bitten by not being strict in the past on issues such
as the pine license, but otoh, there's been reported written affirmations
from Stallman that that's an incorrect interpretation, and I don't think
it'd be considered a "reasonable" one if it ever actually mattered. So
I was happy to punt that to everyone else to decide on, particularly
given that Dato's revised amendment ended up being pretty easy to read.

The other issue was whether the "always free" amendment had received
enough discussion, and whether it should be voted down on its merits,
or because it wasn't adequately clear -- initially I'd have rathered
voted against it on its merits (leading to ranking it above Further
Discussion), but in followup discussions the proper didn't seem to even
be sure if that resolution would let the GFDL be in main or not, which
didn't seem wholly adequate. In the end it was voted down on its merits
anyway, so that didn't matter.

> How easy is it for young people (age < 18) to get involved in Debian?

There's been quite a few people who're under 18 involved in Debian,
so it's not that hard; the main drawbacks are that you often can't
participate in some of the social events (requiring travel, or at pubs),
or that you don't have the sort of knowledge or resources that you'd
get if you worked full time or were at a uni.

> How do you intend to keep a positive, enthusiastic attitude (i.e.,
> productive) during your tenure as DPL, and how do you intend to project
> that attitude inwards to the Debian Developers and outwards to the outer
> community?  How do you plan to avoid the soul-crushing
> productivity-sapping effects of the nay-sayers inside and outside the
> project?

To some degree "nay-saying" is really important, so denigrating all
of it as "soul-crushing" and "productivity-sapping" is too much. I think
the best way to deal with it is to invite and encourage criticism, but
at the same time limit it ("if you want to criticise, do it now, not
everytime anyone ever mentions it again later"), and try to encourage
criticism to be scientific and focussed on alternatives and tradeoffs
("doing it this way makes it be 20% slower, whereas doing it this way is
only 5% slower, and works for 86% of cases, here's how you can validate
those figures...").

There's always going to be ignorant and childish criticism in modded
down slashdot comments and elsewhere, but as long as we can get things
done on our own turf, that's not a bother at all.

> Last year transparency was a hot-button issue. Do you feel that the
> project as a whole has improved on this, or has the furor simply died
> down? What do you think we can do better in this area, and what are your
> specific plans for dealing with it?

I don't think it's changed very much, and I think we were doing pretty
well at in the past. We're already very open about what we do, and the
improvements on top of that are going to keep being incremental.

> What concrete and definite goals have you set that you realistically
> believe you can achieve as DPL?

I'm more interested in the not-so concrete goal of getting things moving
faster, so it's not so much any /particular/ things that I want to have
happen, as making sure a fair number actually do. But:

    * having a constitutional GR to make DPL elections shorter (eg,
      1 week for nominations, 3 for debate, 2 for voting)
    * having (at least) two more etch beta releases, with improved support
      and publicity
    * partial review of *.debian.net and other services with a view to
      what's needed for them to be integrated into debian.org
    * partial review of *.debian.org services with a view to ensuring
      they're properly maintained and not at risk of falling off the
      net like packages.d.o

On Sun, Mar 19, 2006 at 02:15:11AM -0800, Don Armstrong wrote:
> I don't know if the candidates wish to answer these outside of the
> campaign period or not, but if they wish to, feel free. [For some
> reason we always seem to have a traditional moratorium on answering
> questions during the voting period... never quite figured out why.]

If two weeks are enough to discuss major changes to the constitution,
three ought to be enough to discuss electing a new DPL?

> How do you plan on helping Developers to recognize the need to recruit
> more members to join teams that are overburdened? [What will overcome
> the chicken and egg problem?]

I don't think I've seen a team that needs help not recognise it;
where that is the case it's usually just a matter of doing some sort of
objective performance indicators and pointing out why they matter. The
real problem, in my experience, is developing trust in new people, and
finding people that can actually fit in the commitment required. The
latter's just plain hard -- in an unpaid volunteer project you're always
going to end up with people who make commitments that for one reason
or another they're not going to be able to keep. 

The trust issue can be worked around in a few ways though, notably
by encouraging assistant roles with restricted permissions, such as
the release and ftpmaster assistants, and the testing-security team
and security secretaries; and that also has the benefit that it starts
out as a smaller commitment, and causes less of a problem if it has to
be dropped.

> More, better, faster; what do you think everyday contributors who
> aren't RMs or on ftpmaster should be doing to increase the pace of
> Debian? How do you plan on helping them do that?

Obvious answers: packaging new software, fixing bugs, helping users with
problems. Doing NMUs of other packages, encouraging other people to do
stuff, limiting the urge to be negative and discouraging. I don't think
there's much the DPL per se can do technically to help with it beyond
promotion and encouragement, though that alone is pretty valuable.


Attachment: signature.asc
Description: Digital signature

Reply to: