Hi,
It's great to hear that Git, once MediaWiki switches over to it, will solve some of the issues with granting access. Still, I assume no one knows exactly when the change-over will come - and I also assume that, even with Git in place, there will still be issues of access to the "official" repository for each set of code.
So let me propose a technical solution that is hopefully fully feasible: instead of separating out access by core MediaWiki vs. extensions, separate it out as: 1) core MediaWiki, 2) extensions used on public Wikimedia wikis, and 3) all other extensions. Or the separation could even be just MediaWiki core + WMF-used extensions vs. other extensions - two sets of code, separated by whether they're used on Wikipedia and the like.
The group of extensions used on WMF sites, and the group of those that aren't, are almost in two separate worlds - a bug or security hole in the former could potentially impact hundreds of millions of people, while such a bug in the latter would probably impact a few hundred or thousand people at most. If that kind of split were made, I think access to the non-WMF group could then be given almost immediately to anyone who demonstrated a basic understanding of MediaWiki coding, without any real fear of harm. The original extension under discussion, AdManager, for instance, is not going to end up anytime soon on a Wikimedia wiki, as you could guess from its name alone - so any bugs in that code are literally about a million times less important than bugs in extensions like FlaggedRevs.
Any new extensions would simply be grouped into the "non-Wikimedia" group - the Wikimedia group would be an opt-in thing.
There is a potential gray area, of extensions that aren't used in Wikipedia and the like but are used on helper wikis like translatewiki.net and the WMF infrastructure wiki - Replace Text and Semantic MediaWiki are two such extensions. Those could end up in either slot; I think it would be fine either way.
This ties in to something else I've thought about for a while: that maybe the CodeReview protocol should similarly be bifurcated, so that non-WMF extensions like, say, SocialProfile, don't get the same level of scrutiny as extensions like ParserFunctions. As an extension developer, I'm grateful for all the helpful reviews that my commits get - but if all that reviewing work is coming at the expense of the reviewing of code that's used on WMF sites, then it seems like a waste of resources.
Any thoughts on this idea?
-Yaron