Brainstorm here about how to overhaul the various sets of DebConf permissions so that things can get done without unnecessary bottlenecks while still keeping private things as secure as needed.
 Cross-application/infrastructure duplication of permissions
One major source of slowdowns and anti-Auir demotivationalism arises from numerous same or similar permissions sets across the many pieces of our infrastructure. There is already a debconf ldap set up for access to debconf machines, but as far I know, most or none of the applications are tied in to it. At a first pass from memory we have at least these resources, each of which has to have rights requested and managed seperately:
- front accounting
- alioth repos
- git repo
I don't even want to think about the matrix formed with those multiplied by the functional roles dedicated persons play and the probable mis-matches in naming and definitions across apps.
 "Too many already have that access, already. Ask one of them to do it for you" "but, but, but they aren't active this year!?!"
Perhaps at set times in each year of the DebConf development cycle a ping or metric of persons with various perms can be done to gauge who is still active vs. who has been trying to get work done, but, been turned away with the above rationale. Limiting the total number of people with progressively more powerful permissions is a genuinely good thing, but those lists at various levels don't have to be static, do they?
Limiting the total number of people with progressively more powerful permissions is not genuinely a good thing. This is a fallacy.