On Mon, Oct 3, 2011 at 4:30 PM, Yaron Koren <yaron(a)wikiworks.com> wrote: I was under the impression that getting one *was* easy...but admittedly things have changed quite a bit since 2008. I don't think it was Sumana's personal decision, as I believe that a group of people decide what to do with pending commit access requests. In any case, I would have to agree with your conclusion, as I did some review and fixing on the mentioned AdManager extension. I'm sure that we've had some incompetent developers in the past, but becoming a competent dev takes some time and work. :-) Yeah, it certainly seems like that. If and when we want to encourage people to share their code and receive various fixes, rejecting valid commit access requests isn't the way to do that. +1 I wouldn't know, as the process has changed over the years, but I have to say that I liked it when commit access requests were on the MediaWiki.org wiki ([[mw:Commit access requests]]) -- IMO it was a better and more transparent way to manage commit access requests than an OTRS queue or whatever is used nowadays; then again, I'm just giving suggestions here, I'm not here to make any decisions as I'm not employed by the Foundation. Thanks and regards, -- Jack Phoenix MediaWiki developer

On Mon, Oct 3, 2011 at 6:30 AM, Yaron Koren <yaron(a)wikiworks.com> wrote: [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

On Mon, Oct 3, 2011 at 6:30 AM, Yaron Koren <yaron(a)wikiworks.com> wrote: I'm going to leave it to Sumana for the more complete reply here (she and I just spoke). Sumana inherited our existing process, and she's been running it about as well as it can be run. I think she's probably been uncomfortable breaking with tradition while she's relatively new and there's a lot of stakeholders, but I think we've got some room to break with tradition. As it stands, we kinda backed into our current process. When I came on board, Tim had just moved over to OTRS. I spent some time with him understanding the process and figuring out how to speed things up, eventually pulling in other developers. Sumana took over the process at this point, which basically involves a handful of folks (Tim, Chad, and Aaron, I believe) quickly reviewing applications, and Sumana helping to dispatch responses. Since a lot of people are applying, there are quite a few to get through. I think the process could benefit from some transparency on both sides of the equation. I know from talking to her Sumana would love to have a wider pool of developers to vet the list, and a more transparent process would make that easier. Those requesting access can help things by being more transparent, too. Developers who post to the mailing list and participate in IRC will have a lot easier time getting access (assuming they say sensible things in those venues). It's a lot less scary giving access to someone when you have enough information to speculate on what they're likely to do with it, and they've proven that they play well with others. Since we don't have a process for reversing our decision (has anyone ever had their svn access revoked?), we're naturally going to be more conservative about who we let in. Anyway, as Brion says, we're likely to change things around pretty substantially when we migrate to Git, anyway, so we shouldn't spend too much time worrying about what svn access looks like for everyone. I don't want to use that as an excuse to shut down any improvement, but merely want to remind people of why we aren't likely to do anything really radical in the short term. Rob

Caution: long! On 10/03/2011 09:30 AM, Yaron Koren wrote: I agree. I checked with Ike to ensure that he was okay with us discussing his rejection in public -- he hadn't known, but said it was okay. So I'm pasting here in full the response I wrote to Isaac, after having Rob, Chad, Tim, and Aaron review his request and code: The bits that were left out of the excerpt, but that I do think are relevant: I pointed him to further reading, to help him improve his code quality, and suggested that he talk with us on IRC for more detailed feedback, again to help improve his code quality. In general, this is the kind of rejection notice I send, when Chad, Tim, and Aaron decide to reject an applicant. If an applicant has SQL injection or cross-site scripting issues in their code sample, then I specifically advise them about that using a templated text. I would like to provide more constructive and specific feedback, but since that would demand more time per request and we're usually backlogged, I've chosen speed of response over length, and suggested to rejected applicants that they ask for more feedback if they want it. About a third do. As others in this thread pointed out before I got to it -- I'm not the one making the decisions on whether to grant access. Right now it's Chad, Tim, and Aaron. That second point sometimes doesn't get enough attention: yes, when we grant commit access, we are committing to keeping up with post-commit review of that person's code. If the person looks likely to make a lot of mistakes, that adds to our load pretty substantially. And so reviewers get a bit fearful about saying yes. (This of course ties into our ongoing exhortations to code reviewers to be revert-happy, but that's a little beyond the scope of this email.) I believe the reviewers' opinion of this code differed markedly from Yaron's, which is the reason for the rejection. Yes, and that's wrong. Once we straighten out what the actual criteria should be (and I suspect they'll include a division between core and extensions access), I'll want to update that page. Yes, there are groups of developers whom we don't screen hard at the moment of commit access request: Google Summer of Code students, for example, and Wikimedia Foundation developers. The commonalities: they're working as part of teams, they're mentored/managed by developers with commit access, they've already been through at least some competence gating process run by people we trust, and they've made dedicated formal commitments to the work. I feel somewhat comfortable with this, because we're dealing equally with anyone who's in that situation, paid or more volunteer-ish. The wiggle words in there are "basically" and "works". As I see it, the commit access reviewers are very concerned about the code quality of incoming code, because of the post-commit review issue. I think the current situation is not reflective of our stated policy, and that we should both change the situation and articulate a clear policy. My proposal: * Continue to be strict with commit access requests for core, but be far more lenient with commit access requests for extensions * Get more eyes on the commit access review queue, especially for extensions, to ensure reviewers have the time to give applicants specific constructive feedback * Continue to use OTRS for now, because it's a proper ticketing system, and because it allows some privacy for rejection, because I think that's apt to allow more people to apply, and allow us to give more specific and critical feedback to novices in a way that might feel hurtful to them in public; ** split the OTRS queue into core and extensions queues so we can have more reviewers for the extensions queue I'll give further replies to others' posts in this thread. -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation