Given the low participation, it looks like the choice of a DPL is difficult this year. It probably means that the platform of the candidates do no suit everybody… however with DPL teams, there’s more than just the DPL and in theory each member should have their own platform. That’s not the case for me because writing a platform is a big job… which I can avoid since I’m not candidate. 🙂
However I now do feel the need to tell what I would like to propose (and do) if I’m part of a team so that you know better what to expect if you vote for a team where I’m involved. I’d just like to give a warning, those items are quick notes and are in no way full- and flesched out solutions, they will need to be discussed and refined in all cases, and somes ideas may be dropped of course.
- Discuss with the core teams, ask their opinion on the problems / critics made outside. Make propositions and implement them myself when possible in order to unblock the situation when needed. Communicate the results to the DD.
- Discuss with NM, DAM and ftpmasters how to make the NM process evolve. An example of a possible solution sketched out on the basis of recent discussions could be :
- Require from candidates entering the NM process to setup a wiki page listing their regular contributions to Debian in the last 6 months.
- Allow NM who have been successfully sponsored on a package to upload themselves this package (and only this one, no NMU).
- Implement changes in the LDAP database to differentiate privileges (upload, unix account, vote, email) so that people who are not requesting upload rights can have a simplified NM process
- Ensure that the scripts to help management of keyring-maint have been written.
- Suggest to the press team to work with an associated debian-press mailing list which could review the announces before being sent and which could make proposals of announces as well.
- Make irc.d.o point to OFTC to put an end to the useless split on two networks.
- Discuss with DAM to change the expulsion process: the first step should be a mediation with the DPL (or someone delegated for that task) and not a public call for “seconds”… and if the process goes further, then the message indicating that the procedure continues will be posted by the mediator which should allows for more moderated messages.
- Try to moderate the first message of a new thread on debian-devel in order to redirect misplaced messages to the appropriate list and increase the quality of the list and get back people who unsubscribed because of the noise level.
- Try to document as much as possible from the working of core teams in some wiki pages.
- Ask everyone what decisions they would like the DPL to take (maybe use polls to evaluate suggestions).
This list is neither complete nor definitive. Not all items will be achieved but each of them is a real progress IMO and I’d like to be able to work on them.
For people who are concerned by those changes, I’m sorry if you discover my ideas by this post even before I had the opportunity to talk to you… I’m posting those ideas now because they may be considered by people who are currently voting, but it does *not* mean that I’m not interested to discuss them with you.
It’s also true that some of those ideas can be implemented without being part of the DPL team and I’ll certainly try to implement some whatever the outcome of the election, but I really believe that being part of a DPL team helps greatly because you have access to some important informations, and you can effectively discuss with core teams which are otherwise difficult to approach for non-technical discussions when you’re a random DD. And last but not least, the trust of the developers is a big motivation (at least for me) to work effectively on those problems.
See this post for my personal vote recommandation and see you in 3 days for the result of the election !
