Platform for Jeroen van Wolffelaar
My name is Jeroen van Wolffelaar, currently 24 years of age. I'm a computer science student at Utrecht University, the Netherlands. I have had one year of full-time experience as a board member of my study association, A-Eskwadraat. I'm an active contributor to Debian since roughly end of 2003, and am a Debian Developer since the last day of 2004. I've been involved in QA (lintian, MIA, other areas), and have been an ftp-team member for about a year now.Why I am running for DPL, and how I intend to organise that
While I actually prefer to write code or maintain packages, or generally, work on technical issues, I feel compelled to run for DPL this year. I like the Debian project a lot: mostly because of its technical excellence, and because it allows one to contribute to a free operating system together with a lot of interesting and skilled people. However, I perceive some problems in the project that I think should be addressed, and I want to address those. Most of you will know that last year, I started the DPL team in December 2004, mainly because I do feel a team would be better suited than an individual to tackle the hard issues I felt that needed to be addressed. I seek to continue this, but now as lead of such team.
As a result of Branden getting elected last year, I was in the privileged position to witness a large part of what is involved in being DPL. I learned a lot during that year, and noticed things that did and didn't work. As I explained in the original DPL team announcement, a great deal of inspiration for the setup of the "Scud" team was coming from a quite different type of organisation. An important thing I learned is that in order for such a team to work effectively, it is required that the whole team is involved in (at least informed of) all what's going on, and that an agenda is maintained and enforced, and ensuring that assigned (delegated) tasks are fulfilled. I do believe that the opportunities a DPL team offers were in retrospect not fully leveraged. I intend to do better by ensuring, helped by having experienced the past year of DPL team, that I will involve the whole team in the DPL actions, and maintain the agenda of things I want to do. I will ensure the agenda (based on things in this platform and whatever else comes up) is followed, doing whatever is not working well enough in the team myself.
There is no team composed yet, developers interested in helping in general or with one of the below areas specifically can email me privately. I will publish the members of my proposed team in about two weeks, or at the latest just before voting starts.
I will have a public review of how the DPL and the DPL team itself is performing four times, roughly every 3 months, consisting of an online discussion, followed by a mail to debian-devel-announce summarising the reflection and announcing possible changes in focus.
Issues I will work on
Debian is a highly distributed and networked project. It excels where people work together directly on technical problems they like to contribute to. It is the nature of the Debian project, and in the ideal situation, the DPL should not be involved at all. However, there are a couple of problems in the project that require addressing.They are all related to communication.
Communication
Debian needs to focus on technical excellence with free software In order to achieve that, have smooth communication both within the project and from the project to the outside: to users, to potential contributors, and not in the least to Debian developers. A friendly and productive climate is very important, one that does not prevent people from doing good work. Also externally communication is important, both to enable users to leverage Debian to its fullest extent, and for the general world via the media to hear about Debian.Because Debian Developers are by nature mostly technically interested, communication can easily be something getting not enough attention. Below I will outline what areas I'd like to see communication improved, and how I intend to solve that.
Communication among Debian contributors
The major issue we are faced with currently is that a lot of time is wasted on unproductive mailing list discussions, keeping people from doing real work, or worse, driving people away from our central lists. An even more important problem with this situation is that it drives away people from the Debian project as a whole, there are numerous examples of people leaving Debian for this reason, or simply not joining. This needs to improve. For a project like Debian, it is essential to have a list like debian-devel with the vast majority of the regular contributors on it, rather than the current situation of having too regular Debian contributors not being subscribed due to the state of the list.
I will push for the adoption of a code of conduct. I do feel strongly about that mailing lists should be able to provide a forum for productive technical discussion, where one can ask questions to and get a reasonable result. If some people are not able to contribute to this, but rather hurt the discussion, action must be undertaken. If peer pressure does not help, this may include such things like posting delays, moderation of certain individuals, and in extreme cases, banning from mailing lists. I will work with the listmaster team to see whether they are willing to facilitate this, or whether there needs to be a new team of people performing this moderation.
I will also continue to look into other means to structure discussion, see for example my initiative to hold informal polls to gauge developer opinion.
Communication towards Debian contributors
Above all, contributing to Debian should be fun and encouraging. Therefore, I will make a bi-weekly pick of some interesting bit of Debian that I feel is worthy of attention, and invite someone to write a short article about it, and post it to a general mailing list, or I will myself write a piece. With those "insider reports", I hope that the Debian contributors are more aware of some of the many things that are happening inside the project, and create more awareness of the amount of interesting things inside the project.
Communication to our users
Debian does have a lot of users, a lot of which are in need of assistance at some point. Support needs to be accessible, and friendly. Any type of question needs to be able to be asked without meeting hostility. I will continue giving attention to this.
I will encourage more use of the official wiki, look into ways to ensure the #debian IRC channel is a nice place to get help. I will also investigate whether some sort of forums like forums.debian.net, which I started a while ago, could become an official project resource as an addition to the current offerings, specifically targeted for starting Debian users.
Increase transparency of infrastructure teams
There are (perceived or real) problems in communicating with some infrastructure teams at times. Also, the way they function is often not really accessible. This is understandable from the team's point of view, because documenting is often boring. I will work on having infrastructure teams' tasks and way of working documented better (on iwawocd.cewmufwd.tk), and I will work together with those teams to ensure the preferred way of contact is responsive, and/or there's at least another mailing list where people can ask questions and get possibly helped by interested third parties — an example is the debian-security mailing list, where anyone can ask a question, and also non-security-team members can help out in cases where a question doesn't require a team member to be answered.
Act as a mediator/ombudsman
As with all places where humans work together, people can get disagreements with each other. Sometimes this can heat up so much so that it hurts mutual cooperation, which is a bad thing. Whenever I notice this, or such a situation is brought to my attention, I will find the best person I can think of (possibly myself) to act as a mediator. We have the technical committee for technical disagreements, but nothing similar for social disagreements. I will investigate setting up a team like the tech-ctte for this.More visibility in the media
Debian doesn't play itself in the news very often, while there are a lot of interesting things going on. I will actively approach the press, and I will be working together with the our press contact to initiate more visibility in the media. I will try to increase my attendance of various conferences and gatherings, and solicit invitations to come talk about Debian at such gathering.Things I will leave alone
A lot of areas in Debian are running smoothly at the moment. I will not intervene when things are running well. I have good faith in our release team's plan to release Etch by the end of this year, the technical committee is doing fine, and so is our project secretary.Why choose me?
I enjoy working on Debian, and I would like work with a lot of people to ensure working on Debian remains enjoyable, and becomes even more fun to do. I'm a team player, and will seek actively and often for advice and discussion how to achieve this goal best. Together with you all, I hope to make my DPL-ship an enjoyable experience for the project and myself.Summary
I will:- Assemble a team to share responsibilities with and be able to do more
- Involve the team actively, but follow the agenda anyway
- Assemble a team within the next two weeks
- Organise public review of DPL and DPL team performance every three months
- Work on ensuring smooth communication in all areas
- Push for adoption of a mailing list code of conduct, with means to enforce it
- Hi-light interesting developments inside the project to a broader audience
- Work on accessible and friendly user support
- Increase transparency of infrastructure teams
- Mediate in inter-personal issues
- Increase media visibility
- Have fun on improving Debian
Rebuttal
First, I'm glad to see that there are so many good candidates.Steve McIntyre
Steve is a social person, with whom it's good working with. I've talked to him on numerous occasions about Debian in general, and I believe we largely share the same motivation to run for DPL, and things we'd like to fix. If either of us is elected DPL, I hope and expect we will be able to cooperate on certain issues.
About the NM issues, I think a big problem at the moment is the lack of AM's. As some recent experimentation have shown, while that can provide for a more satisfactionary NM process, it also makes that it takes even more time for AM's — a precious resource. I'm wondering how Steve intends to solve that problem specifically.
If Steve happens to become DPL, I hope he'll have the personal bandwidth to tackle the issues he promises to work on. Scalability is a concern for an ambitious DPL.
Anthony Towns
Anthony is an excellent DD, especially in the technical area. I think that's where he excels.I think his stated goals are good ones, and certainly would be very happy to have more vitality, better recruiting, and a more clear direction (read AJ's platform to see what I refer to).
As for the first item, vitality, I believe this is something that is best achieved by ensuring people believe in Debian, and that there is a productive base for people to work under. It's the people who need to make it happen. I think it works best to inspire people by showing better to ourselves and to others the good and interesting things that happen in Debian, and provide something to strive for (showing off cool stuff).
A couple of the issues Anthony mentions do, as he says himself, "require, or even necessarily benefit from magical DPL powers". This is my worry with his proposed way to get more vitality: one cannot solve this magically as DPL. Not only would it be impossible to achieve due to time constraints, but also, as DPL one should ensure that the conditions and are right to make great things happen instead of doing it all oneself — you don't need DPL to do that, and it doesn't scale.
As for the second item, recruiting: I think it's important to get a steady amount of fresh blood in Debian for the reasons Anthony lists. Again, though, I differ in the way how to achieve that: one cannot pull people actively, but instead, one must ensure Debian is a place where great things happen, and then people will come to Debian on their own. I was at FOSDEM last weekend, and everywhere I looked, people were wearing Debian T-Shirts bought from the Debian booth. This is very cool, and by also ensuring Debian's seen as place where also new and interesting developments are taking place, we can most effectively draw more developer interest. I'm a bit puzzled at what exactly Anthony proposes to do here, how he wants to achieve better recruiting. Getting people to be able to give up positions more easily doesn't magically generate new people to do the work.
Andreas Schuldei
Andreas is a great fundraiser, and spends a lot of time to ensure debconfs are happening. This is very much appreciated. Once he sticks to something, he won't let go easily. I hope we will see Andreas continuing to do so the upcoming year regardless of the election results.I do not think teams are the magic solution to everything. It's very valuable organisational form, but it takes organising itself too. Forcing everything to be 'smallteams' won't be productive.
I'm missing a bit how Andreas wants to achieve his ambitious goals, such as "more frequent and regular releases" — our release manager Steve Langasek has stated that at least he won't serve as RM if there would be a release more frequent than each 1.5 year. Any DPL team should in my opinion be an aide in being more effective in achieving the goals one sets, and not a goal on itself. Also for the position of DPL, one needs to have an idea how to resolve the issues one sees, just forming a team alone will do no good.
Bill Allombert
I don't know Bill very well, we've never really had the opportunity to work together directly, so I can't say too much about him.I think that what we need right now is a DPL that's willing to persue some of our current, mostly communication-related, issues that are hurting us. For disagreements among developers, we already have the technical committee, I don't really see why the DPL would need to pull this area towards his role. I think it's very important for especially a DPL to represent Debian to the outside, and would be sad to see such important task delegated away.
I would like to see some more clarification on what exactly he wants to achieve, and how. Thinking globally is nice, but I don't see much concrete action points, for example.