MJ Ray wrote:
That reminds me of one thing that has annoyed me during tbm's leadership (sorry tbm! You have done most things well): it has been very difficult to correct the bastard form of my name listed on db.d.o that was caused by a misconfigured mailserver years ago. The admin@db address seems like an alias for /dev/null and the DPL directed a complaint back to it.
I think it's far more important for people working on Debian to focus their attention on improving our operating system; if "Mark J Ray" is a correct variant of your name, no matter how bastardised, I don't think it's worth worrying about changing that to "MJ Ray" while there are things on the TODO list that effect development directly.
1. Will DPL candidates try to address delegate communication in general? Deal with each case individually?
I believe I've already indicated my answer in the general case. In particular cases, my approach is to contact people privately to try to find out what's going on in a way that doesn't encourage further criticism -- unfortunately that tends to require a fairly high degree of opaqueness. I can't think of any way of giving concrete examples that doesn't conflict with that policy, either; ie, that wouldn't encourage people to criticise the people I've tried to encourage to be more open.
2. How would the candidate deal with complaints? Is it part of the DPL's role, in your opinion? If not, whose?
Every item in the bug tracking system is a complaint, I don't think it's the DPL's job to deal with every one of those, and I don't think it's the DPL's job to deal with every disagreement anyone has with a delegate. I think the DPL's job is to focus on the areas where Debian can most benefit from some attention, and I think that does include things like improving the signal to noise ratio on our mailing lists, and probably doesn't include someone's name being bastardised in the developer database.
Cheers, aj