Hi all,
I am very disappointed by current development process we have on wikimedia project. The wikimedia project itself is classified as open source at some point, but the current development process sort of beats the purpose of that.
I started working on two extensions in October, more than 6 months ago. Both were approved by community on Village Pump and it was agreed to deploy them to english wikipedia. One of the extension had hundreds of lines and is considered as "bigger", the other one consist of +- 15 lines of code, which was developed together with Ian Baker who is employee of the wikimedia foundation. I was told that in order to deploy it, I need to pass code review. I requested code review many times on many places and although it was more than 6 months ago, no one seemed to be able to review these 15 lines of code so far, despite the community agreed with the idea of extension.
I understand it, that only employees of the foundation are actually permitted to write the code which is going to be deployed to wmf sites. If that is true, it should be noted somewhere, so that volunteers (the people who aren't employees / paid for that) can know that spending time on creating such an extensions, will likely result in it never going to be implemented, thus it's not anything they are suggested to do.
While this is secure for the foundation, so that it can actually have perfect control over the code which is wikimedia running on, it is sort of against the idea of open software.
So, it should be either described how this works, because if what I just said is true (I hope it's not) it should be definitely somewhere noted, to avoid getting more volunteers spending time on pointless work, or the development process should be completely changed so that it allows this "open source" project, to be actually open.
Thank you
On 4 April 2012 10:19, Petr Bena benapetr@gmail.com wrote:
I am very disappointed by current development process we have on wikimedia project. The wikimedia project itself is classified as open source at some point, but the current development process sort of beats the purpose of that.
I started working on two extensions in October, more than 6 months ago. Both were approved by community on Village Pump and it was agreed to deploy them to english wikipedia. One of the extension had hundreds of lines and is considered as "bigger", the other one consist of +- 15 lines of code, which was developed together with Ian Baker who is employee of the wikimedia foundation. I was told that in order to deploy it, I need to pass code review. I requested code review many times on many places and although it was more than 6 months ago, no one seemed to be able to review these 15 lines of code so far, despite the community agreed with the idea of extension.
I understand it, that only employees of the foundation are actually permitted to write the code which is going to be deployed to wmf sites. If that is true, it should be noted somewhere, so that volunteers (the people who aren't employees / paid for that) can know that spending time on creating such an extensions, will likely result in it never going to be implemented, thus it's not anything they are suggested to do.
While this is secure for the foundation, so that it can actually have perfect control over the code which is wikimedia running on, it is sort of against the idea of open software.
So, it should be either described how this works, because if what I just said is true (I hope it's not) it should be definitely somewhere noted, to avoid getting more volunteers spending time on pointless work, or the development process should be completely changed so that it allows this "open source" project, to be actually open.
My NaturalLanguageList extension[1] has been queued for code review since March 2010.[2] And I still believe WMF wikis like Wiktionary and Commons would greatly benefit from such an extension. At least until the Lua-wikicode thing gets worked out.
[1] https://www.mediawiki.org/wiki/Extension:NaturalLanguageList [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=22928
On 04/04/12 18:27, Svip wrote:
My NaturalLanguageList extension[1] has been queued for code review since March 2010.[2] And I still believe WMF wikis like Wiktionary and Commons would greatly benefit from such an extension. At least until the Lua-wikicode thing gets worked out.
I think it's pretty likely that the Lua feature will be live before NaturalLanguageList gets looked at again. NaturalLanguageList was not sufficiently inspiring to get included in the roadmap.
On 04/04/12 19:06, Petr Bena wrote:
My point is that if review of 15 lines of code, takes 6+ months, there is very likely a reason for improvement of current process, which may look as "working".
Larger things with more benefits tend to get a higher priority than smaller things. So it's usually quicker to get 1500 lines of code reviewed than 15.
In another post:
Yes, in past it worked. I don't know what is broken now, but it apparently doesn't work anymore.
WMF basically hired every MediaWiki developer with a significant amount of motivation and community trust, and then assigned interesting projects to them all. The senior developers who used to mentor community members and review contributed extensions now mentor teams of employees and review code written internally.
"20% time" is an attempt to correct broader related trends, but perhaps we need a more project-oriented approach within our 20% time policy in order to encourage mentoring and start the pipeline of contributed extensions moving again.
Personally, I've found it difficult to find the time and motivation to bring projects such as VipsScaler and the Score extension through to completion, even though I'm invested in them and personally care very much about the problems they address.
-- Tim Starling
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@wikimedia.org wrote:
On 04/04/12 18:27, Svip wrote:
My NaturalLanguageList extension[1] has been queued for code review since March 2010.[2] And I still believe WMF wikis like Wiktionary and Commons would greatly benefit from such an extension. At least until the Lua-wikicode thing gets worked out.
I think it's pretty likely that the Lua feature will be live before NaturalLanguageList gets looked at again. NaturalLanguageList was not sufficiently inspiring to get included in the roadmap.
On 04/04/12 19:06, Petr Bena wrote:
My point is that if review of 15 lines of code, takes 6+ months, there is very likely a reason for improvement of current process, which may look as "working".
Larger things with more benefits tend to get a higher priority than smaller things. So it's usually quicker to get 1500 lines of code reviewed than 15.
In another post:
Yes, in past it worked. I don't know what is broken now, but it apparently doesn't work anymore.
WMF basically hired every MediaWiki developer with a significant amount of motivation and community trust, and then assigned interesting projects to them all. The senior developers who used to mentor community members and review contributed extensions now mentor teams of employees and review code written internally.
"20% time" is an attempt to correct broader related trends, but perhaps we need a more project-oriented approach within our 20% time policy in order to encourage mentoring and start the pipeline of contributed extensions moving again.
Personally, I've found it difficult to find the time and motivation to bring projects such as VipsScaler and the Score extension through to completion, even though I'm invested in them and personally care very much about the problems they address.
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
That's probably not exactly what I wanted to say:
MediaWiki is clearly still open source at some point, as long as people (strangers / not just employees) are allowed to commit to repository. But the wikimedia project and site is not really that open, since people aren't allowed to submit any software improvements / changes (ok they are allowed to submit them, but will be ignored), as long as they are not employees of foundation. It makes a lot of sense, and is definitely more secure for website itself, but it's very misleading how the developer manuals on mediawiki site suggests that it's even possible.
On Wed, Apr 4, 2012 at 2:58 PM, Petr Bena benapetr@gmail.com wrote:
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@wikimedia.org wrote:
On 04/04/12 18:27, Svip wrote:
My NaturalLanguageList extension[1] has been queued for code review since March 2010.[2] And I still believe WMF wikis like Wiktionary and Commons would greatly benefit from such an extension. At least until the Lua-wikicode thing gets worked out.
I think it's pretty likely that the Lua feature will be live before NaturalLanguageList gets looked at again. NaturalLanguageList was not sufficiently inspiring to get included in the roadmap.
On 04/04/12 19:06, Petr Bena wrote:
My point is that if review of 15 lines of code, takes 6+ months, there is very likely a reason for improvement of current process, which may look as "working".
Larger things with more benefits tend to get a higher priority than smaller things. So it's usually quicker to get 1500 lines of code reviewed than 15.
In another post:
Yes, in past it worked. I don't know what is broken now, but it apparently doesn't work anymore.
WMF basically hired every MediaWiki developer with a significant amount of motivation and community trust, and then assigned interesting projects to them all. The senior developers who used to mentor community members and review contributed extensions now mentor teams of employees and review code written internally.
"20% time" is an attempt to correct broader related trends, but perhaps we need a more project-oriented approach within our 20% time policy in order to encourage mentoring and start the pipeline of contributed extensions moving again.
Personally, I've found it difficult to find the time and motivation to bring projects such as VipsScaler and the Score extension through to completion, even though I'm invested in them and personally care very much about the problems they address.
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 04/04/12 22:58, Petr Bena wrote:
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.
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
When we talk about the public code, why the development of new software like LQT 3 is private? Why community devs can't participate on that? When is it going to be pushed to readeable repository? I also heard from B Harris that there is a work on new interface design, which some code name, there is no code for it, why?
On Thu, Apr 5, 2012 at 5:47 AM, Tim Starling tstarling@wikimedia.org wrote:
On 04/04/12 22:58, Petr Bena wrote:
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.
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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
*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 έγραψε:
When we talk about the public code, why the development of new software like LQT 3 is private? Why community devs can't participate on that? When is it going to be pushed to readeable repository? I also heard from B Harris that there is a work on new interface design, which some code name, there is no code for it, why?
On Thu, Apr 5, 2012 at 5:47 AM, Tim Starling tstarling@wikimedia.org wrote:
On 04/04/12 22:58, Petr Bena wrote:
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.
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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
This isn't true?
https://www.mediawiki.org/wiki/LiquidThreads_3.0
On Thu, Apr 5, 2012 at 9:40 AM, Ariel T. Glenn ariel@wikimedia.org wrote:
*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 έγραψε:
When we talk about the public code, why the development of new software like LQT 3 is private? Why community devs can't participate on that? When is it going to be pushed to readeable repository? I also heard from B Harris that there is a work on new interface design, which some code name, there is no code for it, why?
On Thu, Apr 5, 2012 at 5:47 AM, Tim Starling tstarling@wikimedia.org wrote:
On 04/04/12 22:58, Petr Bena wrote:
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.
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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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@gmail.com:
This isn't true?
https://www.mediawiki.org/wiki/LiquidThreads_3.0
On Thu, Apr 5, 2012 at 9:40 AM, Ariel T. Glenn ariel@wikimedia.org wrote:
*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 έγραψε:
When we talk about the public code, why the development of new software like LQT 3 is private? Why community devs can't participate on that? When is it going to be pushed to readeable repository? I also heard from B Harris that there is a work on new interface design, which some code name, there is no code for it, why?
On Thu, Apr 5, 2012 at 5:47 AM, Tim Starling tstarling@wikimedia.org wrote:
On 04/04/12 22:58, Petr Bena wrote:
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.
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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
The mediawiki page is legit, although you'll notice that it's not been updated since last October; this reflects the fact that there's not current work going on. The email announcement to this list was not.
Ariel
Στις 05-04-2012, ημέρα Πεμ, και ώρα 09:47 +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@gmail.com:
This isn't true?
https://www.mediawiki.org/wiki/LiquidThreads_3.0
On Thu, Apr 5, 2012 at 9:40 AM, Ariel T. Glenn ariel@wikimedia.org wrote:
*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 έγραψε:
When we talk about the public code, why the development of new software like LQT 3 is private? Why community devs can't participate on that? When is it going to be pushed to readeable repository? I also heard from B Harris that there is a work on new interface design, which some code name, there is no code for it, why?
On Thu, Apr 5, 2012 at 5:47 AM, Tim Starling tstarling@wikimedia.org wrote:
On 04/04/12 22:58, Petr Bena wrote:
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.
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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2012/4/5 Petr Bena benapetr@gmail.com:
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
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)
On Wed, Apr 4, 2012 at 8:47 PM, Tim Starling tstarling@wikimedia.org wrote:
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.
I agree with this, but also with the fact that extension review is currently broken. Part of the answer, IMO, is going to have to be to trust more volunteers to do lots of legwork on getting extensions ready for deployment. Part of the answer is more systematic resourcing. Right now we're dealing with a flood of new committers across the board (thanks to the lightweight developer access process), so keeping up with changes to core and deployed extensions, and getting onto a two-week deployment schedule from core, is our highest priority internally.
Petr, regarding the extensions you're hoping will get deployed, do we have existing test setups in labs (single-instance wiki or deployment-prep) so we can give these more eyes from developers and non-devs alike? If not, would you be willing to set those up?
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.
This is very true. Moreover, we're not merely shipping a software product, but actually installing software on a top 5 web property with a large, active and vocal community. What seems trivial is often not. It's clear that WMF will get plenty of blame if we're seen to "ignore consensus" or install software with unforeseen negative side effects, so any extension, no matter how small or large, can potentially be fairly hairy. We do want to make sure we have eyeballs not just from devs but also from user interface/UX folks where needed.
Criticism is warranted and needed. However, I'm always interested in seeing examples of people or organizations who do a better job at solving the same kinds of problems. That would allow us to learn from them, and also add weight to criticism where we're failing to do the obvious. But mostly, these aren't obvious problems. Resourcing to support an ever-changing firehose of suggested changes, many of which should _not_ be made or need improvement, while also making our own pace of continued improvements is inherently hard -- as our problems with new editor retention in the all-volunteer editorial community show.
Erik
Hey,
On 4 April 2012 14:45, Tim Starling tstarling@wikimedia.org wrote: I think it's pretty likely that the Lua feature will be live before
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. --
On 4 April 2012 14:45, Tim Starling tstarling@wikimedia.org wrote: I think it's pretty likely that the Lua feature will be live before NaturalLanguageList gets looked at again. NaturalLanguageList was not sufficiently inspiring to get included in the roadmap.
I think that the correct question is if it was inspiring for the community of commons wiki, which it was designed for. When someone spends the time working on something what is useful for users of site, it should be naturally interesting enough for wmf to spend their time to review it (someone did a work for you, and doesn't even want any reward for that, can you at least look on the code?)
There were many complaints from side of community that wmf comes a lot with some stuff no one really wants or is interested in which is deployed no matter if it gained any consensus or not (simply - wmf overrides the community). Which is bit funny in this context when the "wanted" software made by volunteers is ignored, because it's not sufficiently inspiring for wmf, even if users wants it and some other software is deployed no matter if someone wants it.
I am wondering what makes the software "inspiring enough" to be deployed.
2012/4/4 Petr Bena benapetr@gmail.com:
On 4 April 2012 14:45, Tim Starling tstarling@wikimedia.org wrote: I think it's pretty likely that the Lua feature will be live before NaturalLanguageList gets looked at again. NaturalLanguageList was not sufficiently inspiring to get included in the roadmap.
I think that the correct question is if it was inspiring for the community of commons wiki, which it was designed for. When someone spends the time working on something what is useful for users of site, it should be naturally interesting enough for wmf to spend their time to review it (someone did a work for you, and doesn't even want any reward for that, can you at least look on the code?)
There were many complaints from side of community that wmf comes a lot with some stuff no one really wants or is interested in which is deployed no matter if it gained any consensus or not (simply - wmf overrides the community). Which is bit funny in this context when the "wanted" software made by volunteers is ignored, because it's not sufficiently inspiring for wmf, even if users wants it and some other software is deployed no matter if someone wants it.
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
Tim Starling wrote:
On 04/04/12 18:27, Svip wrote:
My NaturalLanguageList extension[1] has been queued for code review since March 2010.[2] And I still believe WMF wikis like Wiktionary and Commons would greatly benefit from such an extension. At least until the Lua-wikicode thing gets worked out.
I think it's pretty likely that the Lua feature will be live before NaturalLanguageList gets looked at again. NaturalLanguageList was not sufficiently inspiring to get included in the roadmap.
Which roadmap?
Petr Bena wrote:
Yes, in past it worked. I don't know what is broken now, but it apparently doesn't work anymore.
WMF basically hired every MediaWiki developer with a significant amount of motivation and community trust, and then assigned interesting projects to them all. The senior developers who used to mentor community members and review contributed extensions now mentor teams of employees and review code written internally.
s/interesting //
The project needs to (purportedly) advance a keyword from the list here: https://meta.wikimedia.org/wiki/Keywords in order to gain Wikimedia staff time, from what I can tell.
"20% time" is an attempt to correct broader related trends, but perhaps we need a more project-oriented approach within our 20% time policy in order to encourage mentoring and start the pipeline of contributed extensions moving again.
I asked about this "policy" a few months ago: http://lists.wikimedia.org/pipermail/wikitech-l/2012-March/058665.html.
Rob never replied and the thread died. There's a difference between having a page on MediaWiki.org and having a policy. From what I've seen, it's mostly the former, though I'd be thrilled if someone can prove me wrong.
MZMcBride
Le 05/04/12 00:27, MZMcBride a écrit :
I asked about this "policy" a few months ago: http://lists.wikimedia.org/pipermail/wikitech-l/2012-March/058665.html.
Rob never replied and the thread died. There's a difference between having a page on MediaWiki.org and having a policy. From what I've seen, it's mostly the former, though I'd be thrilled if someone can prove me wrong.
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.
On Wed, Apr 4, 2012 at 3:27 PM, MZMcBride z@mzmcbride.com wrote:
I asked about this "policy" a few months ago: http://lists.wikimedia.org/pipermail/wikitech-l/2012-March/058665.html.
Rob never replied and the thread died. There's a difference between having a page on MediaWiki.org and having a policy. From what I've seen, it's mostly the former, though I'd be thrilled if someone can prove me wrong.
Currently 20% is being enforced by reminders from Rob or his delegate during the days that a person's signed up for it. It's typically going towards code review or deployment support. When a person's not ponying up, Rob will escalate the issue if needed. In some cases we've created exemptions (e.g. fundraising engineering has only 2 staff right now, so they're exempt until they get a couple more engineers on board, so they can get any work done).
I'd love more metrics, of course. Do we have any git/gerrit metrics already?
Erik
Le 06/04/12 20:49, Erik Moeller wrote:
I'd love more metrics, of course. Do we have any git/gerrit metrics already?
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.
On Wed, Apr 4, 2012 at 6:19 PM, Petr Bena benapetr@gmail.com wrote:
I started working on two extensions in October, more than 6 months ago. Both were approved by community on Village Pump and it was agreed to deploy them to english wikipedia. One of the extension had hundreds of lines and is considered as "bigger", the other one consist of +- 15 lines of code, which was developed together with Ian Baker who is employee of the wikimedia foundation.
I was told that in order to deploy it, I need to pass code review. I requested code review many times on many places and although it was more than 6 months ago, no one seemed to be able to review these 15 lines of code so far
Who? Where?, Have you tried asking Tim or Roan on IRC?.
I understand it, that only employees of the foundation are actually permitted to write the code which is going to be deployed to wmf sites.
No, Everyone is. Just everything requires review before being pushed to the site and there is a smaller pool of those compared to those commit code (thus, Backlogs can occur). Since general MW code is reviewed by many eyes (Since its generally used by more people) compared to extensions which generally aren't reviewed as much in our normal code review process.
If that is true, it should be noted somewhere, so that volunteers (the people who aren't employees / paid for that) can know that spending time on creating such an extensions, will likely result in it never going to be implemented, thus it's not anything they are suggested to do.
While this is secure for the foundation, so that it can actually have perfect control over the code which is wikimedia running on, it is sort of against the idea of open software.
If that was the case, Half (by a small guess) of MediaWiki wouldn't exist.
Some extensions that come to mind (Attached names are rough memory)
* E:WikimediaIncubator - SQRobin * E:APISandbox - MaxSem (before he was a contractor) * E:AssertEdit - sanbeg * E:CategoryTree - Daniel K (i'm fairly certain, but not postive) * E:CLDR - Niklas iirc * E:ContactPage - Daniel K
https://www.mediawiki.org/wiki/Category:Extensions_used_on_Wikimedia will find you otheres I'm sure.
(CCing Tim/Roan since I mentioned their names, In the style I did).
On Wed, Apr 4, 2012 at 10:46 AM, K. Peachey p858snake@gmail.com wrote:
On Wed, Apr 4, 2012 at 6:19 PM, Petr Bena benapetr@gmail.com wrote:
I started working on two extensions in October, more than 6 months ago. Both were approved by community on Village Pump and it was agreed to deploy them to english wikipedia. One of the extension had hundreds of lines and is considered as "bigger", the other one consist of +- 15 lines of code, which was developed together with Ian Baker who is employee of the wikimedia foundation.
I was told that in order to deploy it, I need to pass code review. I requested code review many times on many places and although it was more than 6 months ago, no one seemed to be able to review these 15 lines of code so far
Who? Where?, Have you tried asking Tim or Roan on IRC?.
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)
I understand it, that only employees of the foundation are actually permitted to write the code which is going to be deployed to wmf sites.
No, Everyone is. Just everything requires review before being pushed to the site and there is a smaller pool of those compared to those commit code (thus, Backlogs can occur). Since general MW code is reviewed by many eyes (Since its generally used by more people) compared to extensions which generally aren't reviewed as much in our normal code review process.
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)
If that is true, it should be noted somewhere, so that volunteers (the people who aren't employees / paid for that) can know that spending time on creating such an extensions, will likely result in it never going to be implemented, thus it's not anything they are suggested to do.
While this is secure for the foundation, so that it can actually have perfect control over the code which is wikimedia running on, it is sort of against the idea of open software.
If that was the case, Half (by a small guess) of MediaWiki wouldn't exist.
Some extensions that come to mind (Attached names are rough memory)
- E:WikimediaIncubator - SQRobin
- E:APISandbox - MaxSem (before he was a contractor)
- E:AssertEdit - sanbeg
- E:CategoryTree - Daniel K (i'm fairly certain, but not postive)
- E:CLDR - Niklas iirc
- E:ContactPage - Daniel K
https://www.mediawiki.org/wiki/Category:Extensions_used_on_Wikimedia will find you otheres I'm sure.
I don't say it didn't work in past, I say it's broken right now.
2012/4/4 Petr Bena benapetr@gmail.com:
I understand it, that only employees of the foundation are actually permitted to write the code which is going to be deployed to wmf sites. If that is true, it should be noted somewhere, so that volunteers (the people who aren't employees / paid for that) can know that spending time on creating such an extensions, will likely result in it never going to be implemented, thus it's not anything they are suggested to do.
This is not correct - extensions by volunteers are deployed. To cite just two notable examples, Cite and CategoryTree. AFAIK, neither Ævar nor Daniel are or were paid by the WMF; Daniel works at WM-DE, but that's a separate organization.
That said, better documentation about the Foundation's process for deciding what is deployed would be quite useful.
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
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@mail.huji.ac.il wrote:
2012/4/4 Petr Bena benapetr@gmail.com:
I understand it, that only employees of the foundation are actually permitted to write the code which is going to be deployed to wmf sites. If that is true, it should be noted somewhere, so that volunteers (the people who aren't employees / paid for that) can know that spending time on creating such an extensions, will likely result in it never going to be implemented, thus it's not anything they are suggested to do.
This is not correct - extensions by volunteers are deployed. To cite just two notable examples, Cite and CategoryTree. AFAIK, neither Ævar nor Daniel are or were paid by the WMF; Daniel works at WM-DE, but that's a separate organization.
That said, better documentation about the Foundation's process for deciding what is deployed would be quite useful.
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
My point is that if review of 15 lines of code, takes 6+ months, there is very likely a reason for improvement of current process, which may look as "working". If I knew it works like it actually works I would never tried to work on what I did. So if there is not going to be improvement in this area, there should either be notification that review of code may take years unless you work for wmf on the page describing the current process, or people from community shouldn't be even suggested to work on that.
On Wed, Apr 4, 2012 at 10:54 AM, Petr Bena benapetr@gmail.com wrote:
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@mail.huji.ac.il wrote:
2012/4/4 Petr Bena benapetr@gmail.com:
I understand it, that only employees of the foundation are actually permitted to write the code which is going to be deployed to wmf sites. If that is true, it should be noted somewhere, so that volunteers (the people who aren't employees / paid for that) can know that spending time on creating such an extensions, will likely result in it never going to be implemented, thus it's not anything they are suggested to do.
This is not correct - extensions by volunteers are deployed. To cite just two notable examples, Cite and CategoryTree. AFAIK, neither Ævar nor Daniel are or were paid by the WMF; Daniel works at WM-DE, but that's a separate organization.
That said, better documentation about the Foundation's process for deciding what is deployed would be quite useful.
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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.
On 04/04/2012 09:14 AM, Sumana Harihareswara wrote:
Petr:
My sympathies on the frustration. First I'm going to talk about the problem in general, then about your issue.
I can't tell whether anyone read my message on the 4th. I know it was long, but that's because I was addressing pretty much all the open questions at the time. :-) If you have concerns about this issue, please do read it.
Petr replied to me offlist to straighten out his particular situation. It sounds like for one of his extensions the ball is in his court, and for the other (OnlineStatusBar), it's in the WMF's.
I've updated three pages to clarify and document our process: * https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment now explains that I'm the point of contact to get extensions authors their initial technical design reviews, Howie Fung is their contact to get initial user experience design reviews, and the release manager is their contact to get reviewed code deployed.
* https://www.mediawiki.org/wiki/Review_queue now has the status of each extension; about 8 are waiting for more WMF work, and 9 are waiting for responses from extension authors.
* https://www.mediawiki.org/wiki/Deployment_queue
So I need to get some user experience reviews and some technical/code reviews going for the 8 extensions that are awaiting more WMF work. Tim suggested that it might be more efficient and pleasant if WMF engineers could concentrate on one project each for their 20% community service time, and RobLa has now decided that I should be the one prioritizing and allocating 20%-time responsibilities. So I'm going to be asking some WMF engineers if they could switch from doing patch review (in Gerrit) to reviewing particular extensions, for their 20% days. I have a few people in mind.
Another snag, in at least one case, was that WMF engineers are unclear on who qualifies for deployment privileges and how to get them. That's something we started talking about in December in http://lists.wikimedia.org/pipermail/wikitech-l/2011-December/thread.html#56... and that still needs followup - I believe Ian is going to put some preliminary notes on mediawiki.org soon, and Platform Engineering (specifically RobLa & I) will follow up on that.
Hope this helps.
Petr Bena wrote:
My point is that if review of 15 lines of code, takes 6+ months, there
is very
likely a reason for improvement of current process, which may
look as
"working". If I knew it works like it actually works I would
never tried to
work on what I did. So if there is not going to be
improvement in this area,
there should either be notification that
review of code may take years unless
you work for wmf on the page
describing the current process, or people from
community shouldn't be
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
MZMcBride wrote:
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.)
Hello,
We also tends to be overwhelmed by mails, so a quick personal mail can often help having a specific code / bug to be rereviewed. Some volunteers are sending me direct mails from time to time which is great when I have miss a notification email.
I have no idea how many mail notifications I am receiving, but I am sure I am missing notifications. To give the readers an idea I get mails from:
- all mediawiki/core code review - my changes made to operations/puppet - some WMF only notifications lists - bugs I am subscribed too - upstream bugs I have reported - mw.org watchlist notifications
Weekend included, which is part of the reason my 20% is on Monday :-]
Whenever you do a comment, submit a patch, if nobody respond after someday, make sure they have actually seen your submission. If not ping them on IRC and then send a personal mail.
As for extensions review, I wish I could do some but I am already too busy keeping up with core, testing and continuous integration though. Unfortunately days are only 24hours :-((
cheers,
wikitech-l@lists.wikimedia.org