On Tue, Feb 28, 2006 at 10:06:34PM +0100, Josselin Mouette wrote: > 1. As you are promoting the team leadership that has been in place > since Branden's election, do you have explanations for the total > absence of leadership during this time? What could you tell to > convince us it's still worth a try?
I don't think your assessment that there was a total lack of leadership is true. What you maybe mean is a lack of guidance; public leadership as in a leader that leads the way, promotes his agenda with the project, and motivates the DD's to follow. It is of course debatable what would be good to have here. Anyway, leadership needs to come from a leader. How the past year went, isn't to my complete satisfaction. I find my platform and the things I want to achieve important, and am determined to hold onto my campaign promises. As such, the DPL team is only part of it, and should make it easier for me to achieve my goals. I will treat the team as such, I expect it to facilitate achieving those goals together. However, if for some reason, the DPL team is actually counter-productive, I will not hesitate to drop (part of) it. I think I can do that, because DPL team members should be there to help achieve the goals I set, and if it doesn't help, the individual members can of course still scratch whatever itches they have their way -- but just as a normal DD can do. What the DPL team do will be my responsibility, and I will take it fully. I really don't expect this to be needed, and think that together with a number of helpful people, we can achieve more than that I could do alone. I simply intend to take on the leadership part inside the DPL team much more strongly. > 2. You seem to consider the useless discussions on mailing lists an > important issue. What real world problems do you think it leads > to? - A lot of time wasted across the board (also people who are normally doing really good work in Debian want to follow the lists to some extent, there might be important things in it). - Inability to have technical issues that affect the whole project discussed productively with a useful result that can be implemented, with slower deployment of new techniques as a result. Instead, such discussion find place hidden away on some smaller list or IRC channel, thusly excluding part of the developers from discussing along. - Preventing/discouraging people to join Debian when they don't feel Debian is a place for them, because all that seems to happen is a huge discussions with no end, and a significant lack of respect for fellow developers. - Radicalisation, because extreme points of view are proclaimed the loudest, and this attracts people with extreme views. > 3. Could you explain how a code of conduct for mailing lists would > help reducing the number of posts that are merely useless, > without being aggressive? Same question for the people who are > killing discussion by always bringing up the same issues, > without ever being aggressive. Any code of conduct cannot really change Debian into a 'perfect' world with no flames, no repetition, no useless posts. Maybe with Orwellian efforts, it might, and we'll end up with "teletubby-type" of lists. But we can do better than the current situation. In my opinion, there needs to be some upper limit how far people can go. What that limit should be exactly, is still to be worked out, but shouldn't be too low, most people shouldn't need to bother about it. The upper limit should only apply to the type of posts that can at times really degrade the list quality badly. For posts that don't cross the line, but still are unproductive, it's better to use social pressure: kind private mails pointing out how one is not being productive, etc. Some "best practices" document might help this by explaining well, best practices (something based on the Debian Community Guidelines is what I'm thinking of). But care should be taken that this won't become another "Does this post really need to be private" type of remark that causes more traffic itself than the traffic it intends to reduce. By not having aggressive and abusive posts, the atmosphere should be much more friendly, and provide grounds for people to kindly hint others if they are being unproductive. The goal is to ensure that technical discussions prevail again our technical lists, without killing the type of related discussions that are *also* important for the wellbeing of a project like Debian. > 4. As a member of the FTP team, do you have any explanations about > the amd64 fiasco, and why we should vote for you despite that > outstanding failure for a team you are part of? I don't think it's a fiasco. At some point it became clear that there really was no way to put amd64 in the archive before the Sarge release. So it would be for etch. I talked about this with Steve Langasek last November, and based on the release schedule, I intended to put some serious effort myself in it by february or so, if there would be not enough progress then. But Anthony Towns has been working steadily on it, so I didn't feel the need, and worked instead on other things I can more effectively work on (I'm 'just' an FTP-assistent, I cannot change the infrastructure any more than you can -- by providing patches, proof of concepts, etc, though admittingly, I'm in a better position help). AJ has put much more thought in the implementation details, and has more experience with working with the infrastructure, and for each given task, it's always most effective to have the best suited person work on it. I have no reason to believe there'd be any problem with getting amd64 in the archive well before etch is released, so I'm not going to try to 'fix' things that are not broken. Of course as ftp-master team member, I will keep following this and helping where help is requested, but that has not much to do with myself as potential DPL or as current DPL team member. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
