Policy Technical Proposals Idea lab WMF Miscellaneous 

New ideas and proposals are discussed here. Before submitting:


RfC: Disable Gather on enwiki

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There seems to be a clear community consensus to disable this extension. Even with changes proposed by the reading team over 3 weeks into this RFC, the consensus would seem to indicate that developers should work on any changes and improvements for this extension, outside of en.wp and will basically have to pitch the community a new version in a separate, later debate. —TheDJ (talkcontribs) 12:53, 22 February 2016 (UTC)[reply]

Should Wikipedia:Gather be disabled on enwiki? Fram (talk) 15:22, 26 January 2016 (UTC)[reply]

Background

In March 2015, Wikipedia:Gather was enabled on enwiki as a mobile Beta feature without much preliminary discussion or support on enwiki. The test was intended to run for about three months, but these quietly passed by without any discussion or changes.

According to The Gather page at Mediawiki, "The project was developed by the Wikimedia Foundation's mobile web team and is currently suspended." (emphasis mine) This was added in July 2015, or more than 6 months ago[1].

A (somewhat acrimonious) discussion at Wikipedia:Village pump (proposals)#Disabling Gather? finally lead to the start of this RfC. The tool in its current incarnation has many problems (see that discussion), including showing fair use images outside accepted locations, not being moderated (it can only be moderated by admins, but they don't have the tools to rapidly check these, nor the motivation to take any action), and being very buggy (check out something like Special:GatherEditFeed, which has potential in theory but is a useless disaster in practice).

The RfC is not intended to be a final judgment of Gather: it only asks that Gather is totally disabled on enwiki now, and remains so until another RfC has shown community consensus that a new trial is acceptable. Fram (talk) 15:31, 26 January 2016 (UTC)[reply]

Discussion

The non-empty collections are a mumbo-jumbo of pictures and links, presented in a seemingly incoherent order. For passing the time, one could just as well use the “random page tool. As a personal “to-read list” (possibly shared, for a project), an organised list on a user page is infinitely more effective. For thematic focus with a “coffee-table book” look (i.e., picture-driven, with links to articles from the encyclopedia), well, perhaps Wikibooks could host something like that. Overall, I feel sorry that resources were spent on this.
—- Wlgrin 02:43, 27 January 2016 (UTC)[reply]
Doubtful that all are actually aware of it. Often, it has happened that users hold these things seemingly oblivious of policy. It's really unfortunate that these types of RfC's don't bother to mention it. Alanscottwalker (talk) 17:05, 27 January 2016 (UTC)[reply]
Fun fact: the extension currently violates the principles for all MediaWiki software, as it is not "fully transparent and observable, with all changes to pages tracked and all actions logged". A typical reason for the WMF to go against community consensus is if that consensus violates these principles; in this case, that objection will not work. —Kusma (t·c) 17:14, 27 January 2016 (UTC)[reply]
Fun? Fact? It violates principles for all MediaWiki software.? It violates some broad and vague principal, according to someone (which is an opinion by the way, not a fact), is not all that momentous.Alanscottwalker (talk) 17:22, 27 January 2016 (UTC)[reply]
Fun fact: ive been a developer for about 6 years now and I have never seen that page before (although i do have some concerns about the architecture of gather - basically I think it reinvents the wheel too much but doesnt reinvent the entire wheel so is then missing things like logging of all actions. Ideally people would not reinvent wheels, but if you do reinvent the wheel you need to reinvent the entire wheel; no half measures). Bawolff (talk) 00:35, 20 February 2016 (UTC)[reply]
I do not see how WP:CONEXCEPT is relevant, this is not asking them to remove the feature from the MediaWiki software. It is saying turn it off on en.wp. This is no different from not implementing Pending Changes Level 2 or Flagged Revisions. The features exist in software we just do not use them here. JbhTalk 02:30, 31 January 2016 (UTC)[reply]
Without comment on Gather (haven't looked into it fully), there has been conflict in the past between the WMF and the en.wiki community regarding software implementation. I suppose the epitome of this was with Media Viewer in 2014. A community RfC ended with a strong consensus that Media Viewer be turned off by default for all en.wiki users. The WMF expressed its dissent on the RfC talk page, writing that per WP:CONEXCEPT, software development is not subject to the same policies which bind English Wikipedia editors. Later, when an admin disabled Media Viewer on the local MediaWiki:Common.js page in accordance with the consensus, a WMF staff member reversed the change, calling it a WMF action, the result of which culminated in a request for arbitration. Today, Media Viewer remains default on for all users. In a nutshell, the issue of WP:CONEXCEPT is actually quite complex, and it deserves no oversimplification. Mz7 (talk) 18:17, 31 January 2016 (UTC)[reply]
CONEXCEPT is an old policy here, from before my time. However, I worked on the most major recent update to it a few years ago, which gives me a reason to believe that I understand what was meant.  ;-) Mz7 is generally correct, but I want to emphasize that there's nothing in CONEXCEPT that prevents us from asking the devs (who may or may not work for the WMF) to make a code or configuration change (e.g., to turn off an extension here). The devs are never required to agree to our requests, but we are still allowed to make requests. WhatamIdoing (talk) 19:27, 2 February 2016 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Deployment

It appears that disabling is scheduled for 16:00–17:00 UTC tomorrow. --Yair rand (talk) 11:59, 21 February 2016 (UTC)[reply]

The listed Phabricator ticket is the one for complete disabling the extension, not the one with the "make stuff private" patch. Weird. —Ruud 16:31, 21 February 2016 (UTC)[reply]

Quote from Chad on the commit:

While it looks like the overwhelming consensus in the RFC is for disabling (and that's probably not going to change), I haven't seen a closure/summary of the RFC (when is it supposed to close, by the way?)
Pending that, I don't think we should put this in Monday's swat.

It seems that we might be in for a delay... --Yair rand (talk) 11:30, 22 February 2016 (UTC)[reply]

Funny, they don't see the need to consult the community at all before installing such an extension, but to disable it, they suddenly need to follow the burocracy... Fram (talk) 11:40, 22 February 2016 (UTC)[reply]
I have closed this, because I think there was more enough input to come to a conclusion. —TheDJ (talkcontribs) 12:57, 22 February 2016 (UTC)[reply]
Thanks for closing the RFC. And to the original comment: I like to follow community consensus and RFCs before deploying/undeploying things. I don't see it being a delay of more than a day or so so nobody's caught offguard. ^demon[omg plz] 17:06, 22 February 2016 (UTC)[reply]

WMF Reading team's response to the closing of the RFC

The Gather RFC has been closed with the decision to disable the feature on English Wikipedia.

We will disable the feature on March 1st US Pacific time to give us time to notify current users with instructions on how to archive their collections.

We'll track the progress in this ticket.

Once Gather is disabled we will have a retrospective on how the feature came about and how the community feedback developed and was managed.

Thank you to everybody who participated in this process. — Preceding unsigned comment added by TNegrin (WMF) (talkcontribs) 02:01, 23 February 2016

Thank you. Fram (talk) 07:42, 23 February 2016 (UTC)[reply]
Thanx :) I'm happy to see the WMF placing more attention on Community engagement. Alsee (talk) 17:27, 24 February 2016 (UTC)[reply]

Disabled. Please report any related issues at T127509. --Tgr (WMF) (talk) 00:13, 2 March 2016 (UTC)[reply]

Personal "to-do" list

One thing I've repeatedly wanted has been a way to tag a page for some sort of follow up action. I've often come across a page needing some work, but without the time to immediately deal with the problem, and there's really not a good way (that I've found) to record that for the future. I'd like to propose the creation of a simple gadget that would add a button to the tools bar (the one with read/edit/history/etc), that would add a line to the end of a user page (perhaps user:username/todo), containing a link to the current article, a timestamp, and a comment. The (optional) comment would come from a dialog box (similar to how Twinkle Rollback AGF and many other tools do it). The line added might look like:

* [[article name]] 05:01, 18 February 2016 - some comment 

Even nicer would be to generate a "delete" button on the "to-do" line, so that removing items would not require editing the page.

A button to take you to your to-do list if the gadget is enabled would be nice too. Rwessel (talk) 05:10, 18 February 2016 (UTC)[reply]

People currently use template ((To do)), which allows you to do this manually. The Quixotic Potato (talk) 10:06, 18 February 2016 (UTC)[reply]
@Rwessel: I've managed to put together a simple userscript that does the basics of what you want: User:Evad37/todo. It adds a link to the interface (location can be customised) which, when clicked, opens a user subpage (can also be customised) in edit mode. A line like you specified above will be preloaded in the edit window, with the article name specified and ~~~~ (which becomes the time/date upon saving). You can then add in a comment and save the page. Obviously not as fancy as a Twinkle-style dialogue box, but it should still be easier than manually filling in a to-do list. - Evad37 [talk] 09:51, 21 February 2016 (UTC)[reply]
@Rwessel: I've updated the script so it has the features you were asking for: optional comment from a dialogue box, remove items without editing the page, and a link to view your to-do list (next to the link to add something to the list). - Evad37 [talk] 06:29, 25 February 2016 (UTC)[reply]

Searching for templates

I realize this has been a Perennial Proposal, but is is quite frustrating when searching for the ((r)) template to have to type template:r into the search box, and searching for longer-named templates is maddening. Is there an existing alternative that I'm not finding?

I've honestly only skimmed the arguments for and against. While I see that using T: as a prefix isn't workable, I'm wondering if TL: would be? Anything that would shorten what's typed in the search box would be most helpful.

I also noticed a comment about setting the search box parameters to search all spaces, not just articles, and the comment said there was a setting in Preferences, but I can't locate it. The comment was from 2010, so I suppose things have changed.

Ah! I found the way to customize searches. Not intuitive at all, but helpful. Even so, if I check the "Template" box and choose to remember my choices, when I type r into the search box, what I'm actually looking for is way down the list, but at least it's on the first page. Searching for pb didn't fare nearly as well. Additionally, the "Remember my choices" box fails, sort of. Future searches don't include templates unless I click on the magnifying glass first to open the search page. I hate the extra step; if I've decided that the search box should search in a set of places, it should apply to just typing something in the box at the top of whatever page I'm on, please?

If nothing else, might it be possible to just type ((r)) into the box?

Thanks!

D'Ranged 1 | VTalk :  15:02, 26 February 2016 (UTC)[reply]

This was previously discussed at Wikipedia:Village pump (proposals)/Archive 127#Prefix suggestion: TP: for Template:. Following that I made User:SiBr4/TemplateSearch.js, which by default allows "((" and "TP:" as shortcuts for "Template:" but can be configured for any search shortcut. You can install that if you want. SiBr4 (talk) 16:13, 26 February 2016 (UTC)[reply]
I scanned the discussions and didn't get to this solution. Thanks so much!
D'Ranged 1 | VTalk :  17:06, 26 February 2016 (UTC)[reply]
To use the double curly bracket, this change to my commom.js file is effective; do it to User:D'Ranged 1/commom.js, and you should be able to search for teplates that way. עוד מישהו Od Mishehu 06:06, 2 March 2016 (UTC)[reply]

WikiLove on Russian Wikipedia

Enable the WikiLove, create task [3]. --忍者ポップ (talk) 04:39, 2 March 2016 (UTC)[reply]

New Village Pump page?

I've been thinking for a while that it might be good to have a Village Pump page specifically to facilitate WMF-Community engagement. In particular I was just collaborating with one of the WMF teams drafting an RFC to get feedback from us on one of the projects they're working on. The only place to post it would be Village pump (miscellaneous). Meh. It's unclear how big the discussion would become, and I think it would be beneficial if this sort of thing were to become a common practice. Alsee (talk) 23:32, 2 March 2016 (UTC)[reply]

New accounts - initial notification

Some while ago it was decided [by whom?] that users opening new accounts should receive a notification when they register, giving a link to a welcome/help/guidance page.

Until recently that page was Wikipedia:Welcoming committee/Welcome to Wikipedia, but within the past 2 weeks or so it has changed to Help:Getting started. Question, who decides on these provisions? - where are changes announced or discussed? If we knew in advance we could ensure that the page to be linked was in the best condition to receive a greatly increased number of views from brand-new editors. Also, these editors, not yet autoconfirmed, find they can't edit the welcome page itself so some of them resort to making all sorts of strange comments on the talk page. The Wikipedia talk:Welcoming committee/Welcome to Wikipedia talk page was eventually redirected to the Teahouse - is this the best course and should Help talk:Getting started now be redirected similarly? In summary we could benefit from more of a dialogue over what is offered to new editors on signup: Noyster (talk), 00:56, 3 March 2016 (UTC)[reply]

It was Special:Diff/705246320. --Krenair (talkcontribs) 01:12, 3 March 2016 (UTC)[reply]
Thank you Krenair! Been able to track back now. The "Welcome" notification has been provided for several years, but only in November 2015 was a link added, to a welcome/help page to be selected by each wiki. This new feature wasn't announced in Technical News, and even an editor like Moxy so active in the welcoming area doesn't appear to have been in the loop. Anyhow the link is specified in MediaWiki:Notification-welcome-link, and at first Legoktm set it to the Welcoming committee page. In February after a discussion divided between here and here, on the suggestion of Quiddity the link was reset to the Help:Getting started page. I do think the use we make of this facility needs to be better publicised and discussed, and a coherent approach developed to the spate of test edits, "hello"'s, adverts and random comments that appear on the talk page of whatever page is linked. I suggest that the Welcoming committee, although not as active as it was, would be a suitable centre for updates and discussions on this feature: Noyster (talk), 11:26, 3 March 2016 (UTC)[reply]