New ideas and proposals are discussed here. Before submitting:
« Archives,
110,
111,
112,
113,
114,
115,
116,
117,
118,
119,
120,
121,
122,
123,
124,
125,
126,
127,
128,
129,
130,
131,
132,
133,
134,
135,
136,
137,
138,
139,
140,
141,
142,
143,
144,
145,
146,
147,
148,
149,
150,
151,
152,
153,
154,
155,
156,
157,
158,
159,
160,
161,
162,
163,
164,
165,
166,
167,
168,
169,
170,
171,
172,
173,
174,
175,
176,
177,
178,
179,
180,
181,
182,
183,
184,
185,
186,
187,
188,
189,
190,
191,
192,
193,
194,
195,
196,
197,
198,
199,
200,
201,
202,
203,
204,
205,
206,
207,
208,
209,
210,
211,
212,
213
- 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.
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
- Support disabling until 2nd RfC - Gather seems really interesting and a promising concept, but the enabling here without much discussion isn't welcomed. If there was a wide discussion we wouldn't be having the issues with admins not being able to moderate through lack of tools, and it's likely more people would get involved in testing and bug reporting, reducing the current buggy behavior -- samtar whisper 15:48, 26 January 2016 (UTC)[reply]
- Support disabling until proper moderation tools exist and the image issues have been addressed. Once Gather fits into Wikipedia, I do not mind trying to use it to attract users. —Kusma (t·c) 16:00, 26 January 2016 (UTC)[reply]
- Support disabling There are far too many problems, not least the non-free images and lack of moderation tools. Apparently inappropriate lists cannot even be deleted. BethNaught (talk) 16:08, 26 January 2016 (UTC)[reply]
- Disable due to the urgent copyright and moderation issues brought up at VPR, as well as the lack of consensus for enabling the tool in the first place. --Regards, James(talk/contribs) 16:18, 26 January 2016 (UTC)[reply]
- Disable. There are plenty of smaller wikis to test this type of faff with. Stifle (talk) 16:58, 26 January 2016 (UTC)[reply]
- Disable The developers are of course free to start an RfC to propose re-enabling Gather after the problems have been fixed. —Ruud 17:00, 26 January 2016 (UTC)[reply]
- Disable ... unless Wikipedia is now social media (which seems to be akin to what "Gather" allows.) Last I checked, this was an encyclopedia. Would it be crazy to call Gather a WP:NOTWIKIA violation? ... Because I think it is a violation. Steel1943 (talk) 17:31, 26 January 2016 (UTC)[reply]
- Support - If the project is suspended at WMF, and the trial period on enwiki has long expired, then disabling Gather is the proper thing to do until the community supports another trial. — Jkudlick • t • c • s 17:38, 26 January 2016 (UTC)[reply]
- Support disabling, and do it immediately. Among the example links Fram pointed out above, at least one was a blatant BLP violation (a sexually-themed attack against a named person, almost certainly a minor, evidently designed as a tool for cyberbullying them). Evidently, nobody at the foundation has been overseeing this kind of abuse, and our community has made it clear we don't wish to take on this task. In this case, I've gone ahead and "hid" it nevertheless – and now I have no idea how to document what I did, or whether it's really gone in those places where it's been used, or whether the creator can still see and use it, or how I could link to it if it ever were necessary, or whether and how somebody could revert the hiding; there's no reason in the log entry, nothing; it's all a mess. Fut.Perf. ☼ 17:53, 26 January 2016 (UTC)[reply]
- Future Perfect at Sunrise: There is an entry in your log, but I can't access it and can't see what you did. Are you able to undo your hiding or is even that impossible? —Kusma (t·c) 20:32, 26 January 2016 (UTC)[reply]
- (Non-sysop here) Nothing on my end either. Just an error message, nothing more.Jo-Jo Eumerus (talk, contributions) 20:36, 26 January 2016 (UTC)[reply]
- (Sysop here). I get an error, "Error - Page not found. The page you are looking for could not be found." So it seems that if someone hid a page by mistake, we are not able to undo that mistake either (or even check whether it was a mistake or not). Note that in this case, it definitely wasn't a mistake but a long overdue action. But if I now wanted to e.g. address the editor who made that page, I have a problem: I can no longer see who created it... Note also that FPaS did (correctly) block the editor involved, but he is blocked for creating attack pages while he has no contributions and no deleted contributions. So admin accountability here is now zero, and we can block anyone who created gather lists with impunity. Fram (talk) 20:53, 26 January 2016 (UTC)[reply]
- Immediate Disable For all of the reasons mentioned above - copyright / WP:NFCC violations justifying immediately disabling the feature. This is nearly a hidden feature which is not subject to community oversight, depending on how lists are put together they can violate core policies like NPOV and BLP because of how elements of the lists are juxtaposed ie grouping crimes, criminals and some recently accused person together. If this feature is kept and the community is not able to manage, edit and delete these lists we should simply point out to anyone complaining about a Gather list that the WMF has not provided that ability, they were advised of the potential harm to individuals and ignored that advice and give them the address of WMF Legal to sort it out. JbhTalk 18:13, 26 January 2016 (UTC)[reply]
- I'm going to go out on a limb here, and oppose disabling. I've looked at and explored Gather a little bit (not much), and I've read the discussions above. I think that with Gather (and the also hotly opposed related articles feature - which is one thing I think should be removed), the WMF is attempting to provide tools that will be of service to Wikipedia's readers, instead of the editors. Several comments in the recent m:2015 Community Wishlist Survey involved things like being able to save pages for future reading, improved watchlists, etc. Readers in this day and age expect to be able to easily share content with others; whether through facebook, twitter, pintrest, etc. Wikipedia's early 2000s design doesn't make that easy. Gather seems to act as the equivalent of a pintrest board where people can group articles they'd like to read, articles on topics that interest them, etc. and share them with others. It seems like fundamentally a good idea to improve the reader experience. Right now it's in beta and there are some hoops to jump through to opt into testing it; it's not particularly visible to most people. There are definitely issues and problems with it; as there always is with software in beta testing. That's why it needs to be tested. It does not make sense to, as someone above me said, test it on the smaller wikis, because they have fewer readers, fewer mobile readers (which is what this is geared towards), and won't provide a good test. It makes sense to test it, as they are doing, as an opt-in feature on the largest wiki, which gets the most mobile traffic. I say leave it enabled, and let the WMF do their job of developing useful software tools for both the editors and the readers we are all here to serve. ~ ONUnicorn(Talk|Contribs)problem solving 18:34, 26 January 2016 (UTC)[reply]
- That's the thing, though—I agree in principle that this is a useful avenue to explore, but as it stands, Gather needs a ton of improvement to even be in a state where we can safely test it; despite being opt-in (in some sense) the problematic collections are publicly visible to everyone. If the WMF has indeed suspended development, why should we keep around another piece of broken software they don't seem interested in working on? — Earwig talk 18:39, 26 January 2016 (UTC)[reply]
- Yeah, I think most of the people here like the idea of this tool. And in a perfect world this would be a fine tool. But the problem is that the world is not. Once you allow people to create public content they will find ways to abuse this ability. The developers don't seem to have taken this into account at any point. And as a result there isn't a plan in place to deal with this. And it's also not clear how to create such a plan, as nobody seems to be interested in moderating all these lists. —Ruud 18:55, 26 January 2016 (UTC)[reply]
- Support, due to the poor implementation and copyright/moderation issues. We really need to improve the watchlist and books systems, but I don't think this is the way to do it. — Earwig talk 18:39, 26 January 2016 (UTC)[reply]
- Disable. Nice idea, and unlike lots of new ideas that don't work well, this one doesn't actively cause problems, but it doesn't have the expected benefits either. No reason not to restore it once the problems are fixed, but no reason to keep it until the problems are fixed. Nyttend (talk) 19:08, 26 January 2016 (UTC)[reply]
- Support disabling. Note: I would consider setting all collections as owner-visible-only to be an reasonable temporary way to minimize disruption while we sort out whether this project should be re-enabled or permanently removed.
- There was zero community input on developing this project. I hope that in the future the WMF will invite input before building and deploying new projects.
- I don't have a link but somewhere I saw the WMF say something to the effect that they like to build mobile-only deployments because it avoids scrutiny and objections from the (primarily desktop) the editing Community. I consider that troubling in itself. If we keep this it obviously shouldn't be mobile-only.
- When this project was announced, the consensus at Administrator's Noticeboard was that this content generally falls under our speedy delete criteria, that it was unwanted, and that if the WMF wanted it then they could do all the work of policing it because admins wouldn't. I don't think anyone considered that a viable path forwards, but the deployment was mishandled in such an offensive manner that the hasty informal consensus was "screw you, if you want it then you can keep it and police it yourself".
- NOTSOCIALNETWORK aka NOTWEBHOST. Substantially all of this content falls under speedy delete criteria U5.
- Pages in userspace consisting of writings, information, discussions, and/or activities not closely related to Wikipedia's goals, where the owner has made few or no edits outside of user pages, with the exception of plausible drafts and pages adhering to Wikipedia:User pages#What may I have in my user pages?.
- This is content "owned" by individuals and the community shouldn't be working to police individual's content. We shouldn't be reviewing an individuals' list of their favorite bands, we shouldn't be reviewing an individual's list of alleged pedophiles. We shouldn't be passing judgement on whether to censor individual's offensive political-attack because we deem it too offensive.
- That Admin Noticeboard consensus should have sent up a giant redflag that they need to stop and have a WMF-Community discussion. I repeatedly asked the Community Liaison to constructively engage the Gather issue with the community. I tried asking the Project Manager. I asked the Executive Director. I asked a half dozen times, trying to organize some sort of collaborative WMF-Community RFC. The question was literally ignored every time, the the WMF engagement model is to disregard the possibility of turning it off, to allow individuals to drop upgrade-ideas in the suggestion box, and to avoid acknowledging Community Consensus as a topic. I regret not filing this RFC myself back then, but pressing real life issues took precedence. I hope that in the future the WMF will be more willing to collaborate on an RFC when there's an obvious issue that needs to be discussed.
- The devs built something that "works", but failed to fulfill basic necessary requirements (moderation tools noted above). Last I checked Gather did not show up in a user's contribution history or anywhere else. If an editor is caught making abusive article edits there's no reasonable way to see that they have Gather collections that need to be checked for abuse.
- As noted above, non-free images are being misused.
- When this was deployed, the WMF announced that it was our "responsibility" to write a policy for acceptable-collections and to do the labor to police it. There's still no policy on it, and at minimum we need to decide that we do want to create said policy before this is re-enabled. Alsee (talk) 19:25, 26 January 2016 (UTC)[reply]
- Support disabling until BLP/NFCC issues have been properly dealt with. --SarekOfVulcan (talk) 21:05, 26 January 2016 (UTC)[reply]
- Disable – Not of any use to Wikipedia, an example of what Wikipedia is not, and a compromise of our integrity as an encylopaedia. RGloucester — ☎ 21:24, 26 January 2016 (UTC)[reply]
- Support disabling. Perhaps there could be a public discussion about the goals of that feature (the needs that it aims to address) and how to best reach them. Browsing the existing collections, I see the following kinds:
- Empty or near-empty: not desirable.
- Purely self-promotional: not desirable.
- Thematic (e.g. “American art”): better addressed by curated thematic portals and bottom-of-article infoboxes.
- Topical (e.g. “Maureen O'Hara”): better addressed by hyperlinks and “see also” sections in articles.
- Personal interest or workspace (e.g. “kimounkimsovan…”): I’m not sure who’d be interested in such a totally-random and disorganised list of links. In any case, it probably belongs to a user page or, better, a personal web site outside Wikipedia.
- 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]
- Disable with prejudice. The deployment and development of this extension shows nothing but contempt for both the encyclopedia and the editing community on part of the WMF. Alsee has the story behind this mostly correct except the WMF were challenged about the lack of benefit to the encyclopedia and warned about conscripting us to moderate the junk a month prior to that AN discussion. That the community liaison is still way out of her depth and refuses to act on or even listen to our concerns nine months later says everything you need to know about the managers of this exercise in wasting donor money. The justification regarding user watchlists above is ludicrous -- I was the one who proposed them at the Community Wishlist Survey, and no, Gather is not even remotely acceptable for that (or any) purpose. MER-C 12:02, 27 January 2016 (UTC)[reply]
- Disable, Uninstall and Forget - as I !voted above (I thought that was already the request to disable this), more wasting of time by WMF developers that can be used for more useful or even requested upgrades to the system. --Dirk Beetstra T C 12:12, 27 January 2016 (UTC)[reply]
- oppose. This is a 100% waste of time because of WP:CONEXCEPT: These independent, co-equal communities operate however they deem necessary or appropriate, such as adding, removing, or changing software features --In actu (Guerillero) | My Talk 16:43, 27 January 2016 (UTC)[reply]
- We are all acutely aware of this. Can you imagine any reason not to ask the WMF to remove it? BethNaught (talk) 16:46, 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]
- Disable Per FPaS disturbing example above. However I am now wondering given Fram's reply what else can be got away with... Only in death does duty end (talk) 17:13, 27 January 2016 (UTC)[reply]
- Disable. This tool is not ready to be used. It is buggy, unclear how it fits into Wikipedia, and has issues with breaching our local copyright policy by including non-free images. The WMF have suspended development and need to test and develop this more before it should be allowed back near English Wikipedia. Fences&Windows 21:54, 27 January 2016 (UTC)[reply]
- Disable for now. There are some potentially interesting possibilities, as mentioned at § Disabling Gather? ([2] and the 'Some positive comments' subsection), but there are too many problems as is, including lack of moderation tools, incomplete or non-existent logs, bugs mentioned above, non-free image problem (might be fixed by phab:T124225, but at the moment is still a problem), and the apparent suspension of development from the WMF. - Evad37 [talk] 14:16, 28 January 2016 (UTC)[reply]
- Disable. This should have been the subject of an RfC before it was enabled for a trial. Until the nonfree content and lack of administrative ability issues are resolved, this is not fit for purpose. Once it is, we need to make sure that administrators are ready to monitor this, it integrates with existing features such as Recent Changes, and that the community considers that to be worth the time and effort. Seraphimblade Talk to me 01:41, 29 January 2016 (UTC)[reply]
- Disable Against community fair-use practices, poor maintainability. — xaosflux Talk 01:52, 29 January 2016 (UTC)[reply]
- Disable - I've spent a good 10 minutes trying to find out what the actual point of Gather is and I still have no idea ....., Why would anyone want collections?.... Anyway what with the copyright concerns and bugs it's better off disabled until everything's fixed. –Davey2010Talk 20:09, 30 January 2016 (UTC)(Amended 23:55, 12 Feb 2016)[reply]
- Disable. Concept totally unsalvageable, should never have started and WMF knew it. The extension is also an ongoing cost for our communication in that it sometimes uses the term "collection" for its byproducts and in so doing boycotts offline users. Nemo 23:04, 30 January 2016 (UTC)[reply]
- Disable Violates WP:NFCC#9 by design. Hard to patrol. Impossible to verify if admins were correct when deleting a collection if there is no way to undelete or view the deleted collection, and as a result also impossible to verify if user blocks are in compliance with policy if the block was given as a result of using this extension. --Stefan2 (talk) 23:11, 30 January 2016 (UTC)[reply]
- Disable per copyright concerns and lack of community consensus to implement. sst✈ (speak now) 07:11, 1 February 2016 (UTC)[reply]
- Disable: Obviously we can't stop the Foundation from doing this on another platform, but it's clear that this system as designed, and when hosted on Wikipedia, violates WP:NOT. The NFCC problems make it even worse. Something like this might be appropriate in a toolserver-like environment, or on something like "gather.wikimedia.org" as a sort of fork or mirror of Wikipedia content, but absolutely not as a local extension on enwiki. —/Mendaliv/2¢/Δ's/ 09:44, 2 February 2016 (UTC)[reply]
- Disable. The principle may (emphasis on "may") be sound, but the implementation is unusable and goes against fundamental Wikipedia principles. The WMF needs to stop treating en-wiki as their own personal sandbox. ‑ Iridescent 20:40, 3 February 2016 (UTC)[reply]
- Disable — Once again, the Foundation rolls out unneeded and undesired buggy software onto En-WP as its special little beta-testing area. No. Test your products elsewhere, fix their deficiencies, demonstrate their worth, and then we can talk. Carrite (talk) 18:01, 4 February 2016 (UTC)[reply]
- Disable for all the reasons listed above. The BLP issue is particularly troubling. SarahSV (talk) 19:53, 4 February 2016 (UTC)[reply]
- Disable without any further delay. The idea isn't necessarily all that bad, but the mere fact that there are BLP issues in there that we can't police means this needs to be pulled immediately for retooling. Lankiveil (speak to me) 12:33, 6 February 2016 (UTC).[reply]
- Disable because even though the idea is good, if deployed in this state enwiki will turn into chaotic hell. 96.237.20.21 (talk) 15:15, 6 February 2016 (UTC)[reply]
- Disable. The lack of actual communication (as opposed to polite stonewalling) from the team is very troubling. --MichaelMaggs (talk) 05:13, 7 February 2016 (UTC)[reply]
- Support disabling. As with so many things, this should not have been implemented without community consensus but we are where we are. It sounds like it has some useful features, but needs improving before it's ready for a production environment - especially considering the fair-use infringement concerns. I'm also not entirely certain what the purpose is, other than a way to group articles together. With Categories, Portals, Topics, Watchlists, Projects and the rest, I'm not sure we need yet another article collation mechanism without a proper strategy that includes all the above. WaggersTALK 13:22, 8 February 2016 (UTC)[reply]
- Disable at once, per Fram and Future Perfect at Sunrise. What a horrifying mess. It is alarming that something so poorly thought out should have been launched without public discussion. Chiswick Chap (talk) 19:34, 8 February 2016 (UTC)[reply]
- Support disabling per many of those above. The Quixotic Potato (talk) 10:00, 9 February 2016 (UTC)[reply]
- Disable. And destroy. Poor implementation of a mediocre at best idea. If people want social networking, there's Twitter, Instagram, Google+ and Facebook. That's not what we're here for. oknazevad (talk) 16:21, 10 February 2016 (UTC)[reply]
- Disable I'm not sure I even get what the point was supposed to be, but the implementation is too poor to be allowed to remain live on en.wp. If the foundation is unwilling to disable it, they need to keep an eye on it themselves since there's no local policy or control over how it works. Beeblebrox (talk) 19:59, 10 February 2016 (UTC)[reply]
- Disable for now. While in principle, I am not opposed to the idea of providing a tool such as this, there are serious problems with the implementation that make it unworkable in its present form. My understanding is that the Gather lists are difficult for editors to monitor (e.g., can changes be reverted?) and it is even difficult for administrators to enforce vital policies like BLP. Until these issues are resolved, the Gather feature must be disabled. When and if they are resolved, there should be another RfC to begin to determine community consensus on how they should be managed (and if they should be reintroduced at all). Sławomir
Biały 12:21, 12 February 2016 (UTC)[reply]
- Disable. Offers no advantages over other available means of aggregation, violates both local and Mediawiki policies, is an imposition on the en.wikipedia community. Yngvadottir (talk) 20:14, 18 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 (talk • contribs) 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) (talk • contribs) 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]
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]
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]
Enable the WikiLove, create task [3]. --忍者ポップ (talk) 04:39, 2 March 2016 (UTC)[reply]
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]
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 (talk • contribs) 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]