On Wed, Oct 30, 2002 at 09:48:41AM -0800, Craig Dickson wrote: RC>>>>> When it comes to a vote only developers can vote just as only RC>>>>> patricians voted in Rome. DB>>>> The difference is, any individual who *wants* to, *can* become DD RC>>> Really? DB>> At least it worked for me, and for everyone else I know who tried. DB>> Do you have a counter-example of a person who applied to become a DB>> DD and was turned down? CD> The DAM has the authority to turn people down and I believe he has CD> done so on occasion. I don't have any names handy, sorry.
The only probable reason for DAM explicitly turning people down could be that person was not ready to meet the requirements of the Social Contract and/or Policy, in which case it can be argued that said person was not actually trying to _become_ DD (which requires being ready to meet the requirements), but to only receive title and rights of DD. Again, without names, it is only hot vapor, I'm just guessing. CD> Additionally, the current DAM is known to have been sitting on CD> applications for up to a year or more without acting on them or CD> even letting people know the status of their application. At least CD> one person has recently, on this very list, announced the CD> withdrawal of his application due to frustration. This may not be CD> exactly the same as "turned down", but functionally speaking, it is CD> unpleasantly similar. It also discourages other prospective DD's CD> from even applying; why bother submitting an application just so CD> some guy can sit on it indefinitely without ever even giving you CD> any idea what its status is? At the very least, this is widely agreed to be a _problem_ for Debian, it is against Debian _principles_, and there are people working on _fixing_ this. In short, it is a bug, not a feature. Last time we had such problems with DAM becoming a bottleneck in accepting new DDs, NM process was improved, and statistics on nm.d.o don't look bad. Now we are having problems with keyring-maint, but I don't see any reason why this can't be solved, too. -- Dmitry Borodaenko
