Wikipedia:Village pump (proposals)/Archive 130

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

• 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

• About me: I try to stay away from too much wiki-talk and prefer to work on content
• This is the first time I heard the word "gather" and I don’t really have the time to look into what it is.
• I was one of the most active participants on
  wp:WikiProject Breakfast where wp:Flow
  was being tested.
• I tried to object, unsuccessfully to removing the Flow trial from WikiProject Breakfast.
• For those who are interested and have lots of time on their hands see:
  ping
  me

• • 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
    Fram (talk
    ) 19:28, 20 January 2016 (UTC)
• Disable Gather for now. Or at least remove its ability to display images.
  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)
  • Thank you for providing that very striking example. Meanwhile, I tried to create a collection to test it further, but the site is simply stuck: I gave a name and description, and clicked save, and that was the end of it. Oh well...
    Fram (talk
    ) 20:08, 20 January 2016 (UTC)
    • I posted to mw:Talk:Gather about the problem. I am not sure how well-watched that page is though. —Kusma (t·c) 20:24, 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
  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)

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

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?

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,

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

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)

@

riding a dead horse to your own loss of relevance. Jbh^Talk

18:36, 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,

Fram (talk

) 13:23, 31 January 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)

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)

@

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)

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)

• In my opinion, this is exactly what should not be done. This category has to be emptied, not to be made more comfortable. I have given some stats at the category talk page. The main fact is that 411 pages among the 823 belong to Wikipedia:WikiProject_Spam/LinkReports/xxx. A typical page is Wikipedia:WikiProject_Spam/LinkReports/adland.tv. It was generated and modified 13:18, 10 July 2011‎ by COIBot. Never modified from this date. No one is using this pages (see http://stats.grok.se/en/latest90/Wikipedia:WikiProject_Spam/LinkReports/adland.tv). And this is the probable reason why nobody has ever remarked that

1. 2011-06-15 03:09:48 (UTC): User
   talk | history | links | watch | logs) (diff  !top) - Link: adland.tv/commercials/oreo-chocolate-creme-mommm-2002-030-usa (R/X^meta/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

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)

The event has started. (refresh)

A

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

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

Undid revision $1 by

talk

)

to

Undid revision

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

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

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

• I like standards and continuity, especially in
  GUI. fredgandt
  00:56, 14 February 2016 (UTC)
• Support if somebody is crazy enough to take this task on --Kiyoshiendo (talk) 17:44, 21 February 2016 (UTC)
• Support: consistency is valuable. {{Nihiltres |talk |edits}} 18:54, 21 February 2016 (UTC)

Oppose

• Useless
  talk
  ) 20:45, 16 February 2016 (UTC)

  @

  Beeblebrox: Since this proposal is essentially about deprecating, about removing a feature (the small parameter of {{ambox}}), how can it be considered creep? {{Nihiltres |talk |edits

  }} 18:54, 21 February 2016 (UTC)

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)

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

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)

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. ^

^{[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)

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

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 | VT^alk :  15:02, 26 February 2016 (UTC)

This was previously discussed at

install that if you want. SiBr₄ (talk

) 16:13, 26 February 2016 (UTC)

I scanned the discussions and didn't get to this solution. Thanks so much!

—D'Ranged 1 | VT^alk :  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)

@

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 | VT^alk :  06:43, 4 March 2016 (UTC)

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)

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

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)

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)

• Support. It will significantly improve the encyclopedia and encourage users to remove more and more dubious content. --Luis150902 (talk | contribs) 18:21, 18 April 2016 (UTC)
• Oppose per
  WP:BLP, lead section, paragraph beginning "We must get the article right" and the Jimmy Wales quotes linked from that. --Redrose64 (talk
  ) 12:38, 4 March 2016 (UTC)
  • I see {{citation needed}} tags in BLPs all the time. You could go and remove all those uncited claims yourself - if there were only some way to tell which tags were for BLPs. bd2412 T 13:22, 4 March 2016 (UTC)
    • Still backwards reasoning. The problem is that the questionable info should not have been tagged at all, but removed. Creating a custom tag to tag that which should not be tagged will just encourage more bad tagging, and serve to pseudo-legitimize it.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  17:56, 4 March 2016 (UTC)
• Comment per
  WP:BLP, "Contentious material about living persons (or, in some cases, recently deceased) that is unsourced or poorly sourced – whether the material is negative, positive, neutral, or just questionable – should be removed immediately and without waiting for discussion." we shouldn't be adding {{citation needed}} tags to contentious material about a BLP. It should be removed immediately before any discussion happens. I see cn tags referring to info about BLPs but how often is that referring to contentious info? I don't know but the info should be removed until it is reliably sourced. -- GB fan
  13:29, 4 March 2016 (UTC)
  • @GB fan: Good point. I have struck "possibly contentious" from the proposal accordingly. Even a non-contentious unsourced statement about a BLP should have some means of distinction over a non-contentious unsourced statement about something else. bd2412 T 13:47, 4 March 2016 (UTC)
• Comment: We have
  Template:BLP unsourced section and the category Category:BLP articles lacking sources. Generally speaking, inline maintenance templates correspond to the same problem as article/section wide. I'm at a loss as to why we can have the article/section wide but not the inline. – Finnusertop (talk ⋅ contribs
  ) 13:44, 4 March 2016 (UTC)
• Oppose Contentious claims about living persons must be removed when they are unsourced and should be removed when they are poorly sourced. Period. Collect (talk) 13:47, 4 March 2016 (UTC)
  • @Collect: I have struck "contentious" from the proposal accordingly. bd2412 T 13:49, 4 March 2016 (UTC)
    • And, amazingly enough, when in doubt, the proper course is to remove unsourced claims from BLPs. No real need to add a new template for the few cases where it might be utile. Collect (talk) 13:51, 4 March 2016 (UTC)
      • But right now you can tag the whole article as containing unreferenced statements with {{BLP sources}}. In order to do this, you necessarily have to find at least one unsourced statement. If you remove this, you need to find another one to tag {{BLP sources}}. When you remove that one, you need to find yet another one... ad infinitum. {{BLP sources}} is practically impossible to use following the logic ("must be immediately removed") presented in this discussion. – Finnusertop (talk ⋅ contribs) 14:00, 4 March 2016 (UTC)
  • NO, they need not be removed; they should, where possible, have sources added. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:35, 4 March 2016 (UTC)

    If you can reliably source them, then fine, go ahead and do that. But if you can't, they should be removed, as stated by Jimbo Wales (talk · contribs) at 20:30, 16 May 2006 (UTC) in [WikiEN-l] Zero information is preferred to misleading or false information. --Redrose64 (talk) 01:03, 5 March 2016 (UTC)

• Oppose as not needed. Non-sourced, non-referenced, and unclear statements in a BLP article should be removed immediately, not tagged, per
  we don't need no stinking templates. GenQuest ^{"Talk to Me"}
  15:53, 4 March 2016 (UTC)
• Do the more sensible thing: The obvious solution to the problem you and Redrose64 want to address is to have a bot populate a cleanup category, by detecting BLPs (by category) that have cn or other dispute (not cleanup) tags on them. You can just go propose that bot on the bot proposals page, and it would probably get unanimous support. The current proposal is a
  Rube Goldberg device approach.  — SMcCandlish ☺ ☏ ¢
   ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  17:56, 4 March 2016 (UTC)
  • I am actually just as concerned with assertions on pages that are not themselves BLPs (for example, uncited statements on the party primary pages that a particular politician endorsed a particular candidate). These should in principle be easy to cite, but a less experienced editor may throw a tag on them anyway. bd2412 T 03:25, 5 March 2016 (UTC)
• Oppose - We already have two templates that are basically already highlighting these kind of issues. Guy1890 (talk) 07:15, 6 March 2016 (UTC)

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

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)

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)

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

• Well, maybe, but we need to establish a re-activation committee via a non-public election process, and then the re-activation committee would need to establish the making new Esperanza pages committee, and we couldn't do this with an
  talk
  ) 02:48, 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)

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)

• Got answers from Debresser, עוד מישהו and kk
  

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

• If the ratio of negative to positive opinions grows by more than two now, please close it up as rejected. CN1 (talk) 02:34, 7 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)

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)

@

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

@

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)

• Support great idea, fills a big need here. --
  talk
  ) 08:45, 5 March 2016 (UTC)
• Worth trying in principle, although if it did become non-constructive as a venue it would have to be closed down. What do any staffers think? BethNaught (talk) 11:32, 7 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)

@

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

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)

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)
  • The template could check for the existence of the appropriate Wikidata properties (see
    talk
    ) 18:59, 3 March 2016 (UTC)
    • For example, Latvian and Norwegian Wikipedia (OK, we (Latvians) simply copied from Norwegians :) ) has template sports external links, which adds some profiles (from Wikidata) to articles. --Edgars2007 (talk/contribs) 08:27, 4 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 {{
  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. @
  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)
  • having five templates when one template would do seems to be an obvious violation of the KISS principle. MartinPoulter (talk) 16:55, 22 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

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. –Davey2010^Talk 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, –Davey2010^Talk 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,
  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

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

• NOTE: I moved this discussion over to
  WP:VPI is apparently the correct place to incubate new ideas. @Fritzmann2002: your comment was moved as well, just fyi. Koala Tea Of Mercy (KTOM's Articulations & Invigilations
  ) 06:38, 24 March 2016 (UTC)

2 proposals

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

banner invite for more info

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

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

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

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

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

   @

   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.
   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. –Davey2010^Talk 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: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.

   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)

   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)

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

• I'll add that this should be way easier to close since PUF actually has daily subpages, making things trackable, unlike NFCR which had squat.
  talk
  ) 04:03, 9 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)

• With regards to the existing backlog, in case it isn't clear - for NFCR, the page was just left open and listed at
  WP:ANRFC, and new requests were directed to FFD by a template. Sunrise (talk
  ) 06:00, 9 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

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.

Pings

Those who commented on Wikipedia talk:Research help. Astinson (WMF) Dirk Beetstra Brigade Piron CFCF Dialectric Roger (Dodger67) Esquivalience Fram Green Hazard Hzh JFW Jytdog Help! Kendall-K1 Kerry KMJKWhite MichaelMaggs MilborneOne Moxy Navyvet2016 NiD.29 Ocaasi (WMF) Pgcudahy Rhododendrites Sadads Steelpillow WhatamIdoing Wugapodes Additional editors from TfD (possible duplicates) theWOLFchild Anotherclown BethNaught Bilorv CFCF clpo13 David Eppstein Dialectric Drmies Garion96 Geogene Hawkeye7 In actu (Guerillero) Izno Jytdog Kierzek KMJKWhite Tom (LT) Martynas Patasius MichaelMaggs Mitch Ames Navyvet2016 Necrothesp Nick Nyttend Ozzie10aaaa Peter (Southwood) RexxS Scolaire Teaktl17 Ed Yaush Yngvadottir Apols if anyone missed.

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

I dug up relevant pages I could find:

• WikiProject_Medicine discussion: Supported.
• WikiProject_Military_history discussion: Supported.
• Village Pump Technical: There was mention of a posting there, but I couldn't find it.
• Bot approval discussion:
  • Approved. 10,000 pages maximum.
  • any further scaling beyond that cap would require Community concensus (referring to Village pump)
• Template for discussion: Heated no consensus. Many 'keeps' were limited to a 1-month test.
• This project's Talk page: mostly complaints.

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
   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.
   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.--
   talk
   ) 17:12, 27 March 2016 (UTC)
4. Oppose, forum shopping after
   [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.

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

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

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

[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

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

[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!

[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

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

I am finally trying to complete a task for which consensus was established 7 years ago - to deal with

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)