Dear Sumana,
I'm going to remove my application from consideration, this whole process has been demeaning and insulting and I've taken enough of a beating over it.
While full of optimism and excitement in mid-September, while constantly active in #mediawiki for over a month, the attitude of the developers (who you do not name, where's the transparency in this process?) and yourself have just leeched out any energy I have towards the MediaWiki community.
When I arrived, extension in hand (which is still mark in beta, I remind you, using your own template), people seemed friendly, encouraging me immediately to apply for access, so that more eyes could look at things and give feedback, which up to that point I was actively soliciting in IRC. In that time I've started two more extensions (each with multiple iterative releases, one in beta and another experimental), which is very clear given the download page for my Realnames extension which lists all three. The mere fact that here you are asking me if I've done anything other then Realnames shows a basic lack of interest in my application, my MW profile, my website where my downloads are hosted and described, as well as an ignorance to my daily presence and participation in IRC for most of September and almost all of October (I've been away on a trip at the very end).
If developers have criticism about my code, I'm happy. I want to actually receive it. I thought that was the whole point of asking for access, so you can get into the code review queue and actually receive that criticism and people can point you in the right direction. Considering I have an extension (and two more now, one beta and one experimental) that work, isn't slow even on large wikis (that I've tested, despite them not being as optimized as they could be -- perhaps if I had a chance to learn the MW Framework better and get feedback), shows that you "don't have to train me from scratch" as the wiki pages about svn access say.
At no point was any attempt made to contact me in IRC (despite my high level of participation there) to speed up this process in any manner, to ask for clarification or voice concerns. Instead it's been 7 weeks of silence with sudden burst of "produce this -- sorry no answer yet, with heavy undertones of doesn't look good".
There seems to have been concern with my original license, a BSD-2-Clause with copyright assignment so I don't lose the ability to distribute my code, this isn't the GPL, you need a contributor agreement with BSD (as I understand it). Yet absolutely no effort was made to communicate these concerns to me, or to work out what those issues were and how they could be resolved. I happen to have stumbled upon another project that had a more elegant solution to the BSD contribution problem (with a different type of contributor agreement) and it seems like that may have cleared things up. But I'm guessing here. From your emails it sounded like you were just ready to turn it down with a "Sorry we don't agree with your license". During which time no attempt was made to look at the code sample, just playing cat-and-mouse for weeks on a licensing concern to now arrive at a cat-and-mouse for weeks on code samples.
You've accused me in the past of not seeing you as a person, but just another staff person part of a bureaucratic organization, and yet in turn, no efforts have been made in this process to treat me like a human being.
To make it clear, I've never asked for core access, I'm not trying to mess up your project, all I wanted to do was be able to participate on equal footing in the community with other extension developers, to co-exist and grow and share knowledge. To take advantages of tools like code-review, the familiarity people have with the MW repo (and other who can contribute to it!) and distribution system.
You've made it painfully clear to me, and gauging from the message left by Yaron, to others as well, that despite all the smiles and nice words:
We're not welcome.
And to me, that's really sad. Olivier Beaton
p.s. I'm cc'ing wikitech-l not just out of frustration, but because I feel my feedback provides a meaningful contribution to the discussion Yaron started weeks ago on this very topic of access -- one which has seen near zero transparency in the community.
On Fri, Nov 4, 2011 at 10:21 PM, Commit access requests commit-access-requests@wikimedia.org wrote:
Olivier,
One of the access-granting developers looked at the code sample, Extension:Realnames, and had some criticisms, as it tries to find and replace all username links in the page output HTML, and the User::newFromName( $m['username'] ); query in the callback for each match is not batched.
He and the other developers would very much like to see more code from you in order to grant commit access -- do you perhaps have some other code samples you've written, for another project, or possibly for MediaWiki or MediaWiki extensions in the sadly long time it's been since you originally submitted this request?
Thank you.
best, Sumana
11/02/2011 01:01 - Olivier Beaton wrote:
Thanks for the update.
On Tue, Nov 1, 2011 at 8:48 PM, Commit access requests commit-access-requests@wikimedia.org wrote:
Olivier:
Thank you, again, for requesting commit access and being part of the MediaWiki community. The developers reviewing your application are fine with your new plan (the BSD-2-Clause license) and are now reviewing your code samples, and I expect a decision based on that code review within the week. Thank you, and sorry for the delay.
Sincerely, Sumana Harihareswara
One of the access-granting developers looked at the code sample, Extension:Realnames, and had some criticisms, as it tries to find and replace all username links in the page output HTML, and the User::newFromName( $m['username'] ); query in the callback for each match is not batched.
We're really being that nitpicky? I've seen some really shit-quality code committed to extensions, batch calling the User class is really minor thing that (imo) shouldn't halt this process. It's extensions access, not core, he's asking for.
That's what I have to say right now, I might some up with something else tomorrow.
Olivier Beaton wrote:
p.s. I'm cc'ing wikitech-l not just out of frustration, but because I feel my feedback provides a meaningful contribution to the discussion Yaron started weeks ago on this very topic of access -- one which has seen near zero transparency in the community.
I found much of your e-mail to be insightful. Thank you for sharing it.
While full of optimism and excitement in mid-September, while constantly active in #mediawiki for over a month, the attitude of the developers (who you do not name, where's the transparency in this process?) and yourself have just leeched out any energy I have towards the MediaWiki community.
The process has evolved quite a bit over time. At some point, it was on MediaWiki.org. Tim moved it to an OTRS queue and now there's some sort of Star Chamber involved in deciding who gets commit access. The current process and procedure is antithetical to Wikimedia's and MediaWiki's operating principles of openness, transparency, and a low barrier to entry. I think a few people realize this/have realized this, but the prevailing view among them is largely "fuck it, we'll switch to git soon and this won't be such an issue." You should not believe that everyone is supportive or accepting of the recent trends against transparency, though. That isn't the case.
At no point was any attempt made to contact me in IRC (despite my high level of participation there) to speed up this process in any manner, to ask for clarification or voice concerns. Instead it's been 7 weeks of silence with sudden burst of "produce this -- sorry no answer yet, with heavy undertones of doesn't look good".
Speed has never been a strong point of Wikimedia or MediaWiki development.
There seems to have been concern with my original license, a BSD-2-Clause with copyright assignment so I don't lose the ability to distribute my code, this isn't the GPL, you need a contributor agreement with BSD (as I understand it). Yet absolutely no effort was made to communicate these concerns to me, or to work out what those issues were and how they could be resolved. I happen to have stumbled upon another project that had a more elegant solution to the BSD contribution problem (with a different type of contributor agreement) and it seems like that may have cleared things up. But I'm guessing here. From your emails it sounded like you were just ready to turn it down with a "Sorry we don't agree with your license". During which time no attempt was made to look at the code sample, just playing cat-and-mouse for weeks on a licensing concern to now arrive at a cat-and-mouse for weeks on code samples.
The license issue sounds like a red herring. The basic requirement is that your code be compatible with the code it adapts/modifies and that it be FOSS. If people are getting caught up in petty copyright bullshit paranoia, they need to be taken out 'round back.
To make it clear, I've never asked for core access, I'm not trying to mess up your project, all I wanted to do was be able to participate on equal footing in the community with other extension developers, to co-exist and grow and share knowledge. To take advantages of tools like code-review, the familiarity people have with the MW repo (and other who can contribute to it!) and distribution system.
To be frank, the fact that you're able to compose coherent sentences makes you more skilled than a lot of the current people who have (full) commit access. Granted, the standards used to be a lot lower. But some of the people with full commit access are sometimes brilliantly bad. Some are even being paid to write bad code. :-/ I'm surprised they haven't approached you to be a contractor, given some of the people Wikimedia has been hiring lately... ;-)
You've made it painfully clear to me, and gauging from the message left by Yaron, to others as well, that despite all the smiles and nice words: We're not welcome.
The smiles and nice words seem to be a lot of passive-aggressiveness. I've seen some similarly disturbing behavior lately on Bugzilla, where patches are greeted with "great, thanks for submitting this patch; we haven't reviewed it, but maybe at some point we might; why don't you contribute more in the meantime?" There's a lot of presumption that people are interested in coding for MediaWiki, which has got to be in the running for most demeaning and demoralizing experience. The talented and untalented alike are flatly ignored on Bugzilla. People wanting to get code reviewed in SVN aren't likely to have much more luck either.
The amount of potentially free code that gets squandered every day would blow your mind. Instead of focusing on developing a community where people are interested in contributing code (and where they receive positive feedback from doing so), there's a system where only a few people have a chance of having their code reviewed or deployed within six to twelve months, otherwise you're SOL. It's been like this for a while and I think a lot of people agree that it sucks. I wouldn't hold my breath for it getting better any time soon.
The long and short of my advice is this: fuck MediaWiki. If they're unwilling to accept your contributions, there are a lot of other FOSS projects that would be happy to have you. Thrilled to have you, even. I'd strongly encourage finding one. :-)
MZMcBride
Olivier, I'm truly sorry you had such a negative experience. This is not an acceptable situation. We have an inconsistent process, and one which is a bit heavyweight when our resourcing for it is rather lightweight.
I wish you had found the patience to assume good faith. There is no reason for accusations that we don't want good developers. Of course we *want* them. If we are failing to act like it, it wasn't a personal slam at you.
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. And she did sound an apologetic note into the email she sent you. So IMO she's not the problem here. Why she played a game of telephone here is a bit of a mystery to me though -- maybe she just wanted to be sure that *someone* pinged you since it had been so long. IMO the developer who reviewed your code should have contacted you directly.
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.
I have some experience with user-contributed module archives, having administered some shared community resources for Perl, Python, and so on. The cultural differences and relative successes were interesting. The Python people wanted to have a review process, and a GUI interface, and binary modules precompiled, and so on and so on, and their projects never really got off the ground. Perl's CPAN started off as a simple FTP site where almost anyone could upload code. Guess which one ultimately succeeded. The point is, IMO there's relatively little payoff for having *any* review process for modules. Just have a way to report and remove malware and be done with it. As long as it's clear that the Foundation doesn't endorse the software there, what is the problem? Maybe we can also have some kind of badge for "reviewed" or "as seen on Wikipedia" for the stuff we consider good enough to deploy on big sites.
We already more or less do this -- for instance, there are modules by GSoC students that are clearly not ready for prime time, and they are marked accordingly.
On 11/4/11 11:47 PM, MZMcBride wrote:
The long and short of my advice is this: fuck MediaWiki. If they're unwilling to accept your contributions, there are a lot of other FOSS projects that would be happy to have you. Thrilled to have you, even. I'd strongly encourage finding one. :-)
And why should he listen to you, when you are unwilling to follow your own advice?
Neil Kandalgaonkar wrote:
On 11/4/11 11:47 PM, MZMcBride wrote:
The long and short of my advice is this: fuck MediaWiki. If they're unwilling to accept your contributions, there are a lot of other FOSS projects that would be happy to have you. Thrilled to have you, even. I'd strongly encourage finding one. :-)
And why should he listen to you, when you are unwilling to follow your own advice?
My contributions are largely in the form of bugs and #mediawiki support, neither of which have a barrier to entry. On rare occasion, I've submitted a patch to Bugzilla just to see how the process worked. It was pretty awful, so I don't spend much time on that.
If I wanted commit access, it probably wouldn't be terribly difficult for me to get it. But you can consider me part of the 99% who would contribute more if the process weren't so horribly and perpetually broken. I have no interest in submitting patches only to have them rot or, worse, submitting revisions only to have them sit for months unreviewed and undeployed.
In a lot of ways, a lot of people have already followed my advice. The people who are contributing primarily nowadays are doing so for a paycheck, aren't they? :-) That's how broken the process is. The only incentive people have to deal with it is the in form of a paycheck. And, of course, those people are enabled by being able to largely (if not wholly) bypass commit access queues or review queues. Neil, I'm sure you had a point; what was it again?
MZMcBride
MZMcBride wrote:
In a lot of ways, a lot of people have already followed my advice. The people who are contributing primarily nowadays are doing so for a paycheck, aren't they? :-) That's how broken the process is. The only incentive people have to deal with it is the in form of a paycheck.
I very briefly looked at the last 5000 revisions to the MediaWiki repository, grouped by author. I added a column to mark whether the author is working for or has worked for Wikimedia. I don't really have the time or patience to do a lot of analysis on this. I can say that, assuming the third column is correct, 41 of the 101 listed authors worked for or work for Wikimedia. That's actually a bit less than I expected. The contribution totals are completely skewed, though, rather unsurprisingly. Of the last 5000 revisions, 3737 came from people with a mark in column 3 (74.74%). So 74.74% of contributions made by 40.59% of the authors.
On average, "paid authors" made 91.15 contributions; "unpaid authors" made 21.05 contributions.
These numbers, taken alone, aren't particularly surprising. I think when you factor in the number of potential contributors (people with a basic understanding of SVN + PHP + FOSS), it looks a lot more bleak.
It'd be interesting to get a breakdown on number of reviewed vs. unreviewed revisions for each author or even time between commit and resolution of the revision, but the sun is shining, so I think I'm going to go outside. :-)
mysql> select -> cr_author, -> count(*) -> from code_rev -> where cr_repo_id = 1 -> and cr_id > 97108 -> group by cr_author; +----------------+----------+---+ | cr_author | count(*) | ? | +----------------+----------+---+ | aaron | 371 | + | | akshay | 2 | | | amire80 | 28 | + | | ariel | 34 | + | | asher | 24 | + | | ashley | 35 | | | awjrichards | 122 | + | | bachsau | 1 | | | bawolff | 18 | | | ben | 9 | + | | bharris | 5 | + | | bkaempgen | 5 | | | blobaugh | 6 | | | brion | 100 | + | | btongminh | 21 | | | catrope | 323 | + | | cervidae | 29 | | | churchofemacs | 1 | | | ckepper | 2 | | | cryptocoryne | 9 | | | dale | 3 | | | danny_b | 5 | | | dantman | 39 | | | danwe | 13 | | | dasch | 19 | | | demon | 65 | + | | diederik | 2 | | | erik | 13 | + | | ezachte | 14 | + | | faurethomas | 2 | | | flohack | 1 | | | foxtrott | 40 | | | fptc | 5 | | | freakolowsky | 2 | | | gicode | 1 | | | greg | 1 | | | gregchiasson | 1 | | | gwicke | 12 | + | | halfak | 1 | + | | happy-melon | 14 | | | hartman | 14 | | | hashar | 78 | + | | ialex | 159 | | | inez | 94 | + | | j | 4 | + | | jamesur | 6 | + | | jeroendedauw | 360 | + | | jhsoby | 6 | + | | johnduhart | 71 | | | jpostlethwaite | 161 | + | | junaidpv | 22 | | | kaldari | 130 | + | | khorn | 104 | + | | kipcool | 7 | | | krinkle | 90 | + | | kwisatz | 8 | | | laner | 28 | + | | liangent | 19 | | | mah | 53 | + | | malvineous | 1 | | | maxsem | 29 | | | mglaser | 4 | | | midom | 2 | | | mkroetzsch | 29 | | | nad | 1 | | | neilk | 51 | + | | nelson | 13 | + | | nikerabbit | 181 | + | | nimishg | 1 | + | | ning | 8 | | | overlordq | 6 | | | petrb | 90 | | | pgehres | 48 | + | | philip | 10 | | | platonides | 80 | | | preilly | 224 | + | | py | 3 | + | | questpc | 23 | | | raindrift | 23 | + | | raymond | 177 | | | reedy | 503 | + | | robin | 32 | | | rotem | 5 | | | samuellampa | 3 | | | santhosh | 52 | + | | saper | 3 | | | sean_colombo | 14 | | | shizhao | 3 | | | siebrand | 110 | + | | smoke3723 | 5 | | | sumanah | 1 | + | | thenub314 | 1 | | | tparscal | 215 | + | | tstarling | 39 | + | | vasilievvv | 3 | | | vitalif | 6 | | | vyznev | 1 | | | werdna | 38 | + | | wikinaut | 26 | | | yaron | 123 | | | yonishostak | 1 | | +----------------+----------+---+ 101 rows in set (27.56 sec)
MZMcBride
On 11/5/11 11:36 AM, MZMcBride wrote:
MZMcBride wrote:
In a lot of ways, a lot of people have already followed my advice. The people who are contributing primarily nowadays are doing so for a paycheck, aren't they? :-) That's how broken the process is. The only incentive people have to deal with it is the in form of a paycheck.
I very briefly looked at the last 5000 revisions to the MediaWiki repository, grouped by author. I added a column to mark whether the author is working for or has worked for Wikimedia. I don't really have the time or patience to do a lot of analysis on this. I can say that, assuming the third column is correct, 41 of the 101 listed authors worked for or work for Wikimedia. That's actually a bit less than I expected. The contribution totals are completely skewed, though, rather unsurprisingly. Of the last 5000 revisions, 3737 came from people with a mark in column 3 (74.74%). So 74.74% of contributions made by 40.59% of the authors.
On average, "paid authors" made 91.15 contributions; "unpaid authors" made 21.05 contributions.
These numbers, taken alone, aren't particularly surprising. I think when you factor in the number of potential contributors (people with a basic understanding of SVN + PHP + FOSS), it looks a lot more bleak.
It'd be interesting to get a breakdown on number of reviewed vs. unreviewed revisions for each author or even time between commit and resolution of the revision, but the sun is shining, so I think I'm going to go outside. :-)
mysql> select -> cr_author, -> count(*) -> from code_rev -> where cr_repo_id = 1 -> and cr_id> 97108 -> group by cr_author; +----------------+----------+---+ | cr_author | count(*) | ? | +----------------+----------+---+ | aaron | 371 | + | | akshay | 2 | | | amire80 | 28 | + | | ariel | 34 | + | | asher | 24 | + | | ashley | 35 | | | awjrichards | 122 | + | | bachsau | 1 | | | bawolff | 18 | | | ben | 9 | + | | bharris | 5 | + | | bkaempgen | 5 | | | blobaugh | 6 | | | brion | 100 | + | | btongminh | 21 | | | catrope | 323 | + | | cervidae | 29 | | | churchofemacs | 1 | | | ckepper | 2 | | | cryptocoryne | 9 | | | dale | 3 | | | danny_b | 5 | | | dantman | 39 | | | danwe | 13 | | | dasch | 19 | | | demon | 65 | + | | diederik | 2 | | | erik | 13 | + | | ezachte | 14 | + | | faurethomas | 2 | | | flohack | 1 | | | foxtrott | 40 | | | fptc | 5 | | | freakolowsky | 2 | | | gicode | 1 | | | greg | 1 | | | gregchiasson | 1 | | | gwicke | 12 | + | | halfak | 1 | + | | happy-melon | 14 | | | hartman | 14 | | | hashar | 78 | + | | ialex | 159 | | | inez | 94 | + | | j | 4 | + | | jamesur | 6 | + | | jeroendedauw | 360 | + | | jhsoby | 6 | + | | johnduhart | 71 | | | jpostlethwaite | 161 | + | | junaidpv | 22 | | | kaldari | 130 | + | | khorn | 104 | + | | kipcool | 7 | | | krinkle | 90 | + | | kwisatz | 8 | | | laner | 28 | + | | liangent | 19 | | | mah | 53 | + | | malvineous | 1 | | | maxsem | 29 | | | mglaser | 4 | | | midom | 2 | | | mkroetzsch | 29 | | | nad | 1 | | | neilk | 51 | + | | nelson | 13 | + | | nikerabbit | 181 | + | | nimishg | 1 | + | | ning | 8 | | | overlordq | 6 | | | petrb | 90 | | | pgehres | 48 | + | | philip | 10 | | | platonides | 80 | | | preilly | 224 | + | | py | 3 | + | | questpc | 23 | | | raindrift | 23 | + | | raymond | 177 | | | reedy | 503 | + | | robin | 32 | | | rotem | 5 | | | samuellampa | 3 | | | santhosh | 52 | + | | saper | 3 | | | sean_colombo | 14 | | | shizhao | 3 | | | siebrand | 110 | + | | smoke3723 | 5 | | | sumanah | 1 | + | | thenub314 | 1 | | | tparscal | 215 | + | | tstarling | 39 | + | | vasilievvv | 3 | | | vitalif | 6 | | | vyznev | 1 | | | werdna | 38 | + | | wikinaut | 26 | | | yaron | 123 | | | yonishostak | 1 | | +----------------+----------+---+ 101 rows in set (27.56 sec)
MZMcBride
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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
Olivier Beaton wrote:
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).
In this case, as you were active in irc, it indeed seems that it would have been faster if you were said "We are going to discuss it at #commit-cabal on the midnight of Friday 13. Can you make it at #sacrifices while we discuss?" That way, you could have been asked the questions on the fly instead of such slow back-and-forth.
On Mon, 07 Nov 2011 09:10:09 -0700, Olivier Beaton olivier.beaton@gmail.com wrote:
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
Small side note, better access separation isn't the only thing the git migration does. The plan seams to be to use a gated trunk model. One with gerrit such that anyone can have a labs/git account, using that account you can push a commit and it shows up a changeset in gerrit, from there once it's reviewed it makes it's way into trunk. Under that model of committing to trunk everyone is pretty much equal. Whether you're a long-time committer or you just got an account a second ago by filling out a form and getting one automatically anyone can get a change in for review and changes are reviewed individually by developers rather than forcing non-developers to deal with reviewing a person based on their past code.
On Sat, Nov 5, 2011 at 10:47 AM, MZMcBride z@mzmcbride.com wrote:
While full of optimism and excitement in mid-September, while constantly active in #mediawiki for over a month, the attitude of the developers (who you do not name, where's the transparency in this process?) and yourself have just leeched out any energy I have towards the MediaWiki community.
The process has evolved quite a bit over time. At some point, it was on MediaWiki.org. Tim moved it to an OTRS queue and now there's some sort of Star Chamber involved in deciding who gets commit access. The current process and procedure is antithetical to Wikimedia's and MediaWiki's operating principles of openness, transparency, and a low barrier to entry. I think a few people realize this/have realized this, but the prevailing view among them is largely "fuck it, we'll switch to git soon and this won't be such an issue." You should not believe that everyone is supportive or accepting of the recent trends against transparency, though. That isn't the case.
At no point was any attempt made to contact me in IRC (despite my high level of participation there) to speed up this process in any manner, to ask for clarification or voice concerns. Instead it's been 7 weeks of silence with sudden burst of "produce this -- sorry no answer yet, with heavy undertones of doesn't look good".
Speed has never been a strong point of Wikimedia or MediaWiki development.
There appear to be problems with every system we've used so far for granting commit access: 1) Initially, commit access was given by senior developers (=Brion or Tim) after a private email to them. This system was highly dependent on their workload because they had to consider everything themselves. 2) When a public page for commit access requests was created, it worked great for community participation in discussion and it had actually taken some load off senior developers' shoulders - eg volunteers advised the candidates on stuff like "this is not a valid SVN username" and "please activate email on your mw.o account so that you will receive CR notifications". Transparency was great, too. The only problem with this system was that it was also great in letting people forget about pending requests for a long time. 3) OTRS allows to see conveniently what needs to be done and how long it's been waiting for reply, however it is not transparent, prone to mistakes by a single human like in Huib's case, and puts all the workload on several staffers, stealing a couple of man-hours per week from the Foundation's limited resources.
So my proposal is to handle commit access requests in the way most other FLOSS projects do it: on the dev mailing list. Public discussions will give far more eyes for analysis of every application and allow decision-makers to make final decisions by glancing through public discussions instead of analysing everything themselves. And transparency will make all accusations of cabalism or carelessness impossible. What do you think about this idea, people?
* Max Semenik wrote:
So my proposal is to handle commit access requests in the way most other FLOSS projects do it: on the dev mailing list. Public discussions will give far more eyes for analysis of every application and allow decision-makers to make final decisions by glancing through public discussions instead of analysing everything themselves. And transparency will make all accusations of cabalism or carelessness impossible. What do you think about this idea, people?
Any system that does not make it easy for "decision makers" to identify pending requests will likely suffer from decision makers missing pending requests, and in my experience even having a dedicated mailing list that only handles access requests so you could identify pending ones, say, by looking for threads that have not been replied to by a decision maker, is not good enough, as that kind of filtering is not well supported by typical mail software. There are many ways to support "show me pending requests" functionality, but "glancing" is not one of them, FWIW.
On 05/11/11 17:47, MZMcBride wrote:
The process has evolved quite a bit over time. At some point, it was on MediaWiki.org. Tim moved it to an OTRS queue and now there's some sort of Star Chamber involved in deciding who gets commit access.
The main reason I moved it to OTRS was so that messages from requesters would send me an email notification, allowing me to shorten the response time. While it was on the wiki, I only managed to check it about once a month. With OTRS, I could do batches of new requests once a week, and respond to followups immediately.
The current system involves a weekly phone meeting involving Sumana and a couple of developers, consisting mostly of silence as people read tickets and code. The outcomes for each ticket are basically:
1. Sumana finds some problem with how the request was written. She'll make a note and eventually send a followup asking for more information. No code review is done.
2. Code review is done and looks fine. Sumana makes a note and approves the request within a day or so.
3. Code review is done and there is some problem. Usually the developer will make a private note, and then Sumana will handle writing the response.
4. Oops, out of time. Outcome deferred for another week.
The old system wasn't perfect. I didn't really like writing rejections, so for some people, I left the ticket open for months when I didn't want to approve them. And a couple of times, I put the whole thing out of my mind for a month or so and didn't approve anyone.
The theory behind this new system was that Sumana would be able to communicate with volunteers with more tact and grace than a developer would be able to manage, and would be able to follow up rapidly, thus leading to happier new committers who are more willing to contribute.
For whatever reason, it doesn't seem to be working as planned. I think some changes are required.
The license issue sounds like a red herring. The basic requirement is that your code be compatible with the code it adapts/modifies and that it be FOSS. If people are getting caught up in petty copyright bullshit paranoia, they need to be taken out 'round back.
He wanted to have a contributor agreement which required anyone who changed the file in Subversion to assign copyright to him. The content was all under a BSD-style license and anyone could modify it, so the contract would have to have the form "if you agree to assign copyright, I will agree to allow you to commit to this file".
This kind of agreement is quite common in certain circles, but for it to work, the person who you're making the contract with has to be able to restrict write access to the source code repository. Since Olivier wasn't going to be able to restrict commit access himself, and we weren't going to do it for him, the contributor agreement didn't make sense.
Olivier gave a detailed response. The complexity of the issue seems to have resulted in Olivier's ticket being left in the "too hard" basket for about a month.
The smiles and nice words seem to be a lot of passive-aggressiveness. I've seen some similarly disturbing behavior lately on Bugzilla, where patches are greeted with "great, thanks for submitting this patch; we haven't reviewed it, but maybe at some point we might; why don't you contribute more in the meantime?"
It's not passive-aggressive, it's just misjudged.
-- Tim Starling
Hi, Olivier. I just woke up and saw this message, and I'm on my way out the door to a volunteering appointment, but I'll be writing a longer response later today. I am taking these concerns seriously; I'm sorry that I can't respond immediately.
Regards, Sumana Harihareswara
On 11/05/2011 01:32 AM, Olivier Beaton wrote:
Dear Sumana,
I'm going to remove my application from consideration, this whole process has been demeaning and insulting and I've taken enough of a beating over it.
While full of optimism and excitement in mid-September, while constantly active in #mediawiki for over a month, the attitude of the developers (who you do not name, where's the transparency in this process?) and yourself have just leeched out any energy I have towards the MediaWiki community.
When I arrived, extension in hand (which is still mark in beta, I remind you, using your own template), people seemed friendly, encouraging me immediately to apply for access, so that more eyes could look at things and give feedback, which up to that point I was actively soliciting in IRC. In that time I've started two more extensions (each with multiple iterative releases, one in beta and another experimental), which is very clear given the download page for my Realnames extension which lists all three. The mere fact that here you are asking me if I've done anything other then Realnames shows a basic lack of interest in my application, my MW profile, my website where my downloads are hosted and described, as well as an ignorance to my daily presence and participation in IRC for most of September and almost all of October (I've been away on a trip at the very end).
If developers have criticism about my code, I'm happy. I want to actually receive it. I thought that was the whole point of asking for access, so you can get into the code review queue and actually receive that criticism and people can point you in the right direction. Considering I have an extension (and two more now, one beta and one experimental) that work, isn't slow even on large wikis (that I've tested, despite them not being as optimized as they could be -- perhaps if I had a chance to learn the MW Framework better and get feedback), shows that you "don't have to train me from scratch" as the wiki pages about svn access say.
At no point was any attempt made to contact me in IRC (despite my high level of participation there) to speed up this process in any manner, to ask for clarification or voice concerns. Instead it's been 7 weeks of silence with sudden burst of "produce this -- sorry no answer yet, with heavy undertones of doesn't look good".
There seems to have been concern with my original license, a BSD-2-Clause with copyright assignment so I don't lose the ability to distribute my code, this isn't the GPL, you need a contributor agreement with BSD (as I understand it). Yet absolutely no effort was made to communicate these concerns to me, or to work out what those issues were and how they could be resolved. I happen to have stumbled upon another project that had a more elegant solution to the BSD contribution problem (with a different type of contributor agreement) and it seems like that may have cleared things up. But I'm guessing here. From your emails it sounded like you were just ready to turn it down with a "Sorry we don't agree with your license". During which time no attempt was made to look at the code sample, just playing cat-and-mouse for weeks on a licensing concern to now arrive at a cat-and-mouse for weeks on code samples.
You've accused me in the past of not seeing you as a person, but just another staff person part of a bureaucratic organization, and yet in turn, no efforts have been made in this process to treat me like a human being.
To make it clear, I've never asked for core access, I'm not trying to mess up your project, all I wanted to do was be able to participate on equal footing in the community with other extension developers, to co-exist and grow and share knowledge. To take advantages of tools like code-review, the familiarity people have with the MW repo (and other who can contribute to it!) and distribution system.
You've made it painfully clear to me, and gauging from the message left by Yaron, to others as well, that despite all the smiles and nice words:
We're not welcome.
And to me, that's really sad. Olivier Beaton
p.s. I'm cc'ing wikitech-l not just out of frustration, but because I feel my feedback provides a meaningful contribution to the discussion Yaron started weeks ago on this very topic of access -- one which has seen near zero transparency in the community.
On Fri, Nov 4, 2011 at 10:21 PM, Commit access requests commit-access-requests@wikimedia.org wrote:
Olivier,
One of the access-granting developers looked at the code sample, Extension:Realnames, and had some criticisms, as it tries to find and replace all username links in the page output HTML, and the User::newFromName( $m['username'] ); query in the callback for each match is not batched.
He and the other developers would very much like to see more code from you in order to grant commit access -- do you perhaps have some other code samples you've written, for another project, or possibly for MediaWiki or MediaWiki extensions in the sadly long time it's been since you originally submitted this request?
Thank you.
best, Sumana
11/02/2011 01:01 - Olivier Beaton wrote:
Thanks for the update.
On Tue, Nov 1, 2011 at 8:48 PM, Commit access requests commit-access-requests@wikimedia.org wrote:
Olivier:
Thank you, again, for requesting commit access and being part of the MediaWiki community. The developers reviewing your application are fine with your new plan (the BSD-2-Clause license) and are now reviewing your code samples, and I expect a decision based on that code review within the week. Thank you, and sorry for the delay.
Sincerely, Sumana Harihareswara
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org