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