We'd then pick off the keywords as we step through the process (e.g. once it's reviewed, remove the "need-review" keyword). We could then generate three queries to get us the three queues I alluded to above: 1. Issues with all three keywords. These are features that someone would like to see deployed and launched, but needs to be reviewed first. 2. Issues with "need-deploy" and "need-enabled". These are extensions that have been reviewed, but need to be checked into the production branch 3. Issues with "need-enabled" only. These are extensions/features that just need action from ops. Does this make sense? If so, I'll add the keywords and start documenting the process and retrofitting existing feature requests into this system.

Hi everyone, One discussion we had at the Hack-a-ton was about the continued frustration of getting features deployed to the WMF-operated sites. Prior to Hack-a-ton, one short-term solution we started work on was consolidating the review queue into a single place: http://www.mediawiki.org/wiki/Review_queue That page still needs some organization and a process around it to make sure that we're actually looking at the page. However, our discussion at Hack-a-ton made it clear that even if we have a well-tuned process there, we still have features rolling off the end of that conveyor belt onto the floor. After review, some (but not all) of the features in the review queue then need to be reviewed for checking into the deployment branch. Our short term answer to that was the deployment queue: http://www.mediawiki.org/wiki/Deployment_queue Even then, we're still not done. We have one more step, which is launching the feature on one or more wikis. We could also create another queue page for that. However, given the complicated workflow here, it seems that a wiki is the wrong tool to keep track of this. My inclination at this point is to augment the list of keywords on Bugzilla, and use mediawiki.org to document the process, and as a place to stash the magical queries to pull up the right lists. We already have the "need-review" keyword. I suggest we add two more keywords: "need-deploy" and "need-enabled". Then we add all three keywords to feature requests that need to go through the whole process before being deployed. For example, we'd add all three to this issue: https://bugzilla.wikimedia.org/show_bug.cgi?id=25454 We'd then pick off the keywords as we step through the process (e.g. once it's reviewed, remove the "need-review" keyword). We could then generate three queries to get us the three queues I alluded to above: 1. Issues with all three keywords. These are features that someone would like to see deployed and launched, but needs to be reviewed first. 2. Issues with "need-deploy" and "need-enabled". These are extensions that have been reviewed, but need to be checked into the production branch 3. Issues with "need-enabled" only. These are extensions/features that just need action from ops. Does this make sense? If so, I'll add the keywords and start documenting the process and retrofitting existing feature requests into this system. Rob _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I wasn't present in D.C. so can't comment on the arguments made there, but it is my understanding that there are people who are responsible for reviewing code who aren't able/willing to deploy it - so this isn't something that has a binary state.

Also, I think it would be useful to document the movement between review, deployment, and enabling - as even if this is done by a single person they might not be able to complete it in one session, and the transparency is nice.

Correct me if I'm wrong, but I believe we're talking specifically about completely unreviewed extensions that need looking at entirely - not incrementally. Certainly once an extension has been initially reviewed and deployed, the existing code review system would come in to effect - and I don't think we need to change anything with that at the moment.

I agree that review and deployment are two parts of a whole and that one doesn't make sense without the other, but I don't think that, of the two, deployment is necessarily the defining part.

After review, some (but not all) of the features in the review queue then need to be reviewed for checking into the deployment branch. Our short term answer to that was the deployment queue: http://www.mediawiki.org/wiki/Deployment_queue

From my position of next to the mozzie bite on the backside of a common breed of antelope

Rob Lanphier wrote: I have a few comments. You're chomping at the edges again, but not focusing on the larger issue. It's still about _WHO_ is going to be deploying these extensions (or doing general code updates). That question is still unresolved and it's at the heart of the problem. By focusing on the periphery, you're simply needlessly adding paperwork (like the new "Deployment queue") without actually accomplishing anything. Read on for a specific example of why deployment is sometimes the sole issue, not review. The issue with focusing on a "Review queue" is that it puts the focus and emphasis in the wrong place. Nobody cares about getting their code reviewed (per se). They want their code live on the site. Most developers don't care if their code is efficient or not (Domas can speak more to this), they just want to see their hard work in production. That's why they contribute code (or contributed, as the case seems to be nowadays). So the emphasis should be on deployment, a key step of which is code review, to be sure. But putting the focus on review (as though once review is finished, something will magically change) is silly and a poor idea. Regarding extension deployment in general, one of the issues that seems to be overlooked is why it's necessary to require individual sites to request that a feature be enabled. As long as there aren't performance concerns, an extension should be enabled by default. Let's look at a specific example. Here's the current configuration for DynamicPageList: 'wmgUseDPL' => array( // controls loading of DynamicPageList extension 'default' => false, 'dewiktionary' => true, 'enwiktionary' => true, 'incubatorwiki' => true, 'metawiki' => true, 'otrs_wikiwiki' => true, 'srwiki' => true, 'strategywiki' => true, 'wikibooks' => true, 'wikimania2009wiki' => true, 'wikimania2010wiki' => true, 'wikimania2011wiki' => true, 'wikinews' => true, 'wikiquote' => true, 'wikiversity' => true, ), Inexplicably, "'wikisource' => true" and "'wikitionary' => true" are missing. It also sets the default to false, even though the vast majority of sites could have this extension without any issue. The consequence of this is that the following bugs are currently open asking for this extension to be enabled on a Wikimedia wiki: nlwiki | https://bugzilla.wikimedia.org/show_bug.cgi?id=6163 iswiktionary | https://bugzilla.wikimedia.org/show_bug.cgi?id=7952 eswiktionary | https://bugzilla.wikimedia.org/show_bug.cgi?id=7952 bswiki | https://bugzilla.wikimedia.org/show_bug.cgi?id=8240 dewikisource | https://bugzilla.wikimedia.org/show_bug.cgi?id=8563 enwikisource | https://bugzilla.wikimedia.org/show_bug.cgi?id=8563 hewikisource | https://bugzilla.wikimedia.org/show_bug.cgi?id=8563 viwiktionary | https://bugzilla.wikimedia.org/show_bug.cgi?id=8886 plwiktionary | https://bugzilla.wikimedia.org/show_bug.cgi?id=11788 nlwikibooks | https://bugzilla.wikimedia.org/show_bug.cgi?id=15477 frwiki | https://bugzilla.wikimedia.org/show_bug.cgi?id=19810 frwikisource | https://bugzilla.wikimedia.org/show_bug.cgi?id=22250 itwikisource | https://bugzilla.wikimedia.org/show_bug.cgi?id=25172 This is (literally) a two-line change that would resolve a large amount of old bugs. Of course this doesn't consider that plenty of sites are simply suffering in silence, having not yet understood how to file a shell bug or, more likely, having watched the progress of the other bugs, I would imagine a good number of communities have simply decided to not waste the time filing a bug that's simply going to be ignored. I don't see how this acceptable or desirable, especially given that this is an example of an extension that has been reviewed, but is purely in the "deployment" arena now. Before someone starts shouting about not considering the performance of large sites, I'll note that according to my numbers, the largest Wiktionary by number of pages (enwiktionary) has this extension enabled.[1] Perhaps there are more complex reasons that this extension can't be enabled elsewhere; I'd certainly be interested in hearing them. I imagine the people waiting years for this extension to be enabled would be interested as well. Call me pessimistic, call me cynical, call me whatever, but take a look at https://bugzilla.wikimedia.org/show_bug.cgi?id=7952 and tell how this is acceptable. This bug will celebrate its fourth birthday this month on November 16. Somehow I don't think the Icelandic Wiktionary with its 19,000 pages is going to crash the servers. Perhaps the addition of a Bugmeister will allow this type of problem to get more attention, though I think it's kind of ridiculous that it's going to require an additional full-time staff member to point out what anyone taking a minute to research can point out right now. MZMcBride [1] https://wiki.toolserver.org/view/Wiki_server_assignments _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Likewise, I think we should first focus on enabling more people to do merge+scap (maybe the same group who review code?) and get it going on a more often basis.

+1. I feel like we're trying to change a workflow when we should be trying to get rid of a backlog. Instead of trying to discuss ways to improve the workflow, we should Just Do It.

One discussion we had at the Hack-a-ton was about the continued frustration of getting features deployed to the WMF-operated sites. Prior to Hack-a-ton, one short-term solution we started work on was consolidating the review queue into a single place: http://www.mediawiki.org/wiki/Review_queue That page still needs some organization and a process around it to make sure that we're actually looking at the page.  However, our discussion at Hack-a-ton made it clear that even if we have a well-tuned process there, we still have features rolling off the end of that conveyor belt onto the floor. After review, some (but not all) of the features in the review queue then need to be reviewed for checking into the deployment branch.  Our short term answer to that was the deployment queue: http://www.mediawiki.org/wiki/Deployment_queue Even then, we're still not done.  We have one more step, which is launching the feature on one or more wikis.  We could also create another queue page for that.  However, given the complicated workflow here, it seems that a wiki is the wrong tool to keep track of this.

Not for core no, but there are plenty of extensions that could be reviewed and deployed in a shorter period of time, and many config changes ready to go.

They are under a plain text RCS now which is documented on wikitech.

On 04/11/10 00:35, K. Peachey wrote: If you are talking about [[RCS]], it is 6 years old, written by myself. http://wikitech.wikimedia.org/history/RCS Always read the Wikitech pages with a critical view!