Consider enabling VE in all namespaces that are used for article creation (normally Draft)
Open, LowPublic8 Story Points

Description

I suggest to config/enable VE in all namespaces that have high number of page moves from them to article namespace.

Assumptions:

  • If there is high number of page moves from specific namespaces to main namespace, it indicate those namespaces are used for article creation (draft/user whatever...)
  • It is unexpected that all wikis that have VE enabled will open bug request+ gain community consensus for such changes (e.g T118060, T87027, T92798, T86688, T91223 ...)
  • We should let communities do their foot voting to suggest what namespaces should have VE enabled

With those assumptions I did a query on all wikis that have VE enabled, and queried it for page moves between namespaces to the main namespace[1], and hereby are good candidates for being required to be supported by VE (wmgVisualEditorAvailableNamespaces)[2] :

alswiki => ['104']
astwiki => ['4']
azwiki => ['4', '10']
be_x_oldwiki => ['4']
bgwiki => ['4']
eswiki => ['104']
euwiki => ['4']
hrwiki => ['1']
idwiki => ['4']
kabwiki => ['4']
ltwiki => ['4']
lvwiki => ['102']
mgwiki => ['4', '14']
mkwiki => ['4']
mnwiki => ['14']
mswiki => ['4']
ptwiki => ['4']
rowiki => ['4']
sowiki => ['4']
sqwiki => ['4']
stqwiki => ['3']
tlwiki => ['4']
viwiki => ['10', '11', '15']

Filtered (already configed):

cswiki => ['4']
enwiki => ['118']
frwiki => ['4']
hewiki => ['118']
ruwiki => ['102']

I suggest to enable it for all of those if there is no objection from the relevant communities/ambassadors

[1] bash script to extract page moves to main namespace for all wikis that enabled VE:

sql meta "select concat(\" UNION (select '\",dbname,\"', log_namespace as 'from_ns', count(*) as 'moves' from \",dbname,\"_p.logging inner join \",dbname,\"_p.page on page_namespace=0 and log_page=page_id 
where log_type= 'move' and log_namespace>0 group by log_namespace)\") as q from meta_p.wiki where family='wikipedia' and has_visualeditor=1" | tail -n +2 |tr '\n' ' ' | sed 's/^ UNION //' | sed 's/UNION/\n
UNION/g' > metaquery.sql
sql meta < metaquery.sql > metaquery.out

[2] zscore calculated for each project separately, threshold of zscore>0.05, then manual filtering of already set namespaces

eranroz created this task.Aug 12 2016, 11:39 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 12 2016, 11:40 AM
Restricted Application added subscribers: JEumerus, Matanya. · View Herald TranscriptAug 12 2016, 11:43 AM
Danny_B removed a subscriber: VisualEditor.
Jdforrester-WMF renamed this task from Foot voting to enable VE in all namespaces that are used for article creation to Consider enabling VE in all namespaces that are used for article creation (normally Draft).Aug 16 2016, 7:27 PM
Jdforrester-WMF triaged this task as Normal priority.

First-off, we're not enabling VE in namespace 3 as that's NS_USER_TALK (stqwiki) and VE doesn't do talk pages.

Similarly with viwiki we're not enabling in 11 or 15 (NS_TEMPLATE_TALK and NS_CATEGORY_TALK). 10 (NS_TEMPLATE) we could do, but I think it'd be more confusing than fun.

It's a bit surprising and troubling how often people are moving things from the project (4) to the content namespace; we should probably find out why.

14 (NS_CATEGORY) is already enabled unless something's broken, so by my reckoning that comes down to:

alswiki => ['104']
eswiki => ['104']
lvwiki => ['102']

… which I believe are all Draft namespaces. Possibly re-title to "enable in all remaining draft namespaces"?

In some languages, such as rowiki the project NS is used also for draft articles (for the example for rowiki - see pattern
Wikipedia:WikiProiect_Articole_de_creat/$1 => $1
)

I think enabling VE in namespaces chunks of which are customarily-signed (mostly the Project NSes, but also WikiProject ones on some wikis) should wait until post-NWE/SET at this point.

I think that this is an interesting and useful approach to identifying potential candidates. But I do also think that a delay until the 2017 wikitext editor is an option would be appropriate.

Qgil moved this task from Backlog to Team radar on the Community-Liaisons board.Aug 25 2016, 9:36 AM
Jdforrester-WMF lowered the priority of this task from Normal to Low.Sep 1 2016, 11:58 PM
Jdforrester-WMF set the point value for this task to 8.

I think enabling VE in namespaces chunks of which are customarily-signed (mostly the Project NSes, but also WikiProject ones on some wikis) should wait until post-NWE/SET at this point.

I think that this is an interesting and useful approach to identifying potential candidates. But I do also think that a delay until the 2017 wikitext editor is an option would be appropriate.

wikitext editor is now in production (as beta).

On how many of those has it been set up already? We do triage similar requests as they come, usually.

Don't expect small communities to request it - they usually not aware it can be configured and aren't always familiar with phabricator. This should be done pro-actively on good candidates, unless there is objection.