On Mon, Oct 3, 2011 at 6:30 AM, Yaron Koren <yaron(a)wikiworks.com> wrote:
I think developer accounts on the Wikimedia SVN
repository should be
easier to get. I say this because a consultant of ours at WikiWorks,
Ike Hecht, asked for a developer account last week and was rejected.
He created his first major MediaWiki extension, Ad Manager, recently,
which I added to the repository a few weeks ago - you can see it here:
[snip]
Specifically as regards stand-alone extensions we've generally been much
more liberal than for core -- perhaps Ike forgot to mention that this is for
maintenance of an extension that's already been committed and that several
people are vouching for him and his code?
Generally speaking...
TL;DR summary: we also want to make it easier to get involved; this is a
work in progress! :)
We're currently in a sort of no-mans-land in trying to make sure our
policies are reasonably responsive and consistent, knowing that we're
sitting just ahead of a planned migration from SVN to Git which will change
the permissions landscape.
In a Git world, it should become a *lot* easier to fully participate in the
development ecosystem without having to get an account manually approved and
created.
Part of what us coders need about having a SVN account now is simply that
without direct checkin ability, you can't, well, check anything in. :) You
otherwise have to wait on other people to look at your code before it even
gets into the system, and your commit won't even have your name on it when
it gets there. :(
In git-land though, we can basically eliminate most of the distinction
between a "submitted patch" (floating around from Bugzilla, mailing list, or
IRC) and something that's been committed-but-not-yet-reviewed (the scary
world of CodeReview, where bad code can live on breaking other things until
people figure out how to fix it months later ;).
Commits will be fully labeled with the names of their creators, whether they
got committed straight to core by Tim Starling himself or whether they came
in as a pull request from someone who's forwarding work from someone we've
never seen before.
Review and fixes can happen on a custom branch -- fully versioned -- and be
merged in to mainline after further commits are made to tweak them.
Being able to maintain extensions as standalone git repositories will
further reduce the difficulty of getting in: setting yourself up with a git
account and creating repos for your extensions will become entirely
self-serve (no need to "ask" for every individual git permission).
We should end up in a better position to do both totally self-serve and
semi-curated work (eg, shared maintenance of translations and security
updates).
-- brion