Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia:PROPS)
Jump to: navigation, search
  Policy   Technical   Proposals   Idea lab   Miscellaneous  
Shortcuts:

New ideas and proposals are discussed here. Before submitting:

« Older discussions, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129
Centralized discussion
Proposals: policy other Discussions Ideas

Note: inactive discussions, closed or not, should be archived.

New usergroup with autopromotion to implement arbitration "30-500" bans as a page protection[edit]

A few months ago, the Arbitration Committee has decided that some pages subject to intractable disputes, like Gamergate controversy, be forbidden from being edited by users who don't have 30 days of registration and 500 edits. To enforce this, an edit filter was created to disallow edits on some of these pages: Special:AbuseFilter/698, or when not covered by it, these edits can be reverted by other users. Although this system might somewhat reduce the disruption in those areas, it has some significant drawbacks:

  1. Using the edit filter affects performance and is user-unfriendly since the edit button still appears[1]
  2. Users who don't strictly meet the criteria but who, based on their history, are expected to contribute positively in these areas cannot
    Sometimes even the page creator can no longer edit it[2]
  3. Sockpuppets of banned users use this as a justification for reverting[3]
  4. Users who are known, based on their history, to contribute negatively to these areas cannot be prevented from editing them, short of blocking

To resolve these issues, it is proposed to create a usergroup that is autopromoted after 30 days and 500 edits, and a new protection level, so that only users in the new usergroup can edit pages subject to this new protection level. In addition:

  1. Users who don't (yet) meet the autopromotion criteria can be manually promoted by admins when based on their history, they are expected to contribute positively to these areas and no evidence of sockpuppetry exists
  2. Users who meet the autopromotion criteria and were therefore automatically added to the usergroup may be manually removed as an arbitration enforcement action
  3. Pages may be protected by admins with the new level only when a decision of the arbitration committee mandates it (note that standard discretionary sanctions do not include it)

Although this was inspired by ArbCom, this is strictly a community proposal and community consensus is required for these configuration changes. Moreover, the community has repeatedly showed interest in such a system, see for example this recent meta Wishlist Survey. Should it get consensus, I believe that the ArbCom will agree that this system is better than the current one and incorporate it in its rulings. Cenarium (talk) 00:19, 10 January 2016 (UTC)

Also, we can give the userright to edit these pages to bots and sysops, and prevent them from being given automatically the new group which would then be redundant (using APCOND_INGROUPS). We'll have to find a name for the usergroup, and the protection level (maybe 'restricted' ?). For example of configs with autopromoted groups, search $wmgAutopromoteOnceonEdit in InitialiseSettings.php. Cenarium (talk) 10:55, 10 January 2016 (UTC)
Sysops obviously would qualify (aside from a few exceptions), but as many bots wouldn't, we shouldn't manually include them in the group: it would be a big waste of time. Instead, just add it to their rights packages. The bot access level includes such rights as bot, noratelimit, etc., so if someone creates a new 30-500 userright (or whatever it's called), such a right could easily be added to the bot access level. Nyttend (talk) 00:38, 11 January 2016 (UTC)
That's what I meant by 'giving' the userright to them: adding it to their userright package. Cenarium (talk) 06:17, 12 January 2016 (UTC)
Support - as to bots, I think that any bot without enough edits/time to qualify will be added on request by the operator should there be any potential need for the bot to edit these pages; this would probably be relatively few bots. עוד מישהו Od Mishehu 18:42, 11 January 2016 (UTC)
  • Support again. Point of clarification: does "a decision of the arbitration committee mandates it" cover the recent decision in ARBPIA linked above? Ivanvector 🍁 (talk) 19:42, 11 January 2016 (UTC)
    • Protecting an article in the area of dispute would be valid arbitration enforcement. Cenarium (talk) 06:17, 12 January 2016 (UTC)
  • Support superior to the edit filter solution. But I would not support making more and more groups as it would just get confusing. Graeme Bartlett (talk) 22:38, 11 January 2016 (UTC)
  • Support seems like it would be an improvement over the current system. Happy Squirrel (talk) 22:51, 11 January 2016 (UTC)
  • Support - As long as the only pages to receive the 30-500 protection are explicitly specified by ArbCom, this seems superior to the current edit filters. I do not presently support automatically adding this usergroup, perhaps called autotrusted, to the bot usergroup, though I do support adding it to sysop. I would also support a way to add the usergroup upon request in a similar fashion as WP:RFP/C. — Jkudlick tcs 02:06, 12 January 2016 (UTC)
  • Questions - Just curious, should this proposal (which appears to be proposing a form of protection/edit restriction which is higher than semi-protection but lower than full protection) be accepted and implemented, how will its implementation be done? For example: could articles be put under this for long-term periods or indefinitely, similar to semi-protection of articles, or is such an action going to be discouraged, similar to full protection? Can such requests be made at RFPP, or can they only be done via decisions (i.e. ArbCom decisions)? Narutolovehinata5 tccsdnew 05:12, 12 January 2016 (UTC)
    • This can only be done as arbitration enforcement (which has its own requests page), so it must be supported by an ArbCom decision specifically authorizing the "30-500" restriction. Standard discretionary sanctions are not enough, since they only authorize semi, full or move protection. These are likely to be long term or indefinite, as disputes that reach ArbCom are some of the most persistent. Cenarium (talk) 06:17, 12 January 2016 (UTC)
      • Sure, TODAY, but it would not be impossible to adjust the protection policy to allow another step between SPP and FP; nor would it be unheard of to deploy in exceptional situations via WP:IAR, just as PC2 is rarely used. — xaosflux Talk 01:45, 16 January 2016 (UTC)
  • Support. Basically, the idea of having a protection level between semi-protection and full protection is needed to deter sock puppetry, amongst other issues related to new auto confirmed accounts. That, and since pending changes level 2 was not a community-accepted option, this is the next best thing. Steel1943 (talk) 06:57, 12 January 2016 (UTC)
  • Support – Sounds like that would work a lot better than using the edit filter. Graham (talk) 07:35, 12 January 2016 (UTC)
  • Oppose per WP:CREEP. 500 edits seems to be a poor measure of anything and seems trivial to game. So, such use of edit count as a measure should not be encouraged. There seem to be plenty of technical tools already for managing problem pages. Andrew D. (talk) 08:42, 12 January 2016 (UTC)
  • Oppose as the autopromote feature currently appears to be broken, from the last attempt to implement a similar request to this. Mdann52 (talk) 09:38, 12 January 2016 (UTC)
    The autopromote feature is not broken, autoconfirmed works just fine right here on enwiki. Autopromoteonce works just as good on plenty of wikis, e.g. on dewiki. phab:T46587 is a configuration issue, the conditions are way too restrictive. A user was autopromoted on 14 August 2014. Cenarium (talk) 01:02, 15 January 2016 (UTC)
  • Oppose Rather than create a new user group patterning after an edit filter created on an ad hoc basis, let's implement PC2! There is consensus for PC2 to exist but not how to implement. I think this situation is what PC2 envisions. Chris Troutman (talk) 12:10, 12 January 2016 (UTC)
    • Given that the I-P and GG topic areas are populated mainly by entrenched people who have a strong COI on the subject that edit such pages relatively rapidly (which contraindicates PC1, let alone PC2) how the hell would PC2 help? —Jeremy v^_^v Bori! 20:40, 12 January 2016 (UTC)
      • @Jéské Couriano: It doesn't and neither does this proposal. That so many "entrenched people" can't be constrained without ARBCOM intervention is a good thing. This proposal (and my preference for PC2) is meant to limit the sockpuppets and straphangers that coalesce around these discussions. Chris Troutman (talk) 13:22, 16 January 2016 (UTC)
  • Support because "Using the edit filter affects performance and is user-unfriendly since the edit button still appears", assuming it is technically possible to do this given the Phabricator link posted by Mdann52 that I am unable to understand. Bilorv(talk)(c)(e) 16:19, 12 January 2016 (UTC)
    • @Bilorv: This was the last attempt to use the auto-promote feature, and no users were autopromoted by it, seemingly because it was broken nowadays as opposed to misconfiguration. Mdann52 (talk) 12:48, 14 January 2016 (UTC
      • @Mdann52: thanks for the explanation. I had assumed that the autoconfirmed group invoked the same code that this new 30/500 group would, and as far as I knew, autoconfirmed still works fine. Is autoconfirmed handled by something different, or is it functional because it was configured before the problem with autopromotion began, or is there some other key difference? Bilorv(talk)(c)(e) 16:29, 14 January 2016 (UTC)
        • @Bilorv: I believe this is hard-coded into the software using different code - mw:Manual:Autoconfirmed users seems to suggest this too. Mdann52 (talk) 16:55, 14 January 2016 (UTC)
          • Thanks for the reply. I've struck my support based on this. Bilorv(talk)(c)(e) 18:51, 14 January 2016 (UTC)
            • @Mdann52: Both Autopromote (used by autoconfirmed) and Autopromoteonce (what we'll use) use the function recCheckCondition of the Autopromote class. The same checks would be done. @Bilorv: The phabricator task linked by Mdann52 is a configuration issue (see more details above), the underlying core Autopromoteonce mechanism works perfectly. Cenarium (talk) 01:02, 15 January 2016 (UTC)
  • Oppose I want something else first. When a page is protected to prevent autoconfirmed users from editing, they ought to still get instant encouragement to do something. Right now, page protection leads people to a splash page for reading, but not action. The action that is recommended is clicking a button that brings users to a page where they can read about edit requests. This still is not an action. From there, the user is supposed to copy the "edit request" template, go back to the article they want to edit, click "talk", scroll to the bottom, then make their post. This is a burdensome chain of requirements. Instead, if someone is blocked they should get an option to make a suggestion with just one additional click. Until and unless we have better infrastructure for seeking contributions from those who do not pass protection, I do not want more people blocked. It is a Wikipedia ideal that everyone can edit, and I want some kind of allowance made to encourage more useful contributions. I would rather subject people to lots of reverts and rollbacks rather than prohibit them outright from doing anything. That said - if it were easier for people to post suggestions on the talk page, then I would support this proposal. It is a reasonable proposal for a new kind of page protection based around a new userright. Blue Rasberry (talk) 20:15, 12 January 2016 (UTC)
  • Support All of the opposes seem to be saying that we shouldn't protect pages in this way, but we already are via the edit filter. This just improves the existing process. Jackmcbarn (talk) 20:45, 12 January 2016 (UTC)
  • Support the idea, with the obvious caveat as to whether this is technically possible. Questions as to whether this kind of protection is a good idea aren't relevant to the question of whether we should do this, as that decision has been made by other processes. Hut 8.5 22:54, 12 January 2016 (UTC)
  • Support as a big improvement to the existing process. APerson (talk!) 02:32, 13 January 2016 (UTC)
  • Support The 500/30 restriction has already been applied to WP:ARBGG and WP:ARBPIA topics and it has very successful at reducing disruption. One problem is that editors are authorized to engage in silly edit wars and can repeatedly revert edits which don't satisfy 500/30. It would be much better for the software to be enhanced to avoid that turmoil, and to avoid klunky edit filters. Johnuniq (talk) 04:56, 13 January 2016 (UTC)
  • Comment, this seems like it might be better done by upping the rules for autoconfirmed. What requires it to be separate? Adam Cuerden (talk) 14:09, 14 January 2016 (UTC)
    500/30 is only approved for very limited use in areas of extreme and persistent disruption. Simply upping the bar for autoconfirmed would require expanding 500/30 to the entire project. That hasn't been suggested, but considering how difficult it was to gain consensus to use 500/30 even in the most toxic areas, I doubt the community is ready for such a discussion. Ivanvector 🍁 (talk) 19:29, 14 January 2016 (UTC)
  • Support provided that this is technically possible and on condition that the new protection level only be used for arbitration enforcement. BethNaught (talk) 16:32, 14 January 2016 (UTC)
    Qualified support: per Mike V, admins should not be able to add users to this group manually as they would still be banned from 30/500 protected articles by the ArbCom ruling. BethNaught (talk) 20:46, 15 January 2016 (UTC)
    Certainly we could request amendments on those ArbCom cases to change the topic bans exclude this entire group, regardless of how the membership was gained. — xaosflux Talk 01:25, 16 January 2016 (UTC)
    Yes, we should make such a request if it passes. Cenarium (talk) 09:26, 16 January 2016 (UTC)
  • Support I wholeheartedly agree. If we are to go this route, a new user group is naturally the best approach. Edit filters can work without much concern of performance (see 747, 748 and {{pp-30-500}}), but the edit button still being visible is quite editor-unfriendly. The filters are still available as a temporary implementation, should we wish to consider that (full disclosure, I helped implement them :) MusikAnimal talk 18:03, 14 January 2016 (UTC)
  • Support a straightforward way to deal with this problem. Good idea--Tom (LT) (talk) 08:53, 15 January 2016 (UTC)
  • Oppose on one point. I disagree with admins being able to promote a user based upon their own discretion. You either meet the restrictions imposed by the arbitration committee or you don't. The community isn't able to make exceptions to this rule. Mike VTalk 20:37, 15 January 2016 (UTC)
One possible scenario I see for this is a very clearly declared and WP:SOCK#LEGIT alternative account of an established user, the number of edits of which happens to fall short of the requirements. Mz7 (alt) (talk) 01:21, 16 January 2016 (UTC)
What's being proposed is broader than that, though. Users who don't (yet) meet the autopromotion criteria can be manually promoted by admins when based on their history, they are expected to contribute positively to these areas and no evidence of sockpuppetry exists. As it's written, it allows admins to grant this right to whomever on the basis that they're "good contributors". The criteria of being a good contributor is subjective amongst admins. I don't feel comfortable with this part in place. As for alternate accounts, is it necessary? From my experience, not very many users use alternate accounts and this would only apply to a subset of editors who edit restricted pages and whose alternate accounts don't meet the requirements. Even then, is the editing so crucial that it can't wait until they return from their travels, get home from work, leave the library, etc. and just edit from their main account? Mike VTalk 19:55, 16 January 2016 (UTC)
I still think we need the committee as a whole to make an amendment to their findings before we allow administrator discretion. If they do choose to amend it, it would be worth asking if it's easier to just revert the problematic edits of those who don't meet the requirements rather than having to green-light the users deemed responsible. Mike VTalk 19:55, 16 January 2016 (UTC)
  • Oppose I understand the motivations behind this proposal, but I cannot support adding to Wikipedia's policy creep. I have a feeling that the easier it becomes to restrict users from editing an article, the more this restriction will be used (and misused) to "break the back of a dispute". If this proposal passes, which looks very likely, I urge the community to draft a lucid and strict policy regarding this tool. 500/30 should only be used as a last resort, but without strong guidelines policing its use, I predict it will inevitably become part of the standard dispute resolution toolkit. Altamel (talk) 23:41, 15 January 2016 (UTC)
    • The proposal is nothing to do with changing policy, and is not creep. The proposal concerns the method that should be used to implement procedures that are already in place for WP:ARBGG and WP:ARBPIA topics. Currently, it's a free-for-all with the rather silly situation that an edit that contravenes the 500/30 restriction can be reverted without limit. This proposal is suggesting that more sophisticated technical procedures should be implemented to reduce uncertainty and edit warring, and to provide more efficiency than an edit filter. Johnuniq (talk) 02:40, 17 January 2016 (UTC)
  • Support This is something we need for fair enforcement. If arb com wants to use this sanction they will do so. If they do, this is the only effective fair way of enforcing this. (as a personal guess, Arb com would not decide whether or not to use it again, until a suitable case came up. Nor do I know what we would do about manual promotions until someone should ask--I personally would support them) DGG ( talk ) 19:33, 16 January 2016 (UTC)
  • Qualified support. I'm not sure if I see the need for an arbitrary 30/500 level, but given that this is something ArbCom has decided it wants to do anyways, better to implement it properly than use an edit filter. -- King of ♠ 20:24, 16 January 2016 (UTC)
  • Support – will make Arbcom enforcement much easier, and nothing else is likely to come of this new usergroup. --IJBall (contribstalk) 23:47, 17 January 2016 (UTC)
  • Support with the understanding that this would strictly be a means to more easily and fairly enforce relevant arbitration decisions, and not a new form of protection that any administrator could enact on any page. However, per Mike V, allowing administrators to discretionarily promote any account that doesn't meet the requirements would run contrary to the ArbCom's decision. However, I can still see a use for manually promoting accounts that are declared, legitimate alternative accounts of established users who do meet the requirements. Mz7 (alt) (talk) 01:01, 18 January 2016 (UTC)
  • Support with the condition that the protection level may only be added to page as the result of community consensus or by the Arbitration Committee as it has been to the Arab-Israeli conflict (it should not be able to be added by an admin on their own cognisance whether AE or not). Callanecc (talkcontribslogs) 07:45, 18 January 2016 (UTC)
  • Support an edit protection level 'between' semi and full, e.g. where only editors can edit with a 'given' right can edit (including a sensible new right that allows then for that). At the same, I would advocate that we have the possibility to remove the 'autoconfirmed' from editors who have shown that they can not be trusted .. yet. It is fine that it is used for Arbitration sanctions, but I would also support it if it would be used outside of that restriction. --Dirk Beetstra T C 09:24, 18 January 2016 (UTC)
  • Support - the more automated the better and per Callanecc above,  Roger Davies talk 10:12, 18 January 2016 (UTC)
  • Qualified support - I strongly oppose a new protection level, and support this proposal only as a more user-friendly way than the edit filter to implement ArbCom's decisions. Accordingly, it must be made immensely clear that this protection level can only be imposed by ArbCom decision. A2soup (talk) 02:36, 19 January 2016 (UTC)
  • Support — it's simply the right technical answer in this instance, regardless of one's opinion on whether a 30-500 "tier" is ideal. I had actually started looking into dealing with implementing some edit filters related to the 30/500 ARBPIA sanction last month (when I had more time) and came to the conclusion that while it was possible to do without a new usergroup, it would be a kludge that would have required either explicitly listing all pages covered by a topic (e.g., the gamergate filter) or dealing with magic templates/categories that can only be added or removed by admins. Neither are the right technical answer, because we shouldn't be bending over backwards when there's already a clear, simple answer built into the software. Of course, from a policy standpoint, it's probably a good idea, as Callanecc and others mention, to restrict its use to an otherwise-case-by-case-consensus basis (and, as is obviously the case with ARBPIA, existing ARB directive). --slakrtalk / 07:53, 20 January 2016 (UTC)
    ...however in contrast to Callanecc, I feel that it actually should be up to an admin to add it on their own cognisance so long as it's within those specific topic areas (or otherwise has clear consensus) and it's not done in bulk (i.e., it should be in response to an issue that's arisen on a page). I mainly say this because when one inevitably pops up on WP:AN3 that's ideally solvable with this form of protection, I'm almost certainly not going to jump through the hoops of extra consensus-building and request-filing; either I can quickly add protection, log the remedy, and move on to the next report, or I'm simply going to keep scrolling and/or use something less effective and let someone else deal with it if they really want. :P Granted, this is just me talking, but I have a feeling that the sentiment will be similarly shared by other admins strapped for time who otherwise avoid ARB venues like the plague. --slakrtalk / 08:17, 20 January 2016 (UTC)
  • Comment As far as I know, any potential edit by anyone (including IPs) can always be taken to the talk page before being made to the article. Without this proposal, it would be simple enough for an editor who could not edit an article directly under this provision to just go to the talk page, say, "I'm not at the "30-500" level yet but I found this interesting, encyclopedic, neutral, and well-sourced fact about this page. Can someone else add it in?" followed by the proposed edit. Typos, grammar issues, and the like can be done the same way. The talk pages of protected articles have lots of this stuff. The main thing would be making it clear when someone is stopped from editing it what is happening, but something parallel to one of the current protection schemes should work. This isn't so much "support" as Not Opposed. Wabbott9 Tell me about it.... 20:15, 21 January 2016 (UTC)
  • Support creating a new userright and assigning it to a new usergroup (plus sysop and bot if needed) and a new protection level corresponding to the new userright to enforce a 30-500 editing restriction. It is far better than using the non-editor-friendly edit filter to enforce this. $wgAutopromoteOnce should be used to add users to this new group. sysop should be given the technical ability to promote and demote users from this group. Policy should require that admins only promote legitimate alternative accounts of users already in this group to this group. (A user's editing history should not be used as justification for promotion when the user does not meet the requirements.) In addition, since use of the new protection level must be mandated by ArbCom, only ArbCom decision and WP:AE should result in demotion from this group. For those that are demoted, there should be a defined method of being promoted again. — JJMC89(T·C) 02:52, 25 January 2016 (UTC)
  • Conditional support if as mentioned by others "that the protection level may only be added to a page as the result of community consensus or by the Arbitration Committee". Also would be nice to have an "suggest button" that brings people to the talk page with an explanation on how they can suggest changes as mentioned by BlueRasberry. Doc James (talk · contribs · email) 16:25, 25 January 2016 (UTC)
  • Oppose for now. The thresholds being used for these restrictions are essentially arbitrary, and we don't have a strong evidence base yet that they are well-chosen. Implementing this as an edit filter is a kludge, but it has the advantage of being obviously so; it's a desperate measure taken as a limited-deployment experiment. Doing this at the software level artificially ossifies these choices before we've actually finished and evaluated the experiment. In any future userright implementation, I'm not too fussed about admins adding the right to legit alts and such, but I would strongly prefer that the right cannot be removed by individual admins - unbundling has already resulted in the routine wiki-activities of many users becoming much more exposed than it used to be to the vicissitudes of "admin discretion", and this would be way too much of a drama magnet. Opabinia regalis (talk) 23:37, 25 January 2016 (UTC)
  • Support but prefer PC2. Stifle (talk) 16:51, 26 January 2016 (UTC)
  • Support this and PC2 for areas with lots of minor disruption. 96.237.20.21 (talk) 20:52, 3 February 2016 (UTC)
  • Oppose it is the right technical answer, but a bad precedent and it doesn't solve much of anything. See the verse on my user page for an explanation of my concerns. I think this will put us yet further on the path to shrinking the number of editors as this "you must be this tall to edit" set of restrictions creeps outward over the years. Hobit (talk) 03:19, 5 February 2016 (UTC)
  • Support from a technical perspective; if we're going to do this, this is obviously the right way to do it. I think that some of the concerns people have raised above about potentially using this sort of restriction too frequently are well-founded, but we are using it in several places already, and it seems silly to do it in a confusing, technically-inefficient way. This discussion isn't really the place to focus on whether or not using the 30-500 restriction itself is a good thing. --Aquillion (talk) 05:43, 5 February 2016 (UTC)

Disabling Gather?[edit]

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

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

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

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

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

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

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

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

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

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

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

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

Some positive comments[edit]

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?[edit]

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

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

Conclusion[edit]

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

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

A WMF reply next week[edit]

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

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

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

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

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

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

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

RfC now started[edit]

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

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

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

Legal issues[edit]

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

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

A Response from the WMF[edit]

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

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

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

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

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

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

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

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

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

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

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

Darker section titles in page history[edit]

Granted, I could use a new glasses prescription, but these titles are always a bit hard to read. A minor thing to many (especially those whose glasses prescriptions are just fine), but it's an easy fix too.

PROPOSAL: Make the section titles in page history darker, while remaining distinguishable from the remainder of the edit summary.

  • Current: all text italic, section title #808080
    (→‎Submitting someone else's CHU request: Origin of this request)
  • Option 1: all text italic, section title #707070
    (→‎Submitting someone else's CHU request: Origin of this request)
  • Option 2: all text italic, section title #606060
    (→‎Submitting someone else's CHU request: Origin of this request)
  • Option 4: all text italic, section title #585858
    (→‎Submitting someone else's CHU request: Origin of this request)
  • Option 3: all text italic, section title #505050
    (→‎Submitting someone else's CHU request: Origin of this request)
  • Option 5: section title italic #585858, comment roman
    (→‎Submitting someone else's CHU request: Origin of this request)
  • Option 6: section title: light, comment italic
    (→Submitting someone else's CHU request: Origin of this request)
  • Option 7: section title: roman #585858, comment: italic
    (→Submitting someone else's CHU request: Origin of this request)

Option 4 was added later by another editor, and is halfway between 2 and 3 in darkness. Options 1–4 are shown in ascending darkness sequence.

Mandruss  08:44, 24 January 2016 (UTC)

I added option 6 and switched everything to use html code closer to what actually shows up in history list and added comments describing the options. PaleAqua (talk) 20:51, 31 January 2016 (UTC)
  • NOTE - I found that the differences are more noticeable if you (1) apply a user CSS change from the collapsed table below and (2) look at actual page history pages. I recommend doing that and trying the change in actual use for awhile. ―Mandruss  11:01, 25 January 2016 (UTC)
  • Support 2 Support 1 Support 5 Support 6 Support 7 as proposer. Consider it an accessibility issue. ―Mandruss  08:44, 24 January 2016 (UTC)
  • Any particular color that you think would contrast well with the black of the edit summary-proper? --Izno (talk) 18:43, 24 January 2016 (UTC)
    @Izno: If someone could tell me the hex triplets for the existing two colors, I could play with it and make the proposal more specific, with color samples—if it hasn't snowed before then. ―Mandruss  01:36, 25 January 2016 (UTC)
    The grey is currently #808080 and the dark grey is #252525, according to my console (user error may apply). --Izno (talk) 01:46, 25 January 2016 (UTC)
    I made the proposal more specific. ―Mandruss  02:28, 25 January 2016 (UTC)
    Hi Mandruss, Maybe it has been asked and answered but whey are one to five in italics but 6 is regular? And, I see 6 as being a speck darker now that the sun is going down. Cheers! {{u|Checkingfax}} {Talk} 23:48, 31 January 2016 (UTC)
    @Checkingfax: It was proposed below (quite rightly in my opinion) that a switch in font, between italic and roman (regular), is at least as noticeable as a difference in darkness, so new options were added for that. Both 5 and 6 include such a switch. And there's a possibility of a 7 that would be the same as 6 but with a lighter (less dark) section title. The third line of my current css, User:Mandruss/common.css, shows how to test such an Option 7. ―Mandruss  23:56, 31 January 2016 (UTC)
  • Comment Note that the class of the element is autocomment. So if you edited your common.css style sheet you could change the color for your account. For example:.autocomment { color: #606060; } would change it to your choice 2 above. PaleAqua (talk) 05:27, 25 January 2016 (UTC)
    Tell ya what ... if this proposal fails, I'll assume I'm the only one who has the problem or ever will, and I'll try your suggestion. For now I'm assuming I'm not so unique, and I'm interested in the overall welfare of the project, not just myself. I've found many people have trouble grasping that concept, but I can't help it. I also hope this, while providing some benefit for some people, is so inconsequential as to stand a chance of passing, so I can experience that joy just once in my Wikipedia career. ―Mandruss  05:37, 25 January 2016 (UTC)
    I actually think this has a good chance. 808080 is kinda light for accessibility as Earwig points out below. But it's nice to be able to test out different values as well as pick a personal setting if those end up different. It also may be some time before anything changes so if it's an improvement for you now why wait? While I supported a higher contrast grey below its likely that I would personally use a lighter color for my own CSS. I heavily tweak the appearance of the watchlist and history to make it easier for me to history drive. PaleAqua (talk) 13:51, 25 January 2016 (UTC)
    PaleAqua, I don't see the autocomment in my User:Checkingfax/common.css file; there is nothing even close to that. Please advise. Cheers! {{u|Checkingfax}} {Talk} 23:33, 31 January 2016 (UTC)
    Wouldn't be there if you hadn't added it yet. common.css is for overriding the default Wikipedia appearance. PaleAqua (talk) 00:18, 1 February 2016 (UTC)
  • This is actually more supported by policy than you might have realized... WP:COLOR (part of WP:ACCESSIBILITY) requires a minimum contrast ratio between text foreground and background colors. The existing combination is actually not compliant; it doesn't even reach the minimum of AA. A good compromise that reaches the recommended AAA level is #585858, which is exactly halfway between #2 and #3 above, so I'll add it below as #4 and support it. If not, any of 1–3 are at least AA-compliant. — Earwig talk 07:34, 25 January 2016 (UTC)
  • While I couldn't see any difference between the different options until I zoomed in, Earwig makes a good argument for changing the colour for accessibility reasons. If this is indeed the case, however, I'd have thought that this should be a central change rather than simply changing it locally. Regardless, I support a change that's WP:COLOR compliant, however it's done. Sam Walton (talk) 08:09, 25 January 2016 (UTC)
  • Comment - All other displays of edit summaries appear to use the same class "autocomment", so I assume this would automatically extend to them as well. This includes contribs and watchlist. This is probably a desirable thing, but it should be stated since I didn't do it in the opening. ―Mandruss  09:20, 25 January 2016 (UTC)
  • Comment - See my new NOTE above. ―Mandruss  11:01, 25 January 2016 (UTC)
  • Support preference towards #4#5#6 (edit switched to #7) but anything that increases the contrast enough should work. PaleAqua (talk) 13:51, 25 January 2016 (UTC)
    • Switched to #7. Would prefer #6 but that doesn't seem to work in all cases. If there was a way to use just lighter ( inheriting #252525 ) in browsers that supported it and fallback to #585858 in other browsers that would be my ultimate choice. But again I support anything that meets accessibility requirements and keeps a visual distinction between the section text and the rest of the comment. PaleAqua (talk) 00:21, 1 February 2016 (UTC)
  • Support 4, per Earwig and SamWalton. Rehman 14:33, 25 January 2016 (UTC)
  • Comment - I urge anyone !voting 3 or 4 to try it in actual use for awhile. Does it always provide enough contrast between the section title and the rest of the editsum? Or do you sometimes have a little trouble seeing where one ends and the other begins? I don't wish to solve one problem and create another. ―Mandruss  00:34, 26 January 2016 (UTC)
    Trying the setting out on my alt account which I use for UI checks as it doesn't have any other setting / UI tweaks from the default. FWIW, seems to work well enough at least with my glasses and monitor. Note that in addition to the brightness difference the autocomment text is obliqued / italicized compared roman for the rest of the comment. PaleAqua (talk) 01:38, 26 January 2016 (UTC)
    @PaleAqua: I'm seeing italics for the whole thing, and always have. ―Mandruss  01:43, 26 January 2016 (UTC)
    You're right. The letters are slightly oblique on my alt account—sans-serif maps to Helvetica on this computer. Probably best to have at least two differences between the text segments. shade/tone is one difference. Changing the hue, face, font size or thickness might be another. I'd actually prefer if both text were black and it was just a font weight difference as that is the effect that the lighter text is emulating. color (#585858) (→‎Submitting someone else's CHU request: Origin of this request) vs weight (lighter) (→‎Submitting someone else's CHU request: Origin of this request). Doesn't look like weight renders properly which doesn't surprise me as it requires a font with a thin or ultra-thin weight. Edit: Works if I specify the font family (Helvetica, Arial, sans-serif) which is similar to what Wikipedia uses: color (#585858) (→‎Submitting someone else's CHU request: Origin of this request) vs weight (lighter) (→‎Submitting someone else's CHU request: Origin of this request) But not sure how reliable that would be still. PaleAqua (talk) 02:18, 26 January 2016 (UTC)
    @PaleAqua: #585858 with switch to roman: (→‎Submitting someone else's CHU request: Origin of this request) - A very noticeable difference that makes #585858 more acceptable. But there doesn't appear to be an easy way to test that, I can't readily see how that change would be implemented from looking at the HTML, and in any case I'm not sure what to do at this point with respect to the proposal. In hindsight, this probably should have been at WP:VPI first, although that page doesn't get much attention. ―Mandruss  02:31, 26 January 2016 (UTC)
    I very much appreciate the switch from italics to straight letters, above. To extract a bit more of the HTML, <span class="comment">(<a href="#FOO"></a><span dir="auto"><span class="autocomment">BAR: </span> FOOBAR</span>)</span>. I think there probably is a way for CSS to take care of this, since FOOBAR is outside the span for italics. #comment should inherit rather than italicize, while #autocomment should italicize. @Edokter: Do you think that would work re specificity (I suppose that's a case of checking the core css?). --Izno (talk) 12:43, 29 January 2016 (UTC)
    Izno, it will work so long you match the original selectors: span.comment {font-style: inherit;} and .autocomment {font-style: italic;}. But I do believe the core issue should be fixed in MediaWiki instead. -- [[User:Edokter]] {{talk}} 21:57, 30 January 2016 (UTC)
    Agreed, but it's usually good to drum up consensus (however small) prior. --Izno (talk) 23:46, 30 January 2016 (UTC)
    Added Option 5. Updating common.css with those two statements and .autocomment { color: #585858; } appears to produce Option 5. The change is fairly dramatic, but I guess that's the point. I changed my !vote. ―Mandruss  13:45, 31 January 2016 (UTC)
  • I will support option 5 per my comments above. @PaleAqua, Rehman, and The Earwig: Do you still support option 4? --Izno (talk) 16:19, 31 January 2016 (UTC)
    Fix ping @Samwalton9:. --Izno (talk) 16:21, 31 January 2016 (UTC)
    I'm not convinced I understand what's changed for option 5, but per my previous comment I support any change that's agreed to be an accessibility improvement. Sam Walton (talk) 16:36, 31 January 2016 (UTC)
    Right, you didn't actually pick an option in your original opinion. Woops. --Izno (talk) 16:51, 31 January 2016 (UTC)
    Updated support especially as I commented above that having two differences makes the distinction clearer. Having played around a bit with "font-weight: lighter;" I'm more of the opinion that it would be a better choice then using a shade of grey. The problem I had with testing earlier seems mostly to be due to the fact that I had customized my body text to a font that doesn't support lighter. The lighter text doesn't look as blurry as the grey text does—consider the impact of using grey on sub pixel rendering etc—and still has a similar contrast to the rest of the comment. With the change of font styles also even for computers that don't render lighter the difference should be clear. PaleAqua (talk) 17:04, 31 January 2016 (UTC)
    Hm, I'm not so sure about that. I definitely see what you're going for, but AFAICT the italics are not an accessibility issue. Is it only so the autocomment remains clearly differentiated? I'm not in love with the look of roman text for edit summaries, but I can live with it if that's what people decide on. — Earwig talk 19:31, 31 January 2016 (UTC)
    To really get into the bike shed I think I might have the section link be roman and the rest of the comments remain italics. Means the comment the the editor wrote is the only thing in italics... everything else including the name of the section which might have been named by other editor is is roman. It also means that there would be no change to history entries that didn't have section links. PaleAqua (talk) 20:26, 31 January 2016 (UTC) (edit conflict) Edit: added option #6 to explain what I'm thinking and switched my !vote to that. PaleAqua (talk) 20:51, 31 January 2016 (UTC)
    Not bikeshed at all. I'm for doing the absolute best we can, even if it means ten options or starting over with a fresh proposal. Most editors look at this so much that seemingly insignificant improvements add up to something very substantial. ―Mandruss  20:42, 31 January 2016 (UTC)
    Was more worried that I was getting close to bike shedding myself. Does the font-weight: lighter work for you? Seems to work on all my browsers once I switched the class of the text to more like what would be on a history page instead of inheriting body text customizations. PaleAqua (talk) 20:56, 31 January 2016 (UTC)
    Was more worried that I was getting close to bike shedding myself. - So I took it, and I'm saying you're not.
    Does the font-weight: lighter work for you? - Um I guess so, I don't see a difference between first half of 6 and last half of 5. They both look like this here text to me. Firefox 44 with Vector. ―Mandruss  21:08, 31 January 2016 (UTC)
    This ( or this logged out without my CSS styles) is what I'm seeing. PaleAqua (talk) 21:24, 31 January 2016 (UTC)
    I'm seeing something close to your second example, but I can't see that weight difference on this page no matter how hard I look at it. Care to do me a favor and update User:Mandruss/common.css for Option 6? Can't figure that out. ―Mandruss  21:38, 31 January 2016 (UTC)
    (edit conflict) I can't update your css file ( user css and js files are protected from other editors ), but you can try something like:.autocomment { font-weight: lighter; font-style: normal;} in place of the 3 lines you currently have at the end of your config. You can switch lighter to normal and back to see the effect that it makes. PaleAqua (talk) 21:49, 31 January 2016 (UTC)
    No detectable difference between lighter and normal, and I put the two in separate tabs and toggled between them. And I added color 585858, since I feel we still need some color difference between the two halves. The more I look at that (see User:Mandruss/common.css if you're thoroughly confused by now), the more I like it. Option 7? ―Mandruss  22:15, 31 January 2016 (UTC)
    I forgot to do include an override of the color in that css bit... should have been: .autocomment { color: #252525; font-weight: lighter; font-style: normal;} but it sounds like lighter isn't working for you which is what I was afraid off. The difference between lighter and normal, should sort of be the difference between normal and bold. For example the lighter and #585858 options on this page look almost identical to me, but the version using 585858 has blurrier letters. But I'm guessing that normal and lighter look the same in your browser. Guessing Arial Light and/or Helvetica Light are not standard across all computers. I would support such an option 7, added above. PaleAqua (talk) 00:18, 1 February 2016 (UTC)
  • Oppose – any change because it makes absolutely zero difference on any of my computers. I tried full zoom, a magnifying glass, and I got zip, no hay nada. Cheers! {{u|Checkingfax}} {Talk} 21:46, 31 January 2016 (UTC)
    Why would one oppose a change that has no effect on them? ―Mandruss  21:47, 31 January 2016 (UTC)
    Because the implementers have tasks on their plates already that have been on their plates for four years and still need to get cleared out first. That is why. Cheers! {{u|Checkingfax}} {Talk} 23:37, 31 January 2016 (UTC)
    This task would take about 10 minutes to implement, not the hours or days most tasks take. --Izno (talk) 23:38, 31 January 2016 (UTC)
    I might be wrong, but I believe this change can be made locally, for all accounts, by any admin willing to edit MediaWiki:common.css. User:PrimeHunter, User:Cenarium, User:Harej, and of course User:Edokter would all be reasonable people to talk to about this. WhatamIdoing (talk) 18:48, 2 February 2016 (UTC)
    You are correct. However, Edokter above said, and I agreed with him on the point, that this change should be made in core rather than locally, since the accessibility problems impact all wikis and not just our own. --Izno (talk) 19:15, 2 February 2016 (UTC)
    Core means WMF? ―Mandruss  19:19, 2 February 2016 (UTC)
    Core means "MediaWiki software" rather than "en.wp style sheets". --Izno (talk) 21:10, 2 February 2016 (UTC)
    Core means a dev; there are more volunteer devs than WMF devs, but the WMF devs are likely to be involved (at least in approving the change). Also, doing it in core means that all future MediaWiki wikis would benefit (e.g., private wikis, too). WhatamIdoing (talk) 06:52, 3 February 2016 (UTC)
    Yeah, just wondering about political ramifications. Other wikis saying, we agree there's an accessibility issue, but we weren't involved in choosing the best solution to it and we don't appreciate having the choice forced down our throat, yada yada yada, ten people astutely offer ten better solutions, which have to be debated until the whole thing really does become a case of bikeshed, and a simple change mutates into Flow Jr. But I'll defer to y'all's vastly superior experience. ―Mandruss  06:58, 3 February 2016 (UTC)
  • Support options 4 or 5. When working on a laptop in bright light, option six is very difficult to read, and option seven is indistinguishable from the plain black text. Five is also pretty close to black in those conditions, but at least the italics separate it. Grutness...wha? 22:27, 2 February 2016 (UTC)
    @Grutness: Thanks for returning the favor! See my NOTE near the top. I really think folks should try out some options in actual use for awhile before !voting (unless they want to agree with my !vote (7), in which case that's less important ;). The samples at the top are NOT good predictors of the actual experience. By "awhile" I mean like a day or two of heavy use, since a lot seems to depend on the many variations in edit summaries. ―Mandruss  07:14, 3 February 2016 (UTC)
  • I started a collapsed table of the required CSS near the top. PaleAqua, Izno (or anyone), I'm not sure of the CSS for 5 and 6, could you add them? ―Mandruss  07:43, 3 February 2016 (UTC)
    Thanks, Izno. I cleaned it up a bit (I think). Isn't span.comment { font-style: italic; } superfluous in 6?
    Also the CSS editor gives an error, Element (span.comment) is overqualified. ―Mandruss  13:16, 3 February 2016 (UTC)
    That just means you can safely remove the "span" from the "span.comment". "Over-qualification" means you have made the selector too specific, which down the road can cause minor issues when you go to override the CSS through some other means. --Izno (talk) 13:41, 3 February 2016 (UTC)
    Sounds like we're better off without it than with it, then, and I'm removing the "span". Revert me if you disagree. ―Mandruss  13:44, 3 February 2016 (UTC)
    Reinstated. Your CSS editor has no clue what it is overriding; without the 'span.' the rule has no effect. -- [[User:Edokter]] {{talk}} 17:01, 3 February 2016 (UTC)
  • Comment: I've filed a task at T125657 on phabricator regarding a change to core. --Izno (talk) 13:41, 3 February 2016 (UTC)

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

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)

RfC: Disable Gather on enwiki[edit]

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

Background[edit]

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

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

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

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

Discussion[edit]

  • Support disabling until 2nd RfC - Gather seems really interesting and a promising concept, but the enabling here without much discussion isn't welcomed. If there was a wide discussion we wouldn't be having the issues with admins not being able to moderate through lack of tools, and it's likely more people would get involved in testing and bug reporting, reducing the current buggy behavior -- samtar whisper 15:48, 26 January 2016 (UTC)
  • Support disabling until proper moderation tools exist and the image issues have been addressed. Once Gather fits into Wikipedia, I do not mind trying to use it to attract users. —Kusma (t·c) 16:00, 26 January 2016 (UTC)
  • Support disabling There are far too many problems, not least the non-free images and lack of moderation tools. Apparently inappropriate lists cannot even be deleted. BethNaught (talk) 16:08, 26 January 2016 (UTC)
  • Disable due to the urgent copyright and moderation issues brought up at VPR, as well as the lack of consensus for enabling the tool in the first place. --Regards, James(talk/contribs) 16:18, 26 January 2016 (UTC)
  • Disable. There are plenty of smaller wikis to test this type of faff with. Stifle (talk) 16:58, 26 January 2016 (UTC)
  • Disable The developers are of course free to start an RfC to propose re-enabling Gather after the problems have been fixed. —Ruud 17:00, 26 January 2016 (UTC)
  • Disable ... unless Wikipedia is now social media (which seems to be akin to what "Gather" allows.) Last I checked, this was an encyclopedia. Would it be crazy to call Gather a WP:NOTWIKIA violation? ... Because I think it is a violation. Steel1943 (talk) 17:31, 26 January 2016 (UTC)
  • Support - If the project is suspended at WMF, and the trial period on enwiki has long expired, then disabling Gather is the proper thing to do until the community supports another trial. — Jkudlick • t • c • s 17:38, 26 January 2016 (UTC)
  • Support disabling, and do it immediately. Among the example links Fram pointed out above, at least one was a blatant BLP violation (a sexually-themed attack against a named person, almost certainly a minor, evidently designed as a tool for cyberbullying them). Evidently, nobody at the foundation has been overseeing this kind of abuse, and our community has made it clear we don't wish to take on this task. In this case, I've gone ahead and "hid" it nevertheless – and now I have no idea how to document what I did, or whether it's really gone in those places where it's been used, or whether the creator can still see and use it, or how I could link to it if it ever were necessary, or whether and how somebody could revert the hiding; there's no reason in the log entry, nothing; it's all a mess. Fut.Perf. 17:53, 26 January 2016 (UTC)
    Future Perfect at Sunrise: There is an entry in your log, but I can't access it and can't see what you did. Are you able to undo your hiding or is even that impossible? —Kusma (t·c) 20:32, 26 January 2016 (UTC)
    (Non-sysop here) Nothing on my end either. Just an error message, nothing more.Jo-Jo Eumerus (talk, contributions) 20:36, 26 January 2016 (UTC)
    (Sysop here). I get an error, "Error - Page not found. The page you are looking for could not be found." So it seems that if someone hid a page by mistake, we are not able to undo that mistake either (or even check whether it was a mistake or not). Note that in this case, it definitely wasn't a mistake but a long overdue action. But if I now wanted to e.g. address the editor who made that page, I have a problem: I can no longer see who created it... Note also that FPaS did (correctly) block the editor involved, but he is blocked for creating attack pages while he has no contributions and no deleted contributions. So admin accountability here is now zero, and we can block anyone who created gather lists with impunity. Fram (talk) 20:53, 26 January 2016 (UTC)
  • Immediate Disable For all of the reasons mentioned above - copyright / WP:NFCC violations justifying immediately disabling the feature. This is nearly a hidden feature which is not subject to community oversight, depending on how lists are put together they can violate core policies like NPOV and BLP because of how elements of the lists are juxtaposed ie grouping crimes, criminals and some recently accused person together. If this feature is kept and the community is not able to manage, edit and delete these lists we should simply point out to anyone complaining about a Gather list that the WMF has not provided that ability, they were advised of the potential harm to individuals and ignored that advice and give them the address of WMF Legal to sort it out. JbhTalk 18:13, 26 January 2016 (UTC)
  • I'm going to go out on a limb here, and oppose disabling. I've looked at and explored Gather a little bit (not much), and I've read the discussions above. I think that with Gather (and the also hotly opposed related articles feature - which is one thing I think should be removed), the WMF is attempting to provide tools that will be of service to Wikipedia's readers, instead of the editors. Several comments in the recent m:2015 Community Wishlist Survey involved things like being able to save pages for future reading, improved watchlists, etc. Readers in this day and age expect to be able to easily share content with others; whether through facebook, twitter, pintrest, etc. Wikipedia's early 2000s design doesn't make that easy. Gather seems to act as the equivalent of a pintrest board where people can group articles they'd like to read, articles on topics that interest them, etc. and share them with others. It seems like fundamentally a good idea to improve the reader experience. Right now it's in beta and there are some hoops to jump through to opt into testing it; it's not particularly visible to most people. There are definitely issues and problems with it; as there always is with software in beta testing. That's why it needs to be tested. It does not make sense to, as someone above me said, test it on the smaller wikis, because they have fewer readers, fewer mobile readers (which is what this is geared towards), and won't provide a good test. It makes sense to test it, as they are doing, as an opt-in feature on the largest wiki, which gets the most mobile traffic. I say leave it enabled, and let the WMF do their job of developing useful software tools for both the editors and the readers we are all here to serve. ~ ONUnicorn(Talk|Contribs)problem solving 18:34, 26 January 2016 (UTC)
    That's the thing, though—I agree in principle that this is a useful avenue to explore, but as it stands, Gather needs a ton of improvement to even be in a state where we can safely test it; despite being opt-in (in some sense) the problematic collections are publicly visible to everyone. If the WMF has indeed suspended development, why should we keep around another piece of broken software they don't seem interested in working on? — Earwig talk 18:39, 26 January 2016 (UTC)
    Yeah, I think most of the people here like the idea of this tool. And in a perfect world this would be a fine tool. But the problem is that the world is not. Once you allow people to create public content they will find ways to abuse this ability. The developers don't seem to have taken this into account at any point. And as a result there isn't a plan in place to deal with this. And it's also not clear how to create such a plan, as nobody seems to be interested in moderating all these lists. —Ruud 18:55, 26 January 2016 (UTC)
  • Support, due to the poor implementation and copyright/moderation issues. We really need to improve the watchlist and books systems, but I don't think this is the way to do it. — Earwig talk 18:39, 26 January 2016 (UTC)
  • Disable. Nice idea, and unlike lots of new ideas that don't work well, this one doesn't actively cause problems, but it doesn't have the expected benefits either. No reason not to restore it once the problems are fixed, but no reason to keep it until the problems are fixed. Nyttend (talk) 19:08, 26 January 2016 (UTC)
  • Support disabling. Note: I would consider setting all collections as owner-visible-only to be an reasonable temporary way to minimize disruption while we sort out whether this project should be re-enabled or permanently removed.
    • There was zero community input on developing this project. I hope that in the future the WMF will invite input before building and deploying new projects.
    • I don't have a link but somewhere I saw the WMF say something to the effect that they like to build mobile-only deployments because it avoids scrutiny and objections from the (primarily desktop) the editing Community. I consider that troubling in itself. If we keep this it obviously shouldn't be mobile-only.
    • When this project was announced, the consensus at Administrator's Noticeboard was that this content generally falls under our speedy delete criteria, that it was unwanted, and that if the WMF wanted it then they could do all the work of policing it because admins wouldn't. I don't think anyone considered that a viable path forwards, but the deployment was mishandled in such an offensive manner that the hasty informal consensus was "screw you, if you want it then you can keep it and police it yourself".
    • NOTSOCIALNETWORK aka NOTWEBHOST. Substantially all of this content falls under speedy delete criteria U5.
      Pages in userspace consisting of writings, information, discussions, and/or activities not closely related to Wikipedia's goals, where the owner has made few or no edits outside of user pages, with the exception of plausible drafts and pages adhering to Wikipedia:User pages#What may I have in my user pages?.
    This is content "owned" by individuals and the community shouldn't be working to police individual's content. We shouldn't be reviewing an individuals' list of their favorite bands, we shouldn't be reviewing an individual's list of alleged pedophiles. We shouldn't be passing judgement on whether to censor individual's offensive political-attack because we deem it too offensive.
    • That Admin Noticeboard consensus should have sent up a giant redflag that they need to stop and have a WMF-Community discussion. I repeatedly asked the Community Liaison to constructively engage the Gather issue with the community. I tried asking the Project Manager. I asked the Executive Director. I asked a half dozen times, trying to organize some sort of collaborative WMF-Community RFC. The question was literally ignored every time, the the WMF engagement model is to disregard the possibility of turning it off, to allow individuals to drop upgrade-ideas in the suggestion box, and to avoid acknowledging Community Consensus as a topic. I regret not filing this RFC myself back then, but pressing real life issues took precedence. I hope that in the future the WMF will be more willing to collaborate on an RFC when there's an obvious issue that needs to be discussed.
    • The devs built something that "works", but failed to fulfill basic necessary requirements (moderation tools noted above). Last I checked Gather did not show up in a user's contribution history or anywhere else. If an editor is caught making abusive article edits there's no reasonable way to see that they have Gather collections that need to be checked for abuse.
    • As noted above, non-free images are being misused.
    • When this was deployed, the WMF announced that it was our "responsibility" to write a policy for acceptable-collections and to do the labor to police it. There's still no policy on it, and at minimum we need to decide that we do want to create said policy before this is re-enabled. Alsee (talk) 19:25, 26 January 2016 (UTC)
  • Support disabling until BLP/NFCC issues have been properly dealt with. --SarekOfVulcan (talk) 21:05, 26 January 2016 (UTC)
  • Disable – Not of any use to Wikipedia, an example of what Wikipedia is not, and a compromise of our integrity as an encylopaedia. RGloucester 21:24, 26 January 2016 (UTC)
  • Support disabling. Perhaps there could be a public discussion about the goals of that feature (the needs that it aims to address) and how to best reach them. Browsing the existing collections, I see the following kinds:
    • Empty or near-empty: not desirable.
    • Purely self-promotional: not desirable.
    • Thematic (e.g. “American art”): better addressed by curated thematic portals and bottom-of-article infoboxes.
    • Topical (e.g. “Maureen O'Hara”): better addressed by hyperlinks and “see also” sections in articles.
    • Personal interest or workspace (e.g. “kimounkimsovan…”): I’m not sure who’d be interested in such a totally-random and disorganised list of links. In any case, it probably belongs to a user page or, better, a personal web site outside Wikipedia.
The non-empty collections are a mumbo-jumbo of pictures and links, presented in a seemingly incoherent order. For passing the time, one could just as well use the “random page tool. As a personal “to-read list” (possibly shared, for a project), an organised list on a user page is infinitely more effective. For thematic focus with a “coffee-table book” look (i.e., picture-driven, with links to articles from the encyclopedia), well, perhaps Wikibooks could host something like that. Overall, I feel sorry that resources were spent on this.
—- Wlgrin 02:43, 27 January 2016 (UTC)
  • Disable with prejudice. The deployment and development of this extension shows nothing but contempt for both the encyclopedia and the editing community on part of the WMF. Alsee has the story behind this mostly correct except the WMF were challenged about the lack of benefit to the encyclopedia and warned about conscripting us to moderate the junk a month prior to that AN discussion. That the community liaison is still way out of her depth and refuses to act on or even listen to our concerns nine months later says everything you need to know about the managers of this exercise in wasting donor money. The justification regarding user watchlists above is ludicrous -- I was the one who proposed them at the Community Wishlist Survey, and no, Gather is not even remotely acceptable for that (or any) purpose. MER-C 12:02, 27 January 2016 (UTC)
  • Disable, Uninstall and Forget - as I !voted above (I thought that was already the request to disable this), more wasting of time by WMF developers that can be used for more useful or even requested upgrades to the system. --Dirk Beetstra T C 12:12, 27 January 2016 (UTC)
  • oppose. This is a 100% waste of time because of WP:CONEXCEPT: These independent, co-equal communities operate however they deem necessary or appropriate, such as adding, removing, or changing software features --In actu (Guerillero) | My Talk 16:43, 27 January 2016 (UTC)
    We are all acutely aware of this. Can you imagine any reason not to ask the WMF to remove it? BethNaught (talk) 16:46, 27 January 2016 (UTC)
Doubtful that all are actually aware of it. Often, it has happened that users hold these things seemingly oblivious of policy. It's really unfortunate that these types of RfC's don't bother to mention it. Alanscottwalker (talk) 17:05, 27 January 2016 (UTC)
Fun fact: the extension currently violates the principles for all MediaWiki software, as it is not "fully transparent and observable, with all changes to pages tracked and all actions logged". A typical reason for the WMF to go against community consensus is if that consensus violates these principles; in this case, that objection will not work. —Kusma (t·c) 17:14, 27 January 2016 (UTC)
Fun? Fact? It violates principles for all MediaWiki software.? It violates some broad and vague principal, according to someone (which is an opinion by the way, not a fact), is not all that momentous.Alanscottwalker (talk) 17:22, 27 January 2016 (UTC)
I do not see how WP:CONEXCEPT is relevant, this is not asking them to remove the feature from the MediaWiki software. It is saying turn it off on en.wp. This is no different from not implementing Pending Changes Level 2 or Flagged Revisions. The features exist in software we just do not use them here. JbhTalk 02:30, 31 January 2016 (UTC)
Without comment on Gather (haven't looked into it fully), there has been conflict in the past between the WMF and the en.wiki community regarding software implementation. I suppose the epitome of this was with Media Viewer in 2014. A community RfC ended with a strong consensus that Media Viewer be turned off by default for all en.wiki users. The WMF expressed its dissent on the RfC talk page, writing that per WP:CONEXCEPT, software development is not subject to the same policies which bind English Wikipedia editors. Later, when an admin disabled Media Viewer on the local MediaWiki:Common.js page in accordance with the consensus, a WMF staff member reversed the change, calling it a WMF action, the result of which culminated in a request for arbitration. Today, Media Viewer remains default on for all users. In a nutshell, the issue of WP:CONEXCEPT is actually quite complex, and it deserves no oversimplification. Mz7 (talk) 18:17, 31 January 2016 (UTC)
CONEXCEPT is an old policy here, from before my time. However, I worked on the most major recent update to it a few years ago, which gives me a reason to believe that I understand what was meant.  ;-) Mz7 is generally correct, but I want to emphasize that there's nothing in CONEXCEPT that prevents us from asking the devs (who may or may not work for the WMF) to make a code or configuration change (e.g., to turn off an extension here). The devs are never required to agree to our requests, but we are still allowed to make requests. WhatamIdoing (talk) 19:27, 2 February 2016 (UTC)
  • Disable Per FPaS disturbing example above. However I am now wondering given Fram's reply what else can be got away with... Only in death does duty end (talk) 17:13, 27 January 2016 (UTC)
  • Disable. This tool is not ready to be used. It is buggy, unclear how it fits into Wikipedia, and has issues with breaching our local copyright policy by including non-free images. The WMF have suspended development and need to test and develop this more before it should be allowed back near English Wikipedia. Fences&Windows 21:54, 27 January 2016 (UTC)
  • Disable for now. There are some potentially interesting possibilities, as mentioned at § Disabling Gather? ([13] and the 'Some positive comments' subsection), but there are too many problems as is, including lack of moderation tools, incomplete or non-existent logs, bugs mentioned above, non-free image problem (might be fixed by phab:T124225, but at the moment is still a problem), and the apparent suspension of development from the WMF. - Evad37 [talk] 14:16, 28 January 2016 (UTC)
  • Disable. This should have been the subject of an RfC before it was enabled for a trial. Until the nonfree content and lack of administrative ability issues are resolved, this is not fit for purpose. Once it is, we need to make sure that administrators are ready to monitor this, it integrates with existing features such as Recent Changes, and that the community considers that to be worth the time and effort. Seraphimblade Talk to me 01:41, 29 January 2016 (UTC)
  • Disable Against community fair-use practices, poor maintainability. — xaosflux Talk 01:52, 29 January 2016 (UTC)
  • Disable - I've spend a good 10 minutes trying to find out what the actual point of Gather is and I still have no idea ....., Why would anyone want collections?.... but more to the point why wasn't any of this thought of before this was even launched ? ...., Anyway as much as I hate to say this I think it should be made a rule that whatever WMF implements it should be brought to an RFC first as so far whatever they implement it's constantly been a disaster with half having bugs & problems... –Davey2010Talk 20:09, 30 January 2016 (UTC)
  • Disable. Concept totally unsalvageable, should never have started and WMF knew it. The extension is also an ongoing cost for our communication in that it sometimes uses the term "collection" for its byproducts and in so doing boycotts offline users. Nemo 23:04, 30 January 2016 (UTC)
  • Disable Violates WP:NFCC#9 by design. Hard to patrol. Impossible to verify if admins were correct when deleting a collection if there is no way to undelete or view the deleted collection, and as a result also impossible to verify if user blocks are in compliance with policy if the block was given as a result of using this extension. --Stefan2 (talk) 23:11, 30 January 2016 (UTC)
  • Disable per copyright concerns and lack of community consensus to implement. sst✈ (speak now) 07:11, 1 February 2016 (UTC)
  • Disable: Obviously we can't stop the Foundation from doing this on another platform, but it's clear that this system as designed, and when hosted on Wikipedia, violates WP:NOT. The NFCC problems make it even worse. Something like this might be appropriate in a toolserver-like environment, or on something like "gather.wikimedia.org" as a sort of fork or mirror of Wikipedia content, but absolutely not as a local extension on enwiki. —/Mendaliv//Δ's/ 09:44, 2 February 2016 (UTC)
  • Disable. The principle may (emphasis on "may") be sound, but the implementation is unusable and goes against fundamental Wikipedia principles. The WMF needs to stop treating en-wiki as their own personal sandbox. ‑ Iridescent 20:40, 3 February 2016 (UTC)
  • Disable — Once again, the Foundation rolls out unneeded and undesired buggy software onto En-WP as its special little beta-testing area. No. Test your products elsewhere, fix their deficiencies, demonstrate their worth, and then we can talk. Carrite (talk) 18:01, 4 February 2016 (UTC)
  • Disable for all the reasons listed above. The BLP issue is particularly troubling. SarahSV (talk) 19:53, 4 February 2016 (UTC)
  • Disable without any further delay. The idea isn't necessarily all that bad, but the mere fact that there are BLP issues in there that we can't police means this needs to be pulled immediately for retooling. Lankiveil (speak to me) 12:33, 6 February 2016 (UTC).
  • Disable because even though the idea is good, if deployed in this state enwiki will turn into chaotic hell. 96.237.20.21 (talk) 15:15, 6 February 2016 (UTC)

Editing one's own talk page/removal of warning templates[edit]

Background[edit]

I know that this policy subject is a Perennial policy suggestion, however I feel like these editors (User:128.61.20.111 and User:153.107.193.208) are perfect examples of why users should not be able to delete their user talk pages. Both of these users had received numerous warnings for unconstructive edits within the last 3 days. If all of the notices were displayed on the user's talk page, they would have been blocked a lot sooner. Three warnings were left on on day for 128.61.20.111 [14] [15] [16]. After they were erased, it was as if the user was never warned. I understand it is the user's responsibility to check the user talk page log, but it is a tedious task that is rarely ever done by editors. One of of the warnings that was left was an Administrator (@Materialscientist: I'd like to get your opinion on this, as well.), who also left a level one warning template when the IP editor vandalized Wikipedia previously in the day. Being able to remove warning templates allows vandals to stay 'under the radar', so to speak. This editor was also given a wrong level warning[17] by User:Eat me, I'm an azuki, having previously vandalized numerous articles[18][19][20][21][22]. Had no-one checked, which editors tend not to do, this vandal could have sunk back into the shadows, both evading a necessary block, and an opportunity to vandalize Wikipedia continually. People that are clever could pick up on this quick, and abuse it until it is dealt with.

Thus is why I am suggesting

  • a change in the policy concerning editing one's own talk page, and deletion of warning templates.
  • Removal of warning templates (of any type) for the last month are prohibited from being removed (including User:ClueBot NG).


I'm not very good at suggesting these sort of things, and putting them together, so any suggestions would be very helpful. Cheers! :) Boomer VialHolla 09:15, 28 January 2016 (UTC)

Discussion[edit]

No vandal can stay under the radar if they are reported at WP:AIV. AIV is the radar. The person doing the reporting can mention that the user deletes warnings, but I don't think that's really necessary. Any admin handling AIV reports very likely knows enough to check the talk page history. If it's disruptive editing, not vandalism, the place is WP:ANI but the same applies there (and you're expected to provide diffs of the disruption there). In any case, how likely is it that a vandal is going to observe a Wikipedia policy about non-removal of warnings from their talk page? Are we going to create a new template for warnings about deleting warnings? ―Mandruss  09:24, 28 January 2016 (UTC)

I personally agree. It makes a lot clearer. Krett12 (talk) 09:30, 28 January 2016 (UTC)
I see what you mean, User:Mandruss, however, it just seems like an unnecessary step that can be prevented if users are prohibited from removing any sort of warning template from their talk page. The user that used as an example above honestly should've been blocked already considering the amount of warnings left on their talk page. The only reason it hasn't happened yet is because the editor removed all warning templates from their talk page. I was even fooled by this[23], leaving only a level 2 blanking warning. Cluebot NG was also fooled by this on a few occasions, leaving the same level warning template[24][25]. It just seems like a problem that could be easily rectified with a simple policy change. Boomer VialHolla 09:38, 28 January 2016 (UTC)
Was that user reported at AIV? If so, when and what was the result? ―Mandruss  09:39, 28 January 2016 (UTC)
I just reported him to AIV, and am currently awaiting a result. You also make a good point about who is going to watch to make sure that warning templates stay on user talk pages, and creating a new warning template. For the first point, I don't have an answer, but I'm hoping another editor that can think of a compromise will come out of the woodwork. As for the second point, we could always edit the misuse of warning templates template to include erasing of templates. Just a suggestion. I tend to give editors the benefit of the doubt, and start off with a level one warning, in the case where a level four warning was left, and it has rolled into a new month. Having all of the warning templates for the last month visible would make problem editors, and vandals a lot more obvious. Boomer VialHolla 09:43, 28 January 2016 (UTC)
I'm not going to remove the RfC template, but I'd suggest that you do so. This page gets enough attention from experienced editors, so this is not RfC-worthy. Good luck. ―Mandruss  09:47, 28 January 2016 (UTC)
Ok, I no problem. I removed it. Thanks. Boomer VialHolla 09:49, 28 January 2016 (UTC)
Btw your vandal has been blocked for 31 hours despite removing warnings, see how easy that is? If they come back and start again after the block expires, repeat. The next block should be longer than 31 hours, maybe 3 days or a week. And so on. ―Mandruss  09:51, 28 January 2016 (UTC)
Yes, I just checked it out before I noticed you posted this. Thanks for the heads-up, though. Also, I'm looking for other opinions, whether for, or against. So don't be afraid to chime in. :) Boomer VialHolla 09:55, 28 January 2016 (UTC)
It's not only the talk page history that the admins look at - they are interested in contributions and always looking for any talk page edits to see the user's response/justification. Previously, when removing warnings wasn't allowed, we had lots of users blocked for only removing warnings from their talk pages. Such a policy results in numerous completely lame edit wars, drives away otherwise productive editors, wastes admin time, and creates long term resentment. I would venture to say that beyond a recent warning, which always can be readily seen, admins are not that fussed about the number of warnings on a talk page. -- zzuuzz (talk) 21:02, 30 January 2016 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Ah, a good point indeed. I'm worried, mainly, about how long these cantankerous editors can fly under the radar until their contribution history until administrators find, and take care of them. I also just realized, also, that it would be a lot of work going through every warning template so "Please do not remove this template for one month after warning date", would be a lot of work. I would have no problem in helping with this, if it became the case. I stand by my suggestion, as I'm sure there is a solution that can benefit everybody. Boomer VialHolla 23:04, 30 January 2016 (UTC)

I'm worried, mainly, about how long these cantankerous editors can fly under the radar until their contribution history until administrators find, and take care of them. - I don't understand how you could still have that concern after reading this thread, and in particular the first two sentences I wrote. If any vandal is "under the radar", it's because others are failing to report them. If no capable editor is aware of what the vandal is doing, no change to warnings will make any difference. ―Mandruss  04:50, 31 January 2016 (UTC)
The reason other editors are failing to report vandals is because they see no warnings on the vandals talk page, leave a level 1 warning, and move on their way. If the vandal is smart, they'll remove the warning, and make no edits for a few days before making another unconstructive edit. Their doing this is dependent on the fact that basically only Administrators check their contributions, and talk page edits. Maybe another solution to this is to make sure users are checking those two things by outlining them in WP:CUV. Boomer VialHolla 14:14, 31 January 2016 (UTC)
As a side topic, it's removing the "shared IP" templates that concerns me. They're easily missed and it's useful to know if an IP is from a school, etc. And not all Admins check for that. Doug Weller talk 17:27, 1 February 2016 (UTC)
  • Really? This again? There is still no compelling reason to force users to maintain warnings for any length of time. The warning does not exist for the benefit of anyone except the user being warned. If they have read it, they have read it and don't need to keep it. If it is a shared or dynamic IP, and it wasn't intended for them, it doesn't need to be kept either. There is no conceivable reason why a user should be forced to wear a scarlet letter for any reason. --Jayron32 21:19, 1 February 2016 (UTC)
Really? This again? - I did find Wikipedia talk:Centralized discussion/Removing warnings in about five minutes via this page's archives. Things are rarely that easy to find in my experience, due to various factors such as the limitations of our search engine (Google it ain't) and the fact that a given issue can usually be in any of multiple venues (how many archives can one be expected to comb through before they start their thread?). ―Mandruss  12:47, 2 February 2016 (UTC)
WP:PEREN is good reading. Every item on there has been brought up literally dozens of times in multiple fora for a decade. The community has rarely budged on any of them. I know that not every newish user would have been involved in these discussions. I apologize for my exasperation; but this makes the rounds every few months. The answer has always been "no", for the reasons I outlined. --Jayron32 16:19, 4 February 2016 (UTC)

My question is, what good does this do? If a vandal doesn't heed the warning to cease vandalizing pages, why would we expect that they would respect the warning against removing the warning? And if they do quit it, I don't care if they remove the warning or not; at that point it's served its purpose. Seraphimblade Talk to me 20:00, 2 February 2016 (UTC)

Model release - medical photos and more - legal review - WMF grant proposal[edit]

This is more of a concern for Wikimedia Commons, but it would affect English Wikipedia too. I am seeking comments and hopefully endorsements on a draft request to the Wikimedia Foundation for grant funds. Opposition and statements of doubt are also useful. If you like, please comment at meta:Grants:PEG/Wikimedia New York City/Legal review and templates for model release.

For some time I have been collecting examples in Wikimedia projects in which there is some disagreement about whether an image violates personality rights and would require a model release to host in Wikimedia Commons. See examples in the discussion sections at meta:Grants_talk:PEG/Wikimedia_New_York_City/Development_of_a_model_release_process_for_photos_and_video.

Thanks. Blue Rasberry (talk) 19:46, 29 January 2016 (UTC)

Sharing content with certain users or specific usergroup[edit]

Hi. As an example, lets assume that I would like to share my mobile number (or anything for that matter) on my userpage or a specific user subpage. And, I would like to either:

  • Allow access to that page's content to only to User:A, User:C, and User:F. Or,
  • Allow access to any registered user, but the system should alert me on who is accessing that page (via alert bar?). Or,
  • Allow access to a specific usergroup (i.e. Autoconfirmed users, admins, etc). Or,
  • Allow access to a specific class of users (i.e. Users who have over 1000 edits, or any other stats-based criteria).

Is any of this possible? Or do we have anything close to something like this? Thanks in advance! Rehman 22:38, 29 January 2016 (UTC)

I know of nothing like that. Other than certain special pages, all undeleted pages can be viewed and read by everyone, including IPs, as can every non-hidden and non-oversighted revision in the history of any existing page back to its start. We are very much about transparency. Best regards--Fuhghettaboutit (talk) 22:47, 29 January 2016 (UTC)
While mediawiki can support most of this, the English Wikipedia is not likely to adopt any sort of READ permissions; it is contrary to our standard licensing model and open-content philosophy. — xaosflux Talk 23:07, 29 January 2016 (UTC)
  • You can make a page accessible only to administrators by making it, and then asking an administrator to delete it, using {{db-u1}}. Admins and (mostly) no one else can see the deleted page. Oiyarbepsy (talk) 07:28, 4 February 2016 (UTC)

Recent additions[edit]

Wiktionary has a feature wherein each new entry to a category shows on the category page. Can wikipedia enable a similar feature to appear on its categories? 92.10.224.67 (talk) 16:34, 1 February 2016 (UTC)

Does it allow the new entries to be sent as watchlist notifications? Praemonitus (talk) 18:42, 1 February 2016 (UTC)
Wiktionary uses DynamicPageList for that, which I don't think is enabled here. --Yair rand (talk) 21:40, 1 February 2016 (UTC)

Simple proposal on "editing old version" editbox[edit]

When comparing old versions of an article via page history, it would be quite useful to be able to directly edit the current version of a page (e.g., in order to restore something which has been inadvertently removed from a page several edits ago). Yet if you click edit, you are presented with an edit box for the difference you are currently looking at (e.g., here), which does have its practical advantages. Surely it would be possible to add a link to this "old version" editbox which would take you to an editbox for the article as it currently is. All that would be needed would be to change to text in the pink box from:

You are editing an old revision of this page. If you save it, any changes made since then will be removed.

to:

You are editing an old revision of this page. If you save it, any changes made since then will be removed. Click here to edit the current version.

Is that do-able, or are there practical or technical reasons why it's a bad idea? Grutness...wha? 00:49, 2 February 2016 (UTC)

  • Support I would also support auto-tagging of edits made from an old version per this earlier discussion. The notice is located at MediaWiki:Editingold. Wikipedia:Village pump (technical) would probably be a better place to ask about if it was possible, though assuming the notices work similar to templates my guess is magic words along with possibly {{Edit}} could create the necessary link. PaleAqua (talk) 03:24, 2 February 2016 (UTC)
  • The phrasing "Click here" is typically considered bad practice, I think. Perhaps the link could be just "Edit the current revision". --Yair rand (talk) 03:59, 2 February 2016 (UTC)
  • There is no technical issue with that, if I'm reading this right, the additional text would just go to the same target as pressing the EDIT tab at the top of the page, is that your intent? If so please work up what you want it to say and propose at MediaWiki talk:Editingold, slap an edit request template in there when ready to go live if no objections. — xaosflux Talk 04:45, 2 February 2016 (UTC)
Can't say I care for the idea of implementing any old little thing that somebody dreams up, as long as there are no objections on a page with such limited exposure. The page has 31 watchers and we all know that doesn't mean 31 active watchers. ―Mandruss  12:21, 2 February 2016 (UTC)
  • Support -- Not because I would use it or have ever felt the need for it, but because the rationale makes sense to me, I recognize that not all editors are the same nor should be, its feature creep factor seems minimal, it doesn't look like a big developer effort, and PaleAqua supports it. The proposer may wish to return the favor in § Darker section titles in page history.
    Re Yair rand's suggestion, I usually try to imagine the link text without a link; does it still seem appropriate? Without a link, "Edit the current revision" looks like an instruction, an imperative. Suggest the alternative: "You may wish to edit the current revision instead." ―Mandruss  11:55, 2 February 2016 (UTC)

Thanks everyone - yes, Xaosflux, that was exactly my intention as far as what I hope it will do. I will propose it at Editingold with Mandruss's correction. Cheers, Grutness...wha? 22:32, 2 February 2016 (UTC)

Oh, and it does look simple: edit this page. There may be even easier ways to do it I'm not aware of. Grutness...wha? 22:41, 2 February 2016 (UTC)
The following line should do it better:
You may wish to {{edit|{{FULLPAGENAME}}|edit the current revision}} instead.
This produces:
You may wish to edit the current revision instead.
עוד מישהו Od Mishehu 10:52, 3 February 2016 (UTC)

Association of Members' Advocates redux[edit]

I and some other people are interested in reviving the Association_of_Members%27_Advocates. It has been ten years since it was discontinued. Wikipedia is a much different place now and perhaps it is time to give it another try. Comments are welcome, as well as suggestions on how to proceed. How exactly does one revive a historical Wikiproject, for instance? Here is a Wikipediocracy thread on the matter. Kingsindian   16:05, 2 February 2016 (UTC)

  • One of the contradictions of Wikipedia, to insert a bit of Marxist jargon, is the dilemma of a person brought before ArbCom — a pseudo-legalistic Discipline Committee. Multiple people pile on with diffs indicating the bad behavior of the "accused." Point-by-point refutation of these charges can start a fast downward spiral of acrimony, tainting the "judges-jury-and-executioners" against the person attempting to defend themself. The only truly viable defense strategy is for third parties to argue the case for the accused. What we have now is a pseudo-legal process in which the defendant has the right to remain silent or to be condemned for engaging in self-defense. This overstates the matter only slightly, as any longtime observer of the ArbCom process will acknowledge.
For myself, I have acted as an informal advocate in a big ArbCom case and in two or three subsequent "clarification" hearings. I feel that there was positive benefit to the project through my participation, that in all likelihood a prolific content contributor was saved for the project at least in part through my actions, and I look forward to participating in a revitalized AMA. Carrite (talk) 17:21, 2 February 2016 (UTC)
  • How about a name whose acronym is not a match for that of the American Medical Association? (No offense intended to the numerous other organizations having the same acronym, including three other medical associations.) Since Wikipedia has users, not members, perhaps Association of Users' Advocates, AUA, in which case your biggest competition is the American Urological Association (better joke potential there, too).
    I assume that all communication between advocate and advocee would be in the open rather than e-mail or other off-wiki, and that this would be an explicitly stated rule. ―Mandruss  17:36, 2 February 2016 (UTC)
  • However, reading some of the Wikipediocracy thread, it appears I may have assumed incorrectly as to communication. At some point, I would like to hear the justification for such secrecy in the process. ―Mandruss  18:01, 2 February 2016 (UTC)
My impression is that when AMA was active, most of the discussion was on-wiki, though some of it was by email (I have only a vague idea). I imagine this would be true in the new version as well. I think the idea was to use the email communication to provide a sympathetic hearing (I am just guessing here). One of the unofficial rules on the AMA page was that the advocate would make clear their role as an advocate in the discussion. So I don't think this would mislead the discussion in any way. Kingsindian   19:36, 2 February 2016 (UTC)
  • Why not Association of Contributors' Advocates? If the majority of ARBCOM cases involve contributors, it makes more sense. Intothatdarkness 19:49, 2 February 2016 (UTC)
I hope we would not be thought of as an association which tries to overhaul the Wikipedia healthcare system. Just kidding. Perhaps it is best to start a new Wikiproject with a new name, rather than use the older one. Since I have little idea of the details of the old one anyway. ACA seems as good a name as any. Kingsindian   07:30, 3 February 2016 (UTC)
Yeah, if the old AMA has any political baggage, a change would probably make a meaningful symbolic statement. Might as well throw in Association of Editors' Advocates for consideration. ―Mandruss  08:19, 3 February 2016 (UTC)
Unless they are committing vandalism, every editor is making a contribution so AEA would be more inclusive. Liz Read! Talk! 20:54, 4 February 2016 (UTC)

More to the point would be an actual requirement that "arbitrators" show completion of at least one college-level course in "arbitration" so that their "kill them all" solutions would be seen as the egregious violation of logic that they are, and that they would properly weigh what passes for "evidence". Too much to ask? Collect (talk) 21:17, 4 February 2016 (UTC)

GOCEreviewed template change[edit]

An example such as {{GOCEreviewed|user=Dthomsen8|date=January 2016|issues=awaiting deletion decision}} should be made sortable by user, date, and especially issues. Some of the articles not copyedited some time ago because they were considered for deletion and then kept should be tagged for copyedit and the GOCEreviewed template should be removed. I am proposing that the GOCEreviewed template be changed to show the user, date, and issues parameters. --DThomsen8 (talk) 22:05, 5 February 2016 (UTC)

Talk about Flow again[edit]

I would like to talk about Wikipedia:Flow again because I can't accept the proposal is failed. In my opinion, I support users can enable the Flow beta function. I think WMF should change the policy on Flow. My suggestion is, the Flow beta can skipped community consensus and allow for users to enable in some days (in major language versions). If the feedback's result is OK, the Flow beta function can still exist. So I would like to restart to talk about Flow function. Please define your opinion, thank you.--Shwangtianyuan (talk) 04:02, 6 February 2016 (UTC)

You posted at WT:Flow a couple of days ago but might not have noticed the mood there: there are plenty of websites where people can chat, and Wikipedia need not provide another. The suggestion that people use one set of procedures for editing an article (the reason we're here), and a different set of procedures for discussing edits in articles is very peculiar. I can't see any advice at WP:SIG about political statements in signatures, but I don't think it's a good idea, however worthy the cause. Johnuniq (talk) 05:18, 6 February 2016 (UTC)
  • @Shwangtianyuan:I certainly like the idea of Flow, but there are serious problems with the actual implementation, that I don't think will ever be resolved (even with full support from Wikimedia that it doesn't have anymore). Flow is not like Visual Editor - it's either on or off and an editor that doesn't like it will be forced to use it if you change your user talk page over (which is one of Flow's fatal flaws). The solution is to implement the one-page-per-topic structure of Flow on our current talk pages and then to create a talk page visual editor. That way, anyone can opt out simply by not using it. Oiyarbepsy (talk) 06:13, 6 February 2016 (UTC)
There's a Draft Flow RfC if anyone wants to look it over or make suggestions. I'm tempted to just post it as a followup to this thread, but there's no rush and I think it may be better not to hit the WMF with multiple negative RFCs at the same time. From what I've seen Community Feedback on Flow has generally been very negative. I expect the consensus will be that we don't want Flow. Alsee (talk) 11:50, 6 February 2016 (UTC)
I would prefer to hold off a Flow RfC for the moment. I wouldn't object to an RfC being based on my text but in that case I would withdraw myself as a proposer. Let's see what happens with Gather. BethNaught (talk) 12:00, 6 February 2016 (UTC)