On 10/03/2011 05:18 PM, Brion Vibber wrote: > On Mon, Oct 3, 2011 at 6:30 AM, Yaron Koren <[email protected]> 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?
He mentioned the ad manager extension, and linked to it, but did not mention that others were vouching for him. > 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 I am looking forward to this. But in the meantime, let's make sure we clarify our ruleset. -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
