Road to the Python Commit Bit

a) You sign up at our SSI, KDE Identity (identity.kde.org).

b) Once you've got an Identity, you'll find a form to request developer access in the web app that manages it. That form asks you to optionally name a supporter for your application, and provide a written justification.

c) Our sysadmin team (of which I'm a part) is tasked with screening the incoming applications. What we look for in doing so is evidence that the applicant has already gathered some experience in working with the community, especially in the form of prior patch contributions, which we encourage them to list in their written justification. If the applicant has named a supporter, we check with the supporter to get their confirmation and opinion on the applicant. If we're satisfied the applicant knows the ropes, the request will be granted; if not, we encourage some further social mingling and patch-based contributions first and to re-try later.

In practice, it's relatively hard, but not entirely impossible, to gain developer access without naming a supporter, because evidence of social ties / working relationships with other team members is very important to us. Occassionally a proven track record of successfully getting lots of patches through review will be enough, and occassionally a low-quality justification will result in a rejection even despite a supporter (after conferencing with them on the matter).

The goals here are to make sure every new developer can immediately act confident about their role in the project, that everyone knows the etiquette well enough to work together productively, and that mutual trust remains high as everyone can rely on their peers having been through the same process.

d) Once you have your developer access, that's basically it: Aside from a few sensitive areas that require additional, special karma that must be requested separately (mainly the websites to avoid embarassing and directly public-facing screwups), all of our developer accounts have equal write access to every repository.

In other words, KDE embraces a flat, meritocratic hierarchy and broad access. We certainly make use of review-based workflows (some teams more than others), but they're enforced by social etiquette, not by ACLs. We find that this makes for a lovely atmosphere in the community and a sense of shared responsibiliy over all our products, and consider it key to our longevity as a successful open source project.

Contrasting with the nine month timespan between first patch submission and getting push access mentioned in the linked article, I'd say our average is probably closer to six months. It can be significantly lower than that, and it can be longer, too.