Platform for Anthony Towns
If at first you don't succeed
Last year when I ran for DPL, my reasoning was that a number of the things I wanted to work on either required or would be much easier to do with some sort of leadership cap. That's changed somewhat for two reasons: first, I've had time to think of how I can do a number of those things without needing the DPL beret, and also because I've since gained a leadership hat in the form of a position on the technical committee.
As a consequence, while I am running again, I'm doing so as much for the opportunity to raise some ideas on what Debian should do over the next year for debate, than to necessarily get the authority to work on their implementation as DPL -- though of course, I'd be entirely happy if that happened too :)
For biographical detail, you might like to look at my platform from last year, or read through my blog.
Vitality
The most important thing that I think would benefit Debian is increasing its tempo. We've been slow in a lot of things, from releasing, to getting updates in, to processing applications from prospective developers, to fixing bugs, to making decisons on policy questions, and all sorts of other things. Even the DPL election process takes longer to go from start to whoa than the last Australian Federal Election, and this year we'll have two state elections run and complete entirely within the election period.
There are often good reaons for this, generally of the form "it's more important to get it right than to do it fast", but that objection is often used even when there's no actual contradiction between those goals. And sometimes doing it fast *helps* you to do it right, by letting you try out solutions and act on the feedback -- that is, the "release early, release often" philosophy.
I've been trying to help build this momentum by trying to help the release team get an effective policy out of the Vancouver meeting; by proposing a GR to get a decision on what we want to do about the GFDL issue, which we've avoided making a decision about for years now; and by trying to setup some policies so that there's regular activity by the technical committee. It's not something anyone can do alone, though, but I think developing an effective focus on getting to a good result quickly will be a big help for the project.
Some of the goals I hope to work towards in the coming year include getting updates accepted into the archive more frequently than once a day, having frequent beta releases of etch/testing that we can legitimately call a release (benefiting from the ongoing work of the installer and testing-security teams), and having reliably quick resolution of RC bugs in unstable. None of those require, or even necessarily benefit from magical DPL powers; but I think the project will benefit if whoever is elected DPL takes that idea on board, and sets a good example at making frequent and improvements to Debian.
Recruiting
An important aspect of vitality is having new blood in the system -- whether to allow old ideas to be reconsidered by fresh eyes, or simply to provide more shoulders to bear increasing burdens. We've been doing better at this, with resources such as alioth to help teams work together, and more maintainers with experience working in teams whether due to collaborating on sponsored uploads, on team maintained packages, or getting together at conferences such as debconf to work on problems.
I think there are a couple of questions we should be asking of ourselves: if other members of Debian have to step aside, are there areas I could step up to? And if I had to reduce my involvement in some area of Debian, is there someone who could step up to take over that work?
In many cases the answer to the second will limit the first -- many of us are already spending a lot of our free time on Debian, so the only way we could do more is by dropping something we already do, and if there's no one who'll take over that work, we might not be able to do that.
But on the positive side of the scale, this also means that by helping fellow developers out in one area, you can free them up to spend more time helping in another area where you might not have been able to contibute directly. In economics, this is known as the principle of comparative advantage: even by doing stuff that someone else is better at, you can still create an overall win if that frees them to do things you could never have done in the first place.
Another interesting option is the idea of compulsory turnover -- that is that when you take on a role, you know you're going to hand it over to someone else fairly soon. We're instituting that for the role of technical committee chair, and the role of DPL is similarly constrained thanks to the annual elections. Extending that principle more broadly in order to encourage and endorse new ideas and distributed authority is probably one we could look into, though it does have its own drawbacks.
I think having the DPL and others actively and visibly recruit people on an ongoing basis would be useful for the project, both as a demonstration that this is a good thing to do, and as an example of how to do it successfully.
Direction
I tend to think it's a little silly that we only really deliberate on these topics around DPL elections. I think it would be a good idea to decouple that more so that we can think about these things when they come up, and more importantly so people who don't want to be DPL can propose good ideas too.
Some of the ways this could be improved include having the DPL raise topics for discussion, and help guide them through to conclusion, or having the DPL invite other people to raise topics they think are important to have discussed, or having the technical committee or maintainers of key infrastructure or packages do the same thing.
Last Year's Goals
I think it's probably worthwhile doing a quick review of my goals from last year, and how they've gone.
First, there was the issue of being courteous to each other on mailing lists and elsewhere. There's been a few outcomes on that topic -- notably the creation of a procedure for expelling developers, the banning of a developer from posting to -devel-announce, and, closer to home for me, the creation of the moderated channel #debian-tech, by Steve Langasek and myself, and a cast of half a dozen or so. What I think that adds up to is that as it turns out, we are able to set expectations about how we'll act towards each other, and I'm hopeful that that means we'll start working out what, exactly, those expectations are in various areas, and that as a result we can be upfront about those expectations, and not leave ourselves finding out about the boundaries only after they've been crossed.
Another issue was that of "supporting delegates". As it turns out, that's perhaps an overly limited description, since a number of roles, including the security team and ftpmaster, might be better thought of as "infrastructure maintainers" instead, which implies a different relationship to the DPL. In any event, I've been trying to help with that anyway, by being involved in the release team's work on setting criteria for release architectures, in supporting the testing security teams attempts to integrate with the rest of the project, in trying to assist with communication for the arm porting machine, and in other areas to a moderate degree of success.
A related issue I raised, was trying to make our activities more public. As well as trying to blog more actively on stuff as I'm doing it, I've also tried to make a point of making logs available for discussions in #debian-tech, and put a limit on how private our discussions are by way of the declassification vote. I'm reasonably happy with how that's gone so far, but I still think it'ss important, and that we can do a lot more along these lines.
I'm very pleased to have recently had the opportunity to join the technical committee, and start trying some of the changes I'd thought about there; obviously those are only just beginning, so we'll have to see how they turn out.
On the downside, I haven't done as much as I would have liked to in the areas of letting users get more involved, or improving the global quality of the distribution. The usertags and usercategories for the bug tracking system are a vague gesture in the area, and the addition of debtags to the Packages file might count for something, but there's a lot more that can be done here. Fortunately some of it is already being taken up by others anyway, such as the automated testing efforts by Lars Wirzenius (piuparts) and Ian Jackson (autodebtest, paid for by Canonical).
Gratuitous Song Parody
To the tune of Can't Buy Me Love by The Beatles...
I'll give you an X with bling my friend, if it makes you feel alright.
I'll promise anything my friend, if it makes you feel alright.
'Cause I don't care too much for money, money can't buy me votes!
I'll give you all I got to give if you say you'll vote for me.
I may not have a lot to give, but what I got I'll give to thee.
I don't care too much for money, money can't buy me votes!
Can't buy me votes, everybody tells me so!
Can't buy me votes, no no no, no!
Say you don't need no compiz bling, and I'll be satisfied.
Tell me that you'll give me the kind of thing, that money just can't buy.
I don't care too much for money, money can't buy me votes!
Note:
compiz is a compositing manager for X that I'm led to believe should be available when Xorg 7.0 enters Debian; it lets you do cool stuff like Mac OS X's Expose feature. Features like this are known in the Xorg technical community as "bling".
Disclaimer:
You may be able to buy votes with money, and the author disclaims any responsibility for any opportunities lost by any candidate or advocate who bases any statemnet or action on any assertion above. Any opinions expressed in the above are undertaken under poetic license, and may or may not reflect the views of anyone living, dead or involved in free software. Poetic licenses may not comply with the DFSG.
No animals were harmed in the making of this parody.
Rebuttals
Bill Allombert
I'm pleased Bill recognises that not everyone has an innate understanding of how to get along well while working with other people, and I think that that alone goes halfway to solving the problem. I'm not sure half a solution is enough in this case -- but it's certainly worth a try.
Bill also claims that he is "very patient" and "can wait a long time to fix a problem if this is necessary to fix it /correctly/" -- which is good, but I think we'd be much better off if we stopped waiting all the time.
The DPL Teamsters: Jeroen van Wolffelaar and Andreas Schuldei
Both Andreas and Jeroen wish to continue the DPL team as a major plank in their platform. I think there are a couple of things that are interesting from this. First is that the DPL team didn't work so well last year -- at a minimum it failed to provide enough help to Branden to reach his goal of monthly reports, and likewise failed to reach its own goals of making public minutes and agenda available for its meetings. I haven't seen any reason to expect any sort of change on this score, and both Jeroen and Andreas should already have been in a position to remedy both problems.
I also find it notable that having worked together for a year, Andreas and Jeroen are campaigning separately; and appear not to be inviting each other to be a member of their team if elected, and that both appear to be blaming Branden for the failure of the DPL team to achieve its objectives in the past year. That seems to lack the level of mutual support and personal responsibility I would hope for from the DPL.
Anti-rebuttals
As you might guess from the above, I don't have much of a problem with most of the goals expressed in the platforms this year, so here's how I believe the other candidates could achieve their goals if I were elected:
Communications (Jeroen, Steve, Bill)
I think there are two ways to approach this: first is by encouraging people to try out new ideas, such as codes of conduct on new mailing lists and IRC channels, which I think anyone can and should do; and second is by encouraging the people managing existing resources to conservatively experiment with some of the ideas being proposed. I think we should approach this in a spirit of scientific inquiry: try something out, discuss what went well and what didn't, and learn from that. I'd be happy to assist Jeroen, Steve, Bill and others in getting the necessary support to setup those projects.
Resource Allocation (Andreas)
Andreas does exceptional work at managing sponsor relations for Debconf, and has expressed a desire to expand that both in his platform this year, and in conversations over the past year. I think there are probably two key things that need to be worked on there: first making it easier for Debian to accept, control and use its resources (both physical and financial), and second having better publicity of the ways people and organisations can contribute to Debian, and of how such contributions actually help Debian. I think Andreas's experience at organising Debconf sponsorship demonstrates that not too much DPL support is actually required there, so I would aim to provide both an ongoing level of interested oversight and a generous amount of delegation.
Observers (Bill)
I'm not sure independent observers are the best way of working out what's going on, but I'm certainly not opposed to the idea, and I think everything in the project (with minor exceptions, such as passwords and embargoed security updates) should be open for anyone to view at all times. So I'm completely happy to support Bill getting access to working areas so that he and others can investigate what's going on and report on interesting things they think are noteworthy.
Where that falls down though, is that it doesn't help reveal the intriguing plans people have; so I think it's much more beneficial for the people doing the work to feel comfortable talking about it directly, which goes back to the "Communications" issue above.
A Fair New Maintainer Process (Jonathan/Ted)
Ted proposes to put forward a general resolution to require all developers to go through new-maintainer repeatedly. On the face of it, I'm concerned that this will stress the resources we devote to process new-maintainers unduly, making it even harder for new people to enter. That might not be the case however -- existing developers may be able to breeze through in the normal case, and the additional load might not be significant. I suspect the easiest way of determining this would be for an interested volunteer to resign from Debian, and to rejoin using the full new-maintainer process, and prepare a report on its flaws when complete. I would be happy to support Ted in that, if he wished to so volunteer.
(I believe Ian Murdock attempted this in the past, but due to lack of time reverted to the reduced emiritus process for rejoining, and -- due to the same lack of time -- hasn't yet completed that)
Audience Rebuttal
In critiquing the candidates on his blog, Jaldhar Vyas wrote of me:
Anthony is heavily involved in such roles as ftpmaster and release manager. It would be a shame if being DPL actually meant he would have less time for that sort of thing. He claims to be running mainly to introduce some new ideas. So hopefully he won't mind if we keep him in the boiler room instead of, um, athwart the foc'sle?
I think it's worth thinking about whether we want to keep the people doing work on Debian "in the boiler room" -- or if we'd like them to wash the grit off their faces and join us for dinner and witty conversation in the upstairs ballroom. I hope my standing for election indicates where I stand on this, too.