Wikipedia

Wikipedia:Village pump (proposals)/Archive 130

< Wikipedia:Village pump (proposals)
(Redirected from Wikipedia:RfC: Disable Gather on enwiki)
Latest comment: 8 years ago by Luis150902 in topic Create a separate "BLP citation needed" template.
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 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, 214

Disabling Gather?

Latest comment: 8 years ago107 comments25 people in discussion

I was looking at Special:Gather and the surrounding pages. Gather is an extension enabled (in Beta) by the WMF in March 2015, aimed mainly at mobile users, with the purpose of, well, that's not really clear. Apparently to create user-defined lists outside of userspace, and somehow share them with your friends or the world. As is so often the case, enwiki is again used as the testing ground, as if we have nothing better to do and there aren't hundreds of wikimedia sites.[1]

Edits to Gather are not noted in the contributions of the users involved, and checking these lists also isn't included in standard page curation (recent changes, newpagespatrol, ...).

Pages related to this include the rather hideous Special:GatherEditFeed, a kind of poor man's watchlist. This shows that Gather could be used to create multiple watchlists (a feature long requested), but this is done in public (everyone can check your watchlists in this way) and with a very poor interface, so doesn't seem useful at all.

Gather Lists have large images, including fair use ones. This seems to be a typical WMF problem, they don't care at all about the copyright status of images (see also the recent "Read more" beta extension with the same problem).

There are more problems with Gather and its interface, please discover it for yourself.

My question is: what is the use of "Gather" for the encyclopedia, and shouldn't we better simply disable it (or have it disabled by the WMF)? It's, as far as I can see, in general not useful, not integrated, not beneficial, and not really attracting more editors. The most prolific Gatherlist editor seems to be User:Elisagwanor (according to Special:Gatherlists; it seems to be impossible to check for older creations, lists by topic, lists by whatever criterion you want), who has more Gatherlists than edits.

The vast majority of these lists have only one article, making them rather bizarre lists. They have for 90% only interest for the user that created them, but not for anyone else. I have no idea why the WMF should need to provide a tool for this, nor why enwiki should need to patrol and maintain this. But others probably disagree, so I'm interested in everyones opinion before I decide to start an RfC on this or not. Fram (talk) 15:21, 20 January 2016 (UTC)

The WMF implemented a poorly designed feature with an unclear purpose without community consultation? I can't believe I'm hearing this. ‑ Iridescent 15:22, 20 January 2016 (UTC)
;-) Fram (talk) 15:31, 20 January 2016 (UTC)
Lol ! - Sitush (talk) 15:32, 20 January 2016 (UTC)

Oh well, I couldn't resist listing some of the typical small problems one encounters with minimal testing (which clearly, as usual, has,'t been done by the WMF before rolling this out and are still there after 9 months). On the overview of all Gatherlists, at the top left is a "Show hidden lists" link. This leads to [2]. Error... If one scrolls further down, the page may look differentn like this[3]. The "show hidden lists" link is much smaller, and leads to [4], which produces a different error. So desktop or mobile seems to make no difference here.

Another strange issue: when I go to Special:Gather, I can no longer type in the "search" box on the top right. This doesn't happen with other "Special" pages.

Oh, and they also created Wikipedia:Gather/User Feedback as a Flow page against all promises of not rolling out Flow any further on enwiki. Good going, WMF! Fram (talk) 15:31, 20 January 2016 (UTC)

  • May I ask the OP to state more clearly (and if possible with less prose) why we need to disable wp:Gather? Was the OP not also involved in another WMF-disabling that prevented a small wikiproject from having its own choice of inner-project communication?
  • Background
    • So, you have no idea what this is about, but because I opposed further Flow testing on a Wikiproject where you would have preferred to continue the test (without indication any benefit for the project of doing this, while the opposers indicated disadvantages caused by Flow), you come here to grill me? If you "prefer to stay away from too much wiki-talk and prefer to work on content", I don't get what you pretend to be doing here (in this discussion I mean): a location you don't like to be in and a topic you don't know anything about and don't have the time to familiarize yourself with.
    • For everyone else who may be objectively interested in the topic: my opinion so far is that Gather is a very buggy piece of software, rolled out prematurely to enwiki, and seems to have little to no benefit for the encyclopedia (the reason we are here). Most "lists" created in it are one article long, often rather random. The tool is very badly integrated with the rest of Wikipedia, makes dubious use of fair use images, is hard to patrol, and in general seems to provide very little actual benefit. But I would like to hear the opinion of others who already have experience with it or who are wiling to check it out. People who only come here to complain about another discussion (the close of which was already discussed and endorsed at WP:ANI anyway) are not really helpful though. Fram (talk) 19:28, 20 January 2016 (UTC)
  • Disable Gather for now. Or at least remove its ability to display images. Special:Gather/id/22108/Asterix is a non-free gallery and violates our policies. However, it is impossible to detect that non-free images are used, as the image use does not show up in the image description page. See for example File:Asterixcover-20.jpg. If we can't even check whether these pages conform to our policies, we should not have them here. —Kusma (t·c) 20:03, 20 January 2016 (UTC)
  • This implementation is clearly a disaster, but just on the idea itself: why have this as a separate thing in lieu of improving (fixing?) books? They seem to have the same purpose of user-created lists of articles. We can apply some of the same design concepts to books (easier in-line display and certain images, maybe). — Earwig talk 22:39, 20 January 2016 (UTC)
  • The WMF was explicitly told, twice, that there may be a refusal among admins to police these lists because this extension does not improve the encyclopedia, among other shortcomings such as those mentioned above and in those two discussions. In fact, this extension demonstrates nothing but sheer contempt from the WMF by failing to consult with the community before designing an extension that imposes an additional moderation workload, not disabling the "feature" when we said no and feeding a community "liaison" to the sharks because he had insufficient knowledge of foundational policy. This extension should be deleted, not merely disabled. MER-C 02:01, 21 January 2016 (UTC)
    • Actually, the bigger problem is that it is completely impossible to curate these pages (either by editors or administrators), because they are in the "Special" namespace. They cannot be deleted, they cannot be suppressed, they cannot be edited by anyone other than the creator. I will try to pull out the Phabricator tickets for the discussions, but essentially what we have is publicly-facing content that is completely unable to be managed by the editing community, which right there should be enough to withdraw it from a live "production" project. I'd be fine with it in a test environment, but English Wikipedia is *not* a test environment. I recently used it as an example of *what not to do* when it comes to new extensions; there's almost nothing that was done properly. Even the naming of the extension is problematic. Risker (talk) 19:56, 22 January 2016 (UTC)
      • From the two discussions above, it was possible for the community to moderate collections. Looks like the WMF then removed this ability and took on sole responsibility for the content instead of removing the entire extension in response. Let's hope the WMF realize they've painted themselves into a corner. MER-C 04:25, 23 January 2016 (UTC)
  • Sigh .. more wasting of time by WMF developers which enforces us to waste more time because they don't solve problems that waste our time. Disable ánd delete. --Dirk Beetstra T C 03:26, 21 January 2016 (UTC)
  • Endorse disabling. The principle of a means of making publicly-visible collections of pages a given editor feels are significant in some way isn't a bad one—it would prevent problems like this, for instance, to have a means of creating pseudo-categories which don't show up at the bottom of the page, and it would make it possible for Wikiprojects to create "pages that need work" lists without plastering articles with tags. However, the current implementation, complete with the inability to edit the lists and the abuse of non-free content, is clearly not it. The WMF devs need to be sent a strong signal that the most-viewed site in their portfolio (by an order of magnitude) is not their personal sandbox, since despite the Flow, Vector and VE debacles the message still doesn't appear to have got through. ‑ Iridescent 20:07, 22 January 2016 (UTC)

Some positive comments

I actually think Gather could be part of a move towards a more social-networking website. I know that we have traditionally frowned upon "social networking" type activity, but I think we should revisit that stance. Ten years ago we were a bit more permissive towards non-write an encyclopedia-oriented things than now, and I think that may have been part of making this a nicer and less grumpy place. We could relax a bit and allow people to have myspacey user pages and guestbooks and play some silly games and have and share "favourite articles" list without damaging the encyclopedia, and we might gain some more people who log in to this site instead of reading a mirror and then could be perhaps persuaded to click "edit" every once in a while and maybe become contributors. —Kusma (t·c) 20:11, 20 January 2016 (UTC)

Everyone is always horrified at anything that smells like "social media", but I've never understood the antipathy toward using an account to optimize one's reading experience rather than to actively edit. Setting preferences, creating bookmarks, and sharing articles are all things that websites of 2016 allow their readers to do. This extension does look poorly put together, but it's aimed in the right direction. Opabinia regalis (talk) 20:30, 20 January 2016 (UTC)
Yeah, adding some social stuff to Wikipedia may be a good thing. But this hasn't be thought through well enough, as usual. If these lists are going to be publicly accessible (but not publicly editable?) then it needs to be made very clear that this content isn't part of the encyclopedia proper. Host it on a separate domain (or at least as a subpage under a user's name), add a disclaimer that this is content curated by one editor instead of the whole community, etc. —Ruud 21:19, 20 January 2016 (UTC)
Of course. In its current state, it must be disabled immediately. —Kusma (t·c) 13:55, 21 January 2016 (UTC)

Actually, how does it work?

There is a "flag" and a "hide" button on each collection. What happens if I click those? —Ruud 22:10, 20 January 2016 (UTC)

Wikipedia:Gather/Moderation Criteria seems to be related to this... —Ruud 22:14, 20 January 2016 (UTC)
Who moderates these? Not the community, I hope, because a bunch of admins (myself included) explicitly refused to do so and the WMF was explicitly told and appeared to agreed to hire their own content moderators. MER-C 02:02, 21 January 2016 (UTC)
Just for clarity, WMF didn't hire content moderators, collections, so far, have been moderated by Gather admins, a sub-right, that allowed people working on the feature to be able to filter Collections throughout the test.--Melamrawy (WMF) (talk) 16:52, 22 January 2016 (UTC)
Both Gather and Related Pages (see Wikipedia:Village pump (policy)/Archive 124#WMF inserts non-free content in articles via automatically generated "See also" section) seem to have been created by the same development team, and they seem to be suffering from the "not invented here"-syndrome—both features duplicating and not integrating well with existing similar features—as well as some other general competence issues... (Wikipedia:Miscellany_for_deletion#Wikipedia:Gather/User Feedback, [5], [6], ...) —Ruud 02:51, 21 January 2016 (UTC)
But concretely speaking, if someone creates a "List of Republican presidential candidates and SS officers", should I click 'flag', or 'hide', or nothing at all because "it's my list and I can damn well put any articles in there that I want"? (Hypothetically speaking, ofcourse, I have better things to do than click buttons all day.) —Ruud 03:14, 21 January 2016 (UTC)
Ruud, the WMF developed Gather without every checking with the community, they announced deployment with a message that we were "responsible" for creating a policy for acceptable/unacceptable collections, and expected us to police it for them. No policy was ever created. The closest thing to an answer here is that several people have said that substantially all Collections fall under Speedy Delete criteria U5. I'd say you could flag or hide basically any and all collections if you feel like running through them by hand. The Admin Noticeboard consensus was that Administrators should take NO ACTION to handle any issues relating to Gather. Alsee (talk) 19:42, 22 January 2016 (UTC)
hahaha Ruud! (your first line) Boscaswell (talk) 10:59, 23 January 2016 (UTC)

Conclusion

Allright, this testing-the-water discussion has shown that multiple editors feel that Gather should be disabled on enwiki for the time being. Now it's time to start a formal discussion to present to the WMF (if the conclusion in that RfC is the same of course). What's the best place? Here? Village Pump Policy? WP:AN? I'ld like to do it correct from the start, if possible, to avoid procedural objections (apart from the objection that the WMF devs technically can do whatever they want against consensus, which is true but doesn't mean that it would be very smart of them to do so). Fram (talk) 20:52, 21 January 2016 (UTC)

Either Village Pump works, it seems to me.Jo-Jo Eumerus (talk, contributions) 20:55, 21 January 2016 (UTC)
IMO this page is most appropriate to run an RFC simply proposing it be shut off. On the other hand we have no policy on handling Gather collections, so it could also make sense to open a Policy page discussion on whether we want to create a policy for handling these.... and if not whether they are all simply subject to speedy delete (or even bot delete) them all... which could have an "incidental" question of whether it should be shut off. Alsee (talk) 03:01, 22 January 2016 (UTC)
  • We should get put it here (VP proposals). I think the question will be that it be disabled, in which case a policy would be redundant. If the RFC for disablement fails, we already have consensus at AN that we don't want to moderate them. BethNaught (talk) 11:32, 26 January 2016 (UTC)

A WMF reply next week

Greetings folks, thanks for initiating this conversation, and clearly stating the legitimate concerns. No further community reactions need to be planned; by next week, the Gather team will have a major update to share about the feature, based on its performance throughout the beta test, and the legitimate concerns that you shared above. Hopefully no more "poorly designed feature with an unclear purpose without community consultation?" will be launched again :). Thanks again for starting the conversation and listing clear concerns.--Melamrawy (WMF) (talk) 16:46, 22 January 2016 (UTC)

@Melamrawy (WMF): I expect that this means you either will (a) disable Gather on the English Wikipedia as the community has repeatedly asked or (b) present a completed product that does not violate local policy, is not lazy about correct image attribution, and addresses the basic points pointed out by Risker last year on Lila's talk page and also here: anything public on Wikipedia must be able to be curated by the community and blend in with the community's tools (say, RecentChanges feed and user contributions lists). I for one am not particularly interested in an update about what your team is doing unless (a) or (b) happens. I have no problems with running beta software, but if a major problem in an optional extension is discovered, it needs to be dealt with immediately, for example by turning off the optional extension. —Kusma (t·c) 19:35, 22 January 2016 (UTC)
For some background on the image attribution question, see also WP:VPP#Images linking to articles. —Kusma (t·c) 20:14, 23 January 2016 (UTC)
Melamrawy (WMF), I would like to remind you that I repeatedly asked if the WMF was willing to constructively engage the Community on what to do about Gather. You repeatedly refused to answer that question. I asked the question at least twice on project manager's talk page, and he repeatedly ignored the question. I asked the WMF Executive Director the same question, and she also ignored it. I asked about a half dozen times. The main reason I never initiated a unilateral Community RFC was because a family member was hospitalized with cancer. I dropped it because I just wasn't up to dealing with the polite-brick-wall approach to community engagement.
Regarding what's next, I can't speak for anyone else but I suspect others will consider it reasonable to hold off starting any RFC for a week. I certainly welcome you posting the WMF's information, plans, and case in favor of Gather. I was hoping for that sort of thing when I basically begged for WMF-Community engagement on this. I hope you recognize that there will almost certainly be an RFC afterwards to discuss it. I really hope the WMF acknowledges that that turning off Gather is a valid topic of that discussion. Probably the worst case scenario would be that the Community rejects Gather, the WMF takes the position that the Community are mere users with no business participating in such decisions, the Community sets Policy to delete/hide all collections, and then the community assigns a bot to handle the drudge work nuking them all. All that would be accomplished would be pointlessly burning yet another bridge in WMF-Community relations. I hope for a more collaborative outcome. Alsee (talk) 22:58, 22 January 2016 (UTC)
Not my project, so I may be wrong, but from Risker's comments above, it appears that it's actually not possible for the local community to delete Gather lists.
I think you should wait until that team has recovered from their mid-year review and can tell you what their plans for the near future are. Whatamidoing (WMF) (talk) 02:21, 23 January 2016 (UTC)
Welcome back Alsee, and so sorry to hear about your family member. I hope they are doing much better now. As you know, WMF had an engineering re-org, then the Reading department started a strategy process in order to define steps moving forward. Those steps meant team changes, as well as taking a few steps back to re-think and plan, not to initiate RFCs around features :). According to the roadmap, Gather upgrades are included, where those updates don't necessarily mean, continuing the work around the current status of the feature. In general, and as mentioned in the positive comments above, the feature has potential, and could also serve other community requests, and after running for a while in beta, it won't be a bad idea re-envision the future of the feature, together. :).--Melamrawy (WMF) (talk) 20:17, 23 January 2016 (UTC)

I suggest we wait until early February to see whether the WMF answer is in any way satisfactory, and only then decide to hold an RfC on disabling this or not. It has been around for more than 1/2 year, waiting two more weeks won't hurt too much now. As long as the WMF realises that it will need to be convincing and significant to hold off this RfC. Cosmetic changes or promises of improvements to come will probably not be sufficient.

Can I also ask: the WMF has started Gather only here (as far as I know). Where have they collected the necessary feedback from the community about the first months of the test? Or are the conclusions and new direction purely data-driven, and not based on textual feedback or maintenance considerations? Fram (talk) 09:43, 25 January 2016 (UTC)

To elaborate on the above: you said "As you know, WMF had an engineering re-org, then the Reading department started a strategy process in order to define steps moving forward." which has nothing on Gather. The Roadmap mentions Gather and Gather upgrades, but tells me nothing about the process that lead to this (or what the upgrades to Gather will be, but I guess that is something we'll hear this or next week?) Fram (talk) 10:00, 25 January 2016 (UTC)

Hi Fram, Gather development requires engineering and design work commitment. Depending on the future of the feature, those need to be decided accordingly to be convenient with the rest of the workload of the of the team. For example, it requires dedicated engineering work to change the way how the feature is built, in order to change the current moderation scenario, and therefore, it might not be something to expect within the next 3 months, given the other per-planned things that the team is working on from January to April. Gather has been running for a while, and it also hasn't been maintained for a while, which is not an ideal case, but unfortunately with changes and planning phase, this could happen. I am hoping that while we sort out this situation together, we all will have an understanding of how to make sure we don't loose a good potential, while maintain our community values.--Melamrawy (WMF) (talk) 18:26, 25 January 2016 (UTC)
Frankly, Melamrawy (WMF), that sounds like a lot of waffle to say nothing at all. So an unwanted tool is implemented here anyway but then not maintained; when we may want, after waiting way too long, to shut it down, you promise to have "a major update" next week (which is by now this week, I guess). But now it seems that no major update will be forthcoming, but some announcement (a "major" announcement I suppose) about plans for May 2016 and later. Fine, if that's the case, then please shut it down, make your announcement, and when the changes have been made ask if it can be re-enabled. That way, you will have made a step in "maintaining our community values". No good potential is lost by shutting a tool down until it is a) a lot better and b) wanted here, but a lot of community goodwill is lost by keeping a tool active which is no good, not wanted and unmaintainable. It's up to you (WMF, not you personally probably) what has priority and best reflects our community values. Fram (talk) 18:50, 25 January 2016 (UTC)
I am a bit at a loss what "good potential" you are talking about: What would be lost of you disable the feature now and re-enable it when it has been made fit to be used on this Wikipedia? I can't see anything about it that is worse than just keeping the broken extension running for the next couple of months. —Kusma (t·c) 20:28, 25 January 2016 (UTC)
Too bad my explanations seem like nothing at all, Fram :). I tried to give some reasoning of why we stand where we are right now, and what I mentioned about the timings, is no secret, the team already shared its plans early, and it is a good sign to abide to them. On another note, having personal user lists (even if private) is an interesting use case, using the same infrastructure (after fixing it) for user watchlists, is a use case that has already been discussed elsewhere, exploring how the feature can serve our readers, while maintaining our workflows and values, and inviting them to understand how Wikipedia works, isn't a bad effort. This is what I meant by the good potential, generally, and regardless of disabling and re-enabling. Finally, the team is still discussing realistic and feasible next steps, and further announcements will made. Thank you.--Melamrawy (WMF) (talk) 21:56, 25 January 2016 (UTC)
That's the problem, your "explanations" first gave the impression that Gtaher would be significantly changed this week, which sparked the reaction that we could wait with the RfC. But in your next post, it looked as if nothing significant would change, only some announcements would be made of what you would start working on in April or later. You gave a reasoning of why nothing was done on this tool no one really wanted anyway, but you haven't given a single reason why it shouldn't be disabled now. Can you provide a clear link to the place where "the team shared its plans early", and if it exists a link to what they based this on? And can you, now or at the time of the announcement later this week, give us a good link to the information that that new announcement, those new plans will be based on? I hope you have some actual community input gathered before this, and that this is announcement isn't just a knee-jerk reaction to this discussion here and now (the timing may be coincidence, but without any evidence for this it certainly looks suspicious). You give "user watchlists" as a good user case to use the same infrastructure after fixing it. you are aware that we already have an infrastructure for watchlists, and that for years and years improvements to those have been asked? Getting a new type, which is at the moment a lot worse than the existing one, is probably not the best solution. User watchlists (and watchlists in general) are not really useful for most readers anyway, they are much more an editor-thing. Developing them first for mobile is even less indicative of any wish to get user interaction and the like. Perhaps you can focus on e.g. getting the talk pages easily accessible and editable from mobile, instead of toying with these ill-thought out and poorly constructed functions in Gather. Finally, why should we believe that "the team is still discussing realistic and feasible next steps" when no realistic and feasible first steps have been made and no clear focus on what is wanted and needed seems to exist? This development has "yet another WMF fiasco" written all over it. But it's nice that something like this can now more easily be shared by users, and that the WMF will patrol it. Or things like [7] or [8]. Do you really think it is wise to let people create this and share it with the world more easily, without having first a good way and people to track and administrate these things? I'm not even showing you the "collections" that only consist of a facebook or twitter link or an email address, or that just an (ineffective) way of promoting things, like [9] or [10] (of course, you also get the collections used to attack companies and the like, not much better). Fram (talk) 08:30, 26 January 2016 (UTC)
As the WMF is officially in charge of policing this content, I assume Melamrawy and her team all think this content is fine. Or they are not doing their job. In which case it would be better for everyone involved if Gather was simply shut off. —Kusma (t·c) 14:37, 26 January 2016 (UTC)
@Melamrawy (WMF): I'm confused by your statement that "by next week, the Gather team will have a major update to share about the feature". (I'm assuming "update" is being used in the information sense here, not the software sense?) Are you part of the Gather team? If so, couldn't you just give the update, instead of this "pre-update"? If not, how do you know about this? Did they say something somewhere? Can we have a link? Is there any sort of open communication going on, or is this stuff just going through private WMF private channels?
Could you explain what kind of situation we have here, please? These kinds of comments are worrying me quite a bit. --Yair rand (talk) 08:48, 26 January 2016 (UTC)
Fram,The reading roadmap is what I meant by the early plans that are shared, and Yair rand, I don't develop Gather patches and I don't design Gather interfaces, so while I am part of the team, still a wider internal discussion needs to happen, that puts in consideration developers and designers workflows, otherwise, we could end up over promising, or mis-estimating, which we certainly don't need. This is an organizational, very logical process, that has to happen along side our public discussion here.  :)--Melamrawy (WMF) (talk) 10:55, 26 January 2016 (UTC)
Melamrawy, are you serious? WMF community liaisons seems to be about as useless as the WMF Board or WMF quality control, as far as I can judge from the two Liaisons I have interacted with for some time. "The reading roadmap is what I meant by the early plans that are shared". Really, that's it. It's what I feared, but I hoped still that some miscommunication was happening. Have you actually checked what that page has to say about Gather? Strategic Pillar: "Develop a community of Readers". Team: "Web" Q4: "TBD (watchlists/Gather)" That's it, that's all there is. And "that" you dare to equate with "the team already shared its plans early, and it is a good sign to abide to them." Well, their "plan" was to decide something in Q4 (which is, annoyingly, 2016Q2 for most people who don't understand why technical changes are announced based on a fiscal year schedule), a "something" that would be web-based and intended to "develop a community of readers (sorry, that's Readers with a capital R)". Well, thank you for sharing, and kudos to the team for abiding by them, really impressive.
Let me rephrase this for you: "we, the WMF, have implemented a tool no one wanted, no one tested, and no one knew how to maintain; we then abandoned it for 9 months, until enwiki was fed up with it and threatened to get rid of it. We then pretended to have planned major changes for just that period anyway, which pretension we then had to change to promising a major announcement only, and no changes before April 2014 at the earliest. We claimed to have shared our plans and goals, but really had done nothing remotely resembling this. While we try to keep the plebs calm by letting our one-way community liaison waffle some more, we scramble to develop some estimates and goals without further community input, and claim that that is a very logical process, just for laughs. With some luck, they'll fall for it and we can continue as we were for another six months at least, and no one higher in the food chain has to know that we nearly failed with a new project again. Another major WMF success!" Fram (talk) 11:16, 26 January 2016 (UTC)
Fram, any roadmap marks the main issues that need to be covered over a long and short term. It is not an action plan, because it doesn't make sense to provide a detailed plan for something that is yet to happen 6 months from now. It will never be accurate. As you see in the Reading roadmap, Gather is mentioned in Android workflow as "Synchronized saved pages list" for Q3, which is from now until April, then web team will have Gather work that is yet to be decided in Q4, which is the 3 months after April. What does that mean? It means that the team understands that certain changes needs to happen to Gather, but this can't move forward without discussion. You happened to post your comment in sync with the plan, and what I am trying to elaborate on, is that, yes, Gather has been in planning, and the details of next steps is something that we need to define together, in line with community discussion (after the initial discussion here) as well as feature performance and team capacity. This is as far as Gather is concerned. On another note, I see your latest comment starts with an offensive tone, that offends me, my colleagues, and the board, while my understanding is that a user who is a real human being, and is making effort to align WMF products with our community values, would care for our values themselves, so I am hoping, that what I read was just a very long typo, or something :).--Melamrawy (WMF) (talk) 14:18, 26 January 2016 (UTC)
There is no indication that "Synchronized saved pages list" has anything to do with Gather though. Gather is only mentioned in Q4. "Synchronized saved pages list" doesn't address any of the reasons why people may want to disable Gather in any case, even though it is an extremely vague term. "What does that mean? It means that the team understands that certain changes needs to happen to Gather, but this can't move forward without discussion." No, that doesn't mean that at all. You may project this on it, but don't expect us to fall for it. That is offending. You link to the FAQ as "the initial discussion" (which is again quite confusing, a FAQ is not a discussion even though it is made to resemble one). From that FAQ, not edited since May 2015: "What is the roadmap? We are expecting to launch beta by the end of March, it will run for ~3 months, then we apply the lessons learned to a full release afterwards." We are now 10 months further (not ~3 months), there is no indication at all that you have any place where the "lessons learned" are gathered and discussed. The FAQ doesn't really resemble the actual implementation wrt e.g. admining of the pages anyway. "Admins have the right to hide/unhide a list if issues are flagged." I have looked at Gather for a few days now, have even created a test list which I can hide, and hide, and hide again, but can't delete. I know where and how to flag Gather lists. But I don't have a clue where to see which pages were flagged, when, by whom... Useful!
So, "the details of next steps is something that we need to define together, in line with community discussion". Where and when was that community discussion planned? You plan on working on Gather this quarter, where has this been discussed and decided?
On your other note; when I notice someone who tries to align WMF products with our community values, I'll treat them courteously. When I notice someone who is supposed to be a community liaison act like a WMF defender, with lots of patient explanations which are civil and otherwise utterly devoid of relevant, useful, concrete information, then I give them one or two chances to correct their approach, and then I'm done with acting as if they have the best interests of the community at heart. As for colleagues that may be offended: the one other community liaison I interacted with known perfectly well how I feel about her; the WMF as an organisation has long ceased to be worthy of much respect (but some individuals in it are nice, well-meaning people who give correct, factual information and answers and really try to help; the ones I intereacted with will know who they are); and "the board", do you mean the WMF Board? The one that currently is the subject of a petition wheer 90% asks them to get rid of their newly appointed member and in the future take care who to appoint? The one that removed a community-elected member but fails to provide one decent reason for it? The one that no one really cares about any more, as they seem to be pointless and toothless in any case? The language used by the current members of that board is a lot more offensive anywaysee the end of that diff. I'm terribly sorry if they are offended by my post here. If, on the other hand, you mean this village pump, well, I guess a discussion board can not be offended, and the people participating will decide for themselves if they are offended or not. Of course the bold part of my previous post was offensive, having your errors publicly pointed out usually is offensive in the short run. That doesn't make any of it wrong obviously.
Basically, instead of being offended, you can perhaps finally indicate a few concrete things. What community discussion is being planned before further work on Gather is started? Where have the team collected data and feedback about Gather? Why shouldn't this malfunctioning, unmaintainable, problematic tool (see links in my previous post for examples) be disabled for the time being? What kind of major update will we get this week? Please, don't point to that roadmap again, you are just making a laughing stock of yourself. Fram (talk) 15:00, 26 January 2016 (UTC)
Stop this. You are yelling at a part-time contractor in Alexandria, Egypt as if you are the worse first-world multi-national boss. It's disgusting. Alanscottwalker (talk) 15:19, 26 January 2016 (UTC)
No idea why you need to add a first-world vs. contractor in Alexandria, Egypt angle to this. I have no idea where Melamrawy is from or currently works, and I don't care. All I care about is getting some useful and truthful answers. If you even can't get those from a community liaison, then what use is that function? In all the responses above, there is nothing I can point to that actually makes anything about their plans for Gather and what these supposed plans are based on any clearer. All we get is obfuscation, ignorance, and being offended when this is pointed out. If you want analogies: I'm not yelling at a contractor, I'm fed up with a salesman who has installed a tool in my house which I didn't want, can't use, and want to get rid off, but which they refuse to even consider removing again because the new, better version is just around the corner. Fram (talk) 15:44, 26 January 2016 (UTC)
I brought it up because your comments suggested, you sorely needed a reality check. This is not your house. This is a place where you have to work with others across wide cultural spaces, and that can be tough, around here, and some people, sometimes, cannot handle it. See, Wikipedia:No angry mastodons --Alanscottwalker (talk) 15:51, 26 January 2016 (UTC)
I don't think the yelling (and the somewhat off topic remarks about the Board and Jimbo) are particularly constructive, but Fram's post contains more content and information about Gather than Melamrawy's, which seem to fit into the "polite-brick-wall approach to community engagement" as Alsee noted above. There seems to be resistance even to fixing the most obvious problem (display of non-free media for decorative purposes). —Kusma (t·c) 15:58, 26 January 2016 (UTC)

Melamrawy (WMF) I would like to thank you for, what I see as, positive progress above. Your first two replies tried to tell us not to run an RFC, and avoided acknowledging important parts of what we were saying. Your objection to some of the "offensive tone" above is entirely understandable, however the reason for that tone is also very understandable. I'm not sure what you're willing to say, or what you're allowed to say, but I'd like to make a suggestion. It would immediately lower the temperature and help us work together if you could clearly indicate two things. (1) The WMF respects Community Consensus as a partner here, and (2) acknowledgement that permanently shutting off Gather is a valid topic on the table for discussion. It's difficult to have a collaborative discussion when there's a perception that the WMF is unwilling to respect any discussion except upgrades for mandatory project. Alsee (talk) 17:15, 26 January 2016 (UTC) Oh, the RFC was just started. Okey, heading over there. Alsee (talk) 17:25, 26 January 2016 (UTC)

RfC now started

The RfC has now been started at Wikipedia:Village pump (proposals)#RfC: Disable Gather on enwiki below. Fram (talk) 15:45, 26 January 2016 (UTC)

I thought we are waiting until our further announcement of next steps? :). What if the issues that support disabling are actually going to be fixed? --Melamrawy (WMF) (talk) 16:31, 26 January 2016 (UTC)
There has been plenty of time already for the WMF to engage on these issues and we already waited for your promised announcement, which turned out to be nothing. For some of us at least, our patience is now at an end. BethNaught (talk) 16:46, 26 January 2016 (UTC)
PS inserting smiley faces do not make people happier or more co-operative. When you're dealing with disgruntled people it comes off as patronising. BethNaught (talk) 16:48, 26 January 2016 (UTC)
Are they? When? How? I think people got a bit tired of all the stonewalling. —Ruud 16:57, 26 January 2016 (UTC)
Well, as explained above several times above, the team is aware that Gather as a feature requires design and engineering changes, and the feature has already been on the roadmap, and having an internal conversation before having a wider community discussion is acceptable. The smiles aren't patronizing, too bad this came across as such, no offense to anyone, I am just surprised why things changes and the decision was made not to wait for the team announcement to be made after the team announces updates. Anyway, WMF update will still be announced by the end of this week --Melamrawy (WMF) (talk) 17:27, 26 January 2016 (UTC)
@Melamrawy (WMF): at this point it is probably best for you to talk to the technical folks and just turn it off. The RfC is very unlikely to say to keep it and you have been advised of how the lists can violate Wikipedia's core content policies, WP:BLP (To the point of an example being provided that seems to target a named minor), WP:NFCC (By making use of images beyond their Fair-use rational.), and WP:NPOV. You have also been informed that the community has no way of adequately policing these lists nor a way to address these policy violations if and when they are found. These are not minor problems and should not be allowed to be continue on en.wp (or anywhere) while the developers diddle with "road maps" and "internal engineering conversations" and whatever other meaningless project management speak for spinning their wheels is in vogue.

The essence of managing community relations is to recognize when you are faced with an unwinnable situation and how to not loose the trust of the community by riding a dead horse to your own loss of relevance. JbhTalk 18:36, 26 January 2016 (UTC)

So neither the community nor the development team seems to be moderating these lists currently. Some of the lists Fram pointed out above are potentially libellous. Has the development team discussed the potential ramifications of this tool with WMF Legal? Are they okay with this? Do they know what to do if someone files a complaint? In the past I would have asked User:Philippe (WMF) about this, be he seems to have left. —Ruud 17:46, 26 January 2016 (UTC)

@Ruud Koot: I think User:Mdennis (WMF) handles that stuff now. (Not completely sure.) --Yair rand (talk) 21:30, 26 January 2016 (UTC)

A Response from the WMF

Hello Folks, I’m Toby and I manage the reading team, including the team that has created Gather, and I wanted to give you an update about it.

First and foremost, I completely understand and acknowledge the issues about Gather and the values of the English Wikipedia community. While I believe the feature was created in good faith with the intention of increasing the number of contributors, the implementation has clearly created problems that were not thought through. I also believe that we as a Foundation were not transparent enough in the creation and design of the feature.

Please understand that this is a complex situation and we in the Reading team need some time to analyze the impact of various options. For example, if the feature is disabled, we need to assess options of what to do with the collections that have been created. We are also looking into the legal concerns that have been raised. The plan is that we will be putting together this analysis starting now with the intention of sharing publicly next week with a decision the week after.

I’d like to have a much better relationship with our communities and I hope that this can be the start of better and more transparent communication from the Reading team. TNegrin (WMF) (talk) 21:11, 28 January 2016 (UTC)

So it takes the threat of an RfC calling for a feature to be disabled before the WMF responds to community concerns? I have some RfCs to write... Anyway, based on the RfC timings, I suppose you have a month. Also, if you want a good community relationship, you can drop the PR tone. Actions speak louder than words and you will only alienate yourself if you talk like certain WMF staffers I could name. BethNaught (talk) 21:26, 28 January 2016 (UTC)
You know what I'm most disturbed by? The fact that there is apparently not a lessons-learned database of some sort at the WMF. It's as if the VE team forgot to tell the Reading team that the community would rather provide their permission first than be asked for forgiveness later. A whole bunch of other teams seem to have shared the same mistaken impression. The phrasing "have a much better relationship with our communities" is one we've heard before, over and over and over. Get out of your apparent silos and talk to each other, or use a wiki and write some stuff down about community engagement, and then have your teams read it. --Izno (talk) 12:37, 29 January 2016 (UTC)
Out of curiosity, User:Melamrawy (WMF), is this the "major update" promised for last week, or an early addition to it, or something we get instead? It's just that your WMF colleague said that the major update was already under development, nearly finished, and that I "[...] happened to post your comment in sync with the plan, [...]", while this gives the impression that you have only started the discussion and analysis in response to the discussion and RfC here. Basically, "we will be putting together this analysis starting now" doesn't seem to match with the promised major update that was already planned by the WMF... Fram (talk) 13:23, 31 January 2016 (UTC)

User:TNegrin (WMF), could you, for starters, remove the rather wrong notice at the bottom of mw:Extension:Gather? "This extension is being used on one or more Wikimedia projects. This probably means that the extension is stable and works well enough to be used by such high-traffic websites." is wrong on so many levels... Fram (talk) 12:48, 1 February 2016 (UTC)

No, that's not possible. The statement is part of a template. And, technically, the extension is stable enough (as in, not-buggy) to use on Wikimedia wikis without e.g. crashing the wiki. --Izno (talk) 12:58, 1 February 2016 (UTC)
That's a very strange answer, Izno. I asked for a removal of a notice, i.e. removal of that template on that page. I fail to see what's "not possible" here. Fram (talk) 13:13, 1 February 2016 (UTC)
I think the issue is that the concerns raised here do not justify the removal. "Extensions" can range in quality from top notch to some bug to serious malfunctions to major security issues, the concerns raised here fall somewhere at the top of this scale, not top notch but not low either.Jo-Jo Eumerus (talk, contributions) 13:15, 1 February 2016 (UTC)
Let me rephrase: Mediawikiwiki has guidelines for extension pages. One of them is documentation of whether the extension is usable (or generally, what state it's in). Removal of the template would thus go against said guideline because it functions well enough to be used on Wikimedia wikis. Basically, this request is barking up the wrong tree. --Izno (talk) 13:18, 1 February 2016 (UTC)
And what will they do if it gets removed here? The extension will still be exactly the same, but the template would be a lie as it isn't being used on any other Wikimedia projects (as far as I know). In any case, if the WMF considers something like this "usable", then that explains a lot. Then again, I note that Liquidthreads has the same, even though at the top they discourage all new installations. Quite contradictory, that. One would expect some pride in realisations, i.e. that they would only give really working extensions, free of all major bugs and thoroughly tested, the "ready to deploy" label, not something hacked in a few weeks and then abandoned, where half of the initially promised functionality doesn't work (like flagging issues), never mind the needed functionality. Fram (talk) 13:23, 1 February 2016 (UTC)
Gather is also in use on the Hebrew Wikipedia. See [11]. The problems with the extension are not technical ones, they are that the extension does not tie in well with the wiki part of the website, and the surrounding social and usability issues. Other MediaWiki users might find it useful. —Kusma (t·c) 13:47, 1 February 2016 (UTC)
Thanks. I see many technical issues as well (flagging does nothing, things deleted can't be undeleted or even checked for who did the creation and the deletion, and so on), but considering the MVP of the WMF (installing this will not crash the rest of the site), it probably should be considered a success instead of a failure. Any idea where I can read the promised-for-last-week major update about Gather, by the way? Or is the major update the reply that they will now look at things, and give us a major update in two weeks or thereabouts? The tension is unbearable... Fram (talk) 13:58, 1 February 2016 (UTC)

@Melamrawy (WMF): you promised us "No further community reactions need to be planned; by next week, the Gather team will have a major update to share about the feature, based on its performance throughout the beta test, and the legitimate concerns that you shared above." on 22 January. So far, all we have got is the above reply by User:TNegrin (WMF), with "we will be putting together this analysis starting now with the intention of sharing publicly next week with a decision the week after." So it looks that after you declared (multiple times) that a major update was forthcoming (and should have been posted last week), and that it was simply coincidence that our discussion started at the same time and so on ("It means that the team understands that certain changes needs to happen to Gather, but this can't move forward without discussion. You happened to post your comment in sync with the plan, [...]"), we now have a statement saying that the analysis only started after we had our discussion here, and that a decision will come in two weeks time. Can you explain that discrepancy and what "major update" you were referring to in your initial statements here? Fram (talk) 08:09, 3 February 2016 (UTC)

I still fail to see how this matters, User:TNegrin (WMF). Below RFC starts to show quite a consensus that en.wikipedia wants it disabled. I understand that all these extensions are created in good faith, but in that good faith it was not considered that it frustrates the community as is, and that it therefore may result in editors actually leaving as a result (or even, new editors may leave as a result of the situations created with the extension - I understand that if I delete a collection, it is gone forever without trail, how does that look to a new user? They made something and they don't know where it went and no-one except for the deleting admin knows). What I do not understand is why these 'features' need to be enabled on a live wiki, and foremost without community consensus first. Can this not be enabled first on a test-wikipedia, thoroughly tested and discussed to take out problems that do not show up early (undeletion?), and before considering to bring it online on a wiki to discuss how it ties in with the local policies (NCFF, WP:NOT) and how that can be addressed (maybe more code changes). And maybe certain 'features' are not suitable for a Wiki/any Wiki and the whole development, even in good faith, is a total waste of time. Did these ideas ever get properly discussed with the community?

For all these features, WMF keeps jumping the gun. As per the RFC below (I'll jump the gun there (per WP:SNOW) to consider that that RFC will likely close as a 'disable Gather' consensus), why not show your good faith in this, and disable it before the RFC runs out, (at the very least) address the issues, and before enabling any feature, show us a working test-version and start an RFC whether the community thinks it is suitable for that wiki, works properly according to them, whether it fits with their local policies and guidelines, and whether they want it. Or better - first consider whether a community wants these things before starting to developing them. --Dirk Beetstra T C 08:46, 3 February 2016 (UTC)

First of all, I want to acknowledge the legitimate feedback from above -- it shouldn't have taken an RFC to get the Foundation's attention on this issue; clearly it wasn't right to let this feature sit in beta for so long with no communications. As I said before I totally acknowledge the issues with the values of English WP and Gather; they are definitely problematic. To be transparent, we're building a more thoughtful and collaborative culture inside the reading team and just as we needed more of these values when we launched Gather I want to make sure we approach all of our issues in this way. It takes time and effort but I feel the output will be better and worthwhile. TNegrin (WMF) (talk) 17:32, 3 February 2016 (UTC)
@Melamrawy (WMF) and TNegrin (WMF): That's all well and good, but can you please distil that nebulous corporate PR speak into something concrete? For example, will you commit to honoring the likely outcome of the RfC? If not, you might as well deny it right away. Saying you want a "thoughtful and collaborative culture" means nothing if it doesn't lead to tangible outcomes. So far all the WMF has told us on this issue has been to kick the issue into the long grass with vague platitudes. BethNaught (talk) 17:46, 3 February 2016 (UTC)
  • I think we can afford to be slightly kinder to each other here. This is not a new problem; I've been fighting the "not meeting minimal production wiki standards" battle for years with any number of extensions. I do sense a change in attitude this time: we have the head of Reading involved in this conversation, which is significantly higher than any prior discussions have gotten until things got so SNAFU'd there was a major revolt. As I note, I've had this discussion repeatedly, with slight variations; however, each time it has happened, it's been with a different development silo within the WMF. What I am hearing Toby say is that he (and hopefully others) are seeing that this is a more universal issue and isn't really an extension-specific problem, and that the team is trying to get its head around understanding when and how to ensure that curation/moderation/logging is integrated into new extensions *before* they hit a roadblock on production wikis. I've finally sat myself down and started writing up the issues that have been identified and the ways they should be addressed before getting out of the testwiki, and will share them widely after a little extra review and buffing. (If you're really curious, just look at my contribs, it's in my userspace.) The WMF staff have been handicapped to a non-trivial extent by their work structure and leadership over the years, and we should leverage this change in pattern. It's no more fun for the developers, CLs and project managers to see their work product slammed as it is for us to see *another* product that isn't able to deal with the routine, daily activities of our project. Let's try to make it better for all of us - some of the stuff they've come up with is really useful (notifications for example), and some of it has potential even if it needs to be rethought; not all of it is dreck. Risker (talk) 19:31, 3 February 2016 (UTC)
    • True, but the rethinking and better approach shouldn't mean that the basic question, to remove this extension for the time being, gets sidestepped. And I do hope that this better approach and communication will also get through to the community liaison, who still have to explain what has happened to their promises. Fram (talk) 19:42, 3 February 2016 (UTC)
      • That's fair, Fram. One of the points that has been mentioned is "what should we do about the "collections" that have been created?" Would you (or anyone else) have some suggestions on how to address that? It's fair to say some should probably be deleted for various reasons regardless of what happens, but some of them appear to be nice, good-faith attempts by users to create something that will be useful for themselves. How do we help them? Perhaps we can brainstorm this out, and perhaps invite one or more of the more frequent users of the extension to participate in that. Risker (talk) 20:21, 3 February 2016 (UTC)
        • Turn every list into a regular subpage in that user's userspace, with links to all pages that made up the original list (and with the same subpage title as the list had). The WMF could write a bot to do this, presumably, as they have easier access to the database beneath these Gather pages. Meanwhile (i.e. until the above is feasible), Gather could be disabled in the sense that no more pages can be added or changed, but that existing pages remain until that bot conversion has been created. Empty pages (lists with no articles) can immediately be deleted of course. Just brainstorming here, but I think something like this should be feasible. Fram (talk) 20:34, 3 February 2016 (UTC)
          • I don't think that's realistic. Let's just disable it, all this has wasted enough of everyone's time now. Let's not waste a couple hundred more hours. —TheDJ (talk • contribs) 22:43, 3 February 2016 (UTC)
            • Oh, I have no problem with that solution, it's just that if the WMF would be convinced that things created so far need to be kept somehow, the above is a possible solution they can do. In any case, no further enwiki hours should be spent on this, that is something most of us agree on. Fram (talk) 08:12, 4 February 2016 (UTC)
          • Perhaps a bot message to the creators of Gather pages advising them that the extension is being disabled and that the pages will be deleted? Perhaps give a few days' notice so that they could "copy" their selected pages to another page within their userspace if they wish? Risker (talk) 19:34, 4 February 2016 (UTC)
          • We've written a bot that downloads collections to a user page; it's a good solution and retains the information in the collection. The bot message to the Gather creators is a good idea and we'll review that next week. Thanks for the thoughts on this.TNegrin (WMF) (talk) 23:12, 5 February 2016 (UTC)
  • Thank you Risker -- that document is very useful. I've added comments to the talk page and feel like this could be the basis for a sort of cultural primer for Wikipedia and other communities. It's certainly something I would have benefited from when I started working at the Foundation!TNegrin (WMF) (talk) 23:12, 5 February 2016 (UTC)

I've posted a summary document that we are using as the basis for the WMF discussion here. While the document is high level, I've tried to at least summarize the community concerns as well as provide some usage metrics in as objective manner as I can. To be clear, I'm trying to work with the time allocated by the RFC process to have a structured discussion of these issues inside the Foundation. The Reading team is having the discussion on February 6th (this Tuesday) and I will communicate the results as quickly as I can.TNegrin (WMF) (talk) 23:12, 5 February 2016 (UTC)

Points for improvement at least (BTW do you mean the 9th of feb?). I guess that gets us as far as "we shall see".©Geni (talk) 17:59, 7 February 2016 (UTC)
Yes -- the 9th. Thanks for the correction. TNegrin (WMF) (talk) 23:03, 7 February 2016 (UTC)
Just a quick note -- we've had our meeting but the analysis has taken longer than I anticipated. I'll post the results as soon as I can. My apologies for the delay. TNegrin (WMF) (talk) 02:13, 12 February 2016 (UTC)
Ominous.©Geni (talk) 05:46, 12 February 2016 (UTC)
@TNegrin (WMF): Any news? It's been nearly a week since the meeting and the RfC has less than 12 days to go. BethNaught (talk) 23:37, 15 February 2016 (UTC)
Nearly a week? Patience, my young padawan, I'm still waiting for a follow-up to things like "Anyway, WMF update will still be announced by the end of this week --Melamrawy (WMF) (talk) 17:27, 26 January 2016 (UTC)" and all the other Melamrawy promises. ("I thought we are waiting until our further announcement of next steps? :). What if the issues that support disabling are actually going to be fixed? --Melamrawy (WMF) (talk) 16:31, 26 January 2016 (UTC)"). Since those, Melamrawy has disappeared from the Gather map completely but has edited enwiki since, so should have noticed the follow-up questions and pings. I still don't know what major update was going to be given weeks ago, and from seeing the response from other WMF people, it seems they had no idea such an update was coming either. What's the point of a Community Liaison who seems to be only interested in making up stories to protect the WMF (and isn't very good at it)? Fram (talk) 08:02, 17 February 2016 (UTC)
Of course, looking at Melamrawy's "what I am up to" board has nothing whatsoever about Gather. Doesn't seem busy with this anymore, is now getting flak about user surveys instead. Building up quite a nice track record! Fram (talk) 08:11, 17 February 2016 (UTC)
@TNegrin (WMF): over a week now.©Geni (talk) 23:40, 18 February 2016 (UTC)
I'm sorry for the delay, it's been quite a week. I've posted a proposal to address the issues raised in the RFC. I think the best place for feedback is the talk page of the post itself. Thank you for your patience and consideration of this proposal.TNegrin (WMF) (talk) 06:56, 19 February 2016 (UTC)
Woah, that proposal is an insult to the community. The WMF doesn't give a fuck about community consensus, what a surprise! The Quixotic Potato (talk) 08:05, 19 February 2016 (UTC)
You haven't actually written a "proposal to address the issues raised in the RFC.", you've written a proposal to create a roadmap in three months time that will then outline the steps to address the issues raised in the RfC. And here I was thinking we would get a major update by the end of January that could well have solved the issues of the RfC already. Strange how often things get miscommunicated with the WMF. Anyway, I've given my comments and rejection of the proposal at the talk page there. Fram (talk) 08:15, 19 February 2016 (UTC)
Likewise. This smacks of yet more stalling tactics and an attempt to save face. BethNaught (talk) 08:27, 19 February 2016 (UTC)
I've provided some more clarification about why we're proposing making the Gather collections private in the proposal. I will continue the discussion over there. TNegrin (WMF) (talk) 16:46, 19 February 2016 (UTC)
@TNegrin (WMF): Do you really believe that "make Gather collections private, but not before April" is an acceptable answer to the well-reasoned demand "please disable Gather now"? —Kusma (t·c) 17:01, 19 February 2016 (UTC)
@TNegrin (WMF): Any reason why you just simply userfy the Gather collections, instead of making them private? You claimed on the 5th "We've written a bot that downloads collections to a user page; it's a good solution and retains the information in the collection." which would "maintain[...] value for the users of Collections." (text from your proposal) while making it possible for the WMF to follow the RfC instead of circumventing it. I see no reason for the new proposal instead of the above bot proposal, apart from "we don't want to disable Gather no matter what". Don't you think, to gain some credit and show some respect for enwiki, that following the RfC would be a better start than making a wishy-washy proposal that may perhaps, in a few months time, if your lucky, do what the RfC wanted, but then again, probably not? Cause that's how it looks now. Coupled with an unreliable Community Liaison, developers at Phabricator who don't know the difference between the RfC and your proposal (whether that is their fault or the fault of the one that made the request to them is not clear from here), and nothing but delays and delays in dealing with the WMF (how long does it take to remove fair-use images from places where they aren't allowed, by the way?), you are not building any bridges here. Fram (talk) 13:28, 20 February 2016 (UTC)
In addition to the above, Gather has now been made redundant by software that is hosted outside of our domain and imposes no moderation burden on the community. MER-C 04:30, 8 February 2016 (UTC)

Category:Pages where template include size is exceeded split by content space

Latest comment: 8 years ago16 comments8 people in discussion

The category now lists many Userspace-pages that are not up for improvement (by the any-editor like me). I propose the analyser splits the list into two categories by contentspace (or articlespace). -DePiep (talk) 20:01, 25 January 2016 (UTC)

Is such a parser technaically possible? I'm not sure if we can do this to MediaWiki:Post-expand-template-inclusion-category, some of the MediaWiki namespace pages can't have wiki text in them, and this one seems likely. עוד מישהו Od Mishehu 08:51, 27 January 2016 (UTC)
I know nothing about it, but the category says it is "populated automatically by the MediaWiki software" so the software could be upgraded to produce two categories: one for articles, and one for everything else. On the other hand, if the category estimate is accurate, it says it contains 832 pages, so it would be reasonably straightforward for a bot to list all pages and make a page that contains only mainspace links. That could be done once a week or once a day. Johnuniq (talk) 02:43, 31 January 2016 (UTC)
If you want a change in the MediaWiki software, please see WP:BUGS. עוד מישהו Od Mishehu 22:12, 31 January 2016 (UTC)
Yes to Johnuniq. -DePiep (talk) 22:35, 2 February 2016 (UTC)
@DePiep: I put a list at cat talk, and an API link that can be used to generate a new list. Johnuniq (talk) 08:55, 3 February 2016 (UTC)
  1. 2011-06-15 03:09:48 (UTC): User 68.90.232.27 t • c • dc • l • ef • b • bl; (12) to Smile of a Child TV (edit | talk | history | links | watch | logs) (diff  !top) - Link: adland.tv/commercials/oreo-chocolate-creme-mommm-2002-030-usa (R/Xmeta/L- removed)
    Other links: www.smileofachildtv.org/watch/schedule_weekview.php (12, 7, 1, 1- R/X/L) www.youtube.com/watch?v=AcJkkolEUws (12, -1, X, X- R/X/L) adland.tv/commercials/stayfree-maxi-aisle-2004-030-usa (12, 104, 4, 1- R/X/L) www.youtube.com/watch?v=S24kVjBGC8M (12, -1, X, X- R/X/L) www.youtube.com/watch?v=Z1YDj4GyGV8, (12, -1, X, X- R/X/L) www.youtube.com/watch?v=2XwFFYdSu3w (12, -1, X, X- R/X/L) www.youtube.com/watch?v=nGQT5GX6HhY&feature=related (12, -1, X, X- R/X/L) www.youtube.com/watch?v=kv3bMgs_OxM (12, -1, X, X- R/X/L) adland.tv/commercials/enbrel-en-2006-60-usa (12, 104, 4, 1- R/X/L) adland.tv/commercials/depend-road-trip-2003-030-usa (12, 104, 4, 1- R/X/L) adland.tv/commercials/oreo-chocolate-creme-mommm-2002-030-usa (12, 104, 4, 1- R/X/L) www.bananascomedy.com (12, 8, 1, 1- R/X/L)
was not displayed at the end of the page. Pldx1 (talk) 17:06, 10 February 2016 (UTC)
Cleaning up would be good—I've done a few and made a module but it's not easy. How about these: User:Rich Farmbrough/Talk Archive Mega2 (Rich Farmbrough) and User:Riegel2222/sandbox (Riegel2222). Johnuniq (talk) 00:52, 11 February 2016 (UTC)
I have done "a few" too.   (Including some optimization on User:COIBot/EditSummary.)
You can perhaps achieve the desired effect, by using the code from {{Namespace Greek}} in the text of the appropriate MediaWiki error message page. The code has to be replicated in its entirety, since by the time the parser has given up on expanding templates.
I do agree that a lot of the bot generated stuff is never used.
All the best: Rich Farmbrough, 01:32, 11 February 2016 (UTC).
I noticed you did a lot of work from your comments at the cat talk. I hope it didn't look like I was complaining—the reason I mentioned the two examples above is that they show the tricky social nature of the quest to clean that category. Johnuniq (talk) 01:53, 11 February 2016 (UTC)
Indeed. However many of the users are long gone, and their pages can be legitimately and with no qualms, tweaked into conformance. My archive pages need rebuilding anyway, but it is interesting to note that the reason they were limited to their current size was transclusion limits, I suspect that many templates have grown in size.
I'm sure we can deal with the big issues, it's working thought the small ones that is actually time intensive. All the best: Rich Farmbrough, 15:56, 11 February 2016 (UTC).

The underlying problem here is that MediaWiki:Post-expand-template-inclusion-category is the name of the category, rather than free form Wiki-text. Nonetheless I think it can be probably be solved. All the best: Rich Farmbrough, 01:08, 14 February 2016 (UTC).

Not sure where, but I think I have seen namespace detectors on such type of MediaWiki pages, which only adds category name. So yes, it should be technically possible. --Edgars2007 (talk/contribs) 03:38, 14 February 2016 (UTC)
It might need a software change since MediaWiki:Post-expand-template-inclusion-category only includes the category name not the [[Category: part and the closing ]].
However it it may be possible ad the sortuing code, since they occur before the ]]. Depends on how it's code, which I couldn't find. out.
Should test it on testwiki really.
All the best: Rich Farmbrough, 19:14, 16 February 2016 (UTC).
just to clarify, tracking categories are allowed to have wikitext in them. The broken file category for example does this. Best support is when it only depends namespace (if it depends on page name it will work on pages but wont show up on special:trackingcategories. Additionally keep in mind that changes to that page are kind of slow to propagate - the category gets updated only next time the page in question is null edited. Bawolff (talk) 15:33, 20 February 2016 (UTC)

I wasn't aware of this discussion earlier, but I suggested the same when being pinged about pages that exceeds the limit. For the pages in question, I couldn't care less that these pages do exceed that limit, and no-one does - if the information needs to be read there are ways of solving it. Otherwise, there is no reason to get these pages out of these category than that they obscure the other pages in there.

This problem is only a problem in content namespaces, and a nuisance on talkpages (and archives). The rest of the pages are not necessarily supposed to easy to read and therefore there is no need to get them out of this category. A split by namespace makes it easier to administrate that. --Dirk Beetstra T C 03:23, 18 February 2016 (UTC)

Bot to address WP:LISTGAP on about 100000 articles

Latest comment: 8 years ago2 comments1 person in discussion
The event has started. (refresh)

A request for bot approval to address listgap accessibility has completed trials and is getting ready to go live. Due to the large scope of this, additional community comment is being solicited. Please place any questions or comments on the request page. Thank you from the bot approvals group, — xaosflux Talk 20:34, 18 February 2016 (UTC)

Barring any objections or additional follow up - this will be going live on 26 FEB. — xaosflux Talk 16:26, 21 February 2016 (UTC)

Undo summary

Latest comment: 8 years ago7 comments5 people in discussion

I suggest that the edit summary for undoing edits be changed from

Undid revision $1 by $2 (talk)

to

Undid revision $1 by $2 (contribs)

As wikimarkup:

From

Undid revision $1 by [[Special:Contributions/$2|$2]] ([[User talk:$2|talk]])

to

Undid revision [[Special:Diff/$1|$1]] by [[User talk:$2|$2]] ([[Special:Contributions/$2|contribs]])

Iceblock (talk) 19:46, 16 February 2016 (UTC)

  • I seem to be saying this a lot here lately, but I'll say it again: when proposing something, it is helpful to explain why this would be an improvement. Beeblebrox (talk) 20:43, 16 February 2016 (UTC)
  • Oppose Adding the diff link would further reduce the available space for explaining the undo for too little gain (see MediaWiki talk:Undo-summary for discussions of this), and modifying the contribs/talk order would create confusion since old undo links would still use the previous edit summary. Cenarium (talk) 21:20, 16 February 2016 (UTC)
  • Oppose – When anonymous users sign comments on talk pages, their IP address links to their contributions. I'm assuming that the automatic undo summary reflects that. I can also see a benefit in having the word "talk" spelled out—it encourages discussion, as the undo function is often used in edit wars. Finally, as Beeblebrox mentioned, the proposer hasn't yet advanced an argument for why this change is an improvement. Mz7 (talk) 02:53, 17 February 2016 (UTC)
  • Support link to diff, oppose change in user links. The current links link to the same places, it's just a question of which link comes with the user name and which link is in the parentheses; having an explicit "Talk" link tends to encourage users to discuss issues. On the other hand, if the diff link, as proposed, actually works, it's a good idea - as it lets users see the original edit in question, including summary. Cenarium and Mz7, whose comments apply only to the user links, may want too express an opinion on the diff link. עוד מישהו Od Mishehu 06:03, 17 February 2016 (UTC)
The wide majority of undos are full reverts, so you can easily see what was reverted just by viewing the diff of the undo itself. I also agree with Cenarium that adding the diff link would needlessly cut down on the amount of space available to write a more explanative edit summary. Mz7 (talk) 16:43, 17 February 2016 (UTC)
  • Pros and cons When a diff link is given, it could be easier to check whether the edit is an exact undo, or contains sneaky vandalism changes. The undoing editor can in some cases delete the contribution and talk links to make more room for a summary, because those links are also at the top of the diff page. However, with a 9-digit oldid number, the diff links increase the edit summary by 27 characters (if the talk and contribution links are not swapped). With a 10-digit oldid number, the increase is 28 characters, and so on. Independent of diff links, the talk and contribution links occupy more characters when swapped, so it is probably best to keep the link order as "Undid revision 1 by Librarian (talk)" rather than change it to"Undid revision 1 by Librarian (contribs)". For a 9-character user name, the contribution and talk links occupy 76 characters. So if the undoing editor deletes the contribution and talk links, and the diff link is present and kept, there will be 48 characters of extra space, and the contribution and talk pages are linked from the diff page, as mentioned. Iceblock (talk) 17:14, 21 February 2016 (UTC)

Make all the "section templates" the same size

Latest comment: 8 years ago7 comments6 people in discussion

Hi, I hope this is the right place to put this proposal. I want to somehow create a guideline for how a template for a section, such as {{cleanup section}} and {{refimprove section}} are laid out. Currently, some of them are long banners and other are small, box-like templates. I could not find every single section template as it'd take too long, but I managed to find the following:

Now obviously those aren't all of them, because as I mentioned before it'd take too long to find them all. What I'm proposing is to have a set guideline for them all to be banner-styled, as that's, from what I've seen, the more common approach to these templates. I tried editing and changing the Cleanup section template and it got reverted, so I came here. Anarchyte (work | talk) 10:17, 13 February 2016 (UTC)

@Anarchyte:You will probably find all of them on this list. עוד מישהו Od Mishehu 22:13, 15 February 2016 (UTC)
Support
Oppose

Subject troublesome IPs to peer review instead of blocking

Latest comment: 8 years ago26 comments9 people in discussion
Technically unsound fredgandt 03:09, 15 February 2016 (UTC)

The following discussion 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.

Moved from Idea Lab.

I imagine this has been discussed before, but in that case it can't hurt to try again. This proposal would almost certainly require changes to the MediaWiki software. Much of the code required already exists in the software, but would need to be tied together in new ways.

Outline
I propose:

Instead of blocking IPs with a history of vandalism and other disruptive behavior, we restrict them to peer reviewed editing via Pending changes (with tweaks), or similar new software.

  1. Any unhelpful work would be no hassle to ignore.
  2. Poor quality attempts to be helpful could be a good place to start the healing process (i.e. education and encouragement).
  3. Good quality edits can be approved and published.
  1. If the IP continues being unhelpful, they stay in limbo.
  2. If they make an effort, we can help them improve.
  3. If they prove worthy, they're released from limbo.

Clearly the prolific vandals are keen to edit ;-)

  • A particular benefit of this procedure would be, in the case of dynamic IPs previously used by vandals being adopted by decent folk who are immediately blocked and have a terrible instant history for no personal fault.
  • Another benefit would be a shared workload, with less administration required.
    • Considering that 10 edits is currently considered enough to earn auto-confirmation, 10 acceptable edits from an IP in limbo could automatically release them.
  • Another would be simply having fewer ugly warnings and block notices around the place, which just don't shout "Welcome!".
Reasoning
Wikipedia is all about allowing-ney-encouraging anyone to edit; it was built that way and needs to continue that way. But an unfortunate few users just don't play nice, and unlike in the case of registered users behaving badly, blocking IPs is often too little, too late, and effectively targeting the wrong people at the other end of the line. I myself have experienced being effectively accused of vandalism early on when I didn't understand about Dynamic IP addresses. I hadn't done anything wrong, but the last person to have my IP had.
I'd like to see a lot less of "we don't want your sort 'round 'ere" and a lot more of "although we appreciate your effort, Brian May was not 'the first man on the moon' as far as we know. If however you can provide a reliable reference, please resubmit you edit".
Experts agree that education works better than punishment.[citation needed]
Process
TBA (I intend to add a breakdown (possibly graphical (flowchart)) of the process in pseudo technical non jargon).
Analogy
Most people have a lockable door as the entrance to their home to keep unwelcome people out whilst allowing welcome people in. Few would argue that there are bad people out there, but nobody in their right mind would brick up the doorway as a just in case measure against them - they'd use a lockable door. Just as we use doors to restrict entry to our homes, this would allow us to filter access by use case where leaving the door wide open is allowing an uncommon number of unwelcome folk through.

For the community's consideration. fredgandt 09:54, 13 February 2016 (UTC)

My apologies for reordering the proposal after several posts. I saw too late that opposition may be divided, and hope simply to make the best sense of feedback possible. I'd like to have fleshed this out in the Idea Lab, but unfortunately little to nothing seems to happen there (or perhaps I'm just impatient). fredgandt 12:23, 14 February 2016 (UTC)

Questions

Help improve the proposal.

  • So you're proposing instead of blocking an IP, every edit they make gets scrutinized similar to a pending change protected page? This, to me, seems like a good idea, but it'd be hard to regulate. Would their edits enter a queue for reviewing or would it come up in each articles history as a "Pending review" entry? If it would enter a queue, I could see that getting backlogged pretty quickly. Anarchyte (work | talk) 10:13, 13 February 2016 (UTC)
I can't see any reason why the frequency of edits would increase after an IP is restricted, and at present, the community handles their negative input adequately (albeit after the fact). Any acceptable suggestions should be a simple click to approve. Simply ignoring negative suggestions deals with those, and users should be encouraged to encourage good faith. An issue that would need to be addressed is ensuring that ALL truly good faith contributions are accepted as if they came from ANY other editor. There could be no bias or special treatment. If a restricted IP suggests ANYTHING that isn't blatant vandalism, it MUST be approved and only then fixed or amended. The entire point should be to allow free editing where that editing is not vandalism. I'd even go so far as to establish policy dictating that approvable suggestions must be approved even if the approving editor intends to undo the edit. This measure should only act to allow us to filter vandalism from IPs known to be frequently responsible in the past. The of course, once the IP has cleaned their slate, they go back to normal, unrestricted editing mode.
As for the specifics of implementation, I'd opt for simple; alert watchers to the submissions and add them to a Special: page like that for New Pages. Users could patrol the submissions at any time.
The only major difficulty I can see is how to handle the order of operations if an article is edited after a suggestion that's later accepted. A possible solution would be for users to have an option to manually merge the accepted suggestion into the revised article, then accredit the IP responsible so it shows in the history and the IP's contribs as their edit. fredgandt 12:25, 13 February 2016 (UTC)

Comments

Help improve the proposal.

Yes it does :-) I'll read that more carefully after sleeping. If it is as it looks, I guess that makes this somewhat moot. fredgandt 12:29, 13 February 2016 (UTC)
Except that I believe this tool should not be in the hands of non admin (unless a new and special power is created) and the application of it should not be in any way automated (the removal can be). fredgandt 01:03, 14 February 2016 (UTC)
I meant the technical implementation, not the policy for its use. Cenarium (talk) 17:07, 14 February 2016 (UTC)
  • I'm not sure the software can do what you think it can or even if we would want it to do this. I think it could lead to other issues, like how does an IP contest the removal or wrongful decline if there is no history for someone to look up? Who would be in charge of reviewing these "limbo" edits, administrators, reviewers, autoconfirmed? Does this create a new noticeboard we have to create? But if the IP user is in limbo they would not be able to post on a noticeboard without another person approving their edit, which leaves email and that could take days for a response. Unfortunately I am seeing a lot of issues with this proposal.McMatter (talk)/(contrib) 05:51, 14 February 2016 (UTC)
Although you say "unfortunately", I say "fortunately" you're seeing a lot of issues. And no, this isn't necessarily a good day to buy that lotto ticket ;-)
Good points; thank you for bringing them up. I'll get back to you. fredgandt 06:08, 14 February 2016 (UTC)
  • Your quote that you want more of "although we appreciate your effort, Brian May was not 'the first man on the moon' as far as we know. If however you can provide a reliable reference, please resubmit you edit" is completely preposterous. BethNaught (talk) 15:08, 14 February 2016 (UTC)
Education and guidance is preposterous? Very sad. fredgandt 03:08, 15 February 2016 (UTC)

Support

Reasoning welcome.

  • n.b.: this post was originally a response to Cedric tsan cantonais: Respectfully; I've been a Wikipedia editor right around a decade. I have an account. I choose not to use it, primarily because identity, to me, runs fundamentally contrary to the purpose of article creation and improvement. I'll admit this is an ideological gripe rather than a practical one, but it's a pet ideology of mine! It shouldn't matter whether an edit comes from a (metaphorical) pauper or prince; Each edit should be judged by its content alone. I think in many cases identity works against good-faith editing; egos develop, bad blood foments, etc. The day wikipedia abolishes IP editing is they day I retire entirely from article space editing. Would I be a huge loss to the project? No, not really. And I'm not sure how many there are like me. Maybe getting rid of IP editing would be a net positive to the project's goal of encyclopedia creation/maintenance. But it would be a serious blow, I feel, to the open culture that Wikipedia has fostered since its founding. As for the proposal, I'm not entirely sure how I feel about it, but I lean towards a moderate support. It's a restriction on the same freedom I was just defending, but is in some ways actually a loosening of IP editing policy. My one concern would be that such a proposal would suffer from the Taser effect; its relatively mild restrictions would be seen as acceptable on a much broader swathe of IP editors, and thus applied with little provocation or consideration. 97.93.100.146 (talk) 23:43, 13 February 2016 (UTC)
In response to whomever was using IP 97.93.100.146 at the time of its last comment: regarding the last two sentances of your comment: One of the pilars is to "assume good faith", which IMO should be how we approach ALL activity on Wikipedia, including the use of tools. Since this would be a tool in the hands of admin, just as blocking currently is, we MUST assume that it will not be abused. fredgandt 00:35, 14 February 2016 (UTC)
  • String support - one major problem with blocking IP addresses is that there is always a decent chance that the problematic user will move to a different address and an okay user will take over the blocked one. This would both prevent the okay user from being completely disallowed from editing, and be an indication to admins when the IP no longer belongs to the problematic user. עוד מישהו Od Mishehu 13:46, 14 February 2016 (UTC)

Oppose

Please explain why.

The principle

Technically

Generally

  • With respect, sir, I would like to insist that phasing out unregistered edits and having all contributors create their own accounts would be a more fundamental solution. Here is my reasoning:
  1. Phasing out unregistered edits means that stubborn vandals would no longer be able to vandalise Wikipedia through dynamic IP addresses;
  2. That being said, subjecting certain users to peer reviews is a good idea of helping new comers get onto the right tracks;
  3. Wikipedia is an encyclopaedia that anyone can edit, but not "anyone can throw whatever trash they want into". Requiring everyone to create their own account does not stop anyone from editing through their accounts. While bad IPs should be blocked at all costs, good IP should be warmly invited and encouraged to create their own accounts. Besides, If a person intends to contribute contents of good quality to Wikipedia in a long-term basis, why should they be afraid of identifying themselves through their user names and signatures? Cédric wants to abolish "Convention №. 2" like abolishing slavery. 21:14, 13 February 2016 (UTC)
Whilst I agree with you (mostly) and feel much the same way, phasing out IP edits altogether is another conversation, had repeatedly over the years, to little avail. So, moving swiftly on...
You appear to be suffering under the illusion that IPs are people; A bad IP might only be bad whilst used by a bad person, then excellent in the hands of another. This consideration lies at the heart of my proposal. All the while there's no way to discern the usership of an IP, we need to treat them as doors through which any kind of edit may pass, from any kind of person. Blocking as such is (practically) NEVER fair.
You are opposing a step toward the very thing you argue we should do instead; opposing this because it is not that. You want to restrict IP edits completely but accept that IP edits can be desirable; this proposal is for a filter that gives us our cake and lets us eat it. Please reconsider you opposition. fredgandt 21:54, 13 February 2016 (UTC)
Respectfully; I've been a Wikipedia editor right around a decade. I have an account. I choose not to use it, primarily because identity, to me, runs fundamentally contrary to the purpose of article creation and improvement. I'll admit this is an ideological gripe rather than a practical one, but it's a pet ideology of mine! It shouldn't matter whether an edit comes from a (metaphorical) pauper or prince; Each edit should be judged by its content alone. I think in many cases identity works against good-faith editing; egos develop, bad blood foments, etc. The day wikipedia abolishes IP editing is they day I retire entirely from article space editing. Would I be a huge loss to the project? No, not really. And I'm not sure how many there are like me. Maybe getting rid of IP editing would be a net positive to the project's goal of encyclopedia creation/maintenance. But it would be a serious blow, I feel, to the open culture that Wikipedia has fostered since its founding. As for the proposal, I'm not entirely sure how I feel about it, but I lean towards a moderate support. It's a restriction on the same freedom I was just defending, but is in some ways actually a loosening of IP editing policy. My one concern would be that such a proposal would suffer from the Taser effect; its relatively mild restrictions would be seen as acceptable on a much broader swathe of IP editors, and thus applied with little provocation or consideration. 97.93.100.146 (talk) 23:43, 13 February 2016 (UTC)
I have to disagree. Ever since in high school when my teachers teach me how to verify sources and how to determine which source is reliable and which one is not, the origin of the source matter more than nearly anything else. Therefore, the way I see it, identity plays a vital role of helping other contributors determine whether an edit is reliable or not, in good faith or in bad faith, etc.. Also, using "choose not to do so (as if it was purely personal)" arguments here sounds too self-centric to me. For you, this might be nothing more than "a choice", but for Wikipedia's credibility, this is not. I stand by my point: "If you want credibility, identify yourself." Cédric wants to abolish "Convention №. 2" like abolishing slavery. 05:09, 22 February 2016 (UTC)
  • Oppose this sounds like more work then it's worth. Even pending edits show up in the history and require a reviewer to look over them so we are really doing very little to stop a disruption to the encyclopedia by doing this and creating more work for the reviewers. As I said earlier pending changes still show up in the history so reverting the edit is just like reverting any other edit so the only declining the blatant vandalism is not needed.McMatter (talk)/(contrib) 05:08, 14 February 2016 (UTC)
I must admit I did not know that the pending changes system sucked so badly (having never used it in any capacity that I can remember (maybe once)). My proposal is for pending edits to not touch the history unless approved.
As a watcher of any given page, surely you review edits as they're published? Why would this be any different? The only difference would be that edits made by restricted IPs wouldn't disrupt the page in any way. Only the positive contributions would pass, which is clearly beneficial for the encyclopaedia.
If your main opposition is to how the software was (slightly erroneously) proposed to be used, would you be more supportive if new and better software was developed to more specifically handle these circumstances - i.e. we not use the pending changes system? fredgandt 05:37, 14 February 2016 (UTC)
It still doesn't affect my thoughts on this. Moved The rest up to Questions McMatter (talk)/(contrib)
  • Strongly oppose: this is a terrible idea for several reasons:
    1. Instead of blocking IPs suggests that traditional blocking would be disallowed or disabled. So imagine the following scenario under the new scheme: an IP user posts libellous content such as "Mr Misoffelees has raped 1050 women"; the edits are reverted and oversighted as they would be currently; the IP is restricted; the IP continues to post the same sentence; the attempted edits are shown in some kind of queue; although the edits don't go live, at least registered users, or perhaps the public depending on the implementation, can still see this libel; without a full block, it becomes a theoretically perpetual whack-a-mole situation.
    2. Any unhelpful work would be no hassle to ignore: this is false because the edit would still have to be reviewed to know it was unhelpful.
    3. a shared workload, with less administration required: it would in truth be a massively increased workload. You would still need the equivalent of WP:AIV to determine which users should be restricted, so it doesn't lighten the burden on admins - and depending on the implementation, you may have the bureaucracy of un-restricting IPs, whereas currently IP blocks are almost always made finite, i.e. automatically expire. Moreover the backlog of unpatrolled IP edits would rapidly balloon and the small number of good edits would be drowned in a sea of depraved inanity.
    4. an unfortunate few users just don't play nice: it's not an unfortunate few. Put AIV on your watchlist and see how high the throughput is, especially at peak times. If it were an unfortunate few, then ClueBot and Huggle and STiki would not have been necessary. I see the proposer of this has not used Huggle or similar. A few stints at that would soon fix your bleeding heart.
    5. This would appear to require massive development efforts. Either go and code it yourself or show that the WMF would agree to write it for us. Of course, if the WMF did it, the implementation would probably be rather shoddy.
BethNaught (talk) 15:04, 14 February 2016 (UTC)
I would love to thank you for giving constructive feedback in the appropriate section, but that's not going to happen.
  1. Assumption of a condition and argument against implementation in that instance, as if all possibilities are covered by that assumed possibility. See Straw man.
  2. You consider it a hassle to review edits? I sure as eggs is eggs don't.
  3. As quite clearly stated, the restrictions could be automatically removed after proof of improved work from that IP.
  4. You assume I don't pay attention or have any experience with vandals, and begin with the personal attacks.
  5. Display of outright negativity and aggression.
This response is terse as I don't believe you deserve more attention. You should fix your attitude. fredgandt 03:07, 15 February 2016 (UTC)
  • Oppose per User:BethNaught above. While some aspects of the proposal are intriguing, I would suggest the proposer withdraw it for now, take some time to use Huggle, or Twinkle, etc. to battle vandals, and then perhaps re-assess and re-submit a proposal along these line. GenQuest "Talk to Me" 18:32, 14 February 2016 (UTC)
I recommend being less inclined to associate yourself with others, however, I tend to agree that this proposal should be closed. I was hoping to take constructive feedback and develop the idea, but frankly, life's too short. fredgandt 03:07, 15 February 2016 (UTC)
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.

More Publicity/Organization for Minor Projects

Latest comment: 8 years ago4 comments2 people in discussion

As a rather mediocre editor who doesn't have many connections, trying to find a few editors to collaborate on a small project is very hard. I just wanted to find a way to put out there that I wanted some help working on Hypericum articles, as it is very time consuming to create articles for its species. A WikiProject or Task Force would be too large scale, so I looked at other alternatives. The only one I found was the "Talk Page Coordination." This is really quite useless, though I did it here, as no one is actually going to look at the talk page of an obscure article and read stuff there.

Proposition

To create a recognized Mini Task Force that can be given some publicity and be a normal thing. This would have a project page but have much less maintenance requirements, etc. compared to a WikiProject or Task Force. It could be placed in the You Can Help Page so it can find publicity.

Why it Would Help

This would encourage editors to collaborate in an informal way, but not so informal that true collaboration is extremely difficult. Minor subjects, especially genera and species, could be given articles more efficiently and with more focus. Also, a new editor won't want to search everywhere just to find help on a subject; this would help that.

Fritzmann2002 13:40, 18 February 2016 (UTC)

Is there a reason why this cannot be handled within WikiProject Plants? Roger (Dodger67) (talk) 08:42, 19 February 2016 (UTC)
There is no reason why WikiProject Plants could not handle it; however, I placed a request for collaboration there 4 days ago and have still not received a reply. The plants project is probably one of the more active projects, and since what I want to do is not very important, it receives no traction there. If there was a place where this scale projects was the norm, they would gain more recognition and actually get replied to. Fritzmann2002 13:55, 22 February 2016 (UTC)
If no one will answer me here, is there anywhere else I can go besides the Teahouse, talk page, and WikiProject Plants? Fritzmann2002 19:03, 24 February 2016 (UTC)

Implement TipWiki into platform

Latest comment: 8 years ago6 comments3 people in discussion

TipWiki is a Chrome extension which replaces the default tooltip from a linked article with content from said article, making the user experience much more enjoyable. This small feature would allow readers to stay on the current page while being able to acquire a minimum amount of context from linked articles (which often times is enough to keep reading).

The code for the extension is public and can be modified. It uses a default browser feature so there are no additional elements being added. It simply rewrites the "title" attribute on the link tag. It also does this asynchronously so the user does not notice it taking place.

I propose the code behind this extension be implemented into the Wikipedia platform. Tooltips are generally not useful unless they are added to elements such as buttons on sites, where it isn't clear what the button will do. This feature would take advantage of this to increase the user experience.

Link to code (link to Chrome download is there as well)

Nikodraca (talk) 23:29, 24 February 2016 (UTC)

This sounds rather like mw:Hovercards (available as a beta feature) or Navigation popups (available as a gadget). --Yair rand (talk) 21:05, 24 February 2016 (UTC)
It definitely is similar. Why I believe this is better solution however (I do think the others are great mind you), is that it does not involve the bloat of JavaScript popups, and the description is minimal. It is much more subtle than any other solution I have seen, some users might not like have a large pop up while browsing. The entire script is 22 lines of JavaScript code, it would be virtually unnoticed.Nikodraca (talk) 22:47, 24 February 2016 (UTC)
Can it run independent of the Chrome extension? This seems like a clever solution. 137.122.64.32 (talk) 23:29, 24 February 2016 (UTC)
Yes it can! Just need to take the contents of the extension and put then in a script on the page. It will automatically retrieve the information and make changes. If JavaScript is disabled for some reason it would just show the original title attribute so there's no risk. Nikodraca (talk) 23:10, 24 February 2016 (UTC)
Just downloaded extension to test. Works fast and is accurate (for the most part) 137.122.64.32 (talk) 23:28, 24 February 2016 (UTC)

RfC: Disable Gather on enwiki

Latest comment: 8 years ago68 comments53 people in discussion
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 (talk • contribs) 12:53, 22 February 2016 (UTC)
Tracked in Phabricator
Task T127509

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

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[12].

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)

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)
  • 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)
  • 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)
  • 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)
  • Disable. There are plenty of smaller wikis to test this type of faff with. Stifle (talk) 16:58, 26 January 2016 (UTC)
  • 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)
  • 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)
  • 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)
  • 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)
    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)
    (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)
    (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)
  • 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)
  • 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)
    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)
    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)
  • 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)
  • 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)
  • 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)
  • Support disabling until BLP/NFCC issues have been properly dealt with. --SarekOfVulcan (talk) 21:05, 26 January 2016 (UTC)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
    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)
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)
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)
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)
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)
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)
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)
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)
  • 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)
  • 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)
  • Disable for now. There are some potentially interesting possibilities, as mentioned at § Disabling Gather? ([13] 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)
  • 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)
  • Disable Against community fair-use practices, poor maintainability. — xaosflux Talk 01:52, 29 January 2016 (UTC)
  • 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)
  • 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)
  • 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)
  • Disable per copyright concerns and lack of community consensus to implement. sst✈ (speak now) 07:11, 1 February 2016 (UTC)
  • 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)
  • 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)
  • 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)
  • Disable for all the reasons listed above. The BLP issue is particularly troubling. SarahSV (talk) 19:53, 4 February 2016 (UTC)
  • 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).
  • 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)
  • 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)
  • 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)
  • 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)
  • Support disabling per many of those above. The Quixotic Potato (talk) 10:00, 9 February 2016 (UTC)
  • 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)
  • 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)
  • 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)
  • 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)
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)

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)

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)

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)
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)
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)

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)
Thanx :) I'm happy to see the WMF placing more attention on Community engagement. Alsee (talk) 17:27, 24 February 2016 (UTC)

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

WikiLove on Russian Wikipedia

Latest comment: 8 years ago1 comment1 person in discussion

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

Searching for templates

Latest comment: 8 years ago6 comments4 people in discussion

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)

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)
I scanned the discussions and didn't get to this solution. Thanks so much!
—D'Ranged 1 | VTalk :  17:06, 26 February 2016 (UTC)
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)
@D'Ranged 1: I use AutoHotKey so that it takes me only three keystrokes to type "Template:". See http://pigsonthewing.org.uk/using-autohotkey-macros-make-typing-life-easier/ for details. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:06, 3 March 2016 (UTC)
Pigsonthewing, thanks for that, but I'm having issues with AHK not being persistent. Every time I want to use it, I have to reload the script file. It's a pain, so I've all but abandoned it, which is frustrating. It was a great tool when it worked and I can't seem to solve the problem at all.
—D'Ranged 1 | VTalk :  06:43, 4 March 2016 (UTC)

Personal "to-do" list

Latest comment: 8 years ago6 comments3 people in discussion

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)

People currently use template {{To do}}, which allows you to do this manually. The Quixotic Potato (talk) 10:06, 18 February 2016 (UTC)
@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)
@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)
@Evad37: Just got back from a bit of a Wikibreak (real life, and all that), and I just installed this. At first glance this looks like exactly what I was hoping for. I will play with it some over the next few days. Thanks. Rwessel (talk) 07:12, 4 March 2016 (UTC)
@Rwessel: I hope you like it! If you have any feature requests, suggestions, or other feedback, you can let me know on my talk page. - Evad37 [talk] 01:16, 5 March 2016 (UTC)

Suggested Changes to Wikipedia

Latest comment: 8 years ago2 comments2 people in discussion

Everyone must get at least one warning before their first block. If a block is for an action specific to one type of article, then the block should not apply to other types of articles. Wikipedia needs to make its suggestion page easier to find. ----— Preceding unsigned comment added by 2601:2C1:C003:EF7A:4C87:C488:5851:C0EA (talk • contribs) 03:10, 4 March 2016

1) Pretty much everyone does get a warning before their first block, unless they're obviously a sockpuppet of a blocked user, or maybe if they're doing something they should know is outright illegal, or it's obvious that they created the account only to troll.
2) Too cumbersome to program and apply. We do have topic bans, which are similar, but require either community consensus or discretionary sanctions and kind of operate on the honor system (though they can be enforced by admins with blocks). Also, this would really belong as the technical village pump.
3) The village pump (which is the closest thing we have to a suggestion page) is linked in the Community Portal, found at the left hand side of the non-mobile version.
Ian.thomson (talk) 03:39, 4 March 2016 (UTC)
(1) Not a good idea, as many editors are not a human, but robots, that don't read warnings. I block several trouble-causing robots every day that are trying to promote something. For people that appear to be new here, we should warn them first and check that they have had time to see the warning before a block. But the purpose is to stop damage to Wikipedia, so the damage caused is balanced against the possibility of rehabilitation of the blockee. Graeme Bartlett (talk) 02:08, 5 March 2016 (UTC)

Create a separate "BLP citation needed" template.

Latest comment: 8 years ago18 comments11 people in discussion

We probably have millions of {{citation needed}} tags throughout the encyclopedia, but some citations are more urgent than others. When an otherwise well-cited BLP article has a possibly contentious statement added without a source, or when a non-BLP article has a possibly contentious statement about a living person added without a source, there should be a {{BLP citation needed}} tag to distinguish the urgency of adding a citation from that of an unsourced claim about a non-BLP topic. bd2412 T 12:26, 4 March 2016 (UTC)

New accounts - initial notification

Latest comment: 8 years ago7 comments5 people in discussion

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)

It was Special:Diff/705246320. --Krenair (talk • contribs) 01:12, 3 March 2016 (UTC)
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)
Erm, it was definitely in tech news: m:Tech/News/2015/47. I don't really have an opinion on where it should link, just that it should link *somewhere*. Legoktm (talk) 17:59, 3 March 2016 (UTC)
Sorry, yes, I see it now: Wikis can make the welcome notification link to a specific page.: Noyster (talk), 18:11, 3 March 2016 (UTC)

I am not sure how the links works ...but a redirect seem not to work....even if the page is redirected new editors seem to use the tlak page any ways somehow. -- Moxy (talk) 16:58, 3 March 2016 (UTC)

The target for that page is controlled at MediaWiki talk:Notification-welcome-link. — xaosflux Talk 18:17, 6 March 2016 (UTC)

Italics in names of spacecrafts vs. no italics in names of orbital launch vehicles (rockets)

Latest comment: 8 years ago6 comments5 people in discussion
See WP:MULTI discussion at WT:SPACEFLIGHT#Italics for spacecraft names? --Izno (talk) 13:10, 7 March 2016 (UTC)

The following discussion 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.

First thing: I do not know if this matter has already been discussed elsewhere. If it has been and is resolved, please give me proper link.

Second thing: If first not true, please tell me if this is not proper place for such queues. If so, I will move it to the proper page...

Third thing: If both first and second not true, I want to ask this question because some administrators on .sr insist on no-italics-writing for names of rockets (just example, I know these are two different languages).
Is there a reason to write spacecrafts names i.e. names and titles of articles because consistency must be fullfilled (such as Juno) in italics, and to write names of rockets i.e. names and titles of articles (such as Falcon 9 v1.1) with no italics?

I think italics is needed in both cases, or if not needed — is not prohibited, at least...

PS One Serbian handbook guide for ortography suggests writing names of cars in italics. Can someone tell me what he/she thinks: can this can be used to create a valid analogy for writing names of rockets, or spacecrafts, or aeroplanes, etc. — all in italics? Sorry for bad English or mistakes in English as I don’t have a professional knowledge of English, and some constructions might be unusual... --Obsuser (talk) 16:59, 6 March 2016 (UTC)

I think the best analogy is that names of ships are italicized: MOS:ITALICS#Named, specific vessels. I think the parallel here is that both are vessels occupied by humans, rockets aren't. – Finnusertop (talk ⋅ contribs) 17:24, 6 March 2016 (UTC)
I think the difference is that spacecraft names are the names of individual spacecraft. For example, Eagle was the first lunar excursion module to land on the Moon. Eagle is italicized but "lunar excursion module" is not. Launch vehicles usually only have a model name like "Saturn V". Individual launch vehicles usually are not given a name. Jc3s5h (talk) 18:04, 6 March 2016 (UTC)
So it hasn’t been discussed before, and this is a right place. Great!
@Finnusertop: Thank you. Is there any MOS rule to approve that?
@Jc3s5h: Thank you. What about Falcon 9 v1.1 compared to names of cars [if we do not take in account this argument of "(non-)occupied by humans"]?
What about "OLV Falcon 9 v1.1" analogy to the "HMS Victory" with italics in both examples [if we do not take in account this argument of "(non-)occupied by humans"; "OLV" stands for "orbital launch vehicle"]?
What about these italics here, in the beginning? Should they be removed or not? What about italics inside the text of Falcon 9 v1.1 for some rocket names (e.g. Falcon 9 full thrust)?
One more thing: If there’s no rule in MOS to stop me, can I put italics on .en Wikipedia or any other in both title and text of an article Falcon 9 v1.1 [for .sr I have the secondary source mentioned above that says "Write car names in italics.", and nobody has anything that says "Don’t use italics for names of OLVs."]?
This is very important for me; if you have time, please try to answer these questions related to MOS for writing titles and names of some articles in italics. Thank you. --Obsuser (talk) 20:25, 6 March 2016 (UTC)
It has been discussed before, since I was pulled up on the matter of italicisation four or five years ago, I forget which article, but suspect that it was one concerning the Gemini program. Certainly there is an ongoing discussion right now, at WT:SPACEFLIGHT#Italics for spacecraft names?, and per WP:MULTI this discussion should not have been started. --Redrose64 (talk) 12:21, 7 March 2016 (UTC)
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.

Listen template

Latest comment: 8 years ago1 comment1 person in discussion

In the "Listen" template, can we please have a clickable button for playing all files in the template, one after another? Thanks.Anythingyouwant (talk) 22:08, 7 March 2016 (UTC)

Creation of redirects for titles with en-dashes

Latest comment: 8 years ago2 comments2 people in discussion
Proposal has been approved. (non-admin closure) — Jkudlick • t • c • s 13:42, 8 March 2016 (UTC)

The following discussion 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.

It has been proposed that a bot create redirects for titles with en-dashes, from the corresponding title with hyphens. Please comment at Wikipedia:Bots/Requests for approval/AnomieBOT 74. Anomie⚔ 23:40, 3 March 2016 (UTC)

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.

Bring back Esperanza!

Latest comment: 8 years ago4 comments4 people in discussion

As jimbo(saw) would say... make wikipedia not suck!66.97.241.196 (talk) 02:25, 8 March 2016 (UTC)

I guess you mean Wikipedia:Esperanza. --Redrose64 (talk) 15:08, 8 March 2016 (UTC)
The WP:TEAHOUSE serves much the same purposes. EllenCT (talk) 13:59, 9 March 2016 (UTC)

Category name syntax

Latest comment: 8 years ago12 comments7 people in discussion

Hello, almost all of my edits aim to improve the category system.

It's very hard to find previous discussions on this topic, I searched the archive of "Wikipedia talk:Category names".

I propose to you to think about the possibility of a detailed, but extensive change in the name syntax of categories in the form of Category:Foo by Bar". Instead it should look like this: Category:Foo (by Bar).

It's easily confusing to me, that the whole category name is written in one straight, sustained line, without and clear separation between the different parts it consists of.

What the simple looking Category:Foo by Bar actually in our head means, is: Category:Register of "Foo" items, categorized by the parameter "Bar". Putting the sorting key in brackets, logically would make the name much easier to read as one can faster distinguish the object from the sorting key. This becomes evident with larger names like Category:Expatriates by country of residence in comparison with Category:Expatriates (by country of residence).
There are many categories, where the sorting key gets very long, because it consists of two or even three keys at once. Example: Category:Musicians by nationality, genre and instrument vs Category:Musicians (by nationality, genre and instrument). <

Appealing to the possible concern, that brackets do already have another function in category names, which is to clarify, I demonstrate the two possible cases, where the new brackets could collide.

Case 1: brackets before sorting key: Category:People from Georgia (country) (by occupation)

Case 2: brackets in the sorting key: Category:People (by city in Georgia (country))

I think the collision is not tragic in both cases, as the brackets still add to bring structure and clarity. Now tell me what you think. I know it's not likely for such an extensive change to be implemented, but consider to take it serious. I would've preferred squared brackets for the sorting key, that would look even better, but Wikipedia doesn't allow it.

A few hours before making this proposal I created a new category, which for demonstration I gave a name with the brackets. If you don't approve, it can be speedy renamed at any time: Category:Music (by genre and nationality). Regards, CN1 (talk) 01:12, 5 March 2016 (UTC)

  • Adding here my point out of my answer to עוד מישהו:
    "X by Y" is only easily understandable, when used in a whole sentence, as one would do normally. Like saying "List these people by occupation" or "I sorted the music by genre". But we are talking about category names, which until now are not designed after sentences, but rather as phrases, made as short and handy as possible. But these names still consists of the main object part and the sort key part and visibly setting them apart would make the cat names easier understandable.
  • After reading Wikipedia:Page_name#Technical_restrictions_and_limitations, I came to an alternative conclusion, which doesn't involve brackets, and even to myself looks better and seems more fitting for future challenges:

Category:Foo - by Bar

Category:People from Georgia (country) - by occupation

Category:People - by city in Georgia (country)

End of Proposal so far. CN1 (talk) 23:45, 7 March 2016 (UTC)

Not in favor of proposed change. Brackets are as a matter of fact incorrect, since it really is "Music by genre and nationality". Debresser (talk) 16:45, 5 March 2016 (UTC)
We use brackets in category names only where the content of the brackets would be unlikely to show up in normal prose. You wouldn't talk about Georgia Country, so the word "country" goes in brackets. Compare to New York City, which is actually referred to by this name on prose. Names like "Expatriates by country of residence" are more like New York City than like Georgia (country). עוד מישהו Od Mishehu 19:47, 5 March 2016 (UTC)
You bring up a good point there, although I don't completely agree with you. "X by Y" is only easily understandable, when used in a whole sentence, as one would do normally. Like saying "List these people by occupation" or "I sorted the music by genre". But we are talking about category names, which until now are not designed after sentences, but rather as phrases, made as short and handy as possible. But these names still consists of the main object part and the sort key part and visibly setting them apart would make the cat names easier understandable. CN1 (talk) 21:01, 6 March 2016 (UTC)
I think [[:Category:People [by city in Georgia (country)]]] is the best solution, and that proposal should not be rejected after five comments. Problem is hard / maybe impossible wikilinking, as you see here...   --Obsuser (talk) 21:26, 6 March 2016 (UTC)
Can be linked like this: {{External link|url=https://en.wikipedia.org/w/index.php?title=Category:People_%5bby_city_in_Georgia_(country)%5d|name=Category:People [by city in Georgia (country)]}}. However, error pops up: Special page | Bad title | The requested page title contains invalid characters: "[". | Return to Main Page. --Obsuser (talk) 21:36, 6 March 2016 (UTC)
I agree with this proposal as nothing above is significant enough to suggest otherwise. kk (talk) 11:23, 7 March 2016 (UTC)
  • From my experience, the number of users who care about categories are quite low compared to the number of people who care about articles and actual content. If you look at the category project talk pages, the discussions are quite slow, and as in fact absolutely no one regularly visits the talk pages of categories, I tell every new user who writes there, to go directly to project pages or portals. What I'm saying is, we might have to wait a bit longer for this one to unfold. CN1 (talk) 20:25, 7 March 2016 (UTC)
What problem is this proposal intended to solve? Chuntuk (talk) 12:02, 8 March 2016 (UTC)
  • Other than the proposer, there is no evidence presented that our current category names cause any confusion. I can easily understand all the examples posted, and the proposed alternatives are either not technically possible or are jarring to read. Fences&Windows 23:50, 10 March 2016 (UTC)

Any thoughts on templates like this??

Latest comment: 8 years ago7 comments4 people in discussion

Wikipedia has many templates saying "This user..." followed by something that talks about the user's preferred English variant. I would like to know if we can have any templates saying "This user thinks trans people should be referred to in a respectful way" or "This user think trans people should be referred to with their gender of rearing for some purposes"?? Georgia guy (talk) 18:48, 9 March 2016 (UTC)

@Georgia guy: Do you mean WP:USERBOXes? --Redrose64 (talk) 20:15, 9 March 2016 (UTC)
Yes, that's the kind of template I'm talking about. Georgia guy (talk) 20:20, 9 March 2016 (UTC)
You could ask at WT:UB, although WT:UBX seems more active. --Redrose64 (talk) 20:29, 9 March 2016 (UTC)
By the same token, can we have lots more userboxes saying "This user thinks foo people should be referred to in a respectful way" where foo is each of lesbian / gay / bisexual / trans / queer / female / black / mixed-race / Asian / Mexican / French / ginger-haired ... pick your oppressed minority ... yeah, it gets silly, doesn't it. No. If we're going this way, let's have one userbox saying "This user thinks all people should be referred to in a respectful way." Maybe there is one, I don't know, I'm not into userboxes. Stanning (talk) 11:25, 10 March 2016 (UTC)
I've found Wikipedia:Userboxes/Life#Gender, Wikipedia:Userboxes/Life/Sexuality and User:ISD/Userboxes/Sexuality; there is something of an overlap here. --Redrose64 (talk) 13:30, 10 March 2016 (UTC)

@Georgia guy:If you can't find the one you want there, you can always make one yourself. They go in your user space. Oiyarbepsy (talk) 00:44, 11 March 2016 (UTC)

New Village Pump page?

Latest comment: 8 years ago33 comments12 people in discussion

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)

There is definitely a perceived need for better WMF-Community engagement. Coupled with the lack of a proper forum, it seems to be channeled to Jimbo's talk page a lot. I hope there is a way to make engagement constructive; lately I've been disappointed by this. If there is a way to make the new Village Pump something that encourages constructive engagement instead of Foundation bashing, then I welcome it. One thing to consider though is that WMF works on a variety of areas (technical, legal, "vision" ... in short there is an inherent "miscellaneous" aspect to it). – Finnusertop (talk ⋅ contribs) 11:55, 3 March 2016 (UTC)
Wouldn't there be a risk of that becoming a page for endless rants? How do you see it being useful? Praemonitus (talk) —Preceding undated comment added 20:04, 3 March 2016 (UTC)
Praemonitus, I understand the concern about "rants". I've been one of the ranters myself. But I'm seeing real positive changes. Gather was agreeably uninstalled after our RFC requesting it. I just helped the WMF draft a request-for-feedback that is basically ready to go, where one of the opening lines is The WMF... does not want to push it on Wikis that do not want it. It also contains says they made a mistake not consulting us earlier. The project lead is very concerned to avoid any perception that they are "doubling down" to push something out. I'm trying to help the WMF figure out how to talk to us and engage us, the way we want. Alsee (talk) 08:03, 4 March 2016 (UTC)
I just realized I didn't really address How do you see it being useful? I see the WMF posting new project ideas there, so we can comment before they start building stuff. They can post requests for feedback on things, and most significantly ask us if we want feature-X built or enabled. The WMF ran some feature-enablement RFCs semi-recently regarding Visual Editor on the proposals page. That would probably shift to the WMF page. And yeah, things like the recent RFC to disable Gather would probably move to the WMF page. To be honest I'm not fully sure how it would evolve, but I think it's a needed page. I believe it will help us build better WMF-Community relations. Alsee (talk) 08:16, 4 March 2016 (UTC)
@Alsee: thank you for your contributions to the improvement of the communication between the Wikimedia Foundation and the communities. In the case of this proposal, I think the intention is correct, but the implementation might not be the best one. One example: what happens when a dozen more wikis decide to follow your steps, creating their own WMF Village Pumps? Can we stop them? Can we satisfy their expectations? Most probably not.
The WMF plan is to have a product development process open to the participation of all communities. Resolving the communication equation is definitely not simple, but the solution probably needs to start with a centralized location with possibilities for translation and equipped with subscriptions to very specific news (e.g. "New project ideas", "Requests for design review", "Feedback on deployment plans"...), and cross-wiki notifications. This way any individual could subscribe to the types of review corresponding to their interests and skills, and they would receive the updates in their own wikis. All the pieces needed for this process already exist. If you want to join the discussion about product development process and communication channels, please check phab:T124288.--Qgil-WMF (talk) 21:03, 8 March 2016 (UTC)
Qgil-WMF, thanks for your work on Community engagement and your comment here. I fully share your concerns about scalability to multiple wikis. I have longer term ideas where the Communities may help solve those problems for you. This needs to be tackled from both ends. Your plans for a WMF-Central location is a necessary step, but I believe it is also necessary to have a local page where we can build local processes to assist you. The WMF was nearly overwhelmed trying to handle the Media Viewer Community Consultation, the process and outcome were widely viewed as completely illegitimate and literally making the situation worse. Expecting even larger numbers of people showing up in countless languages, on a WMF ruled wiki, won't work. It's non-scalable and it completely misses the community's fundamental objection: limiting engagement to individuals in bulk, without acknowledging or respecting Communities and consensus.
Regarding the proposal here, this is a community proposal for a community page where the WMF would be welcome to post. We now have a mixed WMF-response. If the WMF does not find it desirable post here, that is absolutely fine. I still believe the community will find it useful for various purposes. I have some other community-projects in the works that I believe will be valuable, and Village_Pump_(WMF) is absolutely the place for it. Alsee (talk) 01:22, 9 March 2016 (UTC)
Alsee, indeed, local communities need to have own spaces to organize their participation as stakeholders in the product development process. How you organize yourselves, that is up to you. No matter what, we will continue reaching out for feedback and involvement.
I just want to stress that this proposal raises higher expectations. We cannot expect that a discussion in en.wiki (or any local project) will decide whether a new project idea moves into development or is parked. Wikimedia communities should have the power to promote or stop new software projects, but in a place and under a process that is common to all the communities. When it comes to local deployments sure, that is a discussion to be handled locally. However, note that even then we need a centralized process to communicate decisions to the teams in charge of the deployments.--Qgil-WMF (talk) 11:41, 9 March 2016 (UTC)

I have drafted the page, but not linked it into the main Village Pump structure. See Wikipedia:Village pump (WMF). Alsee (talk) 11:22, 4 March 2016 (UTC)

Wikidata has a similar page at d:WD:Contact the development team, which is a hybrid VPT/VPWMF, for the most part. It's very useful, but that may be because Wikidata as a technical project has refined project coordination. That said, most of the big proposals from the technical team which may need social buyin end up at the singular Village pump there, which we don't have here. --Izno (talk) 13:03, 4 March 2016 (UTC)
BethNaught: "What do any staffers think?" - I'm not making any claim about the WMF as a whole, or that there has been widespread WMF comment on it, but I have gotten a clear positive response. A project manager said "I am excited to see your new village pump area, too!" and a liaison used the thanks feature on one of my posts in this section. Assuming no sudden opposition shows up, I plan to make the page live as soon as the WMF greenlights their first official post there. Alsee (talk) 16:25, 7 March 2016 (UTC)
No. It should go to a WMF site. It's a distraction from English Wikipedia, here. Alanscottwalker (talk) 21:13, 8 March 2016 (UTC)
Putting efforts for engagement on another wiki, where fewer people will see it, is counterproductive. Moreover if the issue at hand is restricted to enwiki, discussing it here makes eminent sense. BethNaught (talk) 21:18, 8 March 2016 (UTC)
No it does not. We have four pumps already, English Wikipedia does not need yet another forum to argue over. Put a notice on the relevant pump, if you want to draw attention to a discussion on a sister WMF wiki, people will see it. Alanscottwalker (talk) 22:34, 8 March 2016 (UTC)
@Alanscottwalker: I count five: WP:VPI; WP:VPM; WP:VPP; WP:VPR; WP:VPT. But that still confuses people, and they don't know which to use, so we get policy matters posted at VPT etc. Some people post to the pump talk pages, not the actual pumps. --Redrose64 (talk) 09:53, 9 March 2016 (UTC)

Ping Risker: If/when the new page goes live, would you like to post your WMF Content Checklist there? The WMF was extremely enthusiastic about it. People could make sure it covers all the bases, and we can establish consensus backing. Alsee (talk) 01:31, 9 March 2016 (UTC)

  • Just registering my support for this idea. I think it would be an advantage to have a centralized place for enWP to communicate with the WMF, and this might also help with establishing expectations on process (either formally or de facto). If there are any problems with disruption, we can decide to shut it down again. It might lead to some duplicate discussions, as mentioned above, but all the wikis are independent and make their decisions separately in any case. Sunrise (talk) 05:52, 9 March 2016 (UTC)

I agree that improved communication is necessary, but I have questions about adding this channel, Alsee. How do you envision this new VP working? Do you think it would best operate as a beacon to notify enwiki community of happenings over on Meta or MW in order to direct people to those channels (if they actually check or watch it), or is the expectation that this is an added channel for all staff to communicate in, taking away time from centralized and movement-wide venues such as Meta? Would it be a place for communities to discuss and then decide to bubble issues up to the WMF, or is the expectation that a staffer will be watching it at all times or even some of the time? Or is there another way it could function?

Getting feedback from all of the projects is already time-consuming when it's scattered across multiple venues, and I have doubts about adding this venue for that reason. It's understandable that when testing or launching a project (technical or otherwise) to a particular project, that the specific communities should be able to communicate with the WMF team working on that initiative, but trying to collate different opinions from different locations on a constant basis already takes a significant amount of staff energy that may be best used elsewhere. I'd love to see a solution that supports less channels, rather than more. Do you think there's a way that creating this VP might eventually achieve that goal? -Rdicerb (WMF) (talk) 19:20, 9 March 2016 (UTC)

Ping Rdicerb (WMF), Qgil-WMF. I'll reply to both together, as you raise related concerns. I apologize if I created an impression of placing a burden on WMF staff. To the contrary, I am trying to build a less burdensome solution. Imagine this possible future: The WMF places ONE post on your central page. It could be brought to various community pages by the community, by a bot, or by some cross-wiki-transclusion(if available). The community could take responsibility for translating that one message. The community can fully apply our local processes to have our big messy discussions. The community then generates a summary result. The community translates that ONE summary back to English (if necessary), and it gets delivered to the WMF. That does scale, and it minimizes load on staff. If the WMF posts a new product idea to default all text to Comic Sans, the Community may return a Consensus Oppose. That would translate as "Go forward with the project if you like, but we are unlikely to support any deployment phase here". If you get conflicting responses from different communities, we'll work together on sorting that out reasonably. Alsee (talk) 21:26, 9 March 2016 (UTC)
Thank you so much for clarifying, Alsee. I appreciate your intention FWIW :) It sounds like a bit of a project that would require some buy-in from different stakeholders (from staff around workflows to communities agreeing to create summaries), but it isn't impossible. I'm glad there's a little more clarification around how this would work.-Rdicerb (WMF) (talk) 22:24, 9 March 2016 (UTC)
Rdicerb (WMF), generating discussion summaries is something we already do all the time. We call them Closes :) These would generally be more detailed than usual, and we would probably add a validation step before submitting them, but the importance would make it more rewarding than our usual work. It's all just a general concept. I was hoping we could take baby-steps trying to figure it out together, starting at EnWiki. (Shared language, with the largest and oldest community, makes this the natural place to start.) I helped the Reading team create a very-cautious request for feedback to post here. A toe-in-the-water test. The project manager seems enthusiastic to give it a try, I'm just waiting for the liaison to give the greenlight Alsee (talk) 00:53, 10 March 2016 (UTC)
Alsee, yes, your description above fits the idea I have in mind. Feedback and help to design and implement that process are very welcome. However, a WMF Village Pump in en.wiki is not a hard requirement for such process. I keep being concerned about the expectation that a forum with "Wikimedia Foundation" / "WMF" in its title will arise, and this concern is shared by other WMF colleagues I have checked with. If en.wiki thinks a new Village Pump is needed, we the WMF have nothing to say about that. Just don't call it WMF anything, please.--Qgil-WMF (talk) 10:59, 10 March 2016 (UTC)
Does anyone have any suggestions for an alternate name? Alsee (talk) 18:11, 10 March 2016 (UTC)
("Anyone" reading this, or anyone at WMF? I'll assume the former.)
I don't understand the concern about WMF in the name, as it wasn't explained. If you can't use WMF, it limits the ability to be accurate and descriptive, and the name becomes somewhat opaque. People seeing it for the first time will have no clue what it is, and may or may not take the time to find out. If that's acceptable, perhaps something like Community Liaison would be a little better than, say, Blue Page. If we're still talking about the title of a Village Pump page, and I'm confused about that, it would be Wikipedia:Village pump (community liaison).
One shortcut would need to be WP:VPC (all current pumps have a 3-character shortcut VPx), and that redirect would have to be stolen from Wikipedia:Valued pictures, which doesn't list it in its shortcuts box and is inactive in any case. An alternate shortcut could be WP:VPCL, as in WP:VPIL. ―Mandruss ☎ 03:30, 12 March 2016 (UTC)
Mandruss, yes I was asking "anyone". I believe the concern was that a "WMF" page might be interpreted as being officially connected to the WMF, rather than merely a community page on the topic of the WMF. Also concern that people might form an expectation that WMF staff were obligated to devote time there. In particular, what if every language made a WMF page and they all expected staff to devote time at each of them. Alsee (talk) 07:11, 12 March 2016 (UTC)
Upon further consideration, the description at WP:VP would make WMF in the page title less important, assuming (1) the page is shown there, and (2) the description actually mentions WMF. Not to mention the description at the top of the pump page itself. But would the same concerns exist for those descriptions? At what point would it be ok to show the letters WMF? ―Mandruss ☎ 07:41, 12 March 2016 (UTC)
I think the WMF may be over cautious on how editors might interpret the page, but I want do whatever I can to resolve any concerns. I can't imagine they would object to descriptive text that includes things like "this is a page for developing proposals that will be sent to the WMF" or similar. They don't want editors having unrealistic expectations of what the WMF is "supposed" to do there. Alsee (talk) 03:25, 13 March 2016 (UTC)
Yes, the main concern is the expectation that a certain VP is officially supported by the WMF. This is a factor to consider even when having a perfect title and description for that VP. For instance, Jimmy Wales or (until recently) Lila Tretikov would get routinely questions and requests related to the WMF in their Talk pages just because a critical mass of editors have the expectation to get a reply there. If a forum in en.wiki looks like a channel to file questions or requests to the WMF, I expect that type of expectation to become even more solid.
Also, it looks like the scope discussed here are software products and major features, but the scope of "WMF" and even "WMF community engagement" is wider. If you do create a new VP, the scope should be clearly defined.--Qgil-WMF (talk) 10:06, 14 March 2016 (UTC)
Qgil-WMF, part of the challenge is that the scope is fuzzy. For example some of us were talking about building a basic overview guide about us. (The idea is to offer it to you, in the hopes you'd find it useful.) The assumed audience would be a new WMF hire with no familiarity beyond reading article pages. It would give a superficial explanation of core community concepts and how we work. For example I suspect some staff might be surprised that we commonly refer to "Admin" as a janitorial position (a.k.a. "the mop"). It reinforces, in a lighthearted way, that the "Admin" role does not follow the conventional assumptions. It's not a power-position in a hierarchy. Alsee (talk) 06:23, 15 March 2016 (UTC)
"a basic overview guide about us" where us is en.wiki or the Wikimedia movement in general? Meta has this kind of documentation, en.wiki probably too, and the WMF internal office.wiki too. I agree new employees of the Foundation would benefit from a better onboarding, but yet another source of information is probably not what they need. Anyway, this conversation is getting too far from the original topic.--Qgil-WMF (talk) 12:52, 16 March 2016 (UTC)

Maybe call it Interwiki? I've been racking my brain on an alternate name, and that's the best I've come up with. It could handle anything with non-local aspects. Alsee (talk) 22:46, 18 March 2016 (UTC)

Latest comment: 8 years ago21 comments15 people in discussion

An article such as, for example, Kylie Minogue includes a number of common templates, each of which contain no parameters, as they draw their values from Wikidata: 

{{Commons category}}
{{Wikiquote}}
* {{Official website}}
* {{IMDb name}}

{{Authority control}}

It would seem sensible to try to combine templates like these into a single template, say: 

{{Biography footer}}

or, for specialist fields of endeavour, one of: 

{{Musician footer}}

or 

{{Cricketer footer}}

and so on. These could display (or not) the appropriate values and labels on a case-by-case basis. How might we move towards such a template? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:45, 3 March 2016 (UTC)

  • Support - simplify the article page. The way to do it would be to look at the common footers based on occupation, and create the templates based on them. עוד מישהו Od Mishehu 15:44, 3 March 2016 (UTC)
  • Comment, leaning oppose Most of those templates are problematical if added indiscriminately. {{Official website}} gives a big ugly red error if wikidata has no listing. {{Commons category}} and {{Wikiquote}} claim information is available and create links to potentially nonexistent pages. {{IMDb name}} generates a link to potentially nonsensical search results. It looks like the only one that can consistently be added {{Authority control}}. A unified template could be carefully used where all of the sub-templates happen to be valid, but any added convenience seems minor and I see a downside. It's more confusion and hassles when less familiar editors try to figure out what's going on, or potentially copy it inappropriately. If someone puts the unified template on an article but one of the items is invalid, it is a hassle and extremely non-obvious that they need to swap the unified template for the three correct subtemplates. Alsee (talk) 17:07, 3 March 2016 (UTC)
  • Oppose As has been pointed out, very little upside and a huge downside. We have way too many biographical articles and of a very diverse nature; the proposal would only benefit a very small group of articles. Chris Troutman (talk) 15:46, 4 March 2016 (UTC)
    • This isn't a vote, and in any case you appear to be opposing a proposal that I haven't made. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:32, 4 March 2016 (UTC)
      • Umm, this is Village pump (proposals), which I guess escaped you since you claim not to be making a proposal. In any case, be honest and just say you don't appreciate my opinion rather than talk at me while not pointing to "!vote" to those who agree with you. I don't think we should be moving "towards such a template". Chris Troutman (talk) 20:54, 5 March 2016 (UTC)
  • Oppose for now this particular implementation, but the underlying idea is viable per all of the above comments and replies. Right now, we need to add features to pages as they are required. The proposed template would not simplify anything because, as noted, the templates it would call are problematic when not needed or not used properly, so they can't be on by default, but having them off by default puts us in exactly the same position as having no template for this, since they won't be active on the pages that need them until someone manually enables them. The general idea of auto-generating sister-project links and such from Wikidata is a good one, because most users a) don't even know about these features, and b) would have a hard time figuring them out. The present state of things is just too half-baked to do this now. Maybe this could be done with custom code that doesn't throw errors, generate useless links, etc., instead of shelling out to extant templates that have these problems.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:49, 4 March 2016 (UTC)
    • I don't know which "particular implementation" you think you're opposing, but I haven't proposed one; I asked a question. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:32, 4 March 2016 (UTC)
      • I'm extremely skeptical the closer or anyone else would be confused by my statement, but just in case: I'm obviously referring to "try to combine templates like these into a single template", which you then gave a proposed name for, and then essentially contradicted yourself and proposed different topical templates of a similar combined, multi-function character, for biographies, or even for narrow things like music and cricket. Please see WP:BLUDGEON, and don't badger people with "I will force you to state the obvious, just because" nit-picks, especially when they're expressing support for developing the idea more concretely later.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  05:35, 21 March 2016 (UTC)
        • @SMcCandlish: Sounds like you're not going to disbelieve me, but you did make a confusing statement. Not everyone contributing here sees your opinions as clearly as you do, so please respond to requests for clarity more courteously and in a Wikipedian spirit. MartinPoulter (talk) 16:55, 22 March 2016 (UTC)
          • Fair enough. My tone was based on previous interactions with the same editor in which I feel I'm being needled with nit-picks. I'm sure he has complaints about me, too, and it will blow over. Our interaction is constructive more often than not over the last year or so. @Pigsonthewing:: If you really found my statement confusing, I apologize. Aw, hell, I'll apologize anyway, it's been a long day and I'm cranky. And it's far from over, ha ha.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:50, 22 March 2016 (UTC)
  • There seems to be an inflexibility here. Consider {{Commons category}} - that is supposed to go at the top of the last section. {{Authority control}} by contrast is towards the end of the last section - but before the categories and stubs. There are a number of items, not mentioned above, that should appear between these - such as the true external links (those not covered by templates like {{Official website}}), succession boxes, and navboxes. It seems that a change to WP:FOOTERS would be necessary before a standardised template like {{Biography footer}} is introduced, such change would permit the true external links, succession boxes and navboxes to go before the {{Commons category}}, or after the {{Authority control}}. I don't think that such change is likely. --Redrose64 (talk) 21:42, 4 March 2016 (UTC)
  • Great idea - and easily implementable; we already do something similar with infoboxes. I wonder if in future all articles will automatically have in-article links where other wikilinks exist - eg quotes, with wikidata, commons and so forth. @Pigsonthewing. I suggest move this discussion to village pump (ideas) if you don't want a heated support/oppose discussion. --Tom (LT) (talk) 08:53, 5 March 2016 (UTC)
  • Oppose for now. This is clearly the direction we are headed and a welcome development, but the way Wikidata and Wikipedia work together isn't just ready yet. This would be a huge development and overwhelming consensus is needed on templates that are transcluded on such a large number of articles. Standardization like this seems to work best with things that are actual standards, i.e. library classifications in Authority control. – Finnusertop (talk ⋅ contribs) 21:20, 5 March 2016 (UTC)
  • Maybe It's an interesting idea but I don't like the idea of variations such as {{Cricketer footer}} which will cause trouble when people have more than one possibility. And some people would like us to have the entire article generated by such an omnibus template, which would automatically "fill in the blanks" from Wikidata and other external repositories. We're not there yet. Andrew D. (talk) 08:37, 6 March 2016 (UTC)
  • Support. Agree with Pigsonthewing and Od Mishehu. Good way to increase uniformity and ease of standardization through help from our sister project friends at Wikidata. — Cirt (talk) 16:09, 9 March 2016 (UTC)
  • Oppose. Proposal or not this strikes me as over-design and would raise the hurdle for new editors to understand how the page is rendered by adding another layer of abstraction. In general, I think we should avoid "jars within jars" to the extent possible. KISS principle and all. Jason Quinn (talk) 17:37, 14 March 2016 (UTC)
  • Oppose Too inflexable, adn inappropriate on too many articles, as mentioned above. moreover, at this time, Wikidata entries have too few eyes on them and are too easily the targets of subtle vandalism to have any article content automatically depend on them. Indeed i oppose the sue of templates such as {{Official website}} at this time. DES (talk) 00:19, 19 March 2016 (UTC)

We should not accept pictures with pixelated people's faces

Latest comment: 8 years ago24 comments17 people in discussion
No consensus to enact the proposal.--Jayron32 18:39, 22 March 2016 (UTC)

The following discussion 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.

Across Wikipedia there are articles that display pictures that show people with pixelated faces in public places. I think we shouldn't accept such pictures for display in encyclopedic articles. It's anti-journalistic to pixelate people's faces in photos of public places. An encyclopedia shouldn't accept such pictures. I propose to find replacements for such pictures or remove them and make a policy to not accept any future such pictures. Mark Urzimo (talk) 17:30, 18 March 2016 (UTC)

Assuming these are user contributed pictures (eg taken themselves), of people in clearly public places, and they are being used to demonstrate the public place or general activity shown (an educational use rather than one that is purposely aimed to defame a person involved), then yes, pixelation should not be done. There's no legal issues as there is no expected right of privacy in a clearly public, outdoor location. If there is an object meant to be the focus of the picture and not the people, efforts can be made to trim down to just that object but pixelation is not an option required. --MASEM (t) 17:43, 18 March 2016 (UTC)
If one does not want a picture in an article than replace it with something better (or discuss it on the talk page) - it's as simple as that but no, it's CREEP to make a rule about it. Alanscottwalker (talk) 17:48, 18 March 2016 (UTC)
Pixelation is not generally required, but no argument is present to explain why it should be universally banned. If a photographer wishes to protect the privacy of private individuals beyond the minimum standards required by law, I'm having trouble seeing the harm. If any image in Wikipedia can be replaced by an image of higher quality and educational value, of course we should do so—but whether or not faces are blurred or pixelated should not be the sole (or even most important) criterion. TenOfAllTrades(talk) 17:54, 18 March 2016 (UTC)
However, this is an issue related to reuse , and similar in problem to watermarking a free image. When there are no issues with privacy rights (again, pictures of people in open public spaces), pixelating faces is only a matter of courtesy but is not required at all, just as watermarking is not required if you are donating images freely. We don't want massive post-photo editing to take place (outside of cropping and rotation), so that we do have the most reusable content possible. --MASEM (t) 17:58, 18 March 2016 (UTC)
Well, if people want to reuse an image with a pixilated face, they will reuse an image with a pixillated face. So, there is no problem there. Alanscottwalker (talk) 18:24, 18 March 2016 (UTC)
On a related note, it's been awhile but I vaguely recall a recognizable child image discussion or rule. Alanscottwalker (talk) 18:42, 18 March 2016 (UTC)

NOTE: This talk page edit indicates that Mark Urzimo seems to be referring to the article Rapid transit. I can find no images in there with deliberate pixelation. What I did find were some images with motion blur. Lower quality images should of course be replaced with higher quality images. Articles such as Rapid transit with too many images should certainly have lower quality unneeded images trimmed away. Just be careful not to remove images depicting something significant. A somewhat blurry image, or an image that is otherwise less than ideal, should still be included if it's showing something relevant for the article and there is no better image available. Alsee (talk) 20:08, 18 March 2016 (UTC) P.S. I just saw that Mark has just joined us as a new editor (no article edits yet). I left a welcome template and image-specific editing advice on user_talk. Welcome to Wikipedia Mark! :) Alsee (talk) 20:51, 18 March 2016 (UTC)

  • oppose It may not be required to pixilate or otherwise obscure the faces of people who are incidentally included in a picture of a public place, but if the photographer or uploader chooses to do so, I see no reason to object. If some other person wants to take a replacement photo and upload it under a free license, it could replafce the first if and only if it is judged to be of higher overall quality. I see no valid reason behind a policy or guideline barring such images, and i object to it. DES (talk) 00:00, 19 March 2016 (UTC)
  • Oppose. No need for such a requirement. That said, responding to User:DESiegel's point, I would say that if we had both versions of the same photo, with the only difference being pixellation, the non-pixellated one is ipso facto almost always going to be "higher overall quality". Still, the uploader is not required to provide the photo at all, so if the only one he/she is willing to provide is the pixellated one, then I don't see why we shouldn't be able to say we prefer that to nothing at all. --Trovatore (talk) 00:13, 19 March 2016 (UTC)
    • That might be, Trovatore, although some might argue that the courtesy of pixilation, while not required, is an improvement. But in practice an offered replacement will normally not be identical except for pixilation -- it will be different, perhaps of better quality, perhaps not as good except for the absence of pixilation. A rule that would force acceptance of a lower quality image just to avoid pixilation (as the above proposal seems to) is not on. DES (talk) 00:23, 19 March 2016 (UTC)
      • Well, I would tend to consider pixellation to be a fairly significant intrinsic flaw in a photo. Certainly it's possible that it would be so much better in other ways than a non-pixellated one that on balance it would be considered preferable, but for me it would have to be noticeably better in other ways. Certainly editors can differ on this point and I don't see any need to make an encyclopedia-wide judgment on it at this time. --Trovatore (talk) 05:29, 19 March 2016 (UTC)
  • Oppose - I don't think I've ever seen a pixilated image on here..., Anyway If for instance a picture is taken of a BLP with a fan then the image gets cropped thus only showing the BLP, IMHO Images shouldn't ever be pixilated full stop, It's like the idiots who blur car registrations at Commons ... utterly pointless .... Anyway that's way offtopic, Anyway no need for pixelating anything. –Davey2010Talk 05:51, 19 March 2016 (UTC)
to be clear, Davey2010, you think images should not be pixelated / blured, but you also think we should not forbid any pixelated images (that is, we should replaced them, as possible)?
Hi Nabla, Sorry I should've been clearer - but yep spot on - If there is a pixelated image then nope it shouldn't be deleted "just because it's pixelated" and yep it should be replaced but if there's nothing better available then the pixelated one should be left up, Thanks, –Davey2010Talk 15:30, 19 March 2016 (UTC)
Tks! - Nabla (talk) 18:14, 19 March 2016 (UTC)
  • Oppose. If the image is still informative, why delete? Surely, if we can get a better looking one (non pixelated image is certainly a improvement in that), then, by all means, replace it. - Nabla (talk) 12:03, 19 March 2016 (UTC)
  • As per the above, pixellation should be considered a flaw in the image, but if that remains the best (or only) free image we have available, and even with the pixellation it represents the subject appropriately well, we should use it until a better one comes along. As soon as such a better free image does happen along, of course, we should then replace the pixellated image with the superior one. I think it should be generally discouraged and should be considered a serious image flaw, but not flat-out banned. Seraphimblade Talk to me 15:50, 19 March 2016 (UTC)
  • Oppose So what? If the image is free to use it is free to use, don't like it - replace it. — xaosflux Talk 16:44, 19 March 2016 (UTC)
  • Oppose Hamid Hassani (talk) 16:51, 20 March 2016 (UTC)
  • Oppose the fact that faces are pixellated in a photo is irrelevant when those faces are not the intended subject of the photo. If a notable subject provides a photo of themself with their child sitting on their lap I see no problem at all with the child's face being obscured, in fact it is in line with our presumption of privacy rules. Similar obscuring of vehicle licence plates is also regularly done in in media. Roger (Dodger67) (talk) 18:10, 20 March 2016 (UTC)
  • Oppose: The photos violate no policy, but censoring them off of WP would.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  07:00, 21 March 2016 (UTC)
  • Oppose I don't see how pixelating is "anti-journalistic" when journalistic ethics require pixelation in many cases. It could also be preferred under our WP:BLP. Whether it is unencyclopaedic depends solely on the information content. Hawkeye7 (talk) 03:42, 22 March 2016 (UTC)

Move to CLOSE per SNOW. GenQuest "Talk to Me" 13:52, 22 March 2016 (UTC)

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.

Suggested languages template

Latest comment: 8 years ago4 comments3 people in discussion

Would it be possible to provide an easy alternative mechanic for populating the 'Languages' field to the left of an article page? For example, I'd like to be able to post a template to the talk page where I can suggest a list of alternate language Wikipedia articles. Those who have an interest can then take the suggestions, verify them, and use the URLs to populate the Languages list for the article. (I personally have no interest in wrestling with that arcane system; I'd rather spend my time writing and editing articles.) Thank you. Praemonitus (talk) 21:53, 21 March 2016 (UTC)

I believe that the old system still works, and that a bot (still?) comes around to transfer the results to Wikidata. That means that you can place an old-fashioned interlanguage link at the very end of the page to create the link you want. This uses the form [[xx:Article title]], where "xx" is the language code (e.g., "de" for de.wikipedia.org, "bar" for bar.wikipedia.org, etc.) and "Article title" is the exact article title at the other Wikipedia (e.g., "Hauskatze" or "Hauskotz", for Cat). WhatamIdoing (talk) 18:56, 22 March 2016 (UTC)
Yes, old system still works (also the part about bots). --Edgars2007 (talk/contribs) 18:59, 22 March 2016 (UTC)
Okay, I'll give that a try. Thank you both. Praemonitus (talk) 21:36, 22 March 2016 (UTC)

Consensus Talk Index (CTI) idea

Latest comment: 8 years ago1 comment1 person in discussion

2 proposals

Latest comment: 8 years ago3 comments3 people in discussion
  1. A High lighter for app and signed in users for studying and to mark cool things.
  2. I was studying English authors and I came across these common errors (mostly for poets on the American Poets page):
    1. format of names and dates (varies)
    2. bibliography (sometimes the same word will refer to either the authors works or works on the author. This varies from article to article but the title only says "Bibliography")
    3. works font style (Eg.: Instead of, say, Don Quixote it's just Don Quixote)
    4. sometimes a large list of works are written in a different smaller and thinner font and the capital "I"s and "L"s can't be distinguished. https://en.wikipedia.org/wiki/Anne_Waldman#Works Lovis or Iovis?

So I propose:

a template, tutorial, maybe even clippy (or since it's wikipedia we can call it whippy), or "an-ask-someone-else-to-format-this-correctly" request feature (this can be put up on a separate page for requests or can have a special 'button'/ 'medal' image on top of the page to easily indicate to editors that the page requires special attention.

My idea: A mouse-over explains the meaning of the medal (for the information of the middle-man) with a link to a tutorial. Then, the middle-man (me) can select the right medal, say an expert knowledge medal or formatting medal, and input the location of this error. Then, a mouse-over of the medal (for the information of the editor) would say where the error is, what type of editing is required, time, IP and for how long the request has been unanswered.)

3. I also propose this medal feature, to help people like me, who spot the errors but can't correct it. (I'm studying so maybe when I know more and have more time I can correct it. If this feature were there I could have marked all the errors I spotted on their respective pages, instead of not spending the time to write in the edit page that the biographies are off. ) Medals: A compact, clean, quick way to say "Edit this" without editors having to always read the whole thing. 61.2.163.210 (talk) 13:19, 24 March 2016 (UTC)

Regarding item 3, we already tried this with WP:AFT, which was removed from use here on en.Wikipedia. --Izno (talk) 15:47, 24 March 2016 (UTC)
Regarding Item 4 after the "graphic rework" or whatever they called it I researched suitable sans-serif fonts for Linux, Windows and Mac which don't have this problem, and suggested them to the WMF. I got the usual Not Invented Here response I'm afraid. It might be worth trying again.
All the best: Rich Farmbrough, 17:18, 24 March 2016 (UTC).
Latest comment: 8 years ago1 comment1 person in discussion

So this must be a poll?

Going through the works of famous people I noticed that most of them (who are alive)don't seem to contribute to their own pages. (eg.: date of birth, portraits,etc.). So I propose a banner invite. For example: banner: "The following purpose is only for encyclopaedic purposes and is subject to it as such. We request 'famous' (link: WP: noteworthy) people to donate the portraits of famous people or themselves, and pictures, recordings, etc. of their works to wikimedia, and also to help editors edit their page. They may even give a vocal reading of their own names or perhaps the whole article (if they wish to). The invitation extends to the people who helped them get there to help contribute to their pages and articles related to them." 117.207.234.48 (talk) 08:08, 26 March 2016 (UTC)

Notice: RfC on Citation coding style

Latest comment: 8 years ago1 comment1 person in discussion

See WT:CITE#RFC: Is a change in citation markup method a change in citation style?. More views are wanted. DES (talk) 23:09, 26 March 2016 (UTC)

Close down Possibly Unfree Files

Latest comment: 8 years ago52 comments38 people in discussion
The consensus is overwhelmingly to close the WP:PUF process, with all future discussion within the former scope of PUF to take place at Wikipedia:Files for discussion. The majority argues that there isn't a clear distinction between the PUF and FFD processes and that placing file-related discussions in one place (eliminating redundancy) would lead to improved overall efficiency. Respectfully, Mz7 (talk) 20:14, 7 April 2016 (UTC)

The following discussion 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.

At this discussion, we reached consensus to close down non-free content review and instead send all such discussions to Files for Discussion. Possibly unfree files (PUF) has many of the same issues. It doesn't get enough attention - current there are unclosed discussions from December. And, more importantly, it isn't clear to many editors, nor to any new editors, whether such a deletion discussion should happen at PUF or FFD. Files for discussion is perfectly capable of handling the additional discussions.

The proposal is this: Close down Possibly Unfree Files, with all future discussion at Files for discussion Oiyarbepsy (talk) 03:48, 6 March 2016 (UTC)

Close PUF

  1. Support closing. While they may officially have different purposes, in practice they duplicate each other, and we'd do better to have less processes rather than more anyways. --Jayron32 16:30, 7 March 2016 (UTC)
    Support. With the way that the English Wikipedia has evolved over the years, it just makes sense to have all discussions for "File:" namespace pages to happen in the same place. Steel1943 (talk) 19:02, 7 March 2016 (UTC)
    I'm actually not so sure anymore, given the current WP:FFD and WP:PUF backlogs. I'll be neutral now. Steel1943 (talk) 16:16, 4 April 2016 (UTC)
    I don't think the presence of backlogs constitutes a good reason not to merge the two--you'll still have a backlog but at least it will be all in one place... --Izno (talk) 16:27, 4 April 2016 (UTC)
    @Izno: Yeah, it's definitely not a reason for me to advocate that PUF be "kept", but it now makes me wonder if there may be a different way to approach the issue other than merging PUF into FFD as proposed. In other words, I'm now concerned that this merge will result in a "take action first, ask questions later" scenario. To elaborate, I proposed and tried my best to coordinate the WP:NFCR to WP:FFD merge, and that was quite involved itself and had a period of time (about two months) where there was still a major amount of loopholes in the form of templates relating to FFD not updated, FFD subpage issues, non-admins closing discussions on FFD since the discussion was not advocating deletion, etc. That, and at the present time, WP:FFD and WP:PUF have no admins that are regularly closing discussions. (The only recently active one, Explicit, is currently on a long break.) Another issue is the lack of admins who seem to be willing to touch these discussions, especially considering that the "File:" namespace is one of the few namespaces where occasionally, legal issues concerning a file could, in theory, WP:SUPERVOTE community consensus regarding a specific file. Steel1943 (talk) 16:54, 4 April 2016 (UTC)
    ...With that being said, since PUF deals more with obvious issues regarding copyright infringements that need to be dealt with in a timely manner whereas FFD (and formerly NFCR) are not as urgent since those files are already marked non-free and usually with rationale (unless the rationale is challenged), I think the distinction is clearer and I have changed my mind now (but will probably help out with the PUF to FFD merge if it is approved, as it seems like it is going to be anyways per this discussion.) Steel1943 (talk) 17:08, 4 April 2016 (UTC)
  2. Support - It only makes sense to limit the places that deletion discussions take place; having a different place for each specific reason for discussion leads to bureaucracy. It does make sense to have different places for files, templates, categories, articles, and "other" pages, but since FfD and PUF are essentially duplicating work and many (if not most) editors are not aware of PUF (for example, I was not aware PUF existed), they need to be merged. — Jkudlick • t • c • s 13:34, 8 March 2016 (UTC)
  3. Support - Easier just to have one place to discuss all the particular aspects of files local to Wikipedia, most of which relate to a files particular free-ness. Redirect to FFD or mark historical with a big pointer to FFD. --Izno (talk) 14:21, 8 March 2016 (UTC)
  4. Support – I've had users respond with confusion when I took a file to PUF rather than FFD, the former being less well known. Would be simpler and easier for everyone just to have the one venue for everything. CT Cooper · talk 18:06, 8 March 2016 (UTC)
  5. Support. Seems like unnecessary duplication. --Regards, James(talk/contribs) 18:14, 8 March 2016 (UTC)
  6. Support Per all the above. Having too many forums for discussion of basically th same thing is unhelpful to the project. Beeblebrox (talk) 18:35, 8 March 2016 (UTC)
  7. Support – Reduces bureaucracy, improves efficiency. RGloucester — ☎ 19:17, 8 March 2016 (UTC)
  8. Support - decreases red-tape, and increases performance. — Cirt (talk) 01:39, 9 March 2016 (UTC)
  9. Support. The distinction was often unclear to me, too.  Sandstein  08:15, 9 March 2016 (UTC)
  10. Support as IMHO it's a completely pointless board - It's pretty much a duplicate of FFD so there's not much point in keeping it around, FFD seems to be the best choice here. –Davey2010Talk 03:07, 10 March 2016 (UTC)
  11. Support simplification and centralization and elimination of this and other bureaucratic cul de sacs. Carrite (talk) 12:29, 11 March 2016 (UTC)
  12. Support: fewer is better. Esquivalience t 20:57, 12 March 2016 (UTC)
  13. Support I never understood why it was necessary to have multiple venues for files in the first place. — JJMC89 (T·C) 22:00, 12 March 2016 (UTC)
  14. Support per nominator. Reduction of confusion in regards to "where to go" by removing essentially duplicate spaces is appreciated. I, JethroBT drop me a line 01:24, 14 March 2016 (UTC)
  15. Support. This is a logical next step for reasons already stated above. I'd be interested in feedback from PUF regulars on what they would need to be best accommodated in FFD. czar 03:29, 14 March 2016 (UTC)
  16. Support Thanks to the broadening of FFD's mandate it now can handle non-deletion outcomes. Also, I see rather frequently the freeness of an image being disputed in FFD when PUF would be the right place.Jo-Jo Eumerus (talk, contributions) 17:21, 14 March 2016 (UTC)
  17. Support. Simpler. -- Ϫ 01:56, 15 March 2016 (UTC)
  18. Support – when a process does not get much activity, and can easily be replaced by another process, it is best to close it down. sst✈ 05:45, 15 March 2016 (UTC)
  19. Support --- PUF doesnt get much anyway Ⓩⓟⓟⓘⓧ (talk) 18:52, 16 March 2016 (UTC)
  20. Support -FASTILY 21:59, 16 March 2016 (UTC)
  21. Support per the KISS principle. Andrew D. (talk) 17:44, 18 March 2016 (UTC)
  22. Support Hamid Hassani (talk) 16:47, 20 March 2016 (UTC)
  23. Support. Good reduction in WP:BUREAUCRACY and WP:CREEP, and consistent with the previous closure of the other redundant process of this sort.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  06:55, 21 March 2016 (UTC)
  24. Support. In the long run, PUF is just a specialization or a branch of FFD. Anything at PUF can also be conered at FFD. epicgenius (talk) 13:56, 22 March 2016 (UTC)
  25. Support - PUF gets little attention. It serves the same purpose as FFD. It is therefore redundant and should be closed. Ethanlu121 (talk) 15:56, 22 March 2016 (UTC)
  26. Support - I'm a relatively experienced user yet have been confused by this. Arguments for simplification are compelling. --LukeSurl t c 14:15, 24 March 2016 (UTC)
  27. Support I'm very concerned if the page might be overwhelmed or not, I simply hope not. The idea seems good, imo. --QEDK (T 📖 C) 16:29, 25 March 2016 (UTC)
  28. Support Seems to make the process similar. Other supports make good arguments. Particularly swayed by SST's support. Wugapodes (talk) 00:47, 28 March 2016 (UTC)
  29. Support The two processes duplicate each other a fair bit, and it would be better to have all of the discussion in one place. — Omni Flames (talk contribs) 03:57, 3 April 2016 (UTC)
  30. Support - cutting down bureaucracy sounds good. Per above, there seems to be a fair bit of process duplication going on here. Ajraddatz (talk) 04:04, 3 April 2016 (UTC)

Keep PUF

  1. Support keeping PUF. PUF and FFD have clearly distinct purposes, and the discussions are typically closed after around a week. Also, most PUF discussions are closed by the same users as those who close the FFD discussions, so if you close down PUF because you think it's backlogged, you will just move a backlog from one place to another place and thus not achieve anything. --Stefan2 (talk) 11:19, 6 March 2016 (UTC)
    Yeah, the policy pages say they're different, but when you actually look at the discussions, they aren't. And giving the closers one place to look instead of two will reduce the backlog for that simple reason. Oiyarbepsy (talk) 16:33, 6 March 2016 (UTC)
    Exactly, ×2.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  06:56, 21 March 2016 (UTC)
  2. Keep as the file is not so often deleted. Graeme Bartlett (talk) 00:16, 14 March 2016 (UTC)
    WP:FFD is "files for discussion", not "files for deletion". RGloucester — ☎ 00:37, 14 March 2016 (UTC)
    User:Graeme Bartlett, when non-free content review was closed down, Files for Deletion was renamed to Files for Discussion so that it could handle all the issues that non-free content review covered. For examples, many recent discussions have ended with the result of remove from this and that article without deleting the image. Similarly, with PUF merged in, you could have discussions ending with the result image is free or image is not free, without actually deleting it. Oiyarbepsy (talk) 01:38, 14 March 2016 (UTC)
  3. Keep PUF as it's more streamlined. Stifle (talk) 10:35, 1 April 2016 (UTC)
  4. Keep per my comments in the "Close PUF" section that have resulted in me changing my mind. Steel1943 (talk) 17:09, 4 April 2016 (UTC)

Discussion (PUF)

  • Comment: Just wondering how the cleanup is going to proceed if this RfC is approved. Just going by what happened after the NFCR/FFD merge, it seems there were many in favor of the merge who decided to not get involved in the cleanup, thus causing it to take much longer than it probably should have. A few editors really spent a lot of time updating templates, closing discussions, etc. and few admins worked their way through NFCR files which were added to FFD to help reduce the backlog. Not sure how many PUF discussions will be added to FFD, but it would be nice if there was also some consideration given to the post-merge cleanup. -- Marchjuly (talk) 02:24, 9 March 2016 (UTC)
  • @Marchjuly: I already have a bit of an overview about what will need to take place after this merge is approved. This merge probably will not be as complicated as the FFD rename since rather than a forum being shut down and a forum renamed, instead, we only have a forum to shut down. The technical details will include AnomieBOT having to stop creating daily subpages after the merge is finalized, Twinkle needing to be updated to have the WP:PUF option removed, and the instructions at WP:FFD to be updated to encapsulate everything. And, with this proposal, almost no templates should need to be updated due to no forum being renamed (I know that was the biggest headache with the NFCR to FFD merge.) Steel1943 (talk) 03:24, 9 March 2016 (UTC)
Although I didn't mention you by name Steel1943, you were one of the editors who did a lot of the heavy lifting post merge. So, if you feel things will not take as much time as before than that's good enough for me. Still there may be some discussions on PUF which require further discussion or an admin to close. Is the plan to relist them in stages at FFD like was done with NFCR or will everything be moved at once? Not sure which approach is best. I guess it depends on the number of unresolved discussions at the time of the merge. -- Marchjuly (talk) 04:16, 10 March 2016 (UTC)
@Marchjuly: I think the first step is to have what I outlined above accomplished first (halting the creation of the daily subpages.) Afterwards, if after a while PUF entries do not get closed, then relating could be an option. (I do not see the need to relist PUF discussions on FFD immediately being as necessary as the NFCR to FFD merge since PUF has daily subpages and most of those discussions are being closed in a somewhat more orderly fashion than NFCR was.) Steel1943 (talk) 21:51, 13 March 2016 (UTC)
That's a good point Oiyarbepsy that I forgot about. You also were one of the editors who helped clean things up post merge so if you feel things are going to be more manageable this time, then everything sounds good to go. -- Marchjuly (talk) 04:19, 10 March 2016 (UTC)
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.

"Research help" proposal

Latest comment: 8 years ago43 comments24 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The result of this discussion was the proposal had consensus. The arguments in favour of noincluding the template are emphatic and varied – notably the lack of prior discussion at VP, particularly for a template that breached our usual conventions on cross-space links within article content. Those in favour of leaving the template included rested mainly on the single strand of waiting a little longer to collect more data. I have sympathy with the latter view, but it is clear that the strength of the argument lies with support for the proposal. Discussion has now tailed off, apart from a tangential interchange that is not gainful in seeking a consensus. I believe that the discussion can now be closed. Disclaimer: I did comment at earlier discussions in favour of the trial, so have some background, but I have not participated in this discussion. --RexxS (talk) 08:30, 3 April 2016 (UTC)
Backgound

A pilot project has added this template (or something similar):

Using Wikipedia for research  


to 10,633 articles with a "References" section - based solely on discussions at two WikiProjects, initiated by User: Astinson (WMF) (really the respected user User:Sadads).

It is intended to add these to all articles.

The purpose is to solve a problem or problems. The problem should be stated in Wikipedia:Research_help/Proposal#What_are_we_trying_to_solve?, but there is no clear statement of a problem or problems.

The template links to a page which needs to be read to understand the likley effect. Among other things it makes categorical statements about biases, editors and Wikipedia article which could be contentious, and embeds a not-strictly-accurate video.

A number of editors (including me) are not happy with having this text linked to form the bodies of of some 10,633 articles, many dealing with important topics, without a VP approval.

There are many issues here, including WMF-community relations, believing projects WP:OWN the articles in their scope and cross-namespace links.

I would like to focus on one proposal however:

Proposal

The existing 10,633 article "pilot" be suspended by blanking the template, and no further templates added. When a proper VP proposal for a pilot has been made and passed, which should include community review of the template wording, the help page wording and the purposes behind it, the pilot may continue. If the proposal is not made, or does not pass, within a month from today, the templates will be removed. Meanwhile editors are free to remove the templates in the normal course of editing using editorial discretion.

All the best: Rich Farmbrough, 18:21, 24 March 2016 (UTC).

I dug up relevant pages I could find:

Alsee (talk) 13:06, 25 March 2016 (UTC)

Support (stop the "pilot" until consensus is reached)

  1. Not suitable placement, unclear motivation, target page needs work. Also breach of WMF-community protocol which needs reining in. All the best: Rich Farmbrough, 18:21, 24 March 2016 (UTC).
  2. Pause until we know what we have. GenQuest "Talk to Me" 03:22, 25 March 2016 (UTC)
  3. Pause at least and consider rolling back until there's been consensus considerably stronger than "well, I asked a few people and nobody actively disagreed". It's clear from Wikipedia:Research_help/Proposal#Who is affected? that the intent is to add this to every page on Wikipedia, but there's no obvious impact assessment I can see. On longer articles, it's likely to be lost in the general goop of navboxes, Commons links, portals and external links at the bottom of the page if not made even more obtrusive than it already is, but making it obtrusive enough to stand out to readers will make it an obnoxious and distracting presence on shorter stub articles. Even the actual proposal itself makes it clear that spamming this template isn't appropriate. I have no doubt of the good faith of those involved, but this looks like yet another case of someone at the WMF with a pet project assuming that everyone else is as enthusiastic for their idea as they are themselves, and before it goes any further it needs a discussion among the broader editor base as to whether the benefits of this outweigh the problems, and how to implement it if it does go ahead. ‑ Iridescent 11:06, 25 March 2016 (UTC)
  4. Pause and consider rolling back per Iridescent. In addition, I definitely don't support embedding this into content. Regardless of whether it's needed, this is not the right way to go about it. It should be presented as meta-content (it currently doesn't even use the selfref class or similar), it should be presented in the right place as meta-content relevant to the whole wiki (Main Page or sidebar spring to mind?), and I'd want confirmation before placing it in the references section, where I'd bet it's not read by the people who need it and annoying to the people that don't. {{Nihiltres |talk |edits}} 16:42, 25 March 2016 (UTC)
  5. Stop the pilot and roll back. Self-referential meta-content should not appear in the text of articles and this wide-reaching change should have been brought forward for project-wide consensus rather than consulting just a few wiki-projects, who do not control the relevant articles. Also see my comment below about timelines. BethNaught (talk) 22:23, 25 March 2016 (UTC)
  6. Stop the pilot and roll back promptly. As per BethNaught, this kind of self-refereential content does not belong on article pages. The idea is clearly intended to help readers, but a better way must be found to do this. Do not wait another two weeks to roll this back, and certainly no longer. DES (talk) 09:32, 26 March 2016 (UTC)
  7. Strongly stop the pilot If I had known this had existed, I would have strongly objected. The fact that this project was done without the consensus of the community (WP:VP) undermines the project's ideals. Programming G E E K (mah page! // use words to communicate page) 11:37, 26 March 2016 (UTC)
  8. Support This and anything like it needs needs project wide consensus before implementation; and in this specific case, there needs to be wider discussion on the best method for implementation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:58, 26 March 2016 (UTC)
  9. Strong support: Consensus represents both the concerns of editors as well as the wishes of the entire community. Although the WikiProjects asked were in no way small, they cannot speak for the entire community nor is the community devoid of objections to this project. Esquivalience t 02:35, 27 March 2016 (UTC)
  10. Support. Roll back until more widely discussed and piloted. JFW | T@lk 07:54, 27 March 2016 (UTC)
  11. Support. As I was saying in the discussion concerning the template, it is not just annoying, it is not just violating guidelines about self-references, it also links to the page that is misleading the readers (into thinking that Wikipedia is more reliable than it is) with various "Finally, Wikipedia's millions of readers catch and fix flaws when they find them." or "This works most of the time because many eyeballs make all bugs shallow," (still there in the current version - Special:Diff/711865882). Or, at least, it would be misleading them, if they were actually reading it, which isn't certain (hardly anyone has cited anything from that page in any of those discussions, and the ones who participate in them could be expected to be more motivated to read all that than an average reader) - but if no one reads that page, the template is still useless. And we already know much about this idea (most importantly - that it is not good), thus there isn't much to research, meaning that the further trial is unlikely to be useful. And if it is misleading, violating guidelines, annoying and useless, I'd say that the trial should be stopped. --Martynas Patasius (talk) 18:28, 27 March 2016 (UTC)
  12. Support as per User:Rich Farmbrough. Jason Quinn (talk) 15:44, 30 March 2016 (UTC)
  13. Support, seen that this is transcluded on thousands of pages across Wikipedia (and not on just a few pages regarding specifically only one WikiProject), the consensus of just 2 WikiProjects is NOT enough. Both the methodology as well as the implementation of these templates should be discussed widely. Disable the template and start again. --Dirk Beetstra T C 06:42, 3 April 2016 (UTC)

Oppose (allow the "pilot" to continue ad lib)

  1. Continue Does it really hurt anything for a 30-day test. Give me a break people. The real question is should they remove them all after the trial is up. Oiyarbepsy (talk) 03:24, 25 March 2016 (UTC)
  2. continue just give it a chance--Ozzie10aaaa (talk) 23:47, 25 March 2016 (UTC)
  3. Continue for the next 9 days trial will end on April 7 anyway. I support in general improving articles and the way we communicate article content; part of this involves trying new things. Trying things inherently carries a component of risk (on wikipedia at least: mainly to the proposer of a trial's mental health and wellbeing). This was a small trial with local consensus that has a defined endpoint in 9 days. What a storm in a teacup.--Tom (LT) (talk) 17:12, 27 March 2016 (UTC)
  4. Oppose, forum shopping after Wikipedia:Templates_for_discussion/Log/2016_March_8#Template:Research_help with no notice to participants there (those pings did not work), plus only a couple days left anyway. Ed [talk] [majestic titan] 01:12, 3 April 2016 (UTC)
  5. Oppose per above, it's ending soon anyway, and could be possibly useful. I would prefer it if more consultation was done before implementing something like this, though. I am also concerned with the implementation of a result here by the person who proposed it. Ajraddatz (talk) 03:54, 3 April 2016 (UTC)

Neutral

  1. Neutral Were this a proposal, I would have opposed its implementation. I don't think this is the right way to go about solving the "problem" of helping people do research. But that's not what this discussion is, and I think we can cross that bridge when we get to it. This pilot has a hard stop on April 7th. After going 600 article over the pilot amount, the bot stopped adding them to pages. I don't particularly see a problem with leaving it on these pages for about 10 more days and then addressing whether we want to let it keep going. I don't want it to continue (which is why I'm not in oppose) but I see very little difference between the pause outcome and what's already occurring. By the time we develop consensus, it will likely be just a few days from the pause outcome and when it would have naturally ended anyway. I don't really feel comfortable in either support or oppose because of that, so here I stand. Wugapodes (talk) 18:59, 26 March 2016 (UTC)
  2. can I do the same? Can I? Can I?. I want to add a very nice test I thought of to a mere 10,000 of WP's pages for only one month. Can I? That is, although the intention looks good, it looks very bad. ANd no, Ignoring All Rules is not a good argument to add a poorly designed link to a disclaimer-like page. Anyway Wugapodes makes a good point. Why bother... Lets move on to discuss the big picture, and check if anyone says they will clean up after the deadline and then 'forget' to. - Nabla (talk) 21:26, 26 March 2016 (UTC)

Additional discussion

The Bot approval discussion should have bounced this to Village pump. It should have been foreseeable that controversy would arise over 10,000 "experimental" cross-namespace links (with an icon to boot) added to the Reference lists. The intentions are good, but this is way outside any commonly accepted norms. Any cross-namespace link in an article is typically revert-on-sight, and any content unrelated to the article it is in is also typically revert-on-sight.

It appears that this "pilot" is planned to end in a few days anyway, after which they planned to come to Village Pump anyway. It looks like this discussion is mostly moot, unless it gets a real fast Snow close. Even with a quick Snow close it would make little difference to the apparent end-date anyway. Alsee (talk) 13:31, 25 March 2016 (UTC)

@Alsee: Could you point me to a specific end date? Also, I will say that pilots have a nasty habit of lingering longer than intended (cf Pending Changes trial) and that it could take an exceedingly long time for them to come here, given there are several steps in the given roadmap between the trial phase and the Village Pump phase. The roadmap is not at all clear. BethNaught (talk) 22:23, 25 March 2016 (UTC)
Hi all. Thanks for bringing this up for discussion, we really appreciate the wide range of feedback we have been getting. We had been hoping to collect more data, so that we could reflect on a data-informed discussion (hence the pilot and limited discussion). We hadn't previously documented a specific removal date, because of the delays in the bot activity and variability in visibility created by the TFD (skewing both the feedback and pageviews). However, based on when the bot implemented, I plan to noinclude the template, on or before April 7 (or via concensus of course). I documented it with this edit. I will engage more in the discussion tomorrow. I look forward to any questions and discussion, Astinson (WMF) (talk) 01:44, 26 March 2016 (UTC)
Thanx.
Rich_Farmbrough, the noinclude on the template will blank the template as proposed, additions of the template have already hit the bot-approval cap, and the previously stated intent is a Village Pump proposal before proceeding any further. It seems the objectives of this proposal have been agreeably satisfied. How about withdrawing & boxing the unneeded support/oppose sections? We can leave this discussion section open. Alsee (talk) 04:09, 26 March 2016 (UTC)
I think it's quite useful. I am also not very happy with the idea that this project has "snuck under the radar". I thought perhaps I was being a little cynical entertaining this idea, but I now see that the project was advised to come here back in November, by User: WhatamIdoing

did you spam notices about this to the Village Pumps or anything like that? There was an objection last year (with a script that displayed the editors'/authors' names on the page) that was framed as being a procedural complaint about a LOCALCONSENSUS by a WikiProject. It would be desirable to have attention from non-participants, especially since WPMED doesn't OWN the articles

to which User:Astinson (WMF) replied:

We were aware of that experience. We are operating under the assumption that this is not going to have many strong objections: every person we have shown this to has had no show-stopping objections (mostly positive tweaks, etc), we plan to do this a temporary pilot to see if there is evidence of its usefulness, and it will be a template that can be "noincluded" at a moments notice.

There have been numerous objections, and the template has not been "noincluded" - except by me, and that was reverted.
This is not a small thing, it is, arguably, damage to 10,633 articles.
All the best: Rich Farmbrough, 05:41, 26 March 2016 (UTC).
I was referring to the existing agreement "to noinclude the template, on or before April 7". I don't see what's really being added by piling on supports for what's going to happen anyway. I'm surprised there were no objections raised at MED or MILHIST and I think BOT-approval should have bumped this unusual edit to Pump, but I think we can take this as a good faith situation with an uncontested end to the pilot. Alsee (talk) 10:26, 26 March 2016 (UTC)
If the pilot is going to end naturally, this poll is redundant and ought to be closed. Note that when it was started there was not a clear date, but now there is I agree with you. BethNaught (talk) 10:43, 26 March 2016 (UTC)
"Damage" is a pretty strong word to use there, Rich. Ed [talk] [majestic titan] 01:14, 3 April 2016 (UTC)
The pages are worse with the message displaying. They are therefore damaged. Deliberately making the encyclopaedia worse is something up with which I will not put.
All the best: Rich Farmbrough, 01:34, 3 April 2016 (UTC).
That's just your opinion, which is why I find it strange that you are closing this discussion. Ed [talk] [majestic titan] 01:46, 3 April 2016 (UTC)
If not me, who? If not now, when? All the best: Rich Farmbrough, 02:00, 3 April 2016 (UTC).
WP:AN has an entire section devoted to requests for closure... Ed [talk] [majestic titan] 02:37, 3 April 2016 (UTC)

Proposal implemented

Per consensus. I see no value in leaving the message in articles any further. Sufficient data should already be collected. Per the proposal, the pilot can be resumed by gaining consensus here.

Do I feel like the bad guy? Yes. But I also felt like the bad guy leaving the message in 10,633 articles when there is consensus here to remove it, and many other objections have been voiced. Had my questions on to pilot talk page been answered, I might have lapsed into inaction for another few days.

All the best: Rich Farmbrough, 00:02, 3 April 2016 (UTC).

I've reverted. You should really leave notices to previous participants, as many interested parties don't watch this page (note that your pings above did not work, probably because they weren't followed by a signature, but I can't be sure). That's probably why you don't have many !votes above. In addition, you should leave the closing of such a proposal to a neutral third party. Thanks. Ed [talk] [majestic titan] 01:11, 3 April 2016 (UTC)
I have noincluded the template just as the WMF staffers said it could be if there was any objection.
I therefore think it unreasonable for said WMF staffers to revert, especially since we have clear consensus.
Nor is it concomitant with Wiki culture to filibuster, to get the "required" outcome.
I have re-reverted. In doing this I am protecting the encyclopedia, there should be no reversion unless there is a compelling reason.
All the best: Rich Farmbrough, 01:29, 3 April 2016 (UTC).
This is not 'protecting the encyclopedia,' it's stifling innovation and ignoring that you improperly notified all of the previous participants in past discussions. See my comments above. Also, like in the TFD, I'm commenting here in my volunteer role only. You can see my disclaimer on my user page, my posts to Fram's talk page, and/or as I said at the TfD: I've been a Wikipedian and supporter of the Wiki Library for long before I or it joined the WMF. My edits and thoughts here are mine and mine alone; my personal views very frequently differ from the WMF's official lines. Ed [talk] [majestic titan] 01:44, 3 April 2016 (UTC)
Nothing is being stifled here, except a poorly thought out implementation of what may be a good idea. The fact that there are no answers after many days to questions about this pilot suggest that it is not being seriously pursued or considered any more by those involved - except perhaps with the hope that it gets past the planned end date through the operation of WP:BURO.
I too support the Wiki Library, that does not mean that I have to support every project that is shoved under its banner.
As to which hat you are wearing, you were involved with the discussion started by User:Jytdog in relation to this project "my official capacity". I don't think you can convincingly switch hats in this circumstance, and I am certain that it is unwise to do so.
All the best: Rich Farmbrough, 02:14, 3 April 2016 (UTC).
First, that conveniently ignores my positions taken before that on WT:MILHIST and the TFD. No hat-switching back and forth. Second, while Jytdog's discussion started from the debates surrounding this trial, it quickly became a larger discussion about how the WMF interacts with the community. I said that in the discussion as well, but your truncated quote above doesn't exactly capture the actual sentiment of the sentence: "Going to jump in here in my official capacity, which I think(?) is the right one for this conversation." (emphasis mine)
I take pains to note when I'm writing in a volunteer (untethered to the WMF) or an official (tethered to the WMF) capacity. I'm sure there are plenty of ways to discredit me as a volunteer and there will be a mistake at some point, but that isn't one of them and this isn't that time. Ed [talk] [majestic titan] 02:44, 3 April 2016 (UTC)
Small post-closure note: this tweak to the comment above was saved under the wrong account. I'm aware that the irony here is absolutely palpable. My thoughts and opinions on the Wiki Library remain mine and mine alone! Ed [talk] [majestic titan] 20:16, 3 April 2016 (UTC)
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.

wow way off the mark here--Moxy (talk) 16:44, 3 April 2016 (UTC)

"Event coordinator" user group

Latest comment: 8 years ago17 comments5 people in discussion

I propose creating a new user group, entitled "event coordinator", which has the following rights;

  • (noratelimit) - This allows users to create more than 6 accounts on a single IP in a 24-hour window. Currently, users are given the "account creator" flag, but this also gives access to override spoofing checks and the title blacklist, something event coordinators don't need.
  • (ipblock-exempt) - Many time events are held at libraries of universities, and often these are blocked. This would allow for them to create accounts for others, even though the IP is blocked.
  • Add groups: Confirmed users - Often a source of backlog at PERM, as editors start to get the needed editing experience at events but don't have the needed four days tenure.

This right would be given by sysops at WP:PERM either for short amounts of time or permanently to trusted and frequent event holders.

Thoughts? Kharkiv07 (T) 22:16, 31 March 2016 (UTC)

If we are going to go this route, may want to be so bold as to also bundle in Add groups: Confirmed users. — xaosflux Talk 22:36, 31 March 2016 (UTC)
I agree, and have added it above. Kharkiv07 (T) 00:21, 1 April 2016 (UTC)
How about just assign them the 'account creator' and IPBE groups for the time? Ajraddatz (talk) 01:41, 1 April 2016 (UTC)
They both contain needed and more powerful permissions, account creator has the ability to override spoof-checks and the title blacklist, and IPBE contains tor-overrides that CUs don't like handing out. It's also the ease of one flag instead of two, and per xaxosflux's suggestion the addition of the ability to add the confirm right is a plus. Kharkiv07 (T) 01:45, 1 April 2016 (UTC)
I don't recall those "powerful" rights ever being abused by an event coordinator, but I could be wrong. Creating more bureaucracy with yet another niche user group doesn't seem ideal to me. Ajraddatz (talk) 01:53, 1 April 2016 (UTC)
Please note, this is not adding IPBE 'group' but one of the nested rights, so tor-block would still apply. — xaosflux Talk 14:53, 1 April 2016 (UTC)
I'm aware, this is a benefit from handing out the IPBE group, in my opinion. Kharkiv07 (T) 15:50, 1 April 2016 (UTC)
Do we know the extent to which people with the account creator user right use/need the spoofing/blacklist overrides? Would it be easier to say those are admin rights only and reframe the existing account creator right as something closer to "event coordinator"? The benefit of doing so, to me, is that I think the blacklist and antispoofing measures are part of why there's a reluctance to issue the right for longer than a short period of time. I don't think it's regularly removed from experienced/trusted users, but for those who are, for example, involved in GLAM or education they may not be extremely experienced but would be good people to have that ability nonetheless (without having to request a permission in advance of each event/class they'll need it for). — Rhododendrites talk \\ 16:56, 2 April 2016 (UTC)
Those rights are included for people involved with the WP:ACC process, and are probably useful to have in there, mainly for creating accounts with similar usernames to existing ones. It's a hard right to abuse; you need to explicitly check a box in order to override the blacklist and antispoof, so short of a severe lack of clue or bad intent it isn't something which would see routine damage. Like most things on-wiki, these actions can be very quickly corrected as well (blocking, renaming, etc.), and since there is no access to deleted or suppressed content the "potential for abuse" argument shouldn't be coming into play without a good reason. Ajraddatz (talk) 17:13, 2 April 2016 (UTC)
Perhaps you're right, Ajraddatz, I just figured that this is an easier way to do it (especially after xaosflux's additional proposal, and that if we go down this route there's no reason for them to posses those extra permissions. Perhaps it's too much of a hassle without much to gain, though. Kharkiv07 (T) 21:34, 3 April 2016 (UTC)
My problem with it is that we already have a group for making accounts - account creator! It's not a bad proposal, and I do apologize if I've done too much to dissuade you from pursuing it. I just would prefer to utilize existing infrastructure rather than add on new groups, which would require new policies, and then new debates every time something changes with it. The + confirmed part would be very useful, but it shouldn't be too hard to find admins who can grant that right to the few people who would need it, or remove protection from pages that are part of the editing program.
I'd object to -confirmed, (Note: I only proposed +confirmed) should someone grant this is error they should report it to an admin- if they are regulatory making errors they shouldn't have the permission. — xaosflux Talk 23:00, 3 April 2016 (UTC)
Quite right, I'm just used to typing in +/-. Corrected. Ajraddatz (talk) 23:08, 3 April 2016 (UTC)
If admins are being particularly selective about which event coordinators are getting the rights they need to perform their role, then maybe just remind them how easily all of those actions can be reverted. This is a wiki, after all :-) Ajraddatz (talk) 22:39, 3 April 2016 (UTC)


I've run a lot of events at various venues over the past four or five years and I regularly find myself having to make use of the 'noratelimit' ability, because there's always somebody who forgot to create an account beforehand, or forgot their password. It would often result in a chaotic start to a training session without my accountcreator flag. I can't think of a time when I've needed to override spoofing checks and the title blacklist, but it's more sensible to have that sort of ability and not use it than not to have the ability and need it. The flag also grants the ability to edit page notices, which comes in handy on occasion, but isn't related to the proposed "event coordinator". It would be nice to have 'IPBE' just in case the venue was blocked, but I can work round that by tethering my laptop to my phone and using that to give me the same functionality. 'Add groups: Confirmed users' would make life easier for the participants as they wouldn't have to struggle with the illegible captchas every time they want to work with external urls or images, but that doesn't wreck the session in the way that not having the 'noratelimit' would. In summary, the proposal would make life easier for experienced event organisers, but I couldn't make the argument that it's essential in the same way as the 'noratelimit' ability is. --RexxS (talk) 22:38, 3 April 2016 (UTC)

Please note, accountcreator group can no longer edit page notices, that was transfered to the templateeditor group. — xaosflux Talk 23:05, 3 April 2016 (UTC)
Was removed by no longer allowing accountcreators to override the title blacklist (they can now only override it in respect to creating accounts via tboverride-account). — xaosflux Talk 23:07, 3 April 2016 (UTC)

Article assessment comment subpages

Latest comment: 8 years ago1 comment1 person in discussion

I am finally trying to complete a task for which consensus was established 7 years ago - to deal with several thousand /Comments subpages in article talk space. (Please see WP:DCS for more details.) Here is one example: Talk:Vegetarianism and religion/Comments. Basically these pages have barely been used for years and we are going to migrate the content to the article's talk page and then redirect. If anyone is interested, please comment at WT:DCS or at the bot request for approval where we are ironing out the details. — Martin (MSGJ · talk) 09:21, 4 April 2016 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_130&oldid=1086983091#RfC:_Disable_Gather_on_enwiki"