Hi Tim, So that's exactly how I understand it. All programmers who seemed to be good enough were hired and now work as employees, while people who are working on their own have low priority (simply are ignored). That's why I say this philosophy kills the idea of open source, while it's surely good for foundation itself. There might be people who already have some work, don't wish to be employed by foundation (but want to help with the project, even if they are strange enough they don't demand money for that) or are just not good enough to be hired, it's clearly easier for foundation to assign interesting projects to paid staff and ignore the "newbies who could break things or strangers from internet who seems to know some stuff, but could break stuff as well as long as they are just some strangers who no one really knows, therefore it's hard to rely on them". In fact I don't disagree with this (I work in business environment and understand this philosophy), I am just trying to say that it turns mediawiki to product of "WMF company" from open source software driven by volunteers which it was in past. It should be clearly mentioned somewhere on guidelines for developers that attempts to create software which is supposed to be deployed to foundation sites will be likely overlooked. On Wed, Apr 4, 2012 at 2:45 PM, Tim Starling <tstarling(a)wikimedia.org> wrote:

On 04/04/12 22:58, Petr Bena wrote: We don't want to document it when we don't want it to be the case. Documenting it would give the impression that it is an acceptable situation. Anyway, it certainly isn't the case for core contributions, or for contributions to existing extensions, both of which have a healthy level of community commits. The problem is limited to new extension deployments, and perhaps to major core branch merges like IWTransclusion. We're not behaving like Oracle does with Java or MySQL, or like Google does with Android. We develop code in public repositories and grant commit access liberally. You're setting a high standard with your demands, but it happens to be a standard we want to meet. So please, keep nagging and watch this space. -- Tim Starling

*cough* LQT 3 is private because it doesn't exist... see the date of that email (hint, 1st day of April). If there were to be a project like that I expect it would be very very public indeed. ;-) Ariel Στις 05-04-2012, ημέρα Πεμ, και ώρα 09:10 +0200, ο/η Petr Bena έγραψε:

I don't know if this is a part of some joke https://www.mediawiki.org/wiki/LiquidThreads_3.0/status but it seems that someone wrote some code 2012/4/5 Petr Bena <benapetr(a)gmail.com>om>:

2012/4/5 Petr Bena <benapetr(a)gmail.com>om>: Yes, Werdna was working on it for a bit (hes currently attached to other WMF projects currently as to my understanding) iirc the code he was working on is under: SVN/mediawiki/branches/. (CC'ing Andrew, since well, we are discussing him)

Hey, NaturalLanguageList gets looked at again. NaturalLanguageList was not sufficiently inspiring to get included in the roadmap. I don't know about this particular extension and do not with the comment on it, but rather on the general notion of being "sufficiently inspiring". If a particular piece of code is or is not obviously depends on who you ask. Since CR is managed by WMF staff, it needs to be directly useful to WMF for review resources to be allocated. That might not be the official standpoint on it, but is what is happening as far as I can tell. So WMF is put before MediaWiki itself. I think this is bad for the community and blocks certain kinds of innovation to the software. I do not know how to improve the situation, but think it's important to acknowledge it (which many staff do not seem to do) as a first step. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --

2012/4/4 Petr Bena <benapetr(a)gmail.com>om>: That is quite true. What is even crazier is that the communities deploy a lot of pretty cool code in the form of scripts, gadgets, styles and templates, without asking the WMF. Probably, none of it can break the cluster as badly as bad PHP code in an extension can, but this code does have a lot of problems - among other things, it's hard to translate, to maintain and to port from project to project and it sometimes makes the user experience slow because of the huge heaps of JS involved. And nevertheless people create them and massively use them. Some projects absorb some of it completely - see the Ref Toolbar, which has become outrageously tightly integrated into the English Wikipedia. Much of it would be better done as proper extensions, which would be much easier to translate, install and maintain, but would never make the review process. I totally understand how hard it is, but we must at least dream about a world in which developing and deploying extensions is as easy as doing the same with gadgets. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

Le 05/04/12 00:27, MZMcBride a écrit : Which is an entirely different subject. You might want to send a new message just for that :-] Then I will happily reply about my specific case. -- Antoine "hashar" Musso

Le 06/04/12 20:49, Erik Moeller wrote: Gerrit is based on a SQL database, so we could probably build some reporting of activity. One possible metric would be the time between patch submission and its actual merging or abandon. -- Antoine "hashar" Musso

On Wed, Apr 4, 2012 at 10:46 AM, K. Peachey <p858snake(a)gmail.com> wrote: Yes, many times I asked on irc so many times I stopped counting, I created few bugzilla tickets, informed many developers who are working for wmf, and Mark Hershberger (I think there are many more who knew about it) Review takes so long that until it actually happen, the extension may not be needed anymore (read the first response - 2 years waiting for review and now it seems that a new technology will be implemented which may do similar stuff as extension itself) I don't say it didn't work in past, I say it's broken right now.

Yes, in past it worked. I don't know what is broken now, but it apparently doesn't work anymore. On Wed, Apr 4, 2012 at 10:46 AM, Amir E. Aharoni <amir.aharoni(a)mail.huji.ac.il> wrote:

Petr: My sympathies on the frustration. First I'm going to talk about the problem in general, then about your issue. Yes, the Wikimedia community is too slow to review contributions in general. The experienced developers who could do code review include many people who don't work for the Wikimedia Foundation, but many of them don't review patches or extensions, because they prefer to write code or don't have time for MediaWiki at all. Reviewing code is hard and tedious. It requires more skill than writing code does, more knowledge of MediaWiki internals and of Wikimedia site architecture, and most developers just don't think they're skilled enough to do it. Things we're doing to try to fix this: https://www.mediawiki.org/wiki/Code_review_management As Tim mentioned, WMF engineers are supposed to spend about 20% of their work time on tasks that serve the Wikimedia community, such as review of volunteers' contributions. https://www.mediawiki.org/wiki/Wikimedia_engineering_20%25_policy has the details. For the past several months, the most urgent need has been reviewing individual revisions submitted through the source control system, to get that backlog down so we could deploy 1.19. We have indeed done that. Rob Lanphier leads prioritization of 20% time so I'll wait for his input on whether it's feasible to switch priorities to extension review. The trade-off is that this would lead to an increase in our general Gerrit backlog and probably an increase in the number of patches in Bugzilla awaiting review (currently 177 for MediaWiki core + WMF-deployed extensions). As Bugmeister, Mark Hershberger has been championing the review and deployment of extensions in the review queue, such as the ShortURL extension, but of course hasn't had time to concentrate on that recently, given the urgent demands of the incoming bugs and of the MediaWiki 1.19 deployment and release. I reach out personally to ask experienced MediaWiki developers to review patches that have been submitted in Bugzilla. This has mixed results and costs so much time (for me) per patch that it simply can't scale up to the 150+ patches awaiting review. To address this, Mark is working on turning every patch in Bugzilla into a branch that gets submitted into Gerrit. That way automated tests will get run against those patches (to reduce the amount of work human reviewers have to do), and they'll be in the usual code review workflow. To teach and encourage developers to do more code review and extension review, we have led two code review trainings https://www.mediawiki.org/wiki/Code_review_management/Aug_2011_training and https://www.mediawiki.org/wiki/Code_review_management/July_2011_training and improved our code review documents https://www.mediawiki.org/wiki/Code_review_guide . I also personally reach out to strong developers to ask them if they'd like to be mentored to improve their code review skills. I don't know whether these have been effective. Maybe this thread will awaken a desire among other developers to help out by taking a look at these extensions and giving useful criticism. Now, about your situation specifically: In the extension review queue https://www.mediawiki.org/wiki/Review_queue I see one extension that's labeled (on its extension page) as authored by you, OnlineStatusBar. https://www.mediawiki.org/wiki/Extension:OnlineStatusBar When I look at the bug that's tracking its review, https://bugzilla.wikimedia.org/show_bug.cgi?id=32128 , I see that Timo wants to review the extension thoroughly but hasn't yet; I'll poke him about that. What's the other extension? You mentioned that there should be better guidelines. I think https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment is fairly comprehensive about the process except that it doesn't give any guidelines regarding time. Where were you looking for information about this process? Go ahead and link to this document there. -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation

Petr Bena wrote: is very look as never tried to improvement in this area, review of code may take years unless describing the current process, or people from even suggested to work on that. Regarding the 15 lines of code, are you referring to <https://bugzilla.wikimedia.org/show_bug.cgi?id=32819>? It looks like a bug was submitted on December 6. Less than a week later, Bawolff came along and reviewed the code (on December 15; see comment 3). And then you never responded to any of the review he left. Did you simply overlook it? It seems rather strange that you'd complain about this situation, though, so perhaps you're talking about a different 15 lines of code? Clarification would be appreciated. :-) There are a lot of problems with Wikimedia's/MediaWiki's code review processes, but in this particular case, it looks like the ball is in your court. (And, for what it's worth, I'm not sure your implementation of the idea makes much sense; see my comment on the bug.) And if you'd like to document the current practices/procedures regarding code review (including the excessive wait time), you're more than welcome to create or update a page on Meta-Wiki or MediaWiki.org (or several pages, go wild!). Tim's suggestion that to document the current situation somehow makes it more real is incredibly silly and can safely be ignored. Giving volunteer developers fair warning is the right thing to do, even if it currently involves ugly truths. MZMcBride