Talk:Review queue

Is there any timescale on the SubpageList3 extension activation yet? --McCormack 09:02, 27 May 2008 (UTC)

Criteria for inclusion?

May I ask what is the criteria for addition to the review queue? Or is it more to demonstrate something that may be reflected in Bugzilla? — billinghurst sDrewth 05:20, 19 January 2012 (UTC)

Just needs a bug requesting the extension be enabled on the cluster. Peachey88 05:31, 19 January 2012 (UTC)

revamp

Note to self or anyone else who wants to rework things: consider revamping along the lines of Wikivoyage migration/Extensions. Sharihareswara (WMF) (talk) 19:18, 12 October 2012 (UTC)

Securing commitments

# Beyond step #6, secure the following ongoing commitments:
#* from engineering (a deployer or engineering team) for ongoing support (and from the product manager who the engineer or engineering team reports to).
#* from design if design changes might be needed beyond design review
#* from product if any changes beyond bug fixes might be needed beyond or in conjuction with product review

I moved this recent addition to the talk page for further discussion.

This section is unclear and probably inaccurate. Most developers interested in having their extension deployed to Wikimedia wikis will be focused on the technical issues, not on "securing commitments" as though they're running for elected office.

This section makes vague references to consult "design" and "product" without going into detail as to how someone might do that (or what value it might provide).

This section also feels redundant with previous steps (such as seeking a design review from the design mailing list, if applicable).

This section also contains minor typos and grammar issues. It should be reworked to fit in better with the overall page and to be clear in what the intent of these additional steps is and how to complete them in a timely manner. --MZMcBride (talk) 16:04, 5 October 2013 (UTC)

I agree these are too vague to be essential steps. I'd suggest we try to describe what specifically we would get out of a product review that is different than design or community consultation, and make that part of the checklist. You don't have to be a "Product Manager" to properly review and manage a product. For instance: you could say that asking a product person would be a step. Or, you could say that it is required to list exactly which wikis you want the extension deployed on, and review the current list of extensions and gadgets deployed there, to make sure your extension does not conflict with or substantially overlap other functionality on that wiki. Whoever does the product review and documentation, it should help prevent questions late in the game like "Why aren't you using FooExtension for this instead?". The stupid Echo vs. MassMessage conflict is one that can be avoided in the future, by encouraging extension maintainers to clearly articulate how they've looked at the bigger picture. Steven Walling (WMF) • talk 19:56, 7 October 2013 (UTC)

Require CheckUser and AbuseFilter integration

CheckUser and AbuseFilter is a tool vital for project maintenance and I don't know why it is being omited here. Yes, the page says that any new extensions should be compatible, but compatibility (ie: imposibility to use one extension while the other one exist) is not the same as its [ab]use be controlable via CU/ABF. Extensions to be deployed on Wikimedia sites should not only be compatible with CheckUser, and few other more such as AbuseFilter; they need to be controlable by them. That is, extensions editting or doing log actions should create CU log entries and the posibility to counter abuse via AbuseFilter should exist as well. Let me remind you that according to https://wikimediafoundation.org/wiki/Terms_of_Use/en#10._Management_of_Websites primary responsability of website management relies on the communities, but the communities cannot do that appropriately if things added to our wikis ain't compatible/share data/integrate with the management tools. There are already some Phabricator tasks (some tagged as private) where people have already complained about this. I beg to move that CheckUser and AbuseFilter integration be a hard requirement to get any extension deployed on WMF sites; at least those based on editting, performing log actions or that can be abused. Thank you. —MarcoAurelio (talk) 20:55, 28 August 2017 (UTC)

What "integration" is necessary, beyond using the revision table and standard systems? Everything is a wiki page mentions the problem. --Nemo 05:35, 29 August 2017 (UTC)