I'm going to try to continue the conversation wrt process, and how things can be improved in the future.
I wish you had found the patience to assume good faith.
Delays are expected in any process. In my case it took 3 weeks before my request was looked at, and Sumana was always realistic about this and event sent me a "heads up things are taking awhile" note. While the delays are regrettable, sometimes they are unavoidable.
What ended up bothering me is a further 4 weeks of back and forth emails about "can you tell us more about __X__" only to be met with a "about __Y__" and "about __Z__". Looking at why this is, and how it can be improved should be Issue #1. Where great customer relations fails is when the process shows it hasn't followed due-process, it comes off as sugar coating.
And, if I may be forgiven for white-knighting, Sumana's job is to needle the rest of us so we don't forget about concerns like yours and she generally does it very well.
I don't think Sumana's communication skills wrt writing nicely worded emails is at issue here, but the process as a whole. It's not my intention to single out someone in the process.
IMO the developer who reviewed your code should have contacted you directly.
Having a formal process discourages informal communication. This is a bit of a given, and doesn't mean process is bad, but I think it's important to keep things in perspective. Like you say, sometimes a short informal meeting goes a long way to resolving a lot of bureaucratic red-tape.
In my case a lot of the back-and-forth seemed centered around licensing issues, which can be fairly complex (if you take a look at the robla licensing thread). I tried twice to approach the only point of contact I had (Sumana) to start a discussion about this informally, but was met with what I felt was a "sorry the council in session behind closed doors, please wait until they make their decision" or at the least "I can't really talk about this without everyone being here". Again this is not an attack on Sumana personally, but on the process.
I would of loved it if she had been empowered to say something about what the issues being discussed were, and be able to further facilitate communication between the people raising the issues and myself. I understand sometimes this isn't possible, but given how active I am in IRC and that I (had) a standing rapport with Sumana and other developers, this didn't seem out of the question. Instead each time I waited a week only to learn some new issue was raised. I never knew who these people raising these issues were (so that I wouldn't harass them? I admit this can be a a real issue).
Perhaps the assumption of good faith should rest on the review committee. It seems attractive at first to "process" requests as quickly as possible, to go "reject reject reject done!", rejecting them based on their first inconsistency with policy. But this is fake speed, and only serves to alienate the people who may be contributing to your project for years to come. No instructor would hand you back your essay with the first grammar mistake and say "please fix line one and resubmit", only to then hand it back to you with line 2 highlighted.
I think the review committee should do a complete evaluation of each request they receive, and provide complete feedback. Even if this took an extra week, it wouldn't result in the 7 I did. I think establishing what the things they should look at is worthwhile. Here's a short list off the top of my head:
a) Code example submitted b) Their involvement in the community I) Wiki II) Lists III) IRC c) In the case of extensions, look at what they've put up. Look at the discussion page if present to see how they communicate with their users.
I had a look at the module you wrote. I share some of the same concerns about scalability, but that's not really the issue.
You're right, it's not. And ironically if the committee had looked at the talk page for the Realnames extension, at the very top I had added a FAQ item (before they looked at my extension) explaining my concerns about scalability, and how I planned to solve them in future betas (preferring to release working, iterative code, especially in a new environment where I wasn't yet sure what the proper thing to do was).
This brings us to an interesting point, that the code sample for commit access becomes the first code review the developer receives. In some cases their first interaction with the community. And there is tremendous worth in this. The commit page indicates MW is ready to help you learn MW, but they don't want to teach you to program. In this case I think my experience, and the experience of many others (see Yaron's colleague, who still does not have access) would be much improved if they received something like:
"We looked at your code and would be happy to have you join us. Here's your access so you can get started, it's limited to __X__. Part of being part of the MW community is helping each other out using code reviews, so please consider this your first one -- We found...."
Assuming you found them a "competent programmer". This reinforces your message instead of seeming double-speak "we want you" / "oh but you're not perfect yet".
On 11/4/11 11:47 PM, MZMcBride wrote:
The long and short of my advice is this: fuck MediaWiki.
This isn't very productive. I can of course continue to use my own hosting and tools, but in so far as MediaWiki is concerned, they should be concerned about how to be welcome and make best use of the tools they have. Hence this discussion. Talk of "take it or leave it". While sometimes things have to come to that, it's usually counter-productive (looking at you Rob).
In terms of transparency, my opinion is that access request page should indicate who the committee comprises of, and more of the contents of the discussions taking place should be revealed to both the requester and the community as a whole (for example code review results to the lists!). While adding additional overhead it may be worthwhile for the committee to maintain a wiki page indicating who's requested access (sitting in the queue) and at what stage their request is at, with some indication to when the meetings are taking place (or being delayed). I got some of this in IRC but making it more transparent to everyone would be a plus. highlighting how long the person has been waiting (and if an intervention or closer examination to why it's taking so long) would be another plus.
On Max Semenik's suggestion to do things on the mailing list:
Doing everything on the mailing seems a bit overkill, and I agree would probably bog the process down too much. But see above my suggestion about posting code-reviews here. This could even be done ahead of the meeting "so-and-so has submitted extension:X for review, we would welcome the community to provide feedback ahead of us meeting" and you either get some responses or none. As long as this didn't delay things significantly (after all it's optional), and it seems a win either way the commit request goes.
Tim Starling describes the process
Please see my note above on how the process should be a complete-review, instead of this "back and forth". Yes this means sometimes a "deal breaker" means you wasted a bit of your time, but you're looking at someone who has already invested significant amount of time in the community, and is proposing to spend much more. I think it's worth giving them your attention for longer then it takes to find the first error.
This also makes the assumption that just because there is a problem in the request, doesn't mean that it can't be successful, once you talk to them and get those issues worked out. Time to closing tickets is not everything (and I admit mine was never closed until I did).
As so far as having someone who is people-oriented like Sumana fronting such a process, I think that's great. I just think the process needs to be humanized a bit so she can do her job properly.
And to those who will say "git will fix everything" I should point out nothing in this thread is fixed by having easier access restrictions (ie, restricting access from all of core, to all extensions, to a specific extension -- the last which git solves), and instead tries to look at the question of "do we want this code in the community repository?"
- Olivier