Re: [Ticket#2011091710005702] SVN Extension Access

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Ticket#2011091710005702] SVN Extension Access

Olivier Beaton
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
<[hidden email]> 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
>> <[hidden email]> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Ticket#2011091710005702] SVN Extension Access

John Du Hart
>> 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.

--
John

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Ticket#2011091710005702] SVN Extension Access

MZMcBride-2
In reply to this post by Olivier Beaton
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



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Ticket#2011091710005702] SVN Extension Access

Neil Kandalgaonkar
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  |) <[hidden email]>

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Ticket#2011091710005702] SVN Extension Access

Sumana Harihareswara-2
In reply to this post by Olivier Beaton
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
> <[hidden email]> 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
>>> <[hidden email]> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Ticket#2011091710005702] SVN Extension Access

MZMcBride-2
In reply to this post by Neil Kandalgaonkar
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



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Ticket#2011091710005702] SVN Extension Access

MZMcBride-2
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Ticket#2011091710005702] SVN Extension Access

Neil Kandalgaonkar
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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

--
Neil Kandalgaonkar  |) <[hidden email]>

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Ticket#2011091710005702] SVN Extension Access

Max Semenik
In reply to this post by MZMcBride-2
On Sat, Nov 5, 2011 at 10:47 AM, MZMcBride <[hidden email]> 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?

--
Best regards,
Max Semenik ([[User:MaxSem]])
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Ticket#2011091710005702] SVN Extension Access

Bjoern Hoehrmann
* 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.
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Ticket#2011091710005702] SVN Extension Access

Tim Starling-2
In reply to this post by MZMcBride-2
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


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Ticket#2011091710005702] SVN Extension Access

Olivier Beaton
In reply to this post by Neil Kandalgaonkar
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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Ticket#2011091710005702] SVN Extension Access

Platonides
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.



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Ticket#2011091710005702] SVN Extension Access

Daniel Friesen-4
In reply to this post by Olivier Beaton
On Mon, 07 Nov 2011 09:10:09 -0700, Olivier Beaton  
<[hidden email]> 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.

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l