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
--
WikiWorks · MediaWiki Consulting ·
http://wikiworks.com