Wikipedia:Village pump (idea lab)/Archive 28

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (idea lab) archive  

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

---

< Older discussions · Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62

"Deletion" -> "Unpublish" and "Warning" -> "Final caution"

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Moved from Wikipedia:Village pump (policy)

Hi. This is just a small little question about two words.

Noting the humorous discussion of "wiki dragons" being a dying breed, I contend that I am one of those people, because like many people I misunderstand words that are "toxic" to me.

I get a huge emotional reaction to colours, exclamation marks and particular words. I discuss this at the commons. The most notable ones for me with the Wikimedia Foundation are "deletion" and "warning". I never break policies intentionally, its partially my "illness" which isn't really an illness, and partially just how I think. However I think there are many potential new editors like me.

I simply suggest retitling "deletion" to "removal" and "warning" to "notice of policy violation". That's it. What do we think? E.3 (talk) 05:44, 15 January 2019 (UTC)

Also I suggest as they discuss at wiki dragons - these are the things that speak to me "That's why WikiDragons so often lose. Isolated WikiDragons also have a bit of a problem with the fire-breath: 'Hey, I was just breathing. How come you turned black, fell apart, and blew away?'" "WikiDragons are often driven off from Wikipedia, but some others flee to outlying WikiVillages where local law enforcers are more forgiving of their behavior." "WikiDragons have an amazing ability to become preoccupied with a task, making staying focused on their projects much easier. However, some WikiDragons have been known to have a change in preoccupation. This will usually only happen if there is a major change in the WikiDragon's life." E.3 (talk) 06:08, 15 January 2019 (UTC)

wikipedia changed me today. :) E.3 (talk) 06:08, 15 January 2019 (UTC)

I suggest what they are humorously discussing is the "symptoms" of "hyper focus" and "emotional dysregulation". Which may in fact have been essential to humanity's survival throughout human history. Humans are the same in that they are different. These two little words changing in the Wikimedia Foundation, in my humble humble opinion, may make a difference to one other person, or countless other people. I'm serious, my life changed today :) E.3 (talk) 06:47, 15 January 2019 (UTC)

E.3, I think there is actually a benefit to using charged words like deletion and warning. Because they sound drastic, I think they may encourage users to consider their respective alternatives more carefully. --Bsherr (talk) 16:00, 15 January 2019 (UTC)

@E.3: regarding 'removal' vs 'deletion' these are intended to be different concepts. For the most part, and in their most common uses: anyone may 'remove' content (such as removing a paragraph from an article), however 'deleting' is stronger, wherein an entire article may be (permanently) removed. — xaosflux ^Talk 20:07, 15 January 2019 (UTC)

And “warning” notices should only be isdued after more mild templates have been placed... ie by the time someone gets a “warning”, they have already ignored more mild language - and need something stronger to get their attention. Blueboar (talk) 20:19, 15 January 2019 (UTC)

Is it necessary to use strong language? What about "Final alert message" or "Final caution" for that. For deletion we could use "unpublish". These are probably better I'll change this title. E.3 (talk) 01:46, 16 January 2019 (UTC)

This is your final caution for submitting unpublishable material

this paged has been tagged for speedy unpublishing

They have the same effect, but they are not as likely to cause strong drastic emotional reactions in the reader which in my opinion make some editors at risk of creating further damage rather than calming down. Its a paradox. Like Cigarette warning packets. they have shown that little friendly warnings do much better than dark drastic ugly ones like Australia in terms of reducing cigarette smoking. Does that make sense? "The current findings might help explain why GWs do not always produce beneficial effects on smoking behavior (even when they change intentions to quit smoking)"

This page has been marked for speedy unpublishing. It may not meet any number of English Wikipedia's guidelines for publishing on English Wikipedia. You are invited to contribute to this discussion, as all guidelines and all publications on English Wikipedia are subject to discussion and consensus

"I'm not thick skinned enough for Wikipedia"

This is your final caution for editing English Wikipedia in a fashion not consistent with current community consensus. The most notable examples are here here and here. If you do not contribute to Wikipedia in a more consensus building fashion you will be blocked.

These are not scary words. If we were calling this Criteria for Speedy Page Annihilation or Final Warning Before You Are Nuked to Outer Space, I would see the point, but the words we are using are very common, straightforward words, and couldn't reasonably make anyone feel like they are in actual danger. Natureium (talk) 03:00, 16 January 2019 (UTC)

I don't think that "unpublish" is a good phrase to describe what may occur, in that I do not think it would be very clear (especially to new editors) what the impending action would be. "Delete" is a fairly common verb in data processing and its meaning is well understood. — xaosflux ^Talk 03:02, 16 January 2019 (UTC)

I agree that unpublish isn't the best. Speedy unpublication? I'm trying to discuss options. I'm just saying that delete is not the best for me. It is a strong word. It means many things, in Merriam Webster a synonym is kill. We've been trying to get more women on the projects for ages, as well. But also I think the French have this beautiful word attendre in their discussions. I means wait for, wait, expect, meet, watch, hangon, abide, hold the line, stick about, stick around. Literally. Google synonyms of the 13 translations. Words mean a lot to many people. We can see that delete didn't work for me. Over there, we had a fantastic discussion even when I don't speak French. Do you see for me it was all about that word? and the orange timer. E.3 (talk) 03:33, 16 January 2019 (UTC)

Have you considered editing the Simple English wikipedia? They use different words there that you may like better. Natureium (talk) 03:42, 16 January 2019 (UTC)

Yes I have considered that but the world simple itself means many things, some of which I am very far from. "simple-minded"

"having or showing very little intelligence or judgement." People are allowed to be emotional, I'm just suggesting some options in our language that may help us bring down some of the charged nature of some of our discussions, perhaps at best allowing women especially to feel more included in the project. I don't know, request female comment as I am a man. E.3 (talk) 03:54, 16 January 2019 (UTC)

I also think this discussion was very highly charged leading to the banning of a senior editor. I don't care to know the rationale of the banning, and agree if that's consensus around their banning, but how much of it was the word? E.3 (talk) 04:03, 16 January 2019 (UTC)

I can't figure out what word you're referring to in that AfD, but him being banned was not related to that AfD. Natureium (talk) 00:45, 17 January 2019 (UTC)

I'm just talking about delete. Fair enough I just saw he was banned after, don't care or want to know why, thanks for clarifying it wasn't me. E.3 (talk) 02:01, 17 January 2019 (UTC)

Heres a good one, probably what I think may be the best one? suitability for inclusion discussion then say keep or unsuitable? E.3 (talk) 04:14, 16 January 2019 (UTC)

Just to frame this properly, this venue is for discussing changes to policies - are you proposing we rename all of our deletion processes and tasks to "unpublish"? If you need to work out this idea more, this can be moved to the idea lab. — xaosflux ^Talk 04:50, 16 January 2019 (UTC)

Yes @Xaosflux: thats exactly what I mean. No policy changes just the name deletion to unsuitable or exclude or unpublish. And then consideration of warning, but that I know has more rationale than I am aware of. Can I please get your assistance as to how to put it in the idea lab? Otherwise I'll start myself later on if you don't have the time. Thankyou! --E.3 (talk) 08:43, 16 January 2019 (UTC)

I moved it for you. — xaosflux ^Talk 12:49, 16 January 2019 (UTC)

The "Save" button was recently changed to "Publish" due to requirements from the legal team to make sure that users know they when they "publish" on Wikipedia, their submission gets licensed for reuse. This is irrevocable. If you start using "unpublish" wording, some may consider that to be undoing the licencing, which is not correct, the text is still freely licensed even if the article is deleted (allowing Deletionpedia and other mirrors to use the content, for example) RudolfRed (talk) 19:53, 16 January 2019 (UTC)

• I am inclined to agree that the current escalating word usage is a good route to take - the suggest proposals seem too mealy-mouthy and don't indicate Wikipedia's sufficient unhappiness with their actions and that significant consequences will arise if it does not cease. Personally I quite like @Xaosflux:'s "Criteria for Speedy Page Annihilation Nosebagbear (talk)
• @Nosebagbear: - what you see though is a paradox. People often dont calm down with a series of escalating warning messages. More often they calm down with an escalating series of cautions that have the same effect, with clear examples of what exactly it is that they have done, and noting that they have time to improve that they may be misunderstood. I can find psychological and medical evidence of this is you like. But I think we should keep the ideas separate. I think delete should be the first to be discussed, its a much bigger project convincing anyone than I imagined yesterday. E.3 (talk) 00:47, 17 January 2019 (UTC)

I doubt that making warning messages and speedily deletion notifications will make people stop vandalizing. Most vandals aren't angry or agitated while vandalizing; it's more likely due to boredom or for amusement. If anything, making it seem less serious will encourage them to vandalize more. Vermont (talk) 01:08, 17 January 2019 (UTC)

Yes but I suggest that we don't understand all people. It's impossible. true boredom vandals - OK warning will probably do better. Ones who are actually trying to follow policy but just particularly care about something that isn't yet on wiki, possibly cautions would be better. Any senior editor should be able to best judge what that new editor is, and give harsh or helpful escalating messages. Other possible example is editor below although interested in quite different topics. Do you see what I mean? @Vermont: E.3 (talk) 01:35, 17 January 2019 (UTC)

• Specifically to @E.3:'s word suggestions - some suggestions are characteristics rather than actual actions. Others don't really provide the separation from other aspects. For example, a page can be "unsuitable" without warranting deletion. The issues with unpublish have been given by others. Nosebagbear (talk) 20:03, 16 January 2019 (UTC)

@RudolfRed: That is most interesting. We are publishing, rather than saving. This is the most read source in the world on many topics. So I again suggest we should be using editorial words. Editors of journals or other forms of media don't going about deleting things that are already published. They correct things, deciding on their suitability, possibly excluding them. I ask one more Time, why are English deletion discussions so much more highly charged than many other languages? I don't think its English vs French culture. Why do we have so many less female editors than men? I think if we change delete, we change our tone, we become more serious, more welcoming and then more inclusive. E.3 (talk) 00:34, 17 January 2019 (UTC)

Publishers "retract" when unsuitable material gets published. It will then be removed from the online appearance. However they usually have far more checking before publication happens. If people want to publish an ad, they have to pay! Graeme Bartlett (talk) 01:06, 17 January 2019 (UTC)

Yes @Graeme Bartlett:retract that is probably the world I am looking for. If the lawyers are pushing us to have "publish", presumably they won't ever have an opinion about delete, why dont we just synchronise the terminology, so that we act more seriously. We address concerns about "witch hunting" and the aggressive tone of our debates, by acting like what we are, a publisher. We retract we dont delete!

I don't understand your insinuation that referring to deletions as removals is going to attract more female editors and make enwiki more inclusive. Vermont (talk) 11:27, 17 January 2019 (UTC)

References

• (purposefully skipping the ref list) as far as "warnings" go , we don't really use that phrase with editors at all, here is an example of escalating notices. Generally this escalation would be used if the same non-constructive contributions were being made:

Example of escalating notices for vandalism

Hello, I'm Xaosflux. I wanted to let you know that one or more of your recent contributions have been undone because they did not appear constructive. If you would like to experiment, please use the sandbox. If you have any questions, you can ask for assistance at the Help Desk. level 1 — xaosflux Talk 02:47, 17 January 2019 (UTC) Please refrain from making unconstructive edits to Wikipedia. Your edits appear to constitute vandalism and have been reverted. If you would like to experiment, please use the sandbox. Repeated vandalism may result in the loss of editing privileges. level 2 — xaosflux Talk 02:47, 17 January 2019 (UTC) Please stop your disruptive editing. If you continue to vandalize Wikipedia, you may be blocked from editing. level 3 — xaosflux Talk 02:48, 17 January 2019 (UTC) You may be blocked from editing without further warning the next time you vandalize Wikipedia. level 4 — xaosflux Talk 02:48, 17 January 2019 (UTC)

• As you can see we don't say your are "being cautioned" or "being warned" at all. — xaosflux ^Talk 02:53, 17 January 2019 (UTC)

Thanks for clarifying @Xaosflux:. But to me that makes me a little bit more concerned. So literal vandals do not get "warned" but those who are genuinely trying to contribute but just don't quite understand how ARE warned? --E.3 (talk) 03:03, 17 January 2019 (UTC)

To further clarify the above - I agree with vandals this longstanding templates should stand. I think psychologically it means they are more likely to change their behaviour, if not blocked. 100% agree with those. But what about genuine people like me who are a bit overly concerned about the absence of something from wiki, probable controversial topics, but get a bit obsessed over it and want the articles to stand? Theres a good chance I could have been permablocked, and that would be fine if that was consensus. But I calmed down because I finally got it. My mind doesn't work like most contributors. E.3 (talk) 03:06, 17 January 2019 (UTC)

(edit conflict) @E.3: of course anyone can say what ever they want when engaging others, but that doesn't mean it an institutional standard. Can you show a couple examples (diffs) where you are seeing this occur? For readability you can just use a url like this, please don't wrap in reference tags. — xaosflux ^Talk 03:07, 17 January 2019 (UTC)

Sure. Theres the one on my talk page with the stop sign from the banned editor, and there's this one. I can point to multiple examples on the commons but only because they speak English - they're probably irrelevant to this discussion as different wikiproect. Please note no comment about the conduct of the editor who gave the final warning - who has been integral in helping me with the development of the articles I started without understanding the policies correctly. But for me, it is all the exclamation marks and the colours of the deletion notices. Thats what makes me very upset. I take it very very personally, having to read the policies on not taking it personally about three times before I calm down. Many people don't have the ability to do that and may just give up, like I did in the past, you can see from my whole talk page. The editor below has some examples. I dont want to draw attention to other editors who have received these notices, because they're probably upset too about them. The below editor has asked for discussion. I reckon they're great editor, who probably has a bit of difficulty complying with rules when they are so difficult and hard to understand emotionally (not literally, emotionally). --E.3 (talk) 03:33, 17 January 2019 (UTC)

This is how I think it relates to women. Request female comment again, I'm trying to listen to what they are saying in their own words "“[E]ven the idea of going on to Wikipedia and trying to edit stuff and getting into fights with dudes makes me too weary to even think about it." "women who gave up contributing because their material was edited out, almost always because it was deemed insufficiently significant. It’s hard to imagine a more insulting rejection, considering the massive amounts of detail provided on gaming, television shows, and arcane bits of military history.” "The few times I’ve touched wikipedia, I’ve been struck by how isolating it can feel." Please edit out if too much non free content. E.3 (talk) 03:48, 17 January 2019 (UTC)

@E.3: it appears the one in your archive was just what that person wanted to say, it wasn't "standardized" notice. I don't see any notices on your talk page about "warning"'s - do you have any other examples of that? It is probably best to separate suggested improvements to these areas: (standardized editor warnings) (standardized deletion discussion notices) (general user interaction guidance) - so that this can turn in to an actionable proposal to do something. As far as user-behavior/action warnings go a large chart of the standardized templates is located here: Wikipedia:Template messages/User talk namespace and a task force to keep these useful exists here that you may be interested in: Wikipedia:WikiProject User warnings. — xaosflux ^Talk 03:57, 17 January 2019 (UTC)

@Xaosflux: yes other examples are in the commons. Irrelevant. Great discussion, thankyou. Do you think there is any merit changing delete to retract? Also we could have a further option similar to attendre which could go something like This article needs an urgent meetup for discussion and due attention. Or just Attention. Then we have an improvement discussion rather than a deletion discussion. E.3 (talk) 04:05, 17 January 2019 (UTC)

and sorry for clarification @Xaosflux: the warnings are all on my archive. When I receive one, I have to archive. its too stressful for me to be reminded of it every day I'm on wiki. --E.3 (talk) 04:13, 17 January 2019 (UTC)

@E.3: no worries, OK I see you have an "only warning" warning - I'm not going to investigate the activities related to it - but that is something that the user warnings wikiproject (see above) can certainly discuss about how to improve. From a long history, I don't think you are going to get any significant support for renaming the deletion process to something else - we delete lots of things, not just articles and this is pretty much what it is called on all WMF projects (e.g. in french they have w:fr:Catégorie:Wikipédia:Suppression_immédiate_demandée (roughly cancellation), in German "Schnelllöschen" (roughly Quick Delete). That being said, there is always room to improve notices etc, so there could be room for improvement in updating the deletion discussion/speedy deletion nomination notices. — xaosflux ^Talk 04:22, 17 January 2019 (UTC)

Wonderful. I don't need investigation of anything - its all fine! I'm just saying I'm lucky to have got through it and still want to contribute personally. @Xaosflux: Perhaps there's a women's inclusion project you may direct me to as well? I did a rough check and neither of those words in French or German have a common synonym being "kill", I suggest they are much less harsh words in their language, but I don't know. I wonder if anyone has studied the levels of anger or conflict in the various language wikiprojects. I'll have a look. E.3 (talk) 04:30, 17 January 2019 (UTC)

@E.3: see Category:Women-related WikiProjects - of those some of the most active I've seen are: Wikipedia:WikiProject Countering systemic bias/Gender gap task force (about the topic in general), Wikipedia:WikiProject Women in Red (about making new articles), and tangentially Wikipedia:Meetup/ArtAndFeminism (which is more about increasing coverage of these topics than engaging artists and/or feminists specifically - but it is a very large campaign that runs this time of year). — xaosflux ^Talk 04:57, 17 January 2019 (UTC)

@Xaosflux: thanks so much. youve been amazing. i especially think experts and women in particular have a hard time here. i think i know best because im an expert, when in fact i needed to learn humility and understanding. thats the point of wiki, in my opinion, learning humility and respect for other points of view. do you have any advice on how to proceed without breaking WP:forumshop? 1.152.106.144 (talk) 05:17, 17 January 2019 (UTC)

i just discussed the above with four experts, one female. they just realised of course, its more important to publish here then nejm sometimes. theyll have a ponder. lets not bite the newcomers! yippie 1.152.106.144 (talk) 07:38, 17 January 2019 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Merging pending changes reviewer with other user groups

Pending changes reviewer is the most lightweight permission that administrators are currently able to assign. According to Special:ListGroupRights, the only right that pending changes reviewers have which all autoconfirmed users do not already have is (review), the ability mark revisions as being "accepted" on pages protected by pending changes. TonyBallioni, Amorymeltzer, and I were talking on IRC the other day about how lightweight and mundane this permission is, and we were thinking it would be beneficial to deprecate the pending changes reviewer group and merge the (review) right in with other user groups, such as rollbackers, extended confirmed users, or even autoconfirmed users.

Doing this would save lots of administrator time at WP:PERM and would also reduce any impression that having the (review) right is a special thing. To paraphrase what Jimbo Wales once said about the sysop rights: It's merely a technical matter that the powers given to pending changes reviewers are not given out to everyone. Furthermore, and perhaps most importantly, the Special:PendingChanges backlog is chronically backlogged, and this would expand the permission to editors who are competent enough to review pending changes, but are not interested in going through the bureaucratic step of applying for it.

To emphasize how lightweight pending changes reviewer is, consider the following:

• The right only gives editors the permission to accept pending changes. Any editor may deny pending changes by reverting to the last accepted revision—such a revert would be automatically accepted by the software. I recently tested this at Wikipedia:Administrators' guide/Protecting/Protect with a couple alternate accounts and it worked. This feature is documented at Wikipedia:Pending changes#Frequently asked questions.
• Administrators tend to grant this ability on a fairly liberal basis. The edit notice at WP:PERM/PCR states:

  The pending changes reviewer right should be granted on a fairly liberal basis. Recent blocks or noticeboard threads should generally not be used as a reason to deny a user the right upon request. The reviewer right simply re-enables a tacit ability autoconfirmed editors possessed prior to the implementation of pending changes—the ability to approve anonymous edits.

• The bar for accepting pending changes is deliberately set extremely low. Pending changes is designed only to be a filter for obviously inappropriate edits like vandalism, BLP violations, and copyright violations. Per Wikipedia:Reviewing pending changes#Acceptable edits:

  It is not necessary for you to ensure compliance with the content policies on neutral point of view, verifiability and original research before accepting, but of course you are free to uphold them as you would normally with any edit you happen to notice.

I would welcome any feedback on this idea. The main question, if we think this would be a good idea, is which group we should merge this into. I think on IRC we were thinking this should be given automatically to users after they cross a specific threshold. Autoconfirmed was the first thing that came to mind, but if that's too low of a threshold, we were thinking we could add it to extended confirmed and rollbackers—since the right would be useful to rollbackers and some editors get rollback before they are extended confirmed. Mz7 (talk) 22:53, 17 December 2018 (UTC)

I would support merging the right to extended confirmed and rollbacker classes. At the time of this posting, there are 7090 reviewers and 43,473 extended confirmed users. Clearly, this would greatly expand the amount of users with this right, to a group already deemed trustworthy.

Here's a thought: how would extended confirmed users know that they could review edits? Perhaps an automated talk page notice detailing the new extended confirmed permissions would be in order.

Question: does "barely a screenfull's worth of edits, going back to ~20 hours ago" (its usual state as far as I can tell) really count as backlogged? How fast are these edits supposed to be patrolled? Eman235/talk 23:26, 17 December 2018 (UTC)

I see these as three very different criteria. Rollback is for people who can identify vandalism and can be trusted to know when things are and aren't vandalism. Extended confirmed is an automatically granted right, it could and would go to someone who only adds pictures, But we can assume that by the time someone has earned this they have become a member of our community and are not a vandal. Pending change reviewer I would like to see upgraded/tightened to "this person has shown they know how to make a referenced edit with an inline citation to reliable sources". That is a level above merely being able to spot obvious vandalism. Some of the pages protected with pending changes are pages that have been the target of sneaky edits that have got past the recent changes patrol. I think we should be moving this right up from "it isn't vandalism" and into "it is a good edit" territory. ϢereSpielChequers 23:28, 17 December 2018 (UTC)

@WereSpielChequers: Hmm, that would raise the bar for pending changes reviewer higher than rollback, and I think it would be a significant change to the way we currently implement pending changes. The wording of the current guidelines stem from Wikipedia:PC2012/RfC 2. It seems a big concern was backlog. If we impose an expectation on pending changes reviewers to conduct an investigation of all pending edits for sneaky vandalism, it might take a long time for pending changes to be reviewed. I envision a lot of edits would sit in a limbo where reviewers defer edits because they're not obvious vandalism, but they're not familiar enough with the subject to evaluate whether the edits are truly helpful. Another thing to consider is that we have 7,093 pending changes reviewers (in contrast, there are 6,041 rollbackers) – if we raise the standards, we might have to reevaluate some of the accounts that currently hold the permission. Mz7 (talk) 01:22, 18 December 2018 (UTC)

Mz7, commenting as a very new reviewer, I get the impression that a large fraction of reviewers are doing this already. When there's a long (few hours) tail to the backlog it's usually edits that are difficult to check (they're in the middle of a giant table with the source hidden off at one end, or the source is in Korean, or similar) where the edit is plausible but not obviously correct. Being a cautious kind of person I tend to leave such edits myself as well. Wham2001 (talk) 07:42, 18 December 2018 (UTC)

Don't think of it as higher than rollback, think of it as different to rollback. A rollbacker needs to differentiate between vandalism and edits that they really disagree with. Checking that an edit actually can be verified is a different skill. There are rollbackers who just fight vandalism and in my view should not be pending changes reviewers, certainly not if we tightened the criteria. But there are also lots of content creators who I would hesitate to give rollback to unless they actually did some vandalfighting. ϢereSpielChequers 23:59, 20 December 2018 (UTC)

@Mz7, Eman235, WereSpielChequers, and Wham2001: It's taken me a few days to compose my thoughts on this and I'm afraid the conversation has already moved on, but I figured I'd post this anyway. I'm of two minds about this idea.

Here's a thought: how would extended confirmed users know that they could review edits? Perhaps an automated talk page notice detailing the new extended confirmed permissions would be in order.
— User:Eman235

My bigger concern is: How would extended autoconfirmed users perform edit reviews? While it's absolutely true that any autoconfirmed user can effectively reject pending changes via a mass-revert, based on my own actions as a reviewer and my observations of other reviewers' actions that's almost never how we approach PC reviews, and the review policy frowns upon mass-reverting.

For the cases where there's only one edit pending, or two/three edits by the same single user, sure it's typically an all-or-nothing scenario. But while that may describe the majority of reviews performed, it's a fairly minor component of the time and effort spent working the PC review queue. The real work comes in reviewing the pages which have, for whatever reasons (many and varied), been mobbed with pending edits, in the worst cases numbering into the double digits and representing the efforts of 7, 8, or more different editors.

The documented process, and the one that I know I follow and have observed others following, is to work forward from the oldest changes to the newest, examining each edit or group of edits from an individual user in turn to determine whether anything is problematic and, if so, individually reverting those edits. (Adding even more edits — the reviewer's own — to the pending edit list.) Only once the pending list has been walked forward all the way to the newest edits (or the start of the reviewer's own, if any reverts were required) can the entire set be accepted. It's tedious, at times grueling work, but it's necessary to ensure that each editor's pending changes are considered fairly and independent of any other edits that may be pending from different editors.

So, I agree with the opening premise: PC Review permission is nothing special, reviewers have no special powers. But, the work we do is somewhat specialized, and to do it correctly and diligently requires a particular mindset and approach, and for the most part attempts are made to select for that mindset. (Despite the goal of handing out the permission "broadly", plenty of applicants are turned away, often because they're either too inexperienced, or have shown a propensity to clash with other editors over their own edits.)

There's also the fact that, when making changes to an article with edits already pending, the choices are to either review those edits (choosing to accept/reject them as appropriate), or to add one's own edits to the pending list. Specifically, there's a checkbox added to the "Save your changes" form, "Also accept N pending edits". So, to put a finer point on Eman235's question: How will editors not informed about pending-changes review approach that checkbox?

Question: does "barely a screenfull's worth of edits, going back to ~20 hours ago" (its usual state as far as I can tell) really count as backlogged? How fast are these edits supposed to be patrolled?
— User:Eman235

The current definition of "backlog" for the review queue is laughable. As far as I can tell, > ~10 pages is "high" and > 20 is "very high". It's also apparently based on simple count, with no consideration for the age of pages in the queue. It's an extremely alarmist definition of "backlog", though maybe that's a good thing as it hopefully motivates people to review it. However, the current queue shouldn't be viewed as any sort of "problem", it's actually kept up with very well and frequently emptied completely.

The worst I've ever seen it, in terms of age, was nearly two months ago when (as I explain in more detail on Talk:2018–19 I-League), one article had been sitting in the review queue for three days, and by then had accumulated so many changes (24? 25? an insane number) from multiple editors that it was clear nobody wanted to touch it. The article is also (purely editorializing here) basically a mass violation of WP:NOTSTATSBOOK to begin with, so it's almost impossible to review. Lots of changes, all unsourced, to stats data in tables. (Which the current diff view makes completely unintelligible, showing too little context to be understood.) I finally made the call that it was unreviewable, and just blindly accepted all of the changes. I did this, as I explained in that talk page post, to "release" the backlog of changes to the article's involved editors, so that they could review them any revert any that were problematic.

And that's where, as I said, I'm of two minds. Because, while (as Wham2001 says) a lot of us do attempt to review edits for content, the fact is that there are many topics on which we have no frame of reference to do that.

This is especially true when a non-mainspace page is placed under PC protection. The only other Talk page post I've made about an entry in the review queue, but far from the only other time I've thought this, was at Wikipedia talk:WikiProject EastEnders/List of births, marriages and deaths in EastEnders#Pending Changes protection. Because, as I explained there: You're asking independent editors to police modifications to your project page, even though they're not members of the project and have no context for doing so. When reviewing mainspace articles, the Five Pillars and the general standards of Wikipedia's editorial policy are enough to guide reviewers. But on a project page like this one, those rules don't apply. It becomes an open question what rules do apply, and how a reviewer would possibly know when or how to apply them.

So, maybe it would be better for all experienced editors to have PC review rights, so that they could pitch in with the review of articles on which they are subject-knowledgeable. Maybe that would help keep the review queue from building up to the (limited) extent it does, and make for better reviews. I don't know, but it's certainly worth considering. Thanks, Mz7, for bringing it up for discussion. -- FeRDNYC (talk) 21:28, 26 December 2018 (UTC)

Thanks for suggesting this; I'd kind of been wondering along these lines myself recently as a couple of my watchlisted pages have been put under pending changes. One other thing I wanted to point out, is that even without the pending changes permission, we already can accept...sort of. All you have to do is revert the pending edit, and then revert yourself (or even add it back in manually), but that sort of defeats the spirit of it. What might also be good if it's technically feasible (and I have no idea), is to have a page set up where someone who qualifies could just go read the relevant policy and then press a button to get the permission automatically (maybe a bot would have to be involved). This would at least let people be aware of what's appropriate to accept or not before being able to use it. –Deacon Vorbis (carbon • videos) 00:15, 18 December 2018 (UTC)

That is a ... clever way to game the system. I hadn't thought of that. I'll note that it only works for autoconfirmed users, since you would need the (autoreview) flag to have your changes automatically accepted by the software. Mz7 (talk) 00:31, 18 December 2018 (UTC)

The thing with PCR is that it is more about making sure the person is ready to deal with what to do when they are actually rejecting a PC item, especially if it is not obvious vandalism. EC users would hopefully know how to do this, and adding in some additional help guides as needed at the PC related interface pages should be easy. — xaosflux ^Talk 01:08, 18 December 2018 (UTC)

Can’t they already roll it back? I always thought I could before I had it. I never bothered trying too much because the technical rollout is such a mess. TonyBallioni (talk) 01:29, 18 December 2018 (UTC)

Theoretically, they should decline the edit, but I think in practice people just revert/undo/rollback it, for simplicity's, familiarity's, and editcountitis' sakes. I think the real barrier is understanding what to do when there are multiple edits where maybe some were reverted or only some are good. That gets real complicated real fast. ~ Amory (u • t • c) 02:02, 18 December 2018 (UTC)

@Amorymeltzer, TonyBallioni, and Xaosflux: I just wanted to note, on this: Declining pending edits is implemented as a revert, in the current PC protection. (Specifically, it's implemented as Accepting an edit to revert the pending changes, which sure makes Special:AdvancedReviewLog confusing.) I think that choice was made so that rejection reasons are displayed as edit summaries in the page history of the protected page — unlike accept reasons, which are only visible in the advanced log because they don't create a new edit. Point is, nobody is unnecessarily reverting pending edits to increase their edit count, or for any other reason. -- FeRDNYC (talk) 23:38, 5 January 2019 (UTC)

When someone with the reviewer perm edits a page that is pending changes protected, they are automatically accepting all the pending edits, right? I don't want to be responsible for saying that all of the pending changes are appropriate if I'm, for example, quickly correcting a typo on a high-profile article. Natureium (talk) 01:12, 18 December 2018 (UTC)

Natureium, you have the ability to decide whether to accept your own changes (there is a checkbox – you can check this by going to Special:PendingChanges and opening the edit window of a page that has pending changes). If you prefer, you can leave the checkbox unchecked, and your edit will be lumped in with the rest of the edits pending review. Mz7 (talk) 01:26, 18 December 2018 (UTC)

Natureium, nope. Even when admins edit pages it’s stuck in the mess that is the pending changes clogged drain until the changes before that are by non-autoconfirmed users and IPs are approved. All the permission does is give you an annoying watchlist banner and allow you to try to “approve” changes like you would make a talk page edit request. TonyBallioni (talk) 01:29, 18 December 2018 (UTC)

Oh, then I wouldn't hate this perm and don't see any reason not to lump it in with rollback since both require a basic level of common sense when it comes to identifying vandalism. Natureium (talk) 01:42, 18 December 2018 (UTC)

I'll be honest, I'm not exactly sure where I land on this. PC reviewer and Rollback are often linked as "antivandalism" work, and frequently requests for one might reference the other. I (personally) feel the bar for rollback (aka huggle aka massrollback) should be low but not too low, while PC should be handed out to anyone who can show signs of understanding sourcing, inclusion, etc. I don't think the bar needs to be as high as extended confirmed, but it's not a bad "by this point, you are likely able to be trusted with this" marker and would probably be my preference if I had to choose. It can be removed if need be (i.e. it's not autoconfirmed) and has a sufficiently broad base. ~ Amory (u • t • c) 02:14, 18 December 2018 (UTC)

I'll add that the 2016 RfC closed with 11-2 opposed to autogranting the reviewer right, although the specific conditions were not given. ~ Amory (u • t • c) 15:19, 18 December 2018 (UTC)

I'm not really buying any arguments about WP:PERM backlog or that processing PCR requests is consuming too much admin time; however just like EC we could configure PCR to be automatically granted at a certain level - this would also leave it open to remove it if someone really doesn't want it or for cause. — xaosflux ^Talk 02:20, 18 December 2018 (UTC)

Caveat - this would likely lead to a mass auto-promote period (just like EC was) that can overwhelm a few support processes temporarily. — xaosflux ^Talk 02:21, 18 December 2018 (UTC)

Eh, it’s more like it’s a waste of admin resources to go through a formal process for what is supposed to be more lightweight than semi-protection but because of the PERM actually can be more difficult. It’d also stop the hat collecting of people rushing to PERM so they can display a userbox for what might be the most underwhelming user right on this project (Extended confirmed let’s you do more if you think about it.) I’d support autopromoting after a month and 100 edits (could be talked down, though) as I think it’s a good idea that would make the project more open and less cliquish (new editors realizing they can help out with stuff, etc.) TonyBallioni (talk) 02:44, 18 December 2018 (UTC)

Right, I could have worded it better. WP:PERM/PCR requests aren't that difficult to handle. TonyBallioni put it better than I did. Mz7 (talk) 03:00, 18 December 2018 (UTC)

Additionally, I think it's likely that having the requesting process inadvertently raises the bar for qualification for PCR. ~ Amory (u • t • c) 12:26, 18 December 2018 (UTC)

Yes, I agree. I'm not sure where the bar should be for autogrant, but I think it should be a rough numeric calculation like extended confirmed so the permission really is seen as not that big of a deal. TonyBallioni (talk) 16:30, 18 December 2018 (UTC)

If you're using a rough numberic calculation like extended confirmed, you might as well just use extended confirmed and deprecate PCR all together. There's already community consensus that 500/30 is an appropriate level to implicitly trust an editor in more contentious areas. --Ahecht (TALK
PAGE) 15:36, 20 December 2018 (UTC)

Given that any autoconfirmed user is already trusted to add text to a PC page without further review, I don't see any reason not to give the review userright to all Extended Confirmed users. I also think that we should include the review user-right with rollback, which, since it can be granted to non EC users in the case of an alt account or other extenuating circumstances, would allow us to get rid of the PCR group entirely. --Ahecht (TALK
PAGE) 15:36, 20 December 2018 (UTC)

• It shouldn't be depreciated/merged. It should be granted to any editor who has rollback, NPP etc who has somehow not picked it up already. Merging it would deny it to users who could legitimately get it - as the only userright some can earn they are actually particularly active around it. If it's merged with rollback, it will get less specific focus. WP:PERM is NOT overwhelmed. TL;DR - Don't merge, but grant with other rights Nosebagbear (talk) 17:15, 20 December 2018 (UTC)

  Nosebagbear, mm this could be a good alternative approach. Add the (review) flag into extended confirmed and rollback (and whatever other packages deemed necessary), and then afterwards re-evaluate whether there is a need to deprecate pending changes reviewer (possibly not needed). Mz7 (talk) 21:34, 20 December 2018 (UTC)

  @Mz7: - so I would not add it to the standard Extended-Confirmed, I feel there is a benefit in it being a step up. But rollback and NPP are the obvious ones, the others seem advanced enough that almost no-one would acquire one without grabbing any intermediate right first. The only questionable one might be AWB. Nosebagbear (talk) 21:55, 20 December 2018 (UTC)

• I haven't read through all this and won't have time in the next few days probably, so just a drive-by comment from me. Whatever userright package contains the permission to review pending changes should continue to be one that must be enabled by administrators, not one that a user can achieve by editcountitis. If it's bundled with extended-confirmed then it's one more incentive for disruptive editors to game that permission, and if it's bundled with autoconfirmed then pending changes protection becomes strongly pointless. What about bundling this with new pages review into a new "content reviewer" permissions package? It's fundamentally the same set of skills: knowing when content is encyclopedia-worthy and what to do with it if it's not, as well as diplomacy with newbies. I wouldn't expect everyone who patrols new pages to also patrol pending changes nor vice versa, but I don't see any reason to trust someone to do one but not the other, or if they do cause harm at one task they probably shouldn't do the other either. Ivanvector (^Talk/_Edits) 22:34, 4 January 2019 (UTC)

  @Ivanvector: I would tend to agree with this. Not so much because of the edit-count-gaming issue (though now that you've brought it up, that's another good reason). Mostly because the permission shouldn't be "sprung" on anyone without them having first read WP:PEND, so that they understand the interface changes that occur when they're granted the permission, and what they're supposed to do with those new tools. The application process strongly implies that they have read the necessary documentation. (Or else how would they know to apply?) The principle of least astonishment would say that user interface changes should never happen automatically. -- FeRDNYC (talk) 07:48, 9 January 2019 (UTC)

I'm not convinced it should be granted automatically at ECP; it's somewhat confusing and editors should be aware of what it is before having those buttons show up. Culturally, something has to be "the easiest hat" for editors to get, I don't see a problem there. If people who should have this permission aren't asking for it, perhaps it should be automatically granted with Rollback. power~enwiki (π, ν) 18:51, 23 January 2019 (UTC)

I'm skeptical about autogrant. I can very easily see someone getting to Extended Confirmed and literally never heard of Pending Changes. It's not a trust issue, but that they likely have no idea what Pending Changes is and what to do. I have no objection to adding it into other granted permissions - hopefully anyone qualified and requesting some other permission would have enough Clue to look up Pending changes when they bump into a page where it applies. Any permission that it is added-to should definitely have a note added to its document page about the included right, linking to Pending changes. Alsee (talk) 11:17, 24 January 2019 (UTC)

• This right shouldn't be auto-granted by any means especially with (autoconfirmed) as others mentioned. Autoconfirmed is easy to aquire and those users shouldn't have any additional rights as soon as they are granted autoconfirmed by the system. It could encourage problematic editors to game the system to get the right or those that like to collect hats it makes it easier then having to deal with an admin. Also after last year we don't need inactive accounts that could be targets for being compromised to gain additional rights as well. We shouldn't act like pending changes level 2 doesn't exist there is just a consensus not to use that here at enwiki at this time. As per enwiki policy consensus can change so if the community ever determines that we need pending changes level 2 protection in the future it can be re-enabled. Giving (autoconfirmed) and (extendedconfirmed) the (reviewer) right automatically then trying to use PC level 2 in the future would be redundant. While I see (reviewer) at the same level to (rollbacker) I do not think those two should be merged either. However I would support that (reviewer) and (rollbacker) are automatically given to higher user rights like new page reviewer, file mover, page mover, template editor, edit filter helper and edit filter managers. Alucard 16_{❯❯❯ chat?} 12:24, 24 January 2019 (UTC)

Less prominence to critical templates

The prominence given to template messages has always seemed to me a bit narcissistic, giving more prominence to our perfectionism than to the article. When criticism is levelled at one's efforts, or at an article on one's cherished organization, with showy critical template messages, it may lessen rather than raise one's esteem for Wikipedia. My suggestion is that all critical template messages be one-liners referring editors to a section at the top of the article's talk page, that explains suggested improvements. If several criticisms are to be raised, they can be named in that one-liner template at the top of the article or section of the article. I suggest that this change may be a part of our response to the drop in the number of editors. Jzsj (talk) 13:02, 16 January 2019 (UTC)

100% support. Coming at a different angle with the above idea :) E.3 (talk) 13:46, 16 January 2019 (UTC)

That may be appropriate for some of the level1 warnings, but I'm not going to take the time to write on the talk page of an article exactly how someone should stop vandalizing articles. Perhaps some of the templates could be reworded, but redirecting people to the talk page is far more work than it needs to be. Natureium (talk) 00:42, 17 January 2019 (UTC)

I literally think if we remove the exclamation mark and change it to something more like my suggestions, or anything that is not an exclamation that will make a huge difference to people not taking it personally. Theres heaps of options. E.3 (talk) 01:37, 17 January 2019 (UTC)

@Natureium: The OP seems to be talking about article maintenance tags, not warning/notice to users in particular. –Ammarpad (talk) 07:56, 17 January 2019 (UTC)

• I don't see my suggestion requiring any more work. Wikipedia could easily devise an automated system where the one-liner would appear at the beginning of the article or section and the extended notice (without exclamation points) would appear at the top of the talk page: no more work. Jzsj (talk) 07:17, 17 January 2019 (UTC)

• it could but software updates may cost nothing or millions of dollars, so you know? thats why i suggest changing the exclamation mark first. one bit at a time. 1.152.106.144 (talk) 07:42, 17 January 2019 (UTC)

• @Jzsj: You're not the first to raise this issue. But unfortunately the idea has been rejected on multiple occasions —and there are reasons. See the summary of the reasons at Wikipedia:Perennial proposals#Move maintenance tags to talk pages, the section also contains archives of the discussions that took place between 2007 and 2013. You may need to study them and explain in detail why you feel the community should the reconsider the issue. –Ammarpad (talk) 07:56, 17 January 2019 (UTC)

one step at a time! lets deal with the exclamation mark first in deletion discussions. there cant be a well thought out reason for the exclamation mark. can there? 1.152.106.144 (talk) 11:18, 17 January 2019 (UTC)

Yes! It draws attention and let's the reader know that the information next to it is important! Natureium (talk) 16:18, 17 January 2019 (UTC)

...if it is important. Non-editors don't usually need to know whether a page is being considered for deletion. "Gah, it's yet another {Bollywood actress|book|television show|computer company} that I've never heard of, so it must be non-notable!" is not exactly important to readers. WhatamIdoing (talk) 21:46, 21 January 2019 (UTC)

THE POINT IS that we are very ANGRY on english wikipedia. You do not have any rational reason for the exclamation mark. At all. Literally anything else will be OK. orange traffic light. THE EXCLAMATION MARK IS OFFENSIVE SAME AS USING CAPS IS OFFENSIVE. E.3 (talk) 09:37, 22 January 2019 (UTC)

Since when does an exclamation point denote anger? The exclamation point is used for emphasis, and anger is not inherent in emphasis, while all caps is seen as expressing anger. Maybe you are influenced by the idea that using any punctuation in texting denotes anger, but we are not texting, we are writing (in standard prose) an encyclopedia. Donald Albury 15:10, 22 January 2019 (UTC)

As this section doesn't contain any links to templates, I don't know the surrounding context of the purported punctuation. Can you list the templates in question? isaacl (talk) 16:23, 22 January 2019 (UTC)

I believe that this complaint is about the use of icons such as File:Ambox warning orange.svg, rather than punctuation in text. They're seen in messages such as Template:Non-free promotional. The interpretation of these warning icons as meaning "I'm angry at you" rather than "Please take notice of this important bit" does not seem to be widely shared. WhatamIdoing (talk) 01:42, 24 January 2019 (UTC)

Well, it's the street sign warning for an unspecified hazard, although I suspect there are many who don't know that. The MacOS UI guidelines specify that its exclamation icon indicates caution. The Windows UI guidelines calls its exclamation icon a warning icon. So I think there should be some carryover from these standards to help readers understand the message being conveyed on Wikipedia. isaacl (talk) 02:53, 24 January 2019 (UTC)

Email

My Idea is: When a new user Create Account, it seems; Email (optional). So socks and disruptive users can easily access in Wikipedia. If email required for every user then it will be very greatful. So every user must be verified by email. :) Siddiqsazzad001 <Talk/> 05:22, 16 January 2019 (UTC)

Since it's so easy to get Throw-away accounts from e-mail providers, I'm not sure that it would make much difference in the end, and it would probably deter some legitimate users. WhatamIdoing (talk) 21:14, 21 January 2019 (UTC)

What if users do not want their e-mail addresses becoming common knowledge on their Wikipedia pages? Vorbee (talk) 15:26, 25 January 2019 (UTC)

• Where do I start with this?
  • There is no correlation between socking, disruptive users, vandalism, and whether or not their accounts have been registered to include an email address. Some do, some don't.
  • It is impossible for IP addresses to attach an email address. IP addresses are commonly used to sock, disrupt, vandalize. They're also commonly the way that editors first make good edits. That's one of the reasons that people are not required to register accounts.
  • It is absolutely in violation of the Wikimedia Foundation privacy policy to require users to register or to attach email addresses to their accounts.
  • As noted by WAID above, there are dozens of email services that allow throw-away accounts
  • There is no practical use for the email address. It will in no way be useful in preventing or addressing vandalism, socking or disruption.
  • Registered users can attach and un-attach an email address to their account in their preferences whenever they wish.
• So no, there's no benefit in *requiring* the inclusion of an email address when an account is registered. I can see some good arguments about being more encouraging of new registrants to include an email address (especially after spending a lot of time reviewing compromised acccounts - if there's no email address attached, it's almost impossible to verify the owner of the account). Risker (talk) 17:25, 25 January 2019 (UTC)

Improve template Intitle

Please see disussion about improving intitle template. Coastside (talk) 22:24, 27 January 2019 (UTC)

To reduce the collateral damage from semi-protected articles

A major reason why pages are not semi protected for long durations is to reduce the collateral damage to the constructive IP editors or new users. An alternate to Semi protection is WP:PCPP. While we still see that semi protection is often used on large amount of articles. An IP editor who wants to make a constructive edit, tries to edit the page, and sees that he is not allowed to edit and "Publish" and he abandons editing. Only a very few motivated IP users read the Edit request section and are bothered to put up a well formed edit request that explains changing of X to Y along with a reliable source.

• For Semi protected pages, when you hit "View source" you don't see the publish button. The only button you see is "Make an edit request".
• My proposal/idea is that for these semi protected pages, add another button at the location (where "Publish" button normally exists") with name something along the lines of "Publish as edit request". So the IP will make changes and hit the "Publish as edit request" which will accept the edits from the IP but instead of making it on the article this button will directly move the changes along with some kind of diff to a new section on talk page as an edit request for a reviewer. This way, the collateral damage of loss of constructive IP edits can be reduced.
  
• This idea may be added to existing semi protection policy or as a useful addon for admins to enable whenever useful, those are implementation decisions.
  

Suggestions/feedback/ improvements to my idea are welcome. --DBigXrayᗙ 15:26, 22 January 2019 (UTC)

So your idea is to make semi basically work like WP:PCPP? I think we should rather encourage admins to use semi-protection only in cases where PC protection is inefficient to achieve that goal. Regards SoWhy 15:44, 22 January 2019 (UTC)

It does have certain shared functionalities with WP:PCPP. But I think I would prefer to call my proposal a better way to "submit" an "Edit request". The current format of submitting edit request is not user friendly. And as a edit request patroller, I see a lot of Blank edit requests/unclear edit requests,my proposal can probably help alleviate that problem as well. --DBigXrayᗙ 16:21, 22 January 2019 (UTC)

• As far as I can tell, this method is designed for more-active articles where conventional PCPP wouldn't work - because they'd be added as edit requests, not as pending requests, there wouldn't be the "overlap" issue that makes stacked edit pending requests such a bugger to resolve. However, these would be significantly more effort to execute than authoring a pending-change - particularly in situations when there were overlapping edit requests. The reviewing editor would have to judge which ones to put in, potentially having to merge them him/her self. I don't think the effort saved is outweighed by the effort lost. Nosebagbear (talk) 19:45, 23 January 2019 (UTC)
• I agree as well the current method of submitting edit requests for semi-protected and even extended confirmed protected is unfriendly to IP editors and often result in blank requests. For the semi-protected articles DBigXray is describing I could see this help with processing edit requests and would be easier for IP/non-autoconfirmed users to submit an edit request. However I think most editors would just see this as an alternate form of Pending changes level 2. Alucard 16_{❯❯❯ chat?} 12:48, 24 January 2019 (UTC)

  @Alucard 16: I have an idea that could work, and given that this is the idea lab, I'll propose it before exploring if it is feasible: set a page to unprotected, but with an edit filter to disallow any edits from non-confirmed editors. Then, you could use a tool like this to make the edit based on the abuse log entry. I'll try to get this tested in a subpage of my user page, and see if it is feasible. Thoughts?

  --DannyS712 (talk) 00:47, 25 January 2019 (UTC)

  @Alucard 16 and DBigXray: You and everyone else are hereby invited to try to edit User:DannyS712/not pending with an account that is not extended confirmed, so that i can test this idea. --DannyS712 (talk) 18:13, 25 January 2019 (UTC)

  Will do thanks DannyS712! Alucard 16_{❯❯❯ chat?} 20:54, 25 January 2019 (UTC)

  That's very cool! I never reviewed rejected edits by an edit filter before but it was a lot easier reviewing the edit filter log and and clicking just two buttons to make the edit. Something like this for edit requests would be very cool. Alucard 16_{❯❯❯ chat?} 21:51, 25 January 2019 (UTC)

  @Alucard 16: I'm going to be doing some more testing on it, and I already found a few bugs in the script, but, on a page-by-page basis, this might be a workable idea. We could do a trial on x pages, as long as we fixed the warning template and stuff. --DannyS712 (talk) 22:35, 25 January 2019 (UTC)

  @Alucard 16: I've had the filter expanded a bit - now it also disallows all edits made by my alt account (DannyS712 test2), so that I can test it for real. You, and anyone else that wants to help test this, are welcome to ask that their alts be likewise prevented from editing by having their account names added to AbuseFilter #1. --DannyS712 (talk) 21:04, 28 January 2019 (UTC)

Venezuela and commons data

2019 Venezuelan presidential crisis (edit | talk | history | protect | delete | links | watch | logs | views)

A lot of the comments (and disputes) are ongoing regarding exactly which countries have recognized the Nicolás Maduro or Juan Guaidó governments in Venezuela. Some are here, but many are at Commons, where commons:File:Venezuela president recognition map 2019.svg is hosted. Is there any better way to harmonize discussions across multiple wikis here? Many discussions are simple points of fact that can be sourced to government statements, others ("How should Crimea be colored?") will cause interminable disputes. power~enwiki (π, ν) 21:51, 28 January 2019 (UTC)

Credit

Editors should get more credit, and with their permission, should be featured on main page with something like "Editor of the day". (Don't forget to ping me) ImmortalWizard(chat) 14:38, 19 January 2019 (UTC)

Please no. The main page should reflect the encyclopedia aspect, not the social aspect. Natureium (talk) 20:08, 19 January 2019 (UTC)

@Natureium:Then there must be other types of acknowledgements, both outside and inside the community. Barnstars are not enough. ImmortalWizard(chat) 20:14, 19 January 2019 (UTC)

@ImmortalWizard: the Editor Retention project may be of interest to you, especially the Wikipedia:WikiProject Editor Retention/Editor of the Week process. — xaosflux ^Talk 21:38, 21 January 2019 (UTC)

The main page should be kept for the readership. But there might be mileage in an idea to create an editor-facing portal, which could have "editor of the week" as one of its features. — Martin (MSGJ · talk) 11:11, 31 January 2019 (UTC)

Wikipedia articles should mention the first news source to break an investigative story by name in the article

How is this idea? - That for Wikipedia articles, especially ones related to investigative journalism, articles should mention the media house/newspaper by name in the article, that this is where the story was first published. I am putting this idea forward as a prospective guideline, policy idea. Any suggestions? All respectable news houses do this, they mention where the story first broke, especially in the early stages of the story. Merely citing the article isn't enough in this case, since where the story first broke may get overlooked as the story develops. DiplomatTesterMan (talk) 13:17, 31 January 2019 (UTC)

Direct attribution (naming the source in the text) is really only needed in cases where we want to avoid speaking in Wikipedia's voice; especially when the cited statement is not widely accepted. We would never say "According to the New York Times, the sky is blue", for example. If a particular statement is well established and well accepted by the preponderance of mainstream sources, and not under serious dispute, I see no reason to give direct attribution as you describe, it adds nothing to the article, and indeed it can give the impression that only that source supports the statement, and by contrast other sources may dispute it. I think that direct attribution has its place, but I see no useful reason to create any guidance to suggest that we use it for every time we cite new information to its first source. --Jayron32 14:41, 31 January 2019 (UTC)

@Jayron32: Rather than, "According to the New York Times, the sky is blue", I mean - "First reported by the New York Times, the sky is blue." I don't mean this as an all encompassing thing, but mainly restricted to investigative journalism. It already happens in its own way already say for movie critics and research scholars here... right? DiplomatTesterMan (talk) 15:02, 31 January 2019 (UTC)

I think that clearly stating the origin of a story is important, especially investigative journalism ones...DiplomatTesterMan (talk) 15:07, 31 January 2019 (UTC)

I agree with Jayron32. And your claim that "All respectable news houses do this" is silly, because Wikipedia is an encyclopedia, not a news house. Natureium (talk) 15:09, 31 January 2019 (UTC)

@Natureium: I was trying to focus on the respect part... :) DiplomatTesterMan (talk) 15:10, 31 January 2019 (UTC)

@Natureium: Also, this is an encyclopedia as you said... So I think an important part of the timelines in investigative stories is the origin, when it was made public and who.DiplomatTesterMan (talk) 15:13, 31 January 2019 (UTC)

Yes, but we do give public credit using footnote citations. That is sufficient for our purposes, because our house style is not the same as that of a newsmagazine or newspaper. As an encyclopedia, the actual prose narrative text is organized and written in a different tone and style than one would expect of a newspaper. As such, the use of direct attribution like you propose does not fit with our house style, where we use direct attribution to draw attention to a particular statement or idea in a certain way. When we directly name the source in the narrative (rather than just using footnotes only), it says "something about this fact is different than all the other facts in this article", and what it usually says is "there is not wide agreement on this, so we're telling you who to blame if it isn't right," I'm fine with making sure the source-of-first-record is given primacy through footnoting (i.e. choose the initial report itself as your footnote citation), but the direct in-text attribution changes the meaning of the narrative of a Wikipedia article in ways that I don't think we should do in all cases. --Jayron32 15:22, 31 January 2019 (UTC)

If we are talking about an investigative story, where the media company's reporters did a bunch of work and made the first big reveal, they should be named (eg omitting the Washington Post from the Watergate scandal would be a drastic oversight). For a current event, it would be wise to wait a week or so and see how the rest of the media frames it - if they give credit to the source that broke it, we should include that too, but if that gets overlooked, then we shouldn't have to mention it. --Masem (t) 15:32, 31 January 2019 (UTC)

The thing is, the involvement of Woodward and Bernstein in breaking the Watergate story is so much an integral part of the narrative, it would be odd to go out of our way to ignore them. That's a completely different thing than saying "As first reported in the Washington Post, President Trump was inaugurated on January 20, 2017." The Watergate/Washington Post connection goes beyond merely giving a simple attributive credit to the Post for being the first source-of-record on some fact, the investigation and publication of the scandal is intricately tied to the narrative of the events and cannot be omitted without a major omission in the story. This is quite different from what the OP is talking about, which is adding information on the first source is simply added as an attribution without context, as I read the proposal. These are unrelated issues. --Jayron32 15:42, 31 January 2019 (UTC)

I agree we should not do it automatically, but we should pay attention if sources do give that credit and reflect it appropriately. I know that for Trump there's been a few such stories but I cannot recall what those exactly were, where the story was reported by other sources as "broken by" a specific source, and that's where we should indicate that. So I would guess this means we should follow how the sources present the story and not make assumptions ourselves if that attributions is not mentioned. --Masem (t) 15:57, 31 January 2019 (UTC)

Watergate is a big example... I would therefore like to present an two much smaller examples for consideration:

1. CASE 1: Please see this edition of The Signpost IN THE MEDIA, the first story "The Wall Street Journal credits The Signpost for breaking story on Acting United States Attorney General"
2. CASE 2: I was creating this article University of Farmington scam, when I came across Washingston Post mentioning that Detroit Post was the first to break the story "According to the Detroit News, which first reported on the undercover operation". I felt morally oblidged to state the same too.

(Note, I have just requested one user, Smallbones, in a comment on The Signpost for his opinion on this since it is his article and he has personal experience with this. I repeat this has nothing to do with oppose or support but understanding the situation. Regards.) DiplomatTesterMan (talk) 16:16, 31 January 2019 (UTC)

I think there has to be a reason to name a source. It should not be standard practice. Having said that, an inconspicuous mention is not entirely irrelevant. Readers are savvy about the reputations associated with various sources. There is a difference between the National Enquirer and The Economist. Therefore the identity of the source is not entirely extraneous information. Bus stop (talk) 15:48, 31 January 2019 (UTC)

@Bus stop: Thanks for mentioning this point. Regards. DiplomatTesterMan (talk) 17:20, 31 January 2019 (UTC)

I am excusing myself from this conversation any further... in the sense I myself will not take it forward as an idea... even say a few lines in some essay. If others want to consider it, please do so... I am done with it, (I am withdrawing the idea :D :D if that is possible). Thanks to those who commented. The insight was considered. DiplomatTesterMan (talk) 17:33, 31 January 2019 (UTC)

Each case needs to be decided on its own merits. Where the breaking of the story becomes itself part of the story, as with the example of Watergate given above or the United Kingdom parliamentary expenses scandal, then it is appropriate to mention the role of the media organisation that broke it, but in many other cases it is not. Phil Bridger (talk) 12:33, 1 February 2019 (UTC)

IRB Review of Research on Wikipedia to be submitted to OTRS

Over at WP:VPM GreenMeansGo in small type suggested (through the always fun double negative) that IRB approvals for research on Wikipedia be submitted to OTRS. This seems like an excellent idea to me. Questions I had before trying to submit to WP:VPP included:

• Would this submission be optional or "mandatory" (we obviously can't make researchers do it, but we can say they must in policy)
• Would we allow for submissions of IRB approvals for research that have not been discussed on Wikipedia/META first? Put another way could researchers conduct research confidentially but have otherwise submitted their IRB approval to OTRS?
• Where do we put records of receipt of these documents?

There might be other questions too I hadn't considered and would love the input of other users so something formal can be drafted. Best, Barkeep49 (talk) 16:10, 20 December 2018 (UTC)

• As a matter of course, I don't think we should even consider any research proposals that don't have IRB approval from a reputable institution. Per WP:NOTLAB, researchers are required to notify the community in good faith prior to conducting research. (Although I would personally prefer setting up a WP:IRB project, with enough volunteers who are familiar with these types of submissions, and have conducted scholarly research before themselves, rather than doing it at the Village Pump. Or we could set it up on the OTRS wiki for discussion of private information, and have WP:IRB on en.wiki for public notices.) Having said all that, if we require IRB approval as a matter of course, then how do we verify it? The only two answers I know of is ether they make their IRB packet public information, or they send it to OTRS. GMG^talk 16:30, 20 December 2018 (UTC)

  It sounds like we should start a Research Committee (or WP:IRB or whatever) of knowledgeable, interested, trusted editors. Give them a public noticeboard, an OTRS queue, a mailing list, and a spot on OTRSwiki or a private wiki of their own. That group would be responsible for evaluating research proposals and IRB information and deciding to either approve or request community discussion. Their decisions would be posted on a public noticeboard and would have as much public information possible that the researchers are willing to disclose (I can't think of a reason for someone to not be able to publicly disclose the Five Ws about their project, but I'm not all-knowing). Of course, researchers would be encouraged to do everything as publicly as possible, but the RC would still review everything. Giving type of responsibility to random info-en agents who don't have experienced with academic research in the US or elsewhere doesn't seem like a good idea. We'd probably end up with inconsistent decisions. --AntiCompositeNumber (talk) 18:34, 20 December 2018 (UTC)

  I support this broader vision. However, my initial idea is much more modest: simply require that researchers submit an approved IRB document to OTRS. There would be no need for judgement or approvals simply verification, something I would hope any en OTRS agent could do. Best, Barkeep49 (talk) 18:42, 20 December 2018 (UTC)

  I don't think it would be all that subjective most of the time. Mostly it would just verify that someone isn't...well...lying, and would amount to "I have reviewed their IRB submission and response, and can verify that it faithfully matches their on wiki presentation of their research, and that they have received approval."

  But other than that, not sure who would be up for such a thing. I've got experience from back in grad school, but I'm not like an actively publishing researcher or anything. User:Doc James is already on OTRS and might know a thing or two, or some others who might be interested and qualified. GMG^talk 18:53, 20 December 2018 (UTC)

  That's a pretty good idea. I echo that we should not even consider any research proposals that don't have IRB approval from a reputable institution. ∯WBG^converse 19:41, 20 December 2018 (UTC)

  I think reputable is a slippery word. I would suggest we either go with notable (in the sense that they qualify for a Wikipedia article) or accredited (my preferred word though I don't know if it would work in all countries). Best, Barkeep49 (talk) 19:49, 20 December 2018 (UTC)

  Yes IRB approval is more or less required to publish research that involves people in any venue that is reputable.

  Would be happy to verify these via OTRS. An exception should be made of course for the WMF which does not plan on publishing many of the survey's they do. Doc James (talk · contribs · email) 21:39, 20 December 2018 (UTC)

  There was a research committee. I think meta:Research:Index is probably the place to start if you wanted to see if functions similar to that performed by that committee are still performed. --Izno (talk) 21:54, 20 December 2018 (UTC)

Draft Language

Would love feedback on the following draft language before it's proposed

Should Wikipedia:What Wikipedia is not#Wikipedia is_not a laboratory be modified so the last sentence reads:

Regardless of the type of project, researchers are advised to be as transparent as possible on their user pages, disclosing information such as institutional connections and intentions and must either link to their Institutional Review Board approval on-wiki or submit it privately to OTRS at info-enwikimedia.org.

References

New language in green above

The quality subqueue is probably not the right one to use, either info-en@ directly or a specific subqueue would be better. --AntiCompositeNumber (talk) 17:49, 21 December 2018 (UTC)

That was lazy copy and pasting. I agree that it should just be info-en directly and have fixed it above. Best, Barkeep49 (talk) 17:58, 21 December 2018 (UTC)

• If you're not proposing a strict rule, adding it to a Policy page only sows confusion, and bloats policy pages with content that belongs on guideline pages. The important policy is disrupting Wikipedia, even if it's for beneficial research, is forbidden, full stop. It's nice, but not necessary, that the policy also says researchers are encouraged to open a discussion before proceeding. But it's really getting into the weeds, and out of the scope of policy, to offer "advice" or "suggestion" or "encouragement" to disclose or whatever.

  If it's not a firm rule, it should be on a guideline page, and the appropriate guideline is WP:COI. Just add a sentence or two over on that guideline page saying researchers should disclose. It's probably fine for WP:NOTLAB to have a See also WP:COI note, or a footnote pointing to the COI guidelines, if there's reason to fear researchers might not find their way to the COI guideline without it. --Dennis Bratland (talk) 19:36, 21 December 2018 (UTC)

  I'm pretty sure this is proposing a strict rule. Pretty sure NOTLAB already references WP:DE, because I helped write it. Also pretty sure that whether they have a COI doesn't have anything to do with whether we are going to take their word that they've been given IRB approval, or require them to submit evidence that they have. In other words, it's not abundantly clear that you understand the scope and purpose of the proposal. GMG^talk 19:53, 21 December 2018 (UTC)

  Nope. Please see WP:Don't be a dick. If you mean "required to", say "required to", not "advised to" with the hope that everyone will guess you mean the second or third sense of "advised", not the first.

  Yes, WP:NOTLAB currently forbids disruptive research -- which is why it doesn't need to be changed. If anything, the fluffy bits after that need to be moved to a guideline page.

  "Potentially controversial" is a matter of opinion, and if someone fails to post a notice or send an OTRS email, it's plausible that their opinion of what is potentially controversial is not exactly the same as yours. It's all very squishy and too vague for policy. The entire COI guideline page is written to account for the nuanced questions around the topic, and COI definitely has everything to do with using Wikipedia for research. Whether you're using editing for profit, for advertising or promotion, or using it to further your research, you're using your editing privileges as a means to your own ends, not the goal of building an encyclopedia. That is a conflict of interest, and it falls squarely within the WP:COI guidelines. The footnote's words "a competing motivation such as research objectives" means "conflict of interest".

  It's unhelpful to add any such firm rule to WP:NOT or any policy page, and a better idea to add this to the COI guidelines. Perhaps we don't agree, but that's no reason to be a dick about it. --Dennis Bratland (talk) 20:25, 21 December 2018 (UTC)

  So...what does any of that have to do with whether we will require verification of IRB approval, rather than simply taking their word for it? GMG^talk 20:50, 21 December 2018 (UTC)

  (edit conflict)@Dennis Bratland: The sentence under proposed changed here is not the one which differentiates between controversial and not research. It is instead the one that applies to all research (Regardless of the type of project. It is intended to be a rule and WP:NOTLAB seemed like the clearest place to put it such that researchers would find it - however that isn't the important part of the proposal to me so if we move the requirement to different place well that's why we have the idea lab. The footnote which you have issue with exists currently and has not been changed in the draft above and so feels like part of a different discussion of change for WP:NOTLAB. Best, Barkeep49 (talk) 20:55, 21 December 2018 (UTC)

  OK fine. Still be better to take the last two sentences from the existing NOTLAB paragraph, and this addition, and move them to the COI guideline page. --Dennis Bratland (talk) 21:53, 21 December 2018 (UTC)

I like the direction this is going in. However,

1. I think it's important that this is binding, not merely a guideline.
2. In addition to institutional connections, there should also be a requirement to publicly disclose all sources of funding. See WP:VPM#Relation_to_Facebook (permalink) for an illustration of why this matters
3. The policy should clearly distinguish between research which involves participation in Wikipedia, and research based on existing content. The CCSA licensing means that anyone anywhere is free to use all existing content for nearly any type of research. We can only restrain research which involves intervention in Wikipedia. --BrownHairedGirl (talk) • (contribs) 19:39, 31 December 2018 (UTC)

There was at least an attempt to make the distinction in point 3 in the original formulation of NOTLAB, distinguishing between non-controversial content analysis and potentially controversial intervention based research. Whether or not that is effectively addressed in the existing text may be a matter of disagreement. GMG^talk 19:47, 31 December 2018 (UTC)

Thanks, @GreenMeansGo. However, I don't think that "controversial" covers the distinction.

The CCSA license means that existing content can be analysed in pretty whatever way the researcher chooses, even if most Wikipedians object bitterly. Policy can't override that license.

So I think we need to use wording which explicitly focuses on interventions. --BrownHairedGirl (talk) • (contribs) 21:35, 31 December 2018 (UTC)

I propose "Interventional human subject research is not allowed." Vexations (talk) 22:21, 31 December 2018 (UTC)

The problem being that this type of research will be conducted anyway, and without community input, will be more disruptive than it otherwise would be, and will not be identified to the community until it causes disruption. GMG^talk 22:32, 31 December 2018 (UTC)

BrownHairedGirl and Vexations I would love suggestions on language to make clear that this binding and not a guideline. It read that way to me (and NOTLAB is policy), but since several editors have commented to the contrary perhaps it could be further strengthened. While I think we could do more to improve research practices on Wikipedia, my initial version of this had more changes including research noticeboard, I intentionally decided to keep it go for an incremental change. I think mandatory IRB disclosure felt like something that the community could get behind while continuing to workshop and come to consensus on how to address the larger problems you two have brought up. Best, Barkeep49 (talk) 02:37, 1 January 2019 (UTC)

BHG's Draft Language

Based on WP:NOTLAB, as of revision dated 18:42, 31 December 2018‎

Display: Text added ... deleted text

Research about Wikipedia's content, processes, and the people involved can provide valuable insights and understanding that benefit public knowledge, scholarship, and the Wikipedia community, but Wikipedia is not a public laboratory.

Research that analyzes articles, talk pages, or other content on Wikipedia is not typically controversial restrained, since all of Wikipedia is open and freely usable. However, those conducting such research are kindly requested to submit their proposals for community input at WP:WHEREVERWEDECIDE.

However, research projects that are disruptive to the community or which negatively affect articles—even temporarily—areHowever, research projects which involve any edits on Wikipedia may be disruptive to the encyclopedia or to the community of editors. This applies whatever the type of page is edited, and includes edits intended to be temporary. Disruption is not allowed and can result in loss of editing privileges. Before starting a potentially controversialinterventionproject, researchers should open discussion at the Village Pump to ensure it will not interfere with Wikipedia's mission. Regardless of the type of project, researchers are advised to be as transparent as possible on their user pages, disclosing information such as institutional connections and intentions, and their sources of funding. Reserachers must state whether approval has been sought from an Institutional Review Board, and if so they must either publish that response on-wiki or submit it privately to OTRS at info-enwikimedia.org

Some editors explicitly request to not be subjects in research and experiments. A list of some of those editors can be found here. Please respect the wish of editors to opt-out of research .

References

---

That incorporates some of the ideas discussed above.

In summary, it amounts to a loosening of restrictions on analytical research, and tightening of requirements for "intervention research". --BrownHairedGirl (talk) • (contribs) 03:31, 1 January 2019 (UTC)

I think there's a lot of good stuff above. But it feels much larger in scope than what I had originally mooted and I think more incremental, rather than fundamental overhaul, would be better received by the community right now. Best, Barkeep49 (talk) 18:51, 1 January 2019 (UTC)

• I like BrownHairedGirl's proposal; I think the original , involving chiefly the requirement of an IRB, is against the spirit of WP.

1. It rules out unaffiliated researchers, which is totally contradictory to the spirit of wp. It also effectual rules out any really small-scale studies.

WP software is constructed in considerable part by unaffiliated volunteers, and wp content is entirely constructed by unpaid volunteers (or at least is supposed to be)

Many volunteers and unaffiliated people have skill and experience in technical research, or information science research, or social-science research. (I , for example have no institutional affiliation since retiring, but I've taught research methods and participated in IRBs).

Unaffiliated people will generally not have the resources for a very large scale study, but that doesn't rule them out entirely.

2. This being WP, part of our goal is to encourage the greatest possible widespread participation in all aspects of the project, with the only limitations being competence and willingness to follow the rules.

WP encourages not just people doing major bodies of contributions, but those who may want to do just a little, agains subject to competence and following our rules.

from my experience, the overhead of needing the involvement of a IRB makes such small project impractical.

3.we do need rules: the relevant rules apply to two aspects: research involving possible or deliberate disruption, and privacy, in all the senses we mean it on WP.

To the extent we don't already have rules about that, we need to. that is what would be constructive.

BHG's suggestion above is a very important start to systematizing these rules.

the harder step will be communicating them.

4.WPwas founded on the basis of being as little institutionalized as possible, and as little professional as possible.

Many of us, and in particular very many of the earlier participants, joined with the explicit intention and desire to be involved in an non-insistutionalized project, driven by the volunteers, with the basic rule of IAR.

with the growth of the project way beyond initial expectations, some professionalism has proven necessary.

there's a widespread feeling (which I share) that it has already gone way too far.

It may not be possible to reverse this, but it shouldn't be encouraged.

we therefore want to allow and control research and other work done by professionals, but to actively encourage work done by non-professional amateurs. DGG ( talk ) 19:52, 1 January 2019 (UTC)

@DGG: There might be a way to tweak this (and if there is I want to find it - that's what VPI is for after all) but I don't think it's unreasonable for Wikipedia to say that Wikipedians are not test subjects there to be experimented on willy nilly. Ethical consideration should be given before conducting research on humans. The IRB process serves to give that consideration. If there is someone who doesn't have that kind of institutional support and they want to do research there is plenty of data freely available on Wikipedia. So they can, to pick a 2018 research that has already been cited by others discover how Wikipedia influences science writing without any need for IRB (though those researchers would have had access to one). Wikipedia should absolutely support research on Wikipedia. Wikipedia should be far more cautious about research on Wikipedians and since we lack some institutional structure and know-how to do it effectively I think ensuring that a properly constituted IRB has considered the ethics strikes me as an eminently reasonable balance. Best, Barkeep49 (talk) 00:14, 2 January 2019 (UTC)

IRBs are one way, but they are a way which excludes about 90% of the community. People should be allowed to do any research within their technical abilities, and that follows rules that apply to everyone. I might, as a deliberately remote analogy, find a very clever way of handling something, but it only work on roman alphabets. DGG ( talk ) 01:27, 2 January 2019 (UTC)

I generally agree with DGG. (Sorry I'm late to this party) I think that the current proposal puts too much emphasis on IRBs. FWIW, IRBs would be fine with a researcher contacting the 500 most active Wikipedians to survey them about their motivations. But from our point of view, that is a ridiculous waste of energy for 500 busy people *and* there's already plenty of survey research about editors motivations. It's not an IRB's job to make sure that Wikipedians aren't fatigued and that the research isn't just duplicating past work. It's the IRB's job to protect the university from lawsuits WRT research ethics. In my experience, we get a far more effective review for the ethical considerations and impacts on WP by asking researchers document their study on meta and post about their plans on the village pump -- which has been the status quo that has been working for nearly a decade. Generally, I'll refuse to help a researcher who has is at an institution with an IRB, but has not been approved for human subjects research. But I'm happy to help someone who does not have access to an IRB to describe, announce, and seek approval for their interventions on Wikipedia.

• I have zero confidence in the ability of OTRS volunteers to handle this process. If this is to exist, it should be done at the official level with the WMF and a paid staff contact person. TonyBallioni (talk) 04:20, 2 January 2019 (UTC)

• I agree with Tony here. As an OTRS volunteer (even one with some IRL experience of ethics procedures), I would not be happy taking on this responsibility. I would be surprised if the WMF's legal team was happy with it, either. Cordless Larry (talk) 09:45, 2 January 2019 (UTC)

• While OTRS is able to certainly able to verify the existence of any document, and agents can probably be instructed on how to verify the authenticity and reputability of such a document, there is an open question about if this is sufficient oversight. I can foresee many situations where I would want the Arbitration Committee's involvement (research likely to breach policy, etc), and I don't think the verify, tag, walk away approach we use with username verifications is really going to work here. TheDragonFire (talk) 06:09, 2 January 2019 (UTC)
• I am glad that @ DGG picked up on my making an IRB non-compulsory. I should have explained it more when I posted it, but my thinking is very much akin to DGG's view that an open, non-professional project such as ours should insist of professional credentials from those who want to study us.

I also have very little faith in IRBs. They have not restrained the vast academic research which has developed the human manipulation which underpins the advertising and social media businesses, as recently summarised in journalistic form by George Monbiot. So I don't regard IRBs as an important screening factor.

Given the comments by @Cordless Larry and others about the lack of capacity of OTRS to handle IRB verification, I would be happy to simply drop the idea. --BrownHairedGirl (talk) • (contribs) 09:02, 4 January 2019 (UTC)

I'm strongly in favor of saying that "IRB approval is required if applicable". If you're performing research with an affiliation that *has* an IRB, it's more than reasonable to ask that you have received their approval. IRBs general ask for the same types of documentation that we want. "How will you recruit? What questions will you ask? How will you store the data?" I insist that academic researchers provide a study approval number and a phone number for their IRB on the study description page on meta. This allows anyone to call to confirm their IRB approval status. That has worked pretty well for the last several years. By requiring that researchers post this information openly in a way that can be easily verified, there's a strong incentive to not lie about it. Ultimately, community review on Wikipedia is where we'll catch potentially disruptive studies, so letting researchers who do not have access to an IRB continue will still allow us to effectively filter for problematic research. --EpochFail (talk • contribs) 16:56, 17 January 2019 (UTC)

• It makes no sense to have a requirement for community notification for conducting passive observational research. This is explicitly allowed under our license, and under that license is no different than simply reading Wikipedia. By publishing under that license, we have already waived any advise and consent role we may have had as a community, and we have done so irrevocably.

If researchers who are not affiliated with either the WMF or an institution with an IRB wish to do passive observational research, they are more than welcome to, as again, the content of Wikipedia is freely available for anyone to use for any purpose. If unaffiliated researchers want to do research that involves interaction with human subjects on Wikipedia (which includes changing article content), then they need to affiliate themselves with the WMF or another researcher with access to an IRB. If they do not wish to do either, then they need to design a different type of study.

We can argue all day about particular instances where IRBs have approved studies we personally feel that they ought not have done. However, if you cannot get approval at this most basic level of academic oversight, then you ought not be doing it here. Wikipedia is not a "plan B" for research deemed too unethical to get IRB approval. GMG^talk 13:22, 4 January 2019 (UTC)

GMG's thinking closely mirrors mine. The original proposal was meant in no way to hinder what he calls observational research. It was, and is, meant to ensure that research on live human beings, which is what research that aims to examine editors either directly or through their response to changes in articles, needs ethical consideration. The WMF or an IRB should be performing some level of that dilligence. If it's an IRB then we should not just take researchers at their word that they have done this but verify that this has really happened. People have brought up OTRS agents not being qualified to do this work. On one level I get it. But on a deeper level I would think some level of mandated ethics review is better than none - with none being our current requirement. If OTRS agents are not qualified than the community at large is certainly not qualified which would make doing this on META or here unwise. Longterm we probably could use some sort of Wikipedia IRB. I see this as an incremental stage/step in building towards whatever version of that we would have. Best, Barkeep49 (talk) 01:53, 5 January 2019 (UTC)

Background

Support any researcher who can do their research without Wikimedia community notice or interaction. Analysis of already public data without any contact to the wiki community is awesome!

Push back on researchers who want to interact because of "research fatigue"! Almost all researchers which the Wikimedia community notices are disruptive and will not produce anything positive. When Wikimedia community members interact with researchers, that interaction fatigues them, which means that the community member is less likely to interact with future other researchers. When we let bad research fatigue our community, then that diminishes the pool of community members who would support good research. Historically, most researchers are bad because they ask for a lot, give little or nothing back, and have no self awareness that they are causing problems. The social context of this is a generation / culture change. Even now, researchers and IRBs lack the awareness to understand that online communities like Wiki editors matter, so they cannot imagine hurting these communities. Also, they imagine that the wiki community is much larger than it is. In English Wikipedia we have about 10,000 highly active editors. Typical researchers when asked will guess that we have about 10,000,000 highly active editors, so they see nothing wrong with designing a study which advertises to recruit 1000 of them.

1. In ~2016 there was a meta study which summarized 3000 Wikipedia academic publications. I cannot find this citation...
2. Besides those 3000, 10x as many studies jump into Wikimedia projects, do analysis and disrupt Wiki and its community members, then do not properly publish findings
3. Perhaps ~300 research studies which are disruptive enough to meet the United States academic standard of requiring IRB review happen in English Wikipedia a year
4. This is a nuisance but we have no community infrastructure to manage this
5. Only the Wikimedia community can take leadership here. WMF staffers will not resolve this or conduct review, etc. and will only support Wikimedia community decisions.
6. Many research projects affect multiple Wikimedia projects, even if the researchers themselves say "only English Wikipedia". Probably the guidelines need to go on meta and be cross language, cross project
7. There already is a lot of documentation on meta. The center is currently meta:Research:Index. Many deprecated and halted subprojects exist, such as meta:Research:Committee.

Current best practice:

1. Direct all researchers to complete meta:Research:New_project
2. Determine whether the researchers intend to interact in any way with Wikimedia community members.
   1. If they do, then they are dangerous!
      1. Insist that they have Wikimedia accounts and orient themselves to Wikimedia projects first
      2. Insist that they make commitments to publish in the open
      3. Ask for anything else - their IRB, more documentation, etc
   2. If they do not, then ask for documentation on meta but leave them to their non-invasive, non-interactive data analysis.
      1. Hit them up for open access publishing, but they can do what they want
3. No private data available, so tell them! In general, projects with a research budget of less than ~US$30,000 + paid staff will not be able to get access to private Wikimedia data. If someone actually wants this then generating massive on-wiki documentation up front and showing evidence of a well-oriented Wikimedia account as a prerequisite should not be a problem.

In general, consider researchers as WP:COI editors. Researchers are greedy, clueless, uncaring, disruptive time sinks. Set boundaries and assume the researchers will never publish, will never use anything that anyone gives them. Researchers are especially predatory on minority groups - women, LGBT+, highly active editors, multilingual editors, and other community members whom we want editing wiki and not throwing their labor down a research hole which will never be published.

The most common research project is "Get 50 highly experienced Wikimedia contributors to pause editing Wikipedia, and instead each spend 1-3 hours explaining Wikipedia basics to researchers who do not have Wikimedia accounts and who have never edited." The typical outcome of this kind of research is to disappear without publishing anything. Researchers have done this project thousands of times and it continues to be extremely popular.

Blue Rasberry (talk) 14:45, 2 January 2019 (UTC)

100% support for Open access. WP:5P3 : "Wikipedia is free content that anyone can use, edit, and distribute". I see no reason why Wikipedia:Reusing Wikipedia content would not apply. Also support the other points eloquently made by Bluerasberry which hadn't previously occurred to me. Cabayi (talk) 14:10, 5 January 2019 (UTC)

Bluerasberry, I agree with most of your points. But I think you're maybe painting an unfair picture. E.g., "Researchers are greedy, clueless, uncaring, disruptive time sinks." I've been working with researchers to help them run studies on/around Wikipedia for nearly a decade, and I would say that I have to disagree. I think researchers are sometimes clueless, but they rarely uncaring and greedy. I can name two researchers (out of ~100) who I've found to be uncaring and greedy -- proposing that they run their policy-violating research in secret to avoid review and not listening to me when I advised against it. In those cases, I've notified the relevant people to ensure that they would not be able to cause harm. 2% greedy and uncaring is something we should be prepared for, but let's not paint the picture that most are that way. I also disagree that only 10% of Wikipedia intervention studies and result in a publication. I'd say it's more like 90-95% publish and that 50% of those actually publish something that is valuable to us. Maybe my sample is skewed because I'm working with researchers who either found me and asked for help or were directed to me by Wikipedians who wanted them to follow a decent process for performing their research.

One thing I really like about what you have to say though is drawing a line between researchers who have become Wikipedians and those who have not put the time in. E.g., User:Andicat (sorry to bug you, Dr. Forte) is one of the most experienced Wikipedian researchers I know. She's careful to ensure that her studies benefit Wikimedia broadly and that her students are well informed about the kinds of activities that Wikipedians will find disruptive. Working with researchers like her and her students is really very easy for me. They already get it and want to contribute productively. I wonder what considerations we might give to ensure that these types of researchers not prevented from continuing their work. I'm also interested in what kind of work I could assign researchers who are not Wikipedians (other than registering an account and disclosing their affiliations/funding) to do.

Final note. +1 for Open access. Should we require that researchers clearly state that their results will be published open access? Surely we will struggle to hold them accountable if they don't eventually publish anything or they don't pay the open access fee at their journal/conference/whatever. But we can prevent them from running future studies. I find that most researchers who get involved with Wikipedia run repeat studies and they will value not tarnishing their name with our community. If we simply say we demand open access and then check up on people periodically (which I would do if we wanted something like that), then it will happen the majority of the time. It's really just me and Jmorgan helping these researchers out AFAICT. I would love if we could form some sort of committee for helping to enforce policy & support researchers so we can distribute the load and not just have two white guy/professional researcher/WMF staff members in charge. Either way, I'll help enforce policy, so if we we can get this stuff written down and formalized, I think it can work. --EpochFail (talk • contribs) 16:11, 17 January 2019 (UTC)

I also like the idea of resurrecting some sort of research committee, and would be happy to participate. I have some questions/comments.

1. If we're going to go through the trouble of setting up a research committee, it should be designed from the outset to support all projects, not just English Wikipedia. That means that the committee is available to provide guidance to researchers who are working outside of EnWiki (whether or not the project they're focusing on has a NOTLAB equivalent), and can also serve as a community-wide noticeboard where concerned community members can report disruptive researchers or suspicious research projects.
2. We have an active channel for community wide research discussions in wikiresearch-l. Many experienced academic researchers are on that channel, as well as knowledgable/interested folks who are not professional researchers. If we're requiring (or strongly suggesting) pre-review of research proposals, they should be posted there; not everyone watches meta:Research:Projects. If we want academic allies like Andicat or Benjamin Mako Hill to weigh in (and we definitely do), that's the best venue.
3. What about research performed by community members and movement affiliates? If Wikimedia Australia wants to post survey links to the talkpages of people with the "Australian Wikipedian" userbox or something, do they need to go through this process? In my experience, interventionist research by movement volunteers or affiliates (surveys, interviews) can sometimes put editors at greater risk than research by academics, because they may (in good faith or inadvertently) ask for unnecessary PII, store data for too long and/or in insecure ways, or use "free" survey tools that hoover up lots of metadata about survey respondents. Having training and an institutional affiliation is not a guarantee against this, but does provide some safeguards.
4. I believe that IRB approval is a useful and effective mechanism for screening out potentially disruptive/harmful research proposals. All of my academic research on Wikipedia was subject to IRB, as is all the research performed by people who collaborate with the WMF Research team. At UW, even research I performed with Wikipedia data (non-interventionist) got reviewed by IRB, although they always ruled it "exempt". So I like the proposal by GreenMeansGo and Barkeep49 because it seems like a fairly robust and straightforward way to filter out the less responsible academic research: IMO if you are affiliated with an academic institution, and you want to research Wikipedia, then the burden of proof is on you to justify why you have not submitted your proposal to your local IRB. Many non-academic institutions also have internal review boards or processes. Whether OTRS is the right system, and/or OTRS volunteers are the right reviewers, is a different question I guess. As is how to handle research performed by independent researchers who are not already movement volunteers or affiliates.
5. Concerns about funding sources are often overblown. The fact that some grad student is getting their tuition and stipend paid through a Facebook grant (to pick a completely random example) is generally all smoke and no fire. For example, my own first three years as a Wikipedia researcher were technically funded by (no shit) IARPA, although it was non-interventionist and all of the outputs of that research were open access and free licensed—by the terms of the grant. But I'm probably not a spook :) So by all means ask for this if you want to, but know that it's probably not important from a risk assessment perspective. What is important is that the researchers are transparent about their activities, that their research is vetted by a professional body that knows something about ethics and the law, and that the researchers are clear about the kind of data they will collect and the terms under which it will be stored (e.g. where, in what form, for how long, who has access).
6. I agree with many of your points, Bluerasberry, but if the majority of the folks involved in policy/process discussions share your belief that "Researchers are greedy, clueless, uncaring, disruptive time sinks" and that "Most researchers are bad", then I have trouble imagining how this conversation can move forward in a productive manner. I think we can develop better processes that will reduce research fatigue and (IMO, much more importantly) reduce risk of harm to Wikipedia contributors. But we can only do it if researchers are willing to work with us. Even good researchers may make a pragmatic decision to avoid abiding by community norms and policies if they feel they are unlikely to be treated fairly, viewed as bad faith by default, or subjected to arbitrary demands or an uncomfortable degree of personal scrutiny. Do we want a process that educates researchers, empowers the community, improves the state of free knowledge, and mitigates many potential harms? Or do we want a process that consumes a lot of time, thought, and emotional labor for everyone involved and ends up punishing the people who try to be good while letting those who don't care continue to do whatever they want? J-Mo 21:22, 17 January 2019 (UTC)

Propose to put researchers into Baby walkers

@Jtmorgan and EpochFail: There are positive ways forward. I still say that researchers, toddlers, and COI editors are greedy, clueless, uncaring, disruptive time sinks. By nature all of these are supposed to be selfish, and that is fine. They all deserve the same treatment, which is that they should either closely conform to instructions from authority or otherwise expect to be made to conform if they cause a problem. Researchers are Wikipedia:Not here to build an encyclopedia. Like COI editors, they always have a funding stream tied to their accomplishing their goal, and they are prone to selfishly disrupting the peace. Babies at least do not know better and can be cute about this. COI editors and researchers have no such excuse.

I welcome any researcher who can do their work without disrupting Wikimedia community spaces.

For researchers who will disrupt Wikimedia community spaces, they can come here but only if they give the same respect to our community than they would for an in-person community at their own institution. The worst part about research disruption to me is when researchers dehumanize online communities and do disruption here in Wikipedia that they definitely would never think to do in their own communities.

1. Determine if there will be any Wikimedia community interaction. If no, then forget the rest. If yes, proceed.
2. Complete meta:Research:New_project
3. From this point forward, researchers should treat Wikimedia community members with the same respect that their institution (e.g. university) requires that they treat people in person. Digital communities are not second-class, and people online deserve the same respect that IRBs require for people in person.
4. Anywhere on wiki that a researcher appears, they have to link to their meta research page. We require disclosure of COI editors, and similarly, we should require disclosure of researchers who are consuming Wikimedia community member time.

Is this too much to ask? Blue Rasberry (talk) 20:38, 20 January 2019 (UTC)

Why is meta a better place to get ready for en Wikipedia research than somewhere on Wiki? It seems like that is a smaller pool to play in, which can mean that even researchers who follow that process run into issues once they go live here. Best, Barkeep49 (talk) 00:39, 21 January 2019 (UTC)

The photo is particularly funny in context. Bluerasberry used to work for Consumer Reports, which disapproves of all baby walkers on safety grounds. WhatamIdoing (talk) 19:46, 21 January 2019 (UTC)

Bluerasberry that is not too much to ask. I think it is a very good process as evidence that it has been working for a very long time. And FWIW, this is exactly the process that the researchers who started this discussion followed. They determined that there would be community interaction. They completed a project description on meta using the templates I created at m:R:New project. They reached out to English Wikipedians on the Village Pump. They discussed the concerns that people raised and proposed alternative study designs to try to address the concerns. Eventually things got heated. So the researchers decided to withdraw their study proposal. So what gives? Why are we looking to add new policy and process on the back of a clear success of the old process? Researchers followed the process, concerns were raised, and researchers withdrew their proposal. Good! --EpochFail (talk • contribs) 15:41, 23 January 2019 (UTC)

@EpochFail: A major problem here is the lack of documentation and community conversation. I think it is correct that even in this conversation, we are not naming or linking to the research project which incited the discussion. Without some freedom to have conversation I think we should expect the present success:failure ratio to be the norm. Like you said, the process has mostly worked in the past, so if for example only 10% of research projects cause big problems, then maybe that is the norm for our infrastructure.

I have a bias in that I only come to notice research projects which escalate with problems. So far as I know, no one has big picture data about how many problems have occurred among all research, or how important the failed projects were, so it is hard to guess how serious the problem here is.

Even if there is one research project with a problem, that probably is the lost of at least US$30,000 in value measured by university resources invested, and more realistically any research project with its own institutional IRB approval which comes to Wikipedia is someones 300+ hour project and a US$100,000 entanglement. Even when cash money is not in play researcher time has value we should seek to capture, even from students.

If you could come up with a money estimate of what it is worth to have a friendly research environment and what is lost from research failures, then maybe that could inform the response we create.

I frame this as an investment problem with COI editing in mind, which I feel is the usual social problem associated with research. When Wiki people complain about research it is typically about some unfairness and perceived exploitation from the research, which is analogous to why Wikimedians conflict with COI editors. Researchers ask for a lot and tend to undervalue the Wikimedia community volunteer labor they request, and COI editors do the same thing. Although I do not have data about ratios of research success, I know the success rate for COI editors: ~5 million attempted users doing COI edits, and 0 success stories. There has never been a model COI editor and after all these years COI editing remains a dirty business. Maybe research has something figured out that the entirety of the marketing and communications sector has not, but I think the place to start the conversation with researchers who seek to do disruption is that they should have a baseline expectation of being grouped with COI editors. Lots of researchers navigate around this, but I am not aware of model cases of research which anyone showcases as the ideal model of research and community collaboration.

I favor some kind of infrastructure investment being made to increase research success rates, but I am not sure what that is. It probably includes the creation of documentation and convening some community discussion. I think it begins with some evaluation of the value of what is at stake here. Blue Rasberry (talk) 15:41, 24 January 2019 (UTC)

Have a care with your absolutes. I have seen multiple model COI editors. --Izno (talk) 18:40, 24 January 2019 (UTC)

To quickly to address Barkeep49's question about posting study designs on meta. It's very beneficial to have one repository of all of the research activities. WMF staff (like myself when I'm wearing that hat), academics, and volunteer researchers alike all make wiki pages with the same templates to describe their proposed, ongoing, and completed research activities. Many of these research projects are cross-wiki or at least not enwiki specific, so meta is probably the best place to have such a repository. The general protocol is to create the documentation on meta and post announcements/hold discussions on the target wiki for the research, so we can try to reap the best of both worlds. Given that user accounts work seamlessly cross-wiki, it seems like the cost of having documentation on meta is minimal. --EpochFail (talk • contribs) 15:41, 23 January 2019 (UTC)

On the one hand that makes complete sense. On the other hand I think about meta:Research:How much do Wikipedians in the US value editing Wikipedia? which ran into somewhat predictable flack when they emerged from META, with its relatively few eyes, onto Wikipedia with its many more eyes. I think I've shown an interest in this topic, but META simply isn't a part of my editing routine in the same way that checking out various places on WIKI are. I don't think that this experience is unusual and so reaching the right pool of editors who have expertise on this topic (a category I would not include myself in) is going to be harder simply by it being just that little less accessible on META. Best, Barkeep49 (talk) 16:30, 23 January 2019 (UTC)

Barkeep49 meta:Research:Projects has a reverse-chronological feed (of sorts) set up and IME it's pretty easy to check for new proposals, and even recent discussions. J-Mo 01:38, 24 January 2019 (UTC)

Indeed it does. But that's not my point. Best, Barkeep49 (talk) 02:11, 24 January 2019 (UTC)

Barkeep49, sorry, didn't mean to misrepresent your point. FWIW I agree that Meta isn't ideal for this (is it ideal for anything?), but I share EpochFail's position that if we're going to put effort into revising research processes, we should do it in a way that benefits all the wikis. J-Mo 21:14, 24 January 2019 (UTC)

And I am sorry for being a bit snippy in my reply. It's a tricky thing. Promoting research across Wikimedia projects is a noble endeavor I support. But, again honest question, would the research projects which are active experiments on behavior, that is the kind most likely to be troublesome as opposed to research that involves voluntary interviews or retrospective studies which are clearly permitted under the CC BY-SA license, receive the necessary scrutiny at META, especially when those kinds of studies (discounting WMF work), from what I've looked at over the last couple of years, seem to be aimed at EN? I worry they wouldn't and so by all means let's beef up META, but that doesn't mean EN couldn't/shouldn't go beyond that given our policies (NOTALAB). 00:26, 25 January 2019 (UTC)

Barkeep49 I see your point. Just to close the loop on this set of points (at least in terms of my stance on the issues, I guess): My biggest concern WRT research that involves interaction with communities is probably somewhat different from yours, and from that of Bluerasberry and some others in this discussion. I am most worried about people being irresponsible with research data—for example, asking for personal information in survey responses and interviews, and then either sharing that data in a way that violates privacy or personal security or using that data for nefarious things. This is something IRBs can help vet, and it's one of the reasons people like EpochFail and me want to centralize project proposals in a place like Meta for ongoing monitoring. Personally, I'm less concerned about the dangers of "interventions" like the Barnstar study that set this conversation going. I thought that study had methodological problems, but I didn't (and don't) think it was likely to be fundamentally disruptive or harmful to individuals or the community as a whole. I can't think of an example off hand of any previous intervention research from external researchers that I thought was likely to harm individuals or cause substantial disruption. At least, no more disruption than a poorly-done product launch from WMF... something we have at least gotten better at in the past few years. Not to say there isn't potential for evil intent or disruption in these studies, but so far it seems to be relatively rare, or at least so cleverly disguised that it's never uncovered after the fact (in which case, the whole idea of community oversight is kind of moot). What keeps me up is not a poorly executed experiment that spams some editors' talkpages with undeserved barnstars. What keeps me up is someone gathering personal information from editors under false pretenses and exposing them to real life risk like doxxing, profiling, surveillance, or physical or psychological harm. To illustrate my point, take Facebook: the Cambridge Analytica scandal and the emotional contagion study were equally creepy and wrong, but the CA scandal was far more damaging. J-Mo 00:47, 4 February 2019 (UTC)

@Jtmorgan: We are in complete agreement about the perils of unethical human research. It's what spurred me to post this after reading GMG's comment in the first place. We need more robust protection against the kinds of studies you discuss. Best, Barkeep49 (talk) 02:18, 4 February 2019 (UTC)

IRBs

GMG wrote: "I don't think we should even consider any research proposals that don't have IRB approval from a reputable institution."

I'm a little surprised at this, and I'd like you to reconsider. IRBs only cover a small fraction of research. Under US rules, you can only get IRB approval if you're doing "research" (usually defined as "systematic investigation to produce generalizable knowledge" or some such phrase) that involves either an intervention with living people (e.g., clicking the thanks button to see whether that prompts more edits) or collecting identifiable private information about living people (which would require either WMF assistance or direct cooperation by individual editors, e.g., by filling in a survey form).

Banning anything without IRB approval means banning researchers from asking editors how Wikipedia works, or from interviewing the old hands about how (wildly) different Wikipedia was back in the day. (This is "not research" in IRB terms.) It means banning researchers from looking at the number of links between articles, or how long maintenance templates stay at the top of articles ("research not involving human subjects"). In practice, it would also mean banning all citizen science. I think that this would be a very bad standard.

As for verifying it, in the small fraction of cases that actually need it – not getting IRB approval when you need it is Very Bad, and lying about having approval when your institution requires it and you don't have it is pretty much a career-ending mistake. When we're talking about professional researchers, they'll want to publish the results. It might be worth asking (sensible answers include (a) it's not technically 'research', (b) it's 'research' but it's not technically 'human-subjects research', (c) yes, we've got it, and (d) we're still working on it), but I honestly don't think we need to bother verifying the responses. WhatamIdoing (talk) 20:12, 21 January 2019 (UTC)

@WhatamIdoing: That's not quite exactly what I meant. As has been stated elsewhere, purely observational research is explicitly permitted by the license that everything is published under, including talk page discussions. There's nothing we can do about that, no real way to tell it was even happening, and no reason to object even if we could. The particular research I was talking about is precisely "intervention with living people", i.e. editors. Now it's been ten years since I've been near an IRB, but I assume that much hasn't changed.

Yes, not getting IRB approval for research you intend to publish is a big no-no, a potentially career ending no-no, but glossing over potentially controversial aspects of your proposed research when presenting it to the community may not be, and even so, you know as well I do that there are plenty of less-than-reputable researchers as well as institutions out there. But even for reputable institutions, that you can get IRB approval for your research proposal may not mean it is suitable for Wikipedia, but if you can't then that raises massive red flags that we don't want that on our projects.

As for "Steve in his basement" that has a bright idea for research over some particularly strong coffee, and decides Wikipedia is right place for it (as User:DGG seems to allude to above, although in entirely more cynical terms) we're not Steve's open source laboratory. Steve needs to find an equally over-caffeinated actual researcher with affiliation with an IRB to approve his proposal for research involving human subjects, or Steve needs to go do something else with his time. GMG^talk 20:41, 21 January 2019 (UTC)

• What if DGG himself wants to do a little research project, maybe to find out whether using Template:Welcome was better than clicking the Thanks button? Your rule would prohibit him from doing that.
• It sounds like what you meant might have been more precisely phrased as "We shouldn't even consider any proposals for interventional experiments that have actually been rejected by the researchers' IRB for cause". I agree, but I doubt that this is relevant. Can you actually imagine any academics proceeding with research that their IRB had actually denied? WhatamIdoing (talk) 21:38, 21 January 2019 (UTC)

• @WhatamIdoing: But we're not really talking about DGG are we? I did happen to see DGG give a talk in Columbus, and he's one of a few dozen editors where I have a face to go with a name. But what we're really talking about is "some dude on the internet". There are several reasons why do don't wan't some dude on the internet doing research on human subjects without any oversight. For the most egregious, go to any intro to research methods course. Even if they're doing good research, we don't really want them to take up community time if we don't get any benefit, which means publishing, which means an IRB. Even if they're doing good research, we have no reason to believe that it's not unnecessarily duplicative (wasting community time) or that the person doing so has at all the statistical skills to analyse the data they're gathering (waste of community time also). Can I imagine someone proceeding with research that has actually been denied by an IRB? Well I sure as hell can imagine someone forgetting to apply until it's pointed out to them. GMG^talk 23:07, 21 January 2019 (UTC)

If we're quite literally talking about DGG, or an editor of similar standing, he/they would, likely, be able to get WMF sanction in some way that would obviate the IRB need. But well intentioned researchers have caused negative things in the past when not fully considering the ramifications of their research on humans (and on Wikipedia) and since that's not what Wikipedia is about, I am 100% OK with making it more difficult to effect experiments on humans; this in no way prevents retrospective studies, as GMG says. Best, Barkeep49 (talk) 16:20, 23 January 2019 (UTC)

GMG, I'm not sure about the bit in your reply that runs "which means publishing, which means an IRB". First, academic publishing isn't the only way to produce a benefit. See, e.g., the entire Research: namespace at Meta. Publishing the results on wiki does more direct good for most editor than trying to generalize it into overall human behavior. Second, I'm not sure that IRB approval is actually required for publication. I'd be surprised if Emily Rosa's famous research was approved by an IRB.

On a separate point, I don't think that we can assume that all interventional research "wastes", or even significantly expends, community time, even if we assumed that replicating previous research was bad, which it isn't. IRB approval doesn't care about those factors, anyway, so that would be irrelevant. You seem to be wanting some agency to pre-screen research projects for stupidity and pointlessness and incompetence, and that's not what an IRB does. WhatamIdoing (talk) 02:03, 24 January 2019 (UTC)

@WhatamIdoing: I feel like I've been arguing about this for two months, mostly because I have, and over a half dozen threads, it doesn't look terribly like it's going anywhere one way or the other. For the comment on replication, that's just not what I said. For Emily Rosa, that's great for her. Good job. Wikipedia is still not a place for nine year olds to come tinker in case we happen upon a prodigy. For everyone else, Wikipedia is not an open source laboratory; it is a crowd sourced encyclopedia. Interventionist designs can be assumed to waste community time as a matter of definition, unless they directly affect our ability to build a better encyclopedia. I do want some agency to screen for stupidity and pointlessness and incompetence, that's why I've been rambling on about an internal review board for a year now, but you can see how far that's gotten me. I also want a board in the real world to screen for basic competence and ethics, which is what an IRB does. GMG^talk 23:13, 24 January 2019 (UTC)

I would agree that for someone whose position requires that their work be supervised by an IRB to proceed with work they rejected is certainly not a good thing--but no academic in their right mind would do it, however frustrated they might feel, because it would terminate their career. And since we can not assume IRBs understand the particular privacy conventions of WP, nor our policies about disruptive editing, nor ourr ules about multiple accounts, we should require our approval also. But just as we are open to amateurs to write, we should be open to amateurs to investigate, if they do it properly. We as a community are perfectly capable of understanding our own privacy requirements, and sour rules about disruptive editing. . Whether the work is otherwise methodological sound, and whether it is well-designed to give some possibility of a meaningful result, can be more difficult questions for the general community. There's a sense in which they are not our immediate concern,, but on balance I fell we need to at least comment on this also. There are several hundred WPedians whom I would think qualified to comment (the only difficult is that many of them prefer not to use their credential or even real names on WP , so we can not judge whom they might be, but I think if there are general community comments, we an do as we do in editing, judge the quality of their knowledge by the `uality of their comments. DGG ( talk ) 04:19, 22 January 2019 (UTC)

If someone is affiliated with an institution with an IRB, we of course want to see approval by that IRB as a part of their proposal. However I seriously don't think we want a policy that prohibits us from consensus to approve a clearly harmless project which isn't affiliated with an IRB-institution. I expect the biggest problems come from the projects that don't engage us in advance. Alsee (talk) 14:01, 24 January 2019 (UTC)

Toward a single, required, citation style structure.

We currently have no required style for citations. We should. We have lots of tools which understand how to handle <ref> tags in a structured way. The visual editor knows about them. We've got tools to automatically generate references in that format. We've got tools that know how to fix many kinds of formatting errors (i.e. bare URLs, dead links, duplicated citations, etc) and search them for copyright violations. It makes no sense that we don't require references to be entered in a format which works with all those tools. I'd hate to see us get totally anal about the minutia of punctuation and other formatting, but I think we should require the use of a basic core format with <ref> tags and {{cite}} templates. -- RoySmith (talk) 00:34, 2 February 2019 (UTC)

I want to say this is a WP:PEREN, but basically no. We should have what I would consider a list of allowance reference styles so that people aren't introducing random styles, but certain fields have certain citation formatting approaches that are preferred there, and we should allow those on WP. --Masem (t) 00:41, 2 February 2019 (UTC)

WP:PEREN#Establish a house citation style Anomie⚔ 03:17, 2 February 2019 (UTC)

I tend to agree with RoySmith here. Matters of style such as this should be standardised as far as possible. The first reason for rejecting this perennial proposal is that "academics can't find a single system suitable for all fields", although I have never seen a good reason why any system is unsuitable for a particular field: this seems to be a matter of tradition, rather than suitability. The second is that it would be a massive undertaking to implement this. I disagree. There's no need to implement a common style quickly: all that would be needed is a relaxation of the prohibition on changing to the preferred style.

Having said all that, I don't believe that there is any chance of getting this implemented. Phil Bridger (talk) 11:44, 2 February 2019 (UTC)

• It also seems likely to join the list of MOS decisions that cause unwanted disputes. Nosebagbear (talk) 12:48, 2 February 2019 (UTC)
• The WP:PEREN entry goes back to January 2012. A lot has changed since then. We've got better tools for processing references now. reFill is from 2014. VisualEditor first appeared in December 2012. WebRef (which I believe is what VisualEditor relies on for it's citation tool) is from 2014. Anytime somebody creates an article which doesn't use the standard referencing conventions, those tools can't cope, and that's just dumb.

What got me going on this is when I tried to review Draft:Moral competence and found I couldn't use those tools. There's really no reason for that. I'm not so worried about the trivia like whether the author's name goes first or not. I think all that's needed is to require that references be enclosed in <ref> tags, and use some form of {{cite}} template that breaks out the fields into a machine parsable semantic structure. Different disciplines could have their own {{cite}} variations which formatted things in whatever style they wanted. -- RoySmith (talk) 15:34, 2 February 2019 (UTC)

The trouble with using <ref> style footnotes is that the footnotes get mixed up with the citations and you end with a disorganised mess. Repeating bibliographic information for each page may sound absurd, but I've come across instances where 9 separate pages from the same work were each independently given a full bibliographic citation. If the system is to be overhauled then we need to keep the citations separate from the references in much the way that {{sfn}} and the Harvard-style referencing does. You can tinker with CS1/CS2 (aka {{cite book}} vs {{citation}}) as much a you like, but keep the references and citations separate. On the big pages (where there may be several hundred distinct references) even if editors attempt to keep to a single citation and link references to the master it can still be nigh on impossible to find the citation in a non-alphabetic list. Then there is the problem of multiple works by a single author being scattered throughout the list. Finally, when a two line (in the edit window) paragraph ends up with 12 lines of various citation containing references mixed in, then even text editing becomes confusing. Consider the following contrasting styles: United Kingdom and Subhas Chandra Bose. Try adding a reference to Katya Vasileva's article in the former and compare it to doing the same with Bhagwan Josh's book in the latter. Martin of Sheffield (talk) 17:02, 2 February 2019 (UTC)

VisualEditor (both wikitext and visual modes) uses mw:Citoid, which mostly relies upon Zotero (because most of the refs are URLs).

Have you looked at m:WMDE Technical Wishes/Book referencing? It might provide a way to separate short citations from full bibliographic references, while using ref tags. Whatamidoing (WMF) (talk) 04:28, 5 February 2019 (UTC)

I hadn't seen either, but since I don't use the visual editor that explains Citoid. I do use Zotero a little, both for Wiki work and for other, the main drawback is hand entering offline references. Now looking at m:WMDE Technical Wishes/Book referencing, it seems an ideal solution. It (used correctly) ensures data normalisation and allows alphabetical presentation. The in-line text is short and succinct (indeed might even be jacketed by a template for simple page references). In short it seems to have all the benefits of the {{sfn}} system. I look forward to its deployment. The write-up mentioned that the "main reasons for oppose were: ... it is actually about grouping notes, which can also contain explanatory text, charts". In general notes should be handled by {{efn}} rather than by <ref>. There are borderline cases such as <ref>Bose to Dr. Thierfelder of the ''Deutsche Academie'', Kurhaus Hochland, Badgastein, 25 March 1936 {{harvnb|Bose|Bose|1997a|p=155}}</ref>, but thay can easily be recast as {{efn|Bose to Dr. Thierfelder of the ''Deutsche Academie'', Kurhaus Hochland, Badgastein, 25 March 1936<ref refines=Bose1997a>p=155</ref>}}. Indeed, the only real problem I see is do we use "p=155", "p.155", "p 155" etc. A jacket template would sort that out. Martin of Sheffield (talk) 10:14, 5 February 2019 (UTC)

Strong support for all reasons stated. As a ref tool writer (WP:WAYBACKMEDIC) I frequently come across monumentally complex non-standard styles that get mangled and/or overlooked by tools trying to maintain refs. Just this morning I came across Battle of Torp. Granted, whoever made it did an amazing job using nowiki, {{big}}, sup and other stuff to create an elaborate custom ref system. Wow. Look at that complex wikisource - it deserves an award! The author is basically no longer with us, who is going to maintain Battle or Toro? Another example from this morning is 100-Mosques-Plan. Someone in the past ran a script that converted all occurrences of "/n" and "/e" to "|N" and "|E". This broke dozens of URLs (eg. example.com/new/ --> example.com|New/) which were later tagged by IABOt as being dead (correctly). I spent close to 45 minutes fixing it. Whoever made that script might have done it differently if they knew how to work around a standard referencing system. -- GreenC 18:39, 2 February 2019 (UTC)

I would definitely support a requirement that all citation scripts must be vetted by the community before use (no grandfathering—all existing scripts would have to be vetted, which would eliminate many of them). Without that, Javascript makes it possible to create a lot of trash with little effort, which means that we end up with far more trash than quality. For example, there is one widely-used script that codes the first author, followed by some other parameters, followed by any additional authors. How on earth could its writer have thought that made any sense at all? That's just sloppy, period, and such tools shouldn't be allowed to exist. Yes, it really is worth the time to make a script generate clean, editor-friendly coding, with zero additional time required on the part of the script's user. If script writers were willing and able to do this on their own, they would already be doing so. ―Mandruss ☎ 05:04, 5 February 2019 (UTC)

Splitting an IB for subdivisions from IB Settlement

There's been a pretty large discussion over at WP:TFD about merging Template:Infobox settlement and Template:Infobox former subdivision which prompted a bit of discussion on how IB settlement acts as both a settlement and a subdivision template. I find, that as the name suggests, IB settlement is better suited for settlements, while subdivisions have various fields missing, which can be seen comparing the variables in IB settlement and IB former subdivision, though mostly niche things such as houses of legislature or anthems. One might say that these should just be added to IB settlement and voila! There's no problem! But, honestly, I find the entire idea of having IB settlement also acting for subdivisions is just plain dumb. It goes against the categorization of settlements versus subdivisions, it's a confusing thing to use it in the first place for a subdivision with its name literally being "settlement", and there's no reason that should be the case other than people haven't gotten around to it.

So I'm thinking of proposing a pretty bold proposal that IB settlement should stop acting as a general IB for 2 different concepts and that there will be a new IB for subdivisions. Due to the past, and current usage of infobox settlement, it'd be hell maintain, and I'm not even sure how it would be done. I just wanted to open a discussion, see what people think and what should be done, since no one has ever opened this discussion as far as I'm aware. Hecseur (talk) 22:02, 6 February 2019 (UTC)

While you start your post with {{Infobox settlement}} and {{Infobox former subdivision}}, you quickly switch to Infobox settlement and "subdivision". However, {{Infobox subdivision}} redirects to Infobox settlement and not Infobox former subdivision. You also bring up two missing fields - "anthems" is already present in Infobox settlement as |anthem= and the legislature fields can surely be fields that are needed by other types of settlements. --Gonnym (talk) 10:16, 7 February 2019 (UTC)

The problem, it seems to me, is that there are settlements that are not subdivisions (i.e. unincorporated places, CDPs, and neighborhoods), subdivisions that are not settlements (i.e. civil townships), and some that are both (i.e. incorporated citys and towns). Rather than making people choose between different infoboxes, is there a way that we can combine them, and then leave blank the fields that don't apply? If we have two infoboxes, there is a distinct possibility someone will choose the wrong one. If there is only one infobox, then any information which doesn't make sense would just be left blank, and it wouldn't show up. Problem solved. --Jayron32 14:23, 7 February 2019 (UTC)

Yeah, good point, you can also get capitals for subdivisions by using the |subdivision_type= variables. Just wanted to see what people thought about the idea and ask why there's only 1 template. Cheers. Hecseur (talk) 16:38, 8 February 2019 (UTC)

Categorizing all songs by an artist by genre

I admit, I'm not sure the village pump is the correct venue for this comment. If that's the case, sorry, I'm just trying to solicit feedback from a wider audience since the RfC I submitted before received very little interest. I thought I'd try here.

I've become very frustrated by the fact that Wikipedia has many categories defining all songs by recording artists as one or more specific genres. For example, categories at Category:Lady Gaga songs suggest all of her songs are synthpop, dance-pop, or electropop. Entries in this category include many songs that would never be described as pop, including many jazz standards she's recorded for various projects. For song articles, we require secondary coverage to verify genres listed in the infobox. I argue we should only add genre categories for song articles when the song has actually been described as such. We can't just group all songs by an artist as being a specific genre. Doing so makes Wikipedia wrong, sometimes very inaccurate.

I've raised this issue for a third time at WikiProject Songs, here, and I invite editors to review past discussions and contribute to the ongoing recent one. I don't want to introduce any bias here, but as a general summary, some editors feel strongly about keeping the current method of categorization, but if I'm tallying correctly, more editors seem at least open to making changes. Again, I'm just hoping for feedback from editors who are not necessarily watch listing WikiProject Songs.

I'm also open to other ideas for getting more editor feedback. Thanks! ---Another Believer _(Talk) 00:53, 2 February 2019 (UTC)

I seem to recall a similar discussion about whether we should classify artistes by genre has come up before. Vorbee (talk) 09:23, 2 February 2019 (UTC)

Naming conventions for North Macedonia

The Republic of Macedonia has changed its name to the Republic of North Macedonia. This means that Wikipedia:Naming conventions (Macedonia) needs updating. Ideas are welcome at the guideline's talk page. (I have posted here as the guideline is wide-reaching, but only has 24 active watchers) Danski454 (talk) 20:06, 9 February 2019 (UTC)

FWIW, according to the WP-article it hasn't quite happened yet. Gråbergs Gråa Sång (talk) 18:17, 11 February 2019 (UTC)

A place for inter-wiki communication

I recently had a question about the way the Portuguese Wikibooks does something. Alas, I don't speak Portuguese. If it was just the language barrier, I could ask on the Portuguese wiki for someone who speaks English, or I could try machine translation. The problem is that I cannot navigate or search, and thus cannot find the proper place or the proper person to ask.

I would like to propose a page on the English Wikipedia with subpages for Portuguese, French, Russian, etc. These subpages would be a place where someone who only speaks, say, French could ask a question about or request help from the German Wikipedia. There would be similar pages (with a consistent naming scheme) for every language we cover on every Wikimedia project.

We would encourage editors who are bilingual in, say, Ukrainian and German to watchlist the page on the German Wikipedia where Ukrainians ask for help and the place on the Ukranian Wikipedia where Germans ask for help.

To avoid abuse, I would add a rule that basically says that if you are a Turkish-speaking person who has a problem of some sort with someone on the Turkish Wikipedia, complaining about it on the English Wikipedia will just get your post collapsed unanswered.

Does this sound like something worth doing? --Guy Macon (talk) 05:38, 12 February 2019 (UTC)

Most Wikimedia wikis have an "embassy" (see links at d:Q1197883) for this purpose. --Yair rand (talk) 06:48, 12 February 2019 (UTC)

NFOOTY#2 - raising the bar

A pre-discussion on a possible proposal is taking place at Wikipedia talk:Notability (sports)#Proposal - NFOOTY#2 - raising the bar. Icewhiz (talk) 16:06, 13 February 2019 (UTC)

CfD

I do not have an idea, but rather I am here to ask for ideas. There are CfDs that have been languishing for almost two months waiting to be put out of their misery. I asked some admins why it's such an unpopular task, and I was pointed to the very lengthly set of instructions for closing CfDs. How can we make this process less arduous? Natureium (talk) 19:46, 19 February 2019 (UTC)

• Suggest reduction in protection of Wikipedia:Categories for discussion/Working (to extended-confirmed) to allow NACs for results other than keep/no consensus. --DannyS712 (talk) 00:47, 20 February 2019 (UTC)

The problem with that is that you can instruct the bot to delete things, right? Natureium (talk) 01:19, 20 February 2019 (UTC)

@Natureium: Then we could separate that out - currently, there is a discussion about replacing the bot, so maybe the new one should accept instructions from 2 pages, one for nacs (not including deletion) and one for admins. I was recently thinking about trying to find an admin to approve some closes (so please do not close discussions that require any of the above 3 actions unless you are prepared to implement them manually, or an admin has agreed to help you from Wikipedia:Categories for discussion/Administrator instructions) to help with the backlog. --DannyS712 (talk) 02:00, 20 February 2019 (UTC)

Talk to us about talking

The Wikimedia Foundation is planning a global consultation about communication. The goal is to bring Wikimedians and wiki-minded people together to improve tools for communication.

We want all contributors to be able to talk to each other on the wikis, whatever their experience, their skills or their devices.

We are looking for input from as many different parts of the Wikimedia community as possible. It will come from multiple projects, in multiple languages, and with multiple perspectives.

We are currently planning the consultation. We need your help.

We need volunteers to help talk to their communities or user groups.

You can help by hosting a discussion at your wiki. Here's what to do:

1. First, sign up your group here.
2. Next, create a page (or a section on a Village pump, or an e-mail thread – whatever is natural for your group) to collect information from other people in your group. This is not a vote or decision-making discussion: we are just collecting feedback.
3. Then ask people what they think about communication processes. We want to hear stories and other information about how people communicate with each other on and off wiki. Please consider asking these five questions:
   1. When you want to discuss a topic with your community, what tools work for you, and what problems block you?
   2. What about talk pages works for newcomers, and what blocks them?
   3. What do others struggle with in your community about talk pages?
   4. What do you wish you could do on talk pages, but can't due to the technical limitations?
   5. What are the important aspects of a "wiki discussion"?
4. Finally, please go to Talk pages consultation 2019 on Mediawiki.org and report what you learned from your group. Please include links if the discussion is available to the public.

You can also help build the list of the many different ways people talk to each other.

Not all groups active on wikis or around wikis use the same way to discuss things: it can happen on wiki, on social networks, through external tools... Tell us how your group communicates.

You can read more about the overall process on mediawiki.org. If you have questions or ideas, you can leave feedback about the consultation process in the language you prefer.

Thank you! We're looking forward to talking with you.

Trizek (WMF) 15:08, 21 February 2019 (UTC)

Broadly improving article quality

According to Wikipedia:Version 1.0 Editorial Team/Statistics, only 7.39% of articles are rated C-class or above; the vast majority are stub or start class. This article from MIT Technology Review pointed out that most of our articles don't meet our own quality standards.

I figure there's some sort of power law between a quality/importance rating and the number of articles with that rating, but I wonder what we can do to bring up article quality across all of Wikipedia. What kind of quality goals could we set site-wide (or per-WikiProject)? I'm thinking along the lines of the following:

• Give every article a quality and importance rating (currently 8.54% of articles are unassessed)
• Bring 20% of High- and Top-importance articles to good article and above (currently it's at 4.95%)
• Bring 60% of Start-class articles to C-class and above (I realize that's over a million articles, which is unrealistic given the decline of editors)
• Double the number of good articles / featured articles

I understand that overreliance on metrics is counterproductive, but I'm just using quality ratings as a starting point for conversation. Qzekrom (talk) 20:36, 22 February 2019 (UTC)

A lot of stub articles should remain as stubs. Look at any printed encyclopedia and you will see short two- or three-line entries in amongst the major article. Trying to inflate an article just to satisfy a metric is at best pointless, at worst counter-productive. Martin of Sheffield (talk) 20:53, 22 February 2019 (UTC)

I agree with what Martin says. If a stub article provides a little encyclopedic information, and no more is available, then it's better to have that stub article with a little information than to have nothing. I often get the impression that many editors have grown up with Wikipedia, and have never actually seen a print encyclopedia, so don't understand that many topics can have very short entries. Another point is that Wkipedia editors are volunteers who spend their time where they want to spend it, rather than on what someone tells them to do. Creating such targets will only lead to people lobbying to get the rating of "their" article bumped up, rather than to any actual increase in quality. Phil Bridger (talk) 21:32, 22 February 2019 (UTC)

That depends on the relative importance of the topic covered. If I saw a page marked as start-class and high-importance, I'd be much more disappointed than if I saw one start-class and low-importance. Also, I'm starting to suspect that the quality ratings aren't used consistently—I've seen plenty of pretty good looking articles marked as C or start. Qzekrom (talk) 05:54, 23 February 2019 (UTC)

In my experience articles may be improved, but if the relevant project is moribund a reassessment will not automatically follow. Some assessments relate to the state of the article several years prior to expansion. The alternative is to encourage editors to adjust assessments on articles they have worked on, which would rather defeat the whole object of the exercise! Martin of Sheffield (talk) 09:51, 23 February 2019 (UTC)

In MilHist, we encourage people to self-assess up to and including C class, but nothing higher.--Sturmvogel 66 (talk) 13:12, 23 February 2019 (UTC)

UTC clock

Hello. I had an idea I did not see on Perrenial proposals so I thought it was worth suggesting, and I’d like to see if it should be proposed or not. I think somewhere on the space underneath or to the right of the Wikipedia globe, there should be a UTC clock on there showing the date and time. That way it could be easier for users who aren’t the most familiar with UTC to know what time it is in UTC (for instance, to tell how long it’s been since a signed comment on a talk page was made, or how long ago the previous edit on an article was made). How well would this proposal fare? DrewieStewie (talk) 14:25, 23 February 2019 (UTC)

@DrewieStewie: in Special:Preferences, in the Gadgets tab, see "Add a clock to the personal toolbar that displays the current time in UTC and provides a link to purge the current page". There is also "Change UTC-based times and dates, such as those used in signatures, to be relative to local time (documentation)" a few more lines down. --Izno (talk) 15:04, 23 February 2019 (UTC)

Yeah, my life got a whole lot easier a few years ago when I discovered the option(s) to show me all times local. That's signatures, page histories, contribs, pretty much anything that matters to me.
On the extremely rare occasion when I want to know current UTC, I type "utc time" in my Firefox address bar. Et voila, it's currently 4:16 p.m. UTC. There are tons of things Wikipedia could do to duplicate things already easily available elsewhere, and they are usually unjustifiable. ―Mandruss ☎ 16:17, 23 February 2019 (UTC)

Talk pages consultation 2019

The Wikimedia Foundation has invited the various Wikimedia communities, including the English Wikipedia, to participate in a consultation on improving communication methods within the Wikimedia projects. As such, a request for comment has been created at Wikipedia:Talk pages consultation 2019. All users are invited to express their views and to add new topics for discussion. (To keep discussion in one place, please don't reply to this comment.) Jc86035 (talk) 14:57, 23 February 2019 (UTC)

Endless-length articles

In regards to very long articles.. for various reasons there is no end to article size for some topics. Abraham Lincoln is a good example. Sub-articles have been spun off, but some of those now approaching the length of the original article. Do we create sub-sub articles indefinitely? Managing all this content coherently without duplication or contradiction is challenging, much less reading through it. I would argue this system of sub-articles works to a point, but becomes unwieldy when there is too much fragmentation and content for the topic area.

There is another genre of writing for long-form: books ie. Wikibooks. Length is a non-issue as books can be split into multiple volumes, and chapters into multiple chapters. Books inherently discourage duplication, which reduces contradictions and bubbles of emphasis. They allow for infinite digression and exploration. Much of the material in the Abraham Lincoln series is questionable it even belongs in an Encyclopedia article given the level of detail.

Transwiki from Wikipedia to sister projects has always been difficult, think of all the "dictionary definition" articles transwikied to Wiktionary via AfD. It takes considerable consensus building. And to write in a format that is book-oriented instead of Encyclopedia is not familiar to most editors. And many see WP as the premier platform in terms of exposure of their work. And some may not agree spinning off sub-articles is a problem. Comments or thoughts? -- GreenC 19:56, 23 February 2019 (UTC)

I would agree that this is not a problem. In a way every article is a sub-article of human knowledge (I didn't check what that linked to before putting in in double square brackets). Why do you think that such sub-articles are a problem? The limitations of available technology, such as download speeds that may be pretty slow over links available in some parts of the world, mean that articles need to be split, and sometimes there is lots of encyclopedic content about a topic that belongs in Wikipedia. Phil Bridger (talk) 20:38, 23 February 2019 (UTC)

Hopefully I made it clear that sub-articles are not an inherent problem. If not, my apologies. -- GreenC 20:47, 23 February 2019 (UTC)

Well, then, what is the problem, or the challenge if you prefer more modern value-neutral terms? Maybe I'm being obtuse, but I can't see anything identified in your original post that might require any action on Wikipedia. Phil Bridger (talk) 20:53, 23 February 2019 (UTC)

If something required 'action' I wouldn't be posting in this forum. Was look for "ideas" and thoughts, feedback. You gave some, thanks! -- GreenC 20:59, 23 February 2019 (UTC)

Better guidelines for citations

I have already talked about this with Cullen328 here, please have a look at this (for the full discussion, go here). Both of us seems to agree that this practice has developed over the years. I would like to propose an amendment for a stricter and clearer inline citing guideline and/or probably alter what already exists. Before I do for it, please plant your ideas below that I can take into consideration. THE NEW ImmortalWizard(chat) 11:21, 24 February 2019 (UTC)

• I think this is unwise - obviously functionally all experienced content creators actively use inlines. However, speaking from my AfC work, it's tricky enough to get new editors to provide a few good general sources. Placing even a stricter guideline on inline sources, if they are to be required more, would make it even harder to get new editors. Everyone already determines, rapidly, that it's good practice, so there's no need to further highlight that we'd like it that way. Nosebagbear (talk) 14:25, 25 February 2019 (UTC)

  If you think from a reader's point of view, hardening the rules will increase our credibility. I am not asking for a ratification that will have substantially alter the guidelines; stubs and new articles without any section should still be allowed to have only general references. I don't think this will affect the enthusiast of newcomers to create new articles, as I hardly see them caring too much about the quality; they just want the article to exist, whether it's incomplete or not.
  If the article is notable enough, it is not supposed to deleted because of improper citing. Hence, I believe AFC activities wouldn't be affected much. Instead this will help to enhance article qualities. Implementing this could impact such as content assessment, which is actually positive. THE NEW ImmortalWizard(chat) 16:03, 25 February 2019 (UTC)

Make 'et al.' an expandable list in citations?

It would be handy if the 'et al.' contraction in a citation template could be made a dynamically expandable list of authors via javascript. Is anything like this in work? Praemonitus (talk) 14:45, 3 March 2019 (UTC)

A) In some cases, the citation does not have any other authors listed in the wikitext. That aside, B) this would require some minor markup additions to the citation template. It seems to me that we should have someone build the tool first. Better for you to use Zotero if you want to access authors in the wikitext but not listed in the displayed template. --Izno (talk) 15:56, 3 March 2019 (UTC)

Permalinks to archived discussions

Can the archive bots be set up to change links to discussions to permalinks on the archive pages when those discussions are archived? Qzekrom (talk) 17:46, 25 February 2019 (UTC)

ClueBot already does this. It is, however, very expensive for ClueBot to do so, and has stopped ClueBot from operating before. --Izno (talk) 13:55, 10 March 2019 (UTC)

Good question. Vorbee (talk) 08:52, 10 March 2019 (UTC)

@Vorbee: Please consider not "posting just to post". --Izno (talk) 13:55, 10 March 2019 (UTC)

Hide references.

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The references at the bottom of each page should be hidden and only be shown if the user presses on a special button, this way the user doesn't see a long page and doesn't get discouraged to read it, and this raises the average knowledge of humankind and will make humankind stronger!!! — Preceding unsigned comment added by AdamMichaels784 (talk • contribs) 17:35, 11 March 2019 (UTC)

Nope, because mobile support for expanding collapsed content is so bad, MOS:DONTHIDE. – Finnusertop (talk ⋅ contribs) 17:44, 11 March 2019 (UTC)

I also disagree with this idea, because people reading Wikipedia should understand that it is only reliable in so far as it cites reliable sources. The references are in fact the most important part of any article. Phil Bridger (talk) 18:47, 11 March 2019 (UTC)

Poster: Everyone pretty much understands that there are references in Wikipedia article, and it will be plain evident when they see the "Show references" bold (maybe yellow), I can imagine a way where there's the words in bold in red in mobile: "Show references" and clicking it is super easy and it will open the references, maybe even make when pressing on a number of reference in the article's text it opens references, most people just read the article and if there's something that is controversial they press on the number of references and it opens all the references and scrolls automatically to the reference chosen, as a 29 years old man who uses Wikipedia all day I have never in my life pressed to check for the reference, in the first place it's not hidden it's just not shown unless a tiny simple click is pressed, imagine how many people will proceed in reading after not being discouraged by the enormous "text" when opening a Wikipedia article and how much this will make people more knowledgeable especially in their fields, also when people read and understand and think this makes them smarter and by epigenetics this may even pass to their children's intelligence, you do understand the length of the page would drastically change and not a little bit right? — Preceding unsigned comment added by AdamMichaels784 (talk • contribs) 21:25, 12 March 2019 (UTC)

Your last comment consists of one 220-word sentence preceded by "Poster:". You have written exactly one full stop in this entire section—in the heading, where we generally don't use or need full stops. Please express your thoughts in sentences of reasonable length. Also, please WP:SIGN your comments in talk spaces. ―Mandruss ☎ 22:31, 13 March 2019 (UTC)

References are at the bottom of the article, hence the last thing you see when reading an article on a mobile. How exactly does this discourage you from reading Wikipedia? Daß Wölf 22:40, 13 March 2019 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Automatically mark all stubs as stub-class

I would like to propose a bot action. The bot would find every article in Category:Stubs ∩ Category:Unassessed articles, and for every WikiProject banner on the talk page without a quality rating, it would add |class=stub. Since the quality ratings are managed by WikiProjects, they can opt-in to having ratings automatically added to the articles in their jurisdictions. Qzekrom (talk) 03:07, 23 February 2019 (UTC)

@Qzekrom: If there is consensus for this, I'd be happy to code up such a bot; I think it should be pretty easy (a SMOP) for me, given my scripts to get pages from categories and perform the same edit on all of them. --DannyS712 (talk) 03:35, 23 February 2019 (UTC)

@DannyS712: Great! Would the best place for this be WP:Village pump (proposals) or some wider venue? Qzekrom (talk) 04:37, 23 February 2019 (UTC)

@Qzekrom: That would probably be the right place; can't really think of a wider venue. Or, if its on an opt-in basis, maybe on the specific wikiprojects you were thinking of? --DannyS712 (talk) 05:05, 23 February 2019 (UTC)

I feel that this is mostly at the discretion of individual WikiProjects, but there might be externalities from tagging on a massive scale; see, for example, the current discussion about GreenC bot at WP:Village pump (proposals). I think we would post on WP:VPPRO and then put {{WikiProject please see}} notices on WikiProject Council and some of the largest WikiProjects' talk pages to see if they would be interested in participating in this bot run. Qzekrom (talk) 05:20, 23 February 2019 (UTC)

Also, note—Category:Stubs contains articles while the likes of Category:Unassessed articles contain talk pages, so your script would have to do the matching. Qzekrom (talk) 05:26, 23 February 2019 (UTC)

@Qzekrom: Yeah, the matching would be pretty easy, or I could create the list with AWB... but its more the consensus issue that should be addressed --DannyS712 (talk) 05:50, 23 February 2019 (UTC)

@DannyS712: What do you think about this text?

I propose that we have a bot mark stubs as stub-class en masse. The bot would find every article in Category:Stubs ∩ Category:Unassessed articles, and add |class=stub to each approved WikiProject banner if the banner does not contain a quality rating. Individual WikiProjects would opt-in to having their articles automatically rated. DannyS712 has offered to write the code for the bot.

We have two questions:

1. Would your WikiProject participate in this bot task?
2. What side effects do you foresee from this bot task, if any?

Qzekrom (talk) 06:19, 23 February 2019 (UTC)

@Qzekrom: I say get some wikiprojects to opt-in first, and then make the full proposal. Something along the lines of:

...if there is community consensus for such a task, would you like to opt-in (meaning that stub ratings would be added to templates for your project)?

We (I) also need to figure out a way to ensure that it doesn't mark it as a stub if other wikiprojects have it rated as start or something - then it would need to be humanly resolved to determine which is right.

--DannyS712 (talk) 06:22, 23 February 2019 (UTC)

Good point! Maybe the bot would throw it up on a noticeboard? It could also, more generally, detect conflicts between different projects' quality ratings for the same articles.

In terms of WikiProjects, I heard from Ferret on Discord that some of the most active WikiProjects are WP:MILHIST, WP:VG, WP:MED, and WP:ANIME. I'll also hit up WikiProjects that I'm part of, such as WP:ECON, WP:COMPSCI, and WP:URBAN. Qzekrom (talk) 06:32, 23 February 2019 (UTC)

I would rather have the discussion in one centralized place, though. I'll post in WikiProject Council, then notify the major WikiProjects about the discussion. We can think of this as user research. How does that sound? Qzekrom (talk) 07:30, 23 February 2019 (UTC)

@Qzekrom: That would probably work --DannyS712 (talk) 07:31, 23 February 2019 (UTC)

Actually, here might be better because we already have a discussion going, and it's called the idea lab for a reason. It'd be better not to fragment the discussion. We could still post notices on WikiProject talk pages. Sorry for my waffling. Qzekrom (talk) 07:51, 23 February 2019 (UTC)

@DannyS712: Do you feel comfortable putting this up on WP:BRFA now? Qzekrom (talk) 23:23, 25 February 2019 (UTC)

@Qzekrom: I'd rather wait a bit longer, given how little discussion there has been so far. As far as I can tell, only 1 WikiProject (medicine) has officially opted in --DannyS712 (talk) 23:25, 25 February 2019 (UTC)

@DannyS712: If only WPMED opts in, we'd only have 20 or so pages to auto-tag; Category:Unassessed medicine articles and Category:Unknown-importance medicine articles are both very small. We should focus our efforts on the Wikipedia assessment backlog (which I just realized was a thing). I'll go and ping some of the WikiProjects represented there. Qzekrom (talk) 00:14, 26 February 2019 (UTC)

@Qzekrom: Thanks. Or, if you want to phrase it as opt-out (since assessing articles that are tagged as stubs as stubs should be non-controversial) that's another option --DannyS712 (talk) 00:18, 26 February 2019 (UTC)

Attention WikiProjects

We are developing an idea for a bot script that would perform a few article assessment–related tasks. The tasks we've come up with are:

1. Finding all stubs without a quality rating belonging to a specific WikiProject and tagging them as stub-class. This would be done only with the consent of that WikiProject as we don't want WikiProjects would be able to opt out if they don't want us to interfere with how projects they assess articles.
2. Finding articles where different WikiProjects disagree on the quality rating and throwing it up on a noticeboard, where a human can review those articles and harmonize the ratings as warranted. Dropped as not feasible

Please tell us which WikiProject(s) you represent, whether you think these proposals would be useful to your WikiProject, any other ideas for assessment-related bot tasks that you have. Feel free to post any miscellaneous thoughts as well. Thank you! DannyS712 and Qzekrom (talk) 08:42, 23 February 2019 (UTC)

@Qzekrom: The noticeboard thing isn't as easy, but the bot would definitely skip pages where there is disagreement among WikiProjects as to the assessment, or disagreement between the rating and the presence of a stub template. --DannyS712 (talk) 08:44, 23 February 2019 (UTC)

Notified: Wikipedia talk:WikiProject Council, Wikipedia talk:WikiProject Military history, Wikipedia talk:WikiProject Video games, Wikipedia talk:WikiProject Medicine, Wikipedia talk:WikiProject Anime and manga, Wikipedia talk:WikiProject Biology, Wikipedia talk:WikiProject Mathematics Qzekrom (talk) 09:06, 23 February 2019 (UTC)

• I have historically done most of the article assessment for Wikipedia:WikiProject Medicine. I am familiar with WP:ORES and have worked with User:Nettrom on automated article assessments in the past. Stub predictions with ORES are perfectly reliable – I don't recall ever having found one that was incorrect. I welcome this being done for all medicine-related articles. If/when it's easy, I ask that you additionally tag any article that is also tagged for WPMED as a WP:BLP or as a business/organization with |importance=Low and |society=yes. (Please ping me if you have further questions.) WhatamIdoing (talk) 18:51, 23 February 2019 (UTC)
• I've seen very, very few instances in which differences in WikiProject assessment were based on substantive differences. More often than not, some editor only chose to update one banner or one of the banners has a required B-class process and won't trigger that classification without a bunch of other banner parameters letting it. In short, I'd be wary that the effort to build and maintain the tooling would be worthy of the fix. Plenty of other WikiProject maintenance tasks that needs tooling though... (not watching, please {{ping}}) czar 22:13, 23 February 2019 (UTC)

  @Czar: So, justs for marking these as stubs, since that's not really based on individual project's views, it should be opt-out? --DannyS712 (talk) 22:23, 23 February 2019 (UTC)

  Auto-classifying unassessed articles with prose length below 1500 bytes as stubs is uncontroversial, in my opinion. But sure, it's possible that some projects would want to opt-out. Depends what the bot operators require for consensus. But before investing in writing a bot, however, might want to check in on the meta:Community Tech/PageAssessments conversations linked from Template talk:WikiProject banner shell#Class once, which would ostensibly change the assessment tooling. czar 09:00, 24 February 2019 (UTC)

  @Czar: It seems like most Wikipedians don't care whether assessments are done at the site level or project level; I reckon that WP:Ownership applies to project-level ratings as well.

  We are planning to get automatic consent for the bot at the project level but want to be careful in case there's a reason auto-assessments might be disruptive (have externalities). Qzekrom (talk) 00:24, 26 February 2019 (UTC)

• Personally, I'm okay with auto-assessment of stubs for computing and econ articles, but I'd want to check with other members first. Qzekrom (talk) 00:32, 26 February 2019 (UTC)

Notified: Wikipedia talk:WikiProject Computing, Wikipedia talk:WikiProject Economics, Wikipedia talk:WikiProject Biography, Wikipedia talk:WikiProject United States, Wikipedia talk:WikiProject Africa, Wikipedia talk:WikiProject Women Qzekrom (talk) 01:28, 26 February 2019 (UTC)

• Side-question: Is it possible to have the banner detect the article's page length, similar to how the banner can automatically detect whether the article is a redirect? Would save a lot of bot trouble, if so. czar 01:53, 26 February 2019 (UTC)

• I am active in assessments for WP:PSP, WP:COMP and WP:TELECOM. I have a couple questions: ~Kvng (talk) 14:47, 1 March 2019 (UTC)

1. Would the noticeboard be sorted by Wikiproject somehow? I don't usually have difficulty harmonizing ratings if one of my projects in involved but don't want to try to do this for other projects.
2. How are stubs to be identified? I assume looking for {{*stub}} at the bottom of an article would be non controversial. Basing it on article size would require some discussion.

(2) Yes, we would look for {{*stub}}, but we'd skip articles that already have a rating higher than stub. I'm not sure what we'd do with articles longer than 1500 bytes, but we could temporarily mark them as stubs too and also put them on the noticeboard. We could also add |reassess=yes if the project banner supports that. Unfortunately, it's not in {{WPBannerMeta}}, and not all projects have the reassessment category.

(1) Yes, the noticeboard entries could be sorted by WikiProject. DannyS712, what do you think? Qzekrom (talk) 18:48, 1 March 2019 (UTC)

Speaking of which, I think we should also create an "Articles needing reassessment" category out of all the individual project reassessment categories. Qzekrom (talk) 18:51, 1 March 2019 (UTC)

@Qzekrom: I'm not so sure about a noticeboard, at least at first - it would be a lot harder to program. But, I would completely just skip any with issues. --DannyS712 (talk) 21:58, 1 March 2019 (UTC)

@DannyS712: Okay, we definitely don't have to do the noticeboard right away. I think we should propose (1) at BRFA now as it seems uncontroversial; we can skip (2). What are your thoughts? Qzekrom 💬 ^they_them 20:26, 10 March 2019 (UTC)

@Qzekrom: BRFA filed --DannyS712 (talk) 08:38, 19 March 2019 (UTC)

New WP 1.0 Bot

This may be only tangentially related, but y'all might want to check out this announcement. Qzekrom (talk) 06:07, 27 February 2019 (UTC)

Changing when non-administrative closures are permitted

Editors may be interested in participating in this discussion about what types of non-administrative closures are permissible. Best, Barkeep49 (talk) 00:17, 22 March 2019 (UTC)

Wikipedia at 20

Possibly a bit early, given that Wikipedia's 20th birthday is 22 months away - but could a 'WP 20 Challenge' be set up? There might be several levels - easy (updating a dormant/orphan page, creating a wanted page etc), moderate, difficult and 'fiendish but feasible' etc. Jackiespeel (talk) 11:02, 12 March 2019 (UTC)

Could you be a bit more specific on what examples of each category (easy, moderate, difficult and fiendish but feasible) might be? Thank you. Vorbee (talk) 20:00, 13 March 2019 (UTC)

Almost reached legal drinking age in the U.S. Praemonitus (talk) 22:20, 22 March 2019 (UTC)

Links without https and without underscores

Please visit: Wikipedia:Help desk#Links without https and without underscores

Pinging MusikAnimal, who is great with scripts.

Many thanks,

Anna Frodesiak (talk) 21:18, 21 March 2019 (UTC)

Now being handled here: Wikipedia:User scripts/Requests#A script to help with underscores

Anna Frodesiak (talk) 04:52, 23 March 2019 (UTC)

Script created: User:DannyS712/Easy-link

Anna Frodesiak (talk) 00:02, 24 March 2019 (UTC)

I think we should add an in a nutshell section for some articles

wikipedia is very good at making in depth and knowledgeable articles but one thing it often fails at is summarizing. I think that some articles could benefit from a small paragraph long section that gives a general overview of the topic. Just an idea — Preceding unsigned comment added by Government Man (talk • contribs) 14:21, 22 March 2019 (UTC)

Government Man, That is what the lead at the beginning of the article is for. From WP:LEAD "The lead serves as an introduction to the article and a summary of its most important contents". If you can't find the summary in the lead good enough, it just needs to be rewritten. WelpThatWorked (talk) 14:25, 22 March 2019 (UTC)

This sounds like a request for an even shorter summary. Instead of four paragraphs, many readers probably want one sentence – more like "Rheumatic fever is a complication of strep throat that can cause heart damage" than what you'll find at the top of Rheumatic fever. WhatamIdoing (talk) 17:32, 22 March 2019 (UTC)

You can't get much shorter than {{Short description}}. Praemonitus (talk) 22:17, 22 March 2019 (UTC)

So, I guess OP's suggestion is really "make short descriptions visible in desktop mode"? Eman235/talk 00:47, 24 March 2019 (UTC)

Which I assume would be phab:T186218. --Izno (talk) 00:58, 24 March 2019 (UTC)

Optional custom text when sending "Thanks"

Tracked in Phabricator
Task T58373
Declined

I think it would be a nice improvement to add an optional field that allowed for the inclusion of a limited amount of custom text when sending an editor "wikilove" using the thank feature. Do others agree? Would it be technically difficult to accomplish? I do believe it should only be done if it will also be possible for an admin/OS to revdel/oversight the text in the event that a message qualifies under our existing standards. What do others think about this? Thank you.--John Cline (talk) 01:04, 24 March 2019 (UTC)

This could be used for abuse. If you need to thank someone to such a degree, send them some wikilove instead. --Izno (talk) 02:03, 24 March 2019 (UTC)

Several complexities: Deleting/undeleting, OS/Revdel, logging and whatnot as well as overall needless duplication of Wikilove. Also see attached declined task. – Ammarpad (talk) 07:05, 24 March 2019 (UTC)

I understand, thanks.--John Cline (talk) 13:35, 24 March 2019 (UTC)

Semi-Protect All SPIs

Some sockpuppets are trolls.

Is it feasible to semi-protect all Sockpuppet investigation subpages? In the last few days, these pages have been under attack by new accounts that edit them to report that no match has been found and the investigation is being closed. The pages are then reverted and the new accounts are blocked. This appears to be the work of one trollsockmaster (except that trolls don't wear socks). Would automatically semi-protecting the pages when they are created, normally via Twinkle, prevent this vandalism? The trade-off is that new editors who are not autoconfirmed, and IP addresses, would not be able to report sockpuppetry. That seems like a small price to pay, since new editors and IP addresses are just as likely to be sockpuppets as to know enough to be able to identify and report sockpuppets.

Thoughts? Robert McClenon (talk) 02:26, 23 March 2019 (UTC)

This can be done with the MediaWiki:Titleblacklist (see rules with autoconfirmed and noedit) so that we don't have to apply protection individually. It would be for the best that non-(auto)confirmed users cannot edit them. — JJMC89 (T·C) 04:02, 23 March 2019 (UTC)

I think we need some evidence that there are no good SPI edits by non-autoconfirmed users. Jo-Jo Eumerus (talk, contributions) 08:32, 24 March 2019 (UTC)

As an interim measure, can each SPI be semi-protected each time that an admin reverts vandalism? Some of the SPIs have been vandalized 6 or 8 times, always the same. (It's one trollsockmaster.) Robert McClenon (talk) 15:03, 24 March 2019 (UTC)

Trolls don't wear socks, but they do steal socks. Consider that the next time you have mismatched footwear coming out of your laundry. Robert McClenon (talk) 15:04, 24 March 2019 (UTC)

• I can't talk to whether there are any good IP contributions (thought participating in SPI is so complicated it nearly broke me both times I've done it). I did want to congratulate @Robert McClenon: for one of the great wikispace photos I've seen. And having a better laundry policy than me. Nosebagbear (talk) 09:08, 25 March 2019 (UTC)

It isn't my photo. And my laundry policy is to use sodium hypochlorite. Robert McClenon (talk) 10:49, 25 March 2019 (UTC)

I support semi-protecting any SPI page once vandalized, but oppose blanket-semi-protection for the entire set unless evidence shows that it's needed in many cases. עוד מישהו Od Mishehu 10:59, 31 March 2019 (UTC)

An option to hide page issues (infoboxes, stub notices, and inline templates)

Today, some Wikipedia readers which:

• Not interested to contribute and just read the article
• Not frequently or never doing major edits like adding citations and improving stubs (I’m also same here)

... are annoyed by the templates involving the issues on the page. They think the article editing is too time-consuming, so they are also simply dismissing the “page issues” and just reading the article. I want an option to disable them if they are reading Wikipedia for knowledge purposes. —Ijoe2003 (talk) 03:00, 21 March 2019 (UTC)

Major issues with the article, such as a failure of basic verifiability or neutral point of view, should never be concealed from the reader. However, minor content issues could be hidden, such as stub status or a lack of incoming or outgoing links. – Teratix ₵ 04:42, 21 March 2019 (UTC)

I wondered why the major issues mustn’t be concealed from the reader... —Ijoe2003 (talk) 05:32, 21 March 2019 (UTC)

 Note: I forgot about this. Does the “citation needed” thing is the one of the minor issues? —Ijoe2003 (talk) 05:42, 21 March 2019 (UTC)

Major issues shouldn't be concealed because they have a serious effect on the reliability of the content and thus its usefulness to the reader. (Of course, Wikipedia should not be solely relied upon for a piece of information, but some articles are more reliable than others). A "citation needed" tag is an important issue because it indicates that part of the article is not verifiable. – Teratix ₵ 06:20, 21 March 2019 (UTC)

Wikipedia is designed to turn passive readers into active editors. That's the entire paradigm of the website; every editor here used to be a reader who was initially uninterested in, ignorant of, or not bold enough to seize the opportunity to start contributing. Readers need encouragement to take that step. All of us here turned into editors by reading about something we are interested in, noticing something that could be improved, and realizing that there was nothing stopping us from becoming the person who makes the change.

But Wikipedia is about freedom, too. While I think it's a bad idea to advertise an option to hide maintenance tags, it exists. With some CSS hacking, one can hide anything they like, either at common.css if they are a registered user, or by using a browser add-on if they are not. – Finnusertop (talk ⋅ contribs) 06:50, 21 March 2019 (UTC)

I agree with your points they should add this — Preceding unsigned comment added by Government Man (talk • contribs) 14:23, 22 March 2019 (UTC)

I want an example of the browser addon that hides them. —Ijoe2003 (talk) 06:25, 23 March 2019 (UTC)

@Ijoe2003: Stylish – Finnusertop (talk ⋅ contribs) 09:49, 23 March 2019 (UTC)

Finnusertop, I also want an example of the skin which hides them on Stylish. It’s too hard for me to find them. —Ijoe2003 (talk) 09:55, 24 March 2019 (UTC)

Ijoe2003, the ping won't work if you insert it via an edit of a previous comment. You have to start a new line to make a ping work. --valereee (talk) 10:14, 2 April 2019 (UTC)

I changed it to non-ping comment. — Ijoe2003 (talk) 08:58, 3 April 2019 (UTC)

Ijoe2003, the Reading team re-designed the "Page Issues" stuff a little while ago, to make it more prominent. If you and your friends are finding that it's just in your way, then they'll want to know. Please feel free to post more details about your experience with it.

Teratix, I like to believe that our readers are smart enough to notice when those blue clicky numbers aren't present, even if there isn't a banner at the top that says an editor has noticed that they aren't there. We have never done any research to figure out whether those banners provide any value to readers; they might be as pointless as the one in the middle of this essay. It's also worth remembering that information can be verifiABLE even if it's not verifiED. This is explained more fully at the lead to WP:NOR, which IMO is worth reading in its entirety, including the footnote. WhatamIdoing (talk) 17:23, 22 March 2019 (UTC)

Okay, here’s the more details about that: I am actually reading Wikipedia casually with only doing a minor edits on the article. Therefore, I also thought that the “Page Issues” thing like “citation needed” is annoying. I posted that idea because I imagined that some Wikipedia readers may have a same opinion like this. —Ijoe2003 (talk) 06:25, 23 March 2019 (UTC)

Ijoe2003, I'd argue that, annoying or not, a 'citation needed' tag is one of the more important things someone reading purely for information needs to see. It means at least one editor believes the assertion is not properly sourced and therefore may not be true. It means at least one person is questioning whether we should be including that assertion in the article. Many other things aren't as important, but that's one that I'd never support being able to opt out of seeing. I do get that seeing the reference numbers and inline templates can make articles more difficult to read, especially when you're not used to reading that way, but you get used to it, and it develops an actual skill. Eventually you start recognizing for yourself that, "Hey...that sentence doesn't have a citation. That might mean it's not really true. Maybe I should check further before relying on it." It's one of the things that makes reading on Wikipedia more valuable than much of what you can find on the net. valereee (talk) 09:06, 23 March 2019 (UTC)

Translatathon (translation Wikipedia competition)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I'm curious if any editors would be interested in a Translatathon (portmanteau of "translate" and "marathon"), a Wikipedia competition encouraging multilingual editors to translate and promote Good- or Featured-class English Wikipedia articles at other language projects. For example, an editor might earn points for translating and promoting Grammy Award for Best Disco Recording ( at English Wikipedia) to quality status at Spanish Wikipedia (exists, but not quality status), or German Wikipedia (does not exist). This seems like a great way to get quality content developed at other language projects, and I'm not sure there are major translation competitions or initiatives hosted here at English Wikipedia. Might be fun to organize a one-month pilot competition. Of course, I'm open to other names, rules, judging, forms of recognition (barnstars?), etc. I just wanted to float the idea here and see if any other editors had thoughts or previous experience to share.

Thanks! ---Another Believer _(Talk) 22:58, 19 March 2019 (UTC)

Given that the Village Pump is a page that attracts a lot of new and new-ish editors who aren't necessarily familiar with all our policies, just a few reminders to anyone considering taking part in this (or just inspired to start translating):

1. Don't even consider posting unedited machine translations into the Wikipedia article space unless you have a particular urge to be indefblocked (if you're not fluent in both languages, don't consider translating articles between Wikipedias);
2. Anything translated must credit what you translated it from in the first edit summary, or it will be treated as a copyright violation;
3. It's strongly recommended to put the {{translated page}} template on the talk page of any article you create here;
4. If you're translating from another language to en-wiki, bear in mind that our rules on sourcing are generally much stricter than those of the other Wikipedias, and you need to check the sources in the article to confirm that they actually conform to our definition of "reliable source" (and also that they actually say what the article claims they say);
5. If you're translating from en-wiki to another language, bear in mind that each Wikipedia has different policies and procedures for how they handle incoming translations, a list of which can be found here.

By no means let any of the above put you off, but be careful; translation has a long history of getting people into trouble very quickly if they're not sure what they're doing. ‑ Iridescent 00:44, 20 March 2019 (UTC)

Iridescent, This is all incredibly helpful, thank you. I think part of what I envision is a relatively small but experienced group of editors who would be more than willing to adhere to these recommendations and organize their own activities, much like the Guild of Copy Editors, WikiCup, or some other variant of a WikiProject. I would not be opposed to having specific rules that require strict adherence to what you've outlined. The idea here is to establish a group of editors who are motivated to translate properly, support one another, and perhaps even form a sense of community. I'd love to participate in a project like this, but I only speak English, unfortunately. Thanks again for your feedback. I'm curious to read what others think as well. ---Another Believer _(Talk) 00:51, 20 March 2019 (UTC)

@Iridescent: a few things to keep in mind:

1. Some projects (esp dewiki) make heavy use of transwiki history imports - so before starting over there get familiar with their requirements)
2. To create a new article with WP:CXT here you must be extended confirmed, but you can work around this by creating it in Draft: space. We will not heavily "advertise" this (such as by putting up a banner) but it can be useful for organizers.
3. If creating a page here, we can always bring in the original history from the other project (and again this is especially useful if it comes to here from dewiki). To do this, FIRST make your translated article here, THEN drop a request at WP:RFPI.

Good luck! — xaosflux ^Talk 00:56, 20 March 2019 (UTC)

@Tdslk: I know we've discussed translation projects before. I'm curious what you think about this, and specifically, if you have any insight into how the GOCE model could be applied here. If you're uninterested, no worries, just wanted to invite you to the conversation. ---Another Believer _(Talk) 22:30, 20 March 2019 (UTC)

Hi @Another Believer:! Yes, this is definitely something I am interested in. I think there is a lot of potential for projects and coordination of translation efforts across Wikipedias. I am a bit nervous about calling anything a "competition," though, except maybe for single best article. Anything that incentivizes quantity would run the risk of generating lots of poor-quality translated content. @Iridescent: points out some other important considerations around translation projects. Tdslk (talk) 05:45, 22 March 2019 (UTC)

Tdslk, Totally understand re: "competition". But, isn't GOCE also a competition of sorts? Ditto the WikiCup, which seems to focus on quality. I'm just trying to think of a fun way to incentivize participation, and I'd definitely be open to whatever rules other editors think are best. Just getting the ball rolling here and trying to gauge interest. ---Another Believer _(Talk) 14:29, 22 March 2019 (UTC)

There are competitive awards associated with our drives, but they aren't taken very seriously by most participants. Even so, we still sometimes have problems when an editor decides to game the system for a barnstar. Policing a multilingual competition is inherently tricky; what if the winning editor is accused of making poor quality machine translations into, say, Esperanto? We'd need judges fluent in every Wikipedia language. It would be easier if we were only judging translations into English, but you suggest below that that is not what you have in mind. Anyway, I would be happy to discuss this further at another talk page as you suggest. Tdslk (talk) 19:20, 23 March 2019 (UTC)

Another Believer, is your goal to "export" high-quality articles from the English Wikipedia? Or the other way around? The considerations are very different. For example, if you're "exporting", then none of the local rules about needing to make 500 edits before you can translate an article apply, and most editors will have access to machine translation (which is generally available English-to-other, but not other-to-English). WhatamIdoing (talk) 17:34, 22 March 2019 (UTC)

WhatamIdoing, I guess I'm open to whatever, but I had envisioned translating good English Wikipedia articles into other languages, and having them promoted to quality status locally as well. I realize the processes of promoting quality content are content consistent across all projects, but again, this initiative is really just about translating quality content and creating/improving content at other projects. Again, I'm just getting the ball rolling here and I would welcome all to continue the conversation and determine project/competition goals/rules. If there is enough interest, I would welcome forking this conversation to Wikipedia:Translatathon or wherever. ---Another Believer _(Talk) 17:39, 22 March 2019 (UTC)

Right. So I think you need to talk to User:Amire80, who probably knows more about translation than anyone else.

As for the competition aspect, creating 'missing' articles is often more valuable than updating an medium-quality one to good quality. It's also easier to measure. The new m:Programs & Events Dashboard might be useful for tracking participants. WhatamIdoing (talk) 18:12, 22 March 2019 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I hope editors don't mind, I'm archiving these comments and copying over to Wikipedia:Translatathon for further discussion. ---Another Believer _(Talk) 02:14, 4 April 2019 (UTC)

Wikipedian resource groups

Do we have anything resembling employee resource groups? My new employer has three: one for women, one for employees of color, and one for LGBTQIA+ employees. I think this is a good idea for Wikimedia projects to implement, and would add to it: lower- and working-class Wikipedians, and Wikipedians with disabilities. I think this could work especially if it's complemented by an off-wiki space like a new channel in our Discord. Qzekrom 💬 ^they_them 05:02, 9 April 2019 (UTC)

Users here only disclose what information they want to, so they may or may not identify as members of some group you may be interested in. You can start navigating at Category:Wikipedians and expand out categories, you will see some of the groups you mention there. "Color" is a very American way to pigeonhole people, but there is Category:Wikipedians by ethnicity and nationality‎. I don't like the idea of these subsets being "resource groups", as if they are about to be exploited. Self interest in the Wikiprojects is where our users take their initiative at volountyeering for work. Graeme Bartlett (talk) 10:52, 9 April 2019 (UTC)

I, as a member of two of the groups identified above, also don't like this idea. Participation in any sort of group on Wikipedia, such as Wikiprojects, should be available to anyone interested in the relevant subject rather than just "insiders", and, as Graeme said, we have no means of identifying whether anyone is really a member of any group. There's also the danger that such groups would become a vehicle for advocacy rather than a means of improving Wikipedia. Phil Bridger (talk) 11:05, 9 April 2019 (UTC)

Add dark mode option to Wikipedia

It would be easier on the eyes (especially at night) and waste less battery life. X-Editor (talk) 15:13, 8 April 2019 (UTC)

Is mw:Skin:Vector-DarkCSS what you're looking for? You might want to go to your preferences and check "black background, green text" as an alternative. ‑ Iridescent 15:21, 8 April 2019 (UTC)

@X-Editor: You might also be interested in phab:T122924. Jc86035 (talk) 15:56, 8 April 2019 (UTC)

I want a button on Wikipedia that you can click to change to dark mode for the causal reader and editor, not something you have to download or something that requires multiple steps. X-Editor (talk) 21:57, 8 April 2019 (UTC)

You will likely need an account, but otherwise that is one of the tasks to watch. You can also watch phab:T26070 and children. --Izno (talk) 21:30, 8 April 2019 (UTC)

MusikAnimal was developing 'NightPedia'. When (and if) that is completed, it might be what you are looking for. 125.63.105.110 (talk) 15:15, 9 April 2019 (UTC)

There are a number of tasks out there about a night/dark mode. Following meta:Community Wishlist Survey 2019/Reading/Night mode, we will see a solution sometime this year for all skins, including mobile, and all users, logged in or out. Investigations and designs are still in the early stages. My own Nightpedia is merely a user script that mostly looks good (I think) and works for all skins, except it flashes on every page load because it's not a proper gadget. You can try it by adding importScript('User:MusikAnimal/nightpedia.js'); to your common.js, but don't expect perfection. — MusikAnimal ^talk 15:27, 9 April 2019 (UTC)

I don't expect perfection, I just want a decent dark mode option, and I'm glad you are working on that. X-Editor (talk) 20:17, 9 April 2019 (UTC)

Adopt an article

Is there a system for "adopting" articles after they pass AfC? I'm creating a draft article under a conflict of interest condition and want to trust that someone else will be maintaining it, since I can't be the one to maintain it after it is moved to mainspace. Essentially, after submitting the article, I want to hand it off to another editor who is interested in the subject and plans to add to it whenever new information about the subject becomes available in reliable, published sources. Qzekrom 💬 ^they_them 07:59, 12 April 2019 (UTC)

Not a single editor to the exclusion of others, see WP:OWN. If other editors become sufficiently interested they will perform the maintenance. There's nothing to stop you {{ping}}ing an editor you think will assist though, see WP:OAS. Martin of Sheffield (talk) 08:52, 12 April 2019 (UTC)

Qzekrom everything on Wikipedia is volunteer work, and people work on whatever catches their interest. We have over 5 million articles, so a lot of articles just fall into the background. However you can indirectly maintain the page. You can use {{request edit}} on the article's Talk page to propose updates or other changes. That will bring in someone to review the edit request for neutrality and other criteria. They may make the full edit, or part of the edit, for you if hey find it appropriate. There's a bit more info at WP:Edit requests. Alsee (talk) 17:16, 12 April 2019 (UTC)

RfA reform: straight vote?

Is it really practical to expect 200–300 people to have a discussion that leads to consensus about a controversial topic (as opposed to near-unanimous landslides)? In any "close call" situation, any assessment of consensus is likely to upset a significant number of editors and be seen as a supervote, which hurts the RfA process, the candidate, the 'crats, and the !voters. Does requiring/encouraging oppose rationales encourage mud-slinging/dirt-digging/rehashing old disputes, where a secret vote would not? Maybe it would be better to have a clear, simple vote, in both directions?

What if the system was:

1. Anyone can nominate an editor for RfA including self-nominations. There's a period for questions to the candidate and discussions, followed by a vote (like ArbCom elections). > 50% support gets the bit.
2. Anyone can nominate an admin for a "vote of confidence" (including self-nominations). There's a period for questions to the candidate and discussions, followed by a vote. < 50% support loses the bit.
3. Editors who make bad faith or frivolous nominations can be TBANed through the usual community procedures.

Thoughts? Leviv ich 16:09, 12 April 2019 (UTC)

ArbCom functions very effectively to desysop admins when this is required. Not broken so don't fix. As for RFA, there have been perennial reform proposals and none of them have proven better than the existing process. Jehochman ^Talk 16:19, 12 April 2019 (UTC)

• Per Jehochman, other desysoping alternatives have been proposed at RfC - I've proposed some of them. None of them gained traction. Years ago at WP:RFA2011, the RfA process was examined in depth, compared with the systems on other major Wikis, and thoroughly analysed for solutions but none of the many suggestions even reached RfC stage. What we were left with was the one single verdict that the voter community needs to smarten up its act. Kudpung กุดผึ้ง (talk) 16:38, 12 April 2019 (UTC)

  Indeed, but how many editors who are active now were active in 2011? I never really understood the Wikipedian reaction of, "we don't need to talk about this, we talked about it already five or ten years ago." I would encourage you (or anyone) to put forward whatever you think are the best ideas from previous discussions, and let a new generation of Wikipedians examine them (if they haven't already). To me, there's a difference between talking about something that was talked about a year ago, and talking about something that was last discussed eight years ago. Leviv ich 17:34, 12 April 2019 (UTC)

  • • Without prejudice to the outcome of this discussion, the last time I asked about average tenure about six months ago, it was my understanding that over half of active and very active editors had 7+ years of tenure, and more than 70% of admins did. I rather doubt that's changed very much. I'm sure someone with number crunching skills and sufficient computing power could give a definitive answer. Risker (talk) 01:45, 13 April 2019 (UTC)

      I know I've seen charts that show editors by tenure with multiple colored bands for the "generations", but I can't find it now. Per your understanding, though, about half of active editors didn't take part in the in-depth 2011 RfC, and the other half now have seven additional years of experience to draw upon. I don't think we should be shy about brainstorming solutions (and documenting our efforts at WP:RFA reform), because the potential problems–decrease in admin, decrease in admin:editor and admin:article ratios, increase in backlogs–are objectively-measurable problems. (Even if the idea I posted is not the solution. I'll note Useight has posted a list of concerns for discussion here.) Leviv ich 07:20, 13 April 2019 (UTC)

• My favorite RfA reform is the idea of bundling - that every 3 months ore when there are 5 RfA candidates, whichever happens first, there is an RfA. In this way the focus is taken away from any individual editor which would hopefully provide some "safety in numbers" in general while still being a small enough grouping that each editor could be appropriately vetted by the community. Best, Barkeep49 (talk) 16:48, 12 April 2019 (UTC)

• First of all, 50%+1 is far too small a threshold for granting advanced permissions. Secondly, restricting the RFA process to uncommented votes makes it difficult for people who don't know the candidate. Understanding why people are supporting or opposing a candidate is arguably more important for building consensus than just that they are supporting or opposing a candidate "I vote oppose because I'm an asshole who opposes all RFA candidates" is a very different rationale than "I vote oppose because here's this evidence that this candidate would not use the bits wisely <diffs>" and bureaucrats need to weight the voting based on the strength of the rationale behind them. Certainly, number of votes is a factor in determining strength of support or opposition, but so is why people are voting that way. I wouldn't want to remove that aspect from the vote. --Jayron32 16:51, 12 April 2019 (UTC)

  What are your thoughts on running RfAs like ArbCom elections: discussion and Q&A pages with a SecurePoll, straight vote (at whatever threshold of success), scrutinized by stewards for integrity but no consensus assessment by 'crats. Leviv ich 17:39, 12 April 2019 (UTC)

  No, that's worse. Crats are promoted expressly because their ability to read the nuance in discussions of this nature. We want more nuance in our governance, not less. --Jayron32 17:41, 12 April 2019 (UTC)

• What about the opposite? People can submit comments on nominees, and then the bureaucrats decide if someone passes, and what or may not take whatever is said into consideration. Similar to CU/OS. Natureium (talk) 16:52, 12 April 2019 (UTC)

• Nothing on this site works as a straight vote, everything is a discussion, and I don't think it makes sense for RFAs to be any different. I don't know about you, but I certainly try to read at least most other comments before posting my own. I'm sure the current system isn't perfect, but it does give a very good opportunity for people who are unsure on an issue to see the evidence that other users think is most important, examine it, and then evaluate others' arguments before coming to their own conclusions. RFAs are basically super RFCs, with a somewhat more formal structure and closure restricted to bureaucrats. English Wikipedia is 100% committed to that formula as the ultimate process in resolving questions, so it's only fair that administrators are picked the same way. Red Rock Canyon (talk) 17:57, 12 April 2019 (UTC)

• I agree that RFA shouldn't become a straight vote, for many reasons, but it is not true that nothing on this site works as a straight vote. We vote for arbitrators. Phil Bridger (talk) 18:22, 12 April 2019 (UTC)

• Yes, "nothing" was something of an exaggeration. I'd say that the arbcom elections are the exception that proves the rule. It's the only election or formal vote for anything, as far as I know. Red Rock Canyon (talk) 00:57, 13 April 2019 (UTC)

• Well argued oppose rationales have their use. They can swing the discussion and, regardless of the outcome, can show the candidate aeras in which they can improve. Challenges to oppose !votes can also help turn a straight oppose into something other editors can use to inform their deliberations. Cabayi (talk) 19:14, 12 April 2019 (UTC)

• Please note that whenever the question of whether RfA needs reform 60% to 70% say "yes" but that no proposal for a specific fix has ever reached even 5% approval. Now we are pretty much seeing new people reinvent ideas that were rejected in the past. --Guy Macon (talk) 20:01, 12 April 2019 (UTC)

• We have a declining number of admins, so having an additional and unnuanced route to desysop would be moving in the wrong direction. As for straight votes, remember quite a few of us got through on the second or subsequent run, as someone who got through on my second RFA being able to know why people opposed in the first was useful. More importantly, only a tiny proportion of RFA voters actually research candidates, most look no further than the nomination and the page of the RFA itself. But those few who do research candidates do sometimes find reasons that rightly torpedo an RFA. Moving to straight votes loses that vital safeguard. You don't need it for Arbcom as few will vote for non admins. There have been quite a few changes to RFA over the years, so improvements are still possible, however this proposal would not be an improvement. ϢereSpielChequers 20:26, 12 April 2019 (UTC)

• I am not a fan of the above proposal. However I will say that I have always believed that an admin's tenure should run no more than maybe ten minutes past the point where it becomes clear that s/he has lost the confidence of the community. Arbcom should properly retain the last word on involuntary desysopping. But if a serious motion of "No Confidence" based on credible evidence of egregious misconduct or serial bad judgement calls was presented at AN/I and it became clear that by a wide margin the community had indeed lost confidence in a given admin, I would hope that they would resign. Any such "motion" of course would not be binding. But it would be really hard to ignore and I would assume that Arbcom could enforce it if the vote was overwhelming. -Ad Orientem (talk) 01:33, 13 April 2019 (UTC)

• Argued oppose rationales are critical - they reveal some seriously important concerns at points. I'd be perfectly happy if Support votes were also subject to challenge, but perhaps that's just me. Nosebagbear (talk)

• Personally, I think setting some minimum criteria for non-behavioural criteria (edit count, manual count, articles created etc) should be agreed, and then no oppose votes on those bases would be counted (e.g. If an editor had the agreed 18k edits, no oppose vote on "too few edits" would count). Nosebagbear (talk) 11:42, 13 April 2019 (UTC)

Sandbox edit notice or some other method of discouraging article creation in sandboxes

Dear editors:

While sandboxes are useful for playing around with wikitext, etc., they often are used to draft articles. There is a process flaw that can happen; for example:

• Editor A creates a draft article in their sandbox
• Editor B moves the contents to Draft space or to mainspace (perhaps after an AfC review or a request for help at the Teahouse). This leaves the sandbox with a single diff about the move, attributed to Editor B.
• Editor A creates a new draft in the same sandbox
• The new draft is then moved to mainspace, along with Editor B's move diff from the first article
• Editor B is now credited as the originator of an article that he or she may never have seen.

Here's an example Happy (manga character) - if you check the history you will see my username as the first edit, although I have nothing to do with this article.

Why is this a problem? Well, for example, today I received a notification today from Page Curation that an article was about to be deleted, and that I could contest the deletion. (User talk:Anne Delong#Speedy deletion nomination of Poseidon Asset Management) However, the actual creator of that article was not notified, and likely won't know that the article was deleted or how to contest the deletion.

Really a better way for users to create article drafts in their own space is to make user subpages (for example, User:Editor A/Pagename). That way, the subpages are not reused, and the history of each is clean.

Is there some way to encourage that? Maybe an edit notice on sandboxes ("This sandbox is for experimenting; if you are starting a draft article you can make a user subpage for it. Here's how: Wikipedia:User pages#Creating a subpage". The only problem with this is that that link leads to a video which actually encourages a user to draft articles in the sandbox. It would be nice if this could be changed.

Alternatively, the edit notice could say "This sandbox is for experimenting; if you are starting a draft article, click here" - which would take the user to a process that would ask the name of the proposed article and open an edit window "User:Editor A/Pagename".

—Anne Delong (talk) 12:39, 13 April 2019 (UTC)

When you move the page out of the sandbox, uncheck the "leave redirect" box, if you can. If you can't, then tag the redirect for deletion. ~ ONUnicorn^{(Talk|Contribs)}problem solving 15:23, 15 April 2019 (UTC)

Get people to read Wikipedia:Dispute resolution

I don't know if anybody has noticed, but there's a lot of edit warring, flame warring, and general hissy fitting when people disagree about content. It would help a great deal if more people read Wikipedia:Dispute resolution before getting into arguments. (Yes, I'm guilty of not reading it too. See my talk page.) We need to think up ways to change this. My own pet ideas:

• The first time a logged in user reverts, we ask them to read it. Anonymous users, every time.
• Simplify the damned thing. Does it have to be that complicated?
• Draw a flow chart of the DR process.
• Create a cutsey animated video.

I'm sure others have their own ideas. Let's hear them! Isaac Rabinovitch (talk) 22:59, 14 April 2019 (UTC)

Isaac Rabinovitch, I'm conflicted. On the one hand, I'm not about to argue with the observation that editors jump too quickly into edit warring and other negative behavior than we would like. (Has this increased over time? If so, could it be exacerbated by the growth of social media?) If one agrees that there is too much edit warring, it's a short jump to observe that many new editors are unaware of our dispute resolution processes and want to find ways to make new editors aware of those options.

On the other hand, there are a lot of things I want new editors to learn, not just the existence of DR. I do a lot of work in copyright areas, and it is clear to me that many new editors are under the impression that copying and pasting something you find on the Internet into a Wikipedia article is perfectly acceptable. Should I insist that no one be allowed to edit until they've reviewed an animated video about copyright and walked through a relevant flowchart?

And even if you happen to agree, I suspect many other long time editors could identify a dozen other shortcomings of newer editors. We have to identify and prioritize which things ought to be delivered first.

As an alternative I just glanced at some of our welcome templates: Wikipedia:Welcoming_committee/Welcome_templates and note that the first few I looked at didn't mention anything about dispute resolution. Perhaps it would make sense to debate whether some of those welcome templates ought to be edited to include a link to the dispute resolution process. S Philbrick(Talk) 19:17, 21 April 2019 (UTC)

I think this is a problem with people using templates to welcome people rather than just writing a couple of sentences. Any template will provide far more information than any new editor should be expected to absorb, so welcome messages should be personal. If people are incapable of writing a couple of sentences in English rather than using a template then what are they doing editing an English-language encyclopedia in the first place? Phil Bridger (talk) 19:31, 21 April 2019 (UTC)

Phil Bridger, I have been guilty of the above but (+1). ∯WBG^converse 19:57, 21 April 2019 (UTC)

Add Simple English back to Language selector in sidebar

Don't have time to develop the idea, but I legitimately thought that people just stopped writing Simple English articles ever since the new language selector went into beta. Erik Humphrey (talk) 05:11, 15 April 2019 (UTC)

Its a bug. See phabricator:T210840. The work around for now is to turn off Compact Language Links in your settings and it will start showing up again. -DJSasso (talk) 16:01, 15 April 2019 (UTC)

Depiction of Wikimedia Foundation destroying Wikipedia with Visual Editor, Flow, and Mobile App instead of making obvious but boring improvements to what we have. —pythoncoder (talk | contribs) 21:08, 21 April 2019 (UTC)

Help

I dont know if I am posting this at the right place. But there is some kind of technical difficulty with the Annual readership-tag that can be placed on an talk page of any article. The tag works for a a day or two and then go dead, so no new data over how many readers a article gets over a period of a year or so. It is just a little but annoying problem. My idea was that this particular tag could be upgraded or similar. --BabbaQ (talk) 22:32, 15 April 2019 (UTC)

So this is Template:Annual readership. The right place to ask about this would be WP:VP/T. I hope this is not a joke because you add the template to the pages of the recently dead. I wonder if the page has to be purged to update the template contents. Graeme Bartlett (talk) 23:30, 15 April 2019 (UTC)

I have tried it on a couple of pages, and I cannot reproduce the problem, after a week. Graeme Bartlett (talk) 22:20, 23 April 2019 (UTC)

Smartphone app and/or text notifications

As a suggestion that popped into my mind, I'm not sure if such a feature exists, but maybe there should be some sort of app or text notification service of some sort where, if signed up for, could give us a smartphone notification when registered users are given a notification (such as user talk page messages, pings, change in rights (including blocks), thanks, etc.) or there are changes on a page on their watchlist where smartphone notifications could be enabled to recieve one notification per period of inactivity per watched page for (particularly talk pages, whether for articles, AN(I), Village Pumps, ArbCom cases, RFA, AFD, wikiprojects, etc.). How feasable would such an idea be? DrewieStewie (talk) 01:54, 25 April 2019 (UTC)

So you mean like the email notifications? But sent to a phone number? That probably wouldn't be too hard. Eman235/talk 16:23, 25 April 2019 (UTC)

I would like notifications of talk page messages and pings, but I think watchlist notifications would be unwieldy. ~ ONUnicorn^{(Talk|Contribs)}problem solving 16:29, 25 April 2019 (UTC)

There's a link to an RSS Atom feed on the watchlist page. You could put that in an RSS feed smartphone app of your choice. Daß Wölf 17:41, 25 April 2019 (UTC)

DrewieStewie, you could also post that idea to mw:Talk:Talk pages consultation 2019. Some similar suggestions have already been made (mostly about a smartphone notification for messages left on your talk page), but I don't think anyone has mentioned this exact idea. Whatamidoing (WMF) (talk) 18:03, 26 April 2019 (UTC)

Citation proposal

I use shortened notes linked with {{tl|sfn}} and citation templates, styled Sudirman, (the featured article on the day I joined). The benefits I find using {{tl|sfn}} are no large interruptions in prose when editing, and {{tl|citation}} for the alphabetization of sources. The only detriment is the auxilliary set of references in addition to sources.

-	<ref></ref> and {{reflist}}	{{sfn}}}, {{reflist}} and {{citation}}
Prose	Within hours, the Paris prosecutor's office had opened an investigation into the fire, led by the Paris Region Judicial Police.<ref>{{cite news |title=Notre-Dame de Paris : une enquête a été ouverte pour "destruction involontaire par incendie" |url=https://www.laprovence.com/actu/en-direct/5459359/notre-dame-de-paris-une-enquete-a-ete-ouverte-pour-destruction-involontaire-par-incendie.html |accessdate=15 April 2019 |website=La Provence |date=15 April 2019|language=fr }}</ref> The cause of the fire was not immediately known. The investigation most strongly suspected a case of "accidental destruction by fire", but had not ruled anything out, saying it was too early to know the cause of the fire.<ref name="ladepeche">{{cite web |url=https://www.ladepeche.fr/2019/04/15/incendie-a-notre-dame-lorigine-de-lincendie-reste-inconnue,8132982.php |title=Notre-Dame : la piste accidentelle privilégiée, les ouvriers du chantier entendus en pleine nuit |trans-title=Notre-Dame: prioritized accident investigation, construction workers heard in the middle of the night |website=La Depeche |accessdate=16 April 2019 |language=fr}}</ref><ref name="six_questions">{{cite web |url=http://www.leparisien.fr/faits-divers/six-questions-sur-l-incendie-de-notre-dame-de-paris-15-04-2019-8054094.php |title=Six questions sur l’incendie de Notre-Dame de Paris |trans-title=Six questions about the fire of Notre-Dame |website=Le Parisien |accessdate=16 April 2019 |language=fr}}</ref> ==References== {{reflist}}	Within hours, the Paris prosecutor's office had opened an investigation into the fire, led by the Paris Region Judicial Police.{{sfn|La Provence Staff|2019}} The cause of the fire was not immediately known. The investigation most strongly suspected a case of "accidental destruction by fire", but had not ruled anything out, saying it was too early to know the cause of the fire.{{La Depeche Staff|2019}}{{La Pariesen Staff|2019}} ==References== {{reflist}} ;Bibliography {{citation|author=La Depeche Staff|url=https://www.ladepeche.fr/2019/04/15/incendie-a-notre-dame-lorigine-de-lincendie-reste-inconnue,8132982.php|title=Notre-Dame : la piste accidentelle privilégiée, les ouvriers du chantier entendus en pleine nuit|trans-title=Notre-Dame: prioritized accident investigation, construction workers heard in the middle of the night|website=La Depeche|accessdate=16 April 2019|language=fr}} {{citation|author=La Parisien|url=http://www.leparisien.fr/faits-divers/six-questions-sur-l-incendie-de-notre-dame-de-paris-15-04-2019-8054094.php|title=Six questions sur l’incendie de Notre-Dame de Paris|trans-title=Six questions about the fire of Notre-Dame|website=Le Parisien|accessdate=16 April 2019|language=fr}} {{citation|author=La Provence Staff|title=Notre-Dame de Paris : une enquête a été ouverte pour "destruction involontaire par incendie"|url=https://www.laprovence.com/actu/en-direct/5459359/notre-dame-de-paris-une-enquete-a-ete-ouverte-pour-destruction-involontaire-par-incendie.html|accessdate=15 April 2019|website=La Provence|date=15 April 2019|language=fr}}
Benefits	One-level Bibliography	Continuous prose Alphabetical, centralized Bibliography
Detriments	Interruption in prose Disordered Bibliography	Two-level Bibliography

Proposal

A script, loaded during publishing, which scans the page, and matched {{sfn}} with {{citation}}, generating a BACKREF suffix, after the appropriate citation. By using {{sfn}} and {{citation}}, built the way I've described, there will be no two-level Bibliography, saving page space, no large interruption in prose, making it easier to read, and an organized, alphabetized bibliography.

In the case of pages, or locations, they will be added in the suffix, and linked to the selected citation via CITEREF, (example, p. 25, highlighted in blue), after clicking.

*Ricklefs, M.C. (1993). A History of Modern Indonesia Since c.1200 (2nd ed.). London: MacMillan. ISBN 978-0-333-57689-2., ^{^ a} p. 12 ^b p. 25 ^c p. 74

Logic

IF {{sfn|Ricklefs|1993}} AND {{citation|last=Ricklefs|date=1993}} THEN: CITEREFRicklefs1993a AND BACKREFRicklefs1993a

AND (a second reference is used)

IF {{sfn|Ricklefs|1993}} AND {{citation|last=Ricklefs|date=1993}} THEN: CITEREFRicklefs1993b AND BACKREFRicklefs1993b

For the prose: [[CITEREFRicklefs1993a|[[1]] ]]; to link to the Bibliography section.

For the Bibliography: [[BACKREFRicklefs1993a|a]]; to link to the article citation.

Proposal

References AllMusic Staff (2011), "Tyler Pursel Credits", AllMusic, retrieved 27 January 2014 {{citation}}: |author= has generic name (help), ^ Apar, Corey (5 September 2007), "Ladybirds", Spin, retrieved 22 January 2014, ^ a b c d Apple, Meiyee (16 July 2007), "Regional Community Theater", The Fader, retrieved 23 January 2014, ^ a b c d Aubin, Paul (19 July 2007), "Videos: Ladybirds: "The Brown and Red Divide"", Punknews, retrieved 26 January 2014, ^ Bunch, Adam (22 August 2007), "Ladybirds: Regional Community Theatre", PopMatters, retrieved 24 January 2014, ^ a b DeAndrea, Joe (2007), "Ladybirds - Regional Community Theater", AbsolutePunk, retrieved 24 January 2014, ^ a b c Greene, Jo Anne (2007), "Regional Community Theatre", AllMusic, retrieved 24 January 2014, ^ a b c Hasty, Katie (17 September 2007), "Ladybirds Take Flight", Billboard, retrieved 26 January 2014, ^ Olund, Paul (6 July 2007), "Candy-coated goodness to make you smile", Today, NBC, retrieved 22 January 2014, ^ a b c d

Article

Regional Community Theater is the debut studio album from the American pop duo Ladybirds. After the breakup of Ley Royal Scam in 2006, Tyler Pursel returned to working with Gym Class Heroes and writing dance-pop music on the side, while Teeter Sperber relocated to Oregon. When composing, Pursel originally intended for many vocalists to be featured on the album, however, contacting his former band-mate Sperber to sing one of the tracks ultimately led Pursel to ask Sperber to sing the entirety of Regional Community Theater. Most of the album was arranged while Pursel and Sperber were in different regions of the United States, but by January 2007, they joined at a Creep Records basement studio in West Chester, Pennsylvania to put the final touches on Regional Community Theater. Tyler Pursel is credited as producer. The album was released on 18 September 2007, on Creep Records on compact disc and digital download. Regional Community Theater was reissued by Mint 400 Records digitally on 5 July 2011. While in post-production, Sperber was singing "How can we be the best, yet be failing all the time?" for the title track, which elicited uproarious laughter from Pursel. In a Billboard interview, she explains "I sang the word "best," like a total, unabashed thespian spazz, arms raised to the sky, channeling my very best Bernadette Peters [and] once we composed ourselves I said, "Geez Ty, I am so sorry for getting all Regional Community Theater on your ass" to which he said "It's okay, Teet, as long as that can be the title of our record." Regional Community Theater is an eleven track album of dance-pop, described by Corey Apar of Spin as a "Nintendo version of Candyland, where eight-bit blurps, shiny werps and ticks, and apple-colored synth beats entertain the whole way to Candy Castle." Lyrically, the album focuses on relationships; from friendship to romance. Several rock lead vocalists appear on Regional Community Theater; The Get Up Kids' Matt Pryor sings on "Cooper, Thanks for the Birds" and Max Bemis of Say Anything sings on "Maxim and the Headphone Life." Additionally, Danger O's' Justin Johnson and Fairmont's Neil Sabatino appear on the album. The opener "Slice Our Hands (We Are Blood Sisters)" is constructed with 8-bit music by Pursel. The second song, "Brown and Red Divide," was released as a single in June 2007, and accompanied by a music video. A children's chorus, the class of one of the Creep Records owner's daughters, sings the refrain on the love song "Andy Lex." On the title-track "Regional Community Theater," Max Bemis makes his first appearance assisting with vocals. The final song, "You Are The Torro King" is an instrumental track, which features distorted drums, dark synthesizers, vintage electro-accordion and bells. Professional ratings Review scores Source Rating AbsolutePunk 85% AllMusic The Fader Mixed PopMatters 6/10 Reviews for Regional Community Theater were mixed to positive. Joe DeAndrea of AbsolutePunk gave a favorable review, noting the "superb" list of guest vocalists and calling it "overall a very fun listen." Similarly, in an AllMusic review Jo-Ann Greene applauds the album, saying "..so upbeat is the music, that inevitably the characters have no choice but to make peace." She goes on to explain that Regional Community Theater "work[s] on two levels, enchanting the kids whilst simultaneously capturing the imagination of adults." In a mixed review in The Fader, Meiyee Apple likens Sperber's vocals to Hilary Duff, and calls the album "cute electro-pop[,] if you like being sung to by a baby, and you are an actual baby." Sharing the same sentiment in a PopMatters review, Adam Bunch describes Regional Community Theater as a mostly straightforward album, but admires the moments of variety such as children’s choir (in "Andy Lex") and pitch-shifted vocals. However, Apple acknowledges Ladybirds admission of their "sticky sweet sound," saying that they do a "good job [in the] department of mindless fun."

Current

References Citations Online sources AllMusic Staff (2011), "Tyler Pursel Credits", AllMusic, retrieved 27 January 2014 {{citation}}: |author= has generic name (help) Apar, Corey (5 September 2007), "Ladybirds", Spin, retrieved 22 January 2014 Apple, Meiyee (16 July 2007), "Regional Community Theater", The Fader, retrieved 23 January 2014 Aubin, Paul (19 July 2007), "Videos: Ladybirds: "The Brown and Red Divide"", Punknews, retrieved 26 January 2014 Bunch, Adam (22 August 2007), "Ladybirds: Regional Community Theatre", PopMatters, retrieved 24 January 2014 DeAndrea, Joe (2007), "Ladybirds - Regional Community Theater", AbsolutePunk, retrieved 24 January 2014 Greene, Jo Anne (2007), "Regional Community Theatre", AllMusic, retrieved 24 January 2014 Hasty, Katie (17 September 2007), "Ladybirds Take Flight", Billboard, retrieved 26 January 2014 Olund, Paul (6 July 2007), "Candy-coated goodness to make you smile", Today, NBC, retrieved 22 January 2014

- NorthPark1417 (talk) 10:33, 18 April 2019 (UTC)

So, in other words, you want to have a script that somehow reinvents what the Cite extension already does in a slightly different way? For this example you can fix the "interruption in prose" disadvantage by simply using WP:List-defined references (LDR) instead of {{sfn}}. It's unclear what benefits you see in alphabetical ordering of the references in a hypertext document using numbered note markers (versus a text document with [[[parenthetical referencing|parenthetical references]]).

The usual argument for {{sfn}}, which LDR doesn't fix, is that it allows more compact referencing of multiple pages in a work (as with Cite-style footnotes you have to repeat the entire citation with only the page number changed). But IMO to solve that it would be better if the change proposed at m:WMDE Technical Wishes/Book referencing were implemented. Anomie⚔ 11:48, 18 April 2019 (UTC)

An interesting and well thought out idea. I'm not certain however that a two-level bibliography can be dismissed without discussion as a "con". Possibly because I have a background in computers or else possibly due to familiarity I have no problems with a normalised two table approach. Others may disagree. @Anomie: I've used LDR referenced articles in the past and the solution is a workable one, but it does lead to a requirement for editors to devise and keep track of a naming scheme; {{sfn}} does this for you. LDR also can generate messages along the lines of "Cite error: A list-defined reference named "FOOTNOTELa Chesnaye des Bois1770table at the end of the volume" is not used in the content (see the help page)." which have the clarity of mud.

As Anomie points out though, work is progressing at m:WMDE Technical Wishes/Book referencing to address all these points and it would be wasteful to spend a lot of time on yet another approach. I've even heard a whisper that a citation manager such as Zotero could be integrated at some point in the future and allow an automatic, uniform citation style. A final point, when exactly would your script run? If it is as part of the preview or publish process (ie effectively a "subst:") that is reasonable, but if it is to be implemented as part of template processing it may have a notable impact of server load and page responsiveness. Martin of Sheffield (talk) 13:00, 18 April 2019 (UTC)

IIRC, Zotero is what's behind VisualEditor's citation insertion/formatting tool, but the uniform styling comes from our family of citation templates rather than the fact that Zotero can be used to help fill in those templates. Anomie⚔ 13:11, 18 April 2019 (UTC)

Thanks for that. I always use the traditional text editor, not the visual one - just personal choice. I accept what you are saying about the styling within citations coming from CS1/2, I was thinking of the slightly larger picture, possibly "layout" rather than "styling" would be a better term. Martin of Sheffield (talk) 13:27, 18 April 2019 (UTC)

Wikipedia:CITEVAR would prevent such a script from being used. * Pppery * _{has returned} 13:31, 18 April 2019 (UTC)

Hello Anomie, Martin of Sheffield, and Pppery,

To Anomie, List-defined references does address most of my proposal, however, the naming of citation, and mixing html with template, are not ideal. For a single citation with multiple locations or pages, it separates instead of one listing. Alphabetical listing is easier to read, familiar from school.

To Martin of Sheffield, It would run at publishing the page, included in mw.loadData. The idea came from other Editors changing the citation style I write with, to compact the referencing. They noted that {{sfn}} was primarily used for multiple citation locations in a work, which does not typically occur with webpages. The user has to click once to the citation and again to the bibliographical listing.

To Pppry, to not interrupt the current citation style, I realize it would probably require a uniquely titled template (say, {{rfe}}) for in prose citation, to recognize not to generate a {{reflist}}. - NorthPark1417 (talk) 19:29, 18 April 2019 (UTC)

It looks like I badly misinterpreted what was being proposed here. However, given that CITEVAR says you can't convert existing articles to this style, is it really a good idea to invent your own unique citation style that is going to be used on some tiny minority of all articles? * Pppery * _{has returned} 21:01, 18 April 2019 (UTC)

An example of a page I have written, with excessive white space, as a result of the {{sfn}} and {{citation}} format, which I would convert. The style I am proposing may attract editors who are writing new articles. - NorthPark1417 (talk) 21:18, 18 April 2019 (UTC)

{{sfn}} and related templates are popular with a small group of editors who mostly cite books (rather than webpages, which easily outnumber all the other types of sources cited in Wikipedia). They are less convenient for other types of sources. These templates are also not supported by the visual editor, and, realistically, I do not expect that to change. In addition, they don't exist at many wikis, which causes problems for people trying to translate articles from this wiki. I do not encourage editors to use those templates. Whatamidoing (WMF) (talk) 19:56, 23 April 2019 (UTC)

Whatamidoing (WMF), apart from book, if I am citing a journal paper, 40 pages long, I will prefer sfn. Also, FWIW, editors who use such sources heavily, shall be urged to use SFN. Any article having thirty similar citations over the reference-section but with different page numbers is a horrible eyesore. It's another story as to why it's not supported by VE and that has a got a lot to do with WMF's culture than realistic coding difficulties. ∯WBG^converse 18:41, 25 April 2019 (UTC)

WP article have a section "Bibliography" or "Publications" that can be longer than the article itself. It is an eyesore that can be avoided if:

• Template:Collapse_top is implemented by default in Wikipedia of all languages (and then added to this kind of sections)
• Wikipedia create an open and separate project specific for bibliographies, like bibliowiki (Wikilivres) was untill six years ago. Bibligraphies can be moved from Wikipedia to the future Bibliowiki and linked in the WP "External links" section, so as not to have yet endless lists of books and publications on WP. The main advantage of an open Bibliowiki is that anyone can contribute, adding references that are discarded, censored, not indeed by the Web (Google Books) and by the main libraries -and so by Worldcat and similar databases. — Preceding unsigned comment added by 94.38.238.40 (talk) 22:23, 27 April 2019 (UTC)

Pending-changes blocks?

The question of school blocks was recently raised at Wikipedia:Requests for adminship/HickoryOughtShirt?4. While school blocks may be effective at preventing silly vandalism, they also prevent potentially helpful edits. Is it possible for school blocks to be implemented in a way that forces all edits made from the school to require review, via a process similar to pending changes? Is that technically feasible? feminist (talk) 03:29, 29 April 2019 (UTC)

@Feminist: Maybe something along the lines of Wikipedia:Flagged revisions and a bot to automatically flag revisions from schools? --DannyS712 (talk) 03:57, 29 April 2019 (UTC)

I'm not thinking a bot, that would be too slow. Just as admins apply school blocks to an IP or an IP range, so can they instruct the software to flag every edit that comes from these IPs and require them to be reviewed. feminist (talk) 04:17, 29 April 2019 (UTC)

Regardless of the implementation, I think the only way to make the edits be "pending" and need review is the implement flagged revisions. --DannyS712 (talk) 04:19, 29 April 2019 (UTC)

Well this wouldn't be a bad thing to at least test out in my opinion. Its a better solution than blocking a whole rang of IPs or placing individual articles under protection. Alucard 16_{❯❯❯ chat?} 06:19, 29 April 2019 (UTC)

Yes, the revisions should be flagged, but not via a bot, that would be too slow. Is it possible to instruct the software to automatically flag edits from a particular IP range (e.g. a school) for review. feminist (talk) 10:20, 29 April 2019 (UTC)

Edit filter ought to be able to tag all edits from from an IP or IP range. Something like a "PCP Level 0" (allow all edits, PCP queue people with a bit) applied to all pages might be possible but I have no idea whether IPs can be given bits or not (AFAIK, no ATM but I don't know if it can be easily implemented). Alpha3031 (t • c) 11:21, 29 April 2019 (UTC)

As a pending changes reviewer myself, I think this would be an amazing idea. We can filter out the vandalism from the helpful edits. After reading this idea, I am now a firm believer that Proxy IPs should be subject to flagged revisions or pending changes, and that they should only be blocked if the vast majority (provided the edits are frequent) of the proposed edits coming from a single IP are vandalism or disruptive. I'd be willing to perform this task and participate in any tests we initiate on this, and I'd be willing to report IPs falling under the disruptive criteria to admins for a potential block. It would also make it possible to create an account on an open proxy, which if we gain good faith, constructive contributors with their own accounts: Great! If we get vandalizing, disruptive contributors having an account: no problem, we can just revert them and place blocks if necessary as usual. DrewieStewie (talk) 11:29, 29 April 2019 (UTC)

Exception The exception to this would be any open proxies blocked as part of the Church of Scientology, per Wikipedia:Requests for arbitration/Scientology. Those should not be allowed to participate in the proposed flagged revisions for proxies proposal in order to uphold the ArbCom ruling. DrewieStewie (talk) 11:51, 29 April 2019 (UTC)

• Pending Changes queues can get pretty lengthy at times - if we were to implement this trial we'd need a way of actually get a higher % of the PC-authorised editors (which is a lot) to be more active on an ongoing basis (not just a big surge at the start). I also think any trial shouldn't just go head-first in to schools, proxies, organisations etc. Instead Schools might be a good start, as though the vandalism rate is staggering, it's quite easy to pick out - not much thinking required (whereas other organisation-blocks are more biased-edits, which can take more effort to filter). Nosebagbear (talk)
• As a follow-up to that, as this would be a flagged revisions consideration, it's going to get major massive blowback from the "slippery slope" crowd. Thus reasoning based on allowing currently prohibited groups to edit rather than restricting new editors would be needed from the off. Nosebagbear (talk) 21:34, 29 April 2019 (UTC)

I'd clear the backlog whenever I find time to. This has been my first week as a reviewer and I got to say, I love it. I have turned the backlog from 5 to 1 on a couple occasions, and plan to continue that in the future. I would agree though, we need more people to spend time actually using those tools, especially those who have that right but not admin rights. You have points. Should we seek further, more widespread community consensus elsewhere and ditto our already stated opinions onto there and see what others say? DrewieStewie (talk) 00:01, 30 April 2019 (UTC)

@DrewieStewie: - It shouldn't go to full community until there's a well set-up proposal and justification created. What would be a good first step, is to post this on the pending changes/pending changes reviewer talk page(s) (link here with a 2 line summary of what we're considering), to get some extra thoughts. A chat with a couple of our more technically adept editors to ensure we aren't considering something that would be a major technical hassle. Nosebagbear (talk) 15:07, 1 May 2019 (UTC)

@Nosebagbear: True. I'll discuss it there. DrewieStewie (talk) 16:04, 1 May 2019 (UTC)

As for running the idea down with an experienced technical editor, I shall ping a humble editor I've seen around and have much respect and admiration for, interface administrator, edit filter manager, and computer software engineer/expert @Oshwah: Two questions for you: 1. Would this idea be technically feasable and not problematic? I encourage you to run it down with other Wikipedia technical experts and maybe even invite them here for their thoughts on the technical feasability of this idea. 2. What are your thoughts on this idea? DrewieStewie (talk) 18:27, 1 May 2019 (UTC)

DrewieStewie - I appreciate the very kind words. :-) If you (or others) keep up at all with Wikimedia's tools that are under development and in-progress, we're (in a way) already developing and testing an extension to Special:Block and diversifying its ability. What's currently being tested is the ability to apply partial blocks to users and IP addresses / ranges, meaning that we can specify specific pages or namespaces that the user will be blocked from editing or interacting with, while allowing the user to edit all other areas of the project. There isn't currently an extension to it that would require all of one's edits to be reviewed before being published, but given the project's development, I wouldn't see this as a bad idea to bring forward if the community potentially sees this as a good idea. :-) ~Oshwah~^{(talk) (contribs)} 19:26, 1 May 2019 (UTC)

• Wouldn't it be possible to use a version the German model of WP:FLR but where, instead of sysops assigning a flag to an account to exempt them from review, all users were exempt, and sysops could assign a flag to opt them in? GMG^talk 19:39, 1 May 2019 (UTC)

Weekly newsletter for Meta-related (or other) news

​​Would it be a good idea to make a weekly or biweekly community-led Meta-focused newsletter, similar to Tech News, the Wikidata status updates or the OSM weekly/Wochennotiz?

This came up on the Discord server, in discussion of the Azerbaijani Wikipedia's RFC and the Croatian Wikipedia's RFC. The main issue this proposed newsletter would address is that almost no one seems to be actually aware of any of the things happening at Meta unless they are advertised somewhere else (e.g. through CentralNotice, posted on Jimmy Wales's talk page). m:Goings-on only includes WMF-related news (and not even all of it), which reduces its utility.

However, since new RFCs and new WMF initiatives don't occur that frequently, it might be useful (or pragmatic, depending on your point of view) to also include other things, like project milestones and meet-ups. It could also partially supplement the sort of news included in the Signpost (e.g. Wikipedia/other projects in the news), since that publication is now monthly rather than weekly.

Extended implementation brainstorming

Ways the newsletter could gain traction: ask WMF or WMDE to help make it, might be rebuffed write it (on Meta), spam it to various village pumps and assorted other places, and see if people like it ask for permission to create a newsletter or use MassMessage, see if anyone signs up begin it as a local (e.g. enwiki-only) newsletter, try to export it if that's successful run an RFC on Meta, which might get closed as invalid or might not be supported (and, of course, virtually no one would know about it…) Publication methods: send the entire newsletter (like Tech News) send section headers (like the Signpost) only send notifications don't send anything, wait for readers to come Things that could potentially be included: new and closed Meta RFCs new WMF-led discussions WMF blog posts things that WMF staff are doing – contributor-focused software initiatives, interviews, speaking engagements, etc. upcoming edit-a-thons / meet-ups and other events projects-related trivia or new material competitions (e.g. WikiCup) new projects, project closures, milestones external news coverage, scientific articles other news related to the projects in some way English Wikipedia goings-on, mailing list drama (à la OSM Wochennotiz), etc.

As noted above (in the collapsed section), it might be pragmatic to get the newsletter started on the English Wikipedia and then only move it to Meta if those who mainly contribute to other projects are interested in it. (A helpful factor is that the English Wikipedia is the largest project and many contributors to other projects know English as a second language.) Would this be a good approach? Jc86035 (talk) 17:39, 8 May 2019 (UTC)

Sounds like a great idea! Benjamin (talk) 06:09, 9 May 2019 (UTC)

• Definitely sounds like a good idea - I'm open to how we go about early-stage implementation language wise (it'd be nice to get a couple of other languages, but it will require at least a few translators for each language, so that the absence of some doesn't hold up an "edition"). I strongly think section headers (ala Signpost) are the way to go. While we're at it, we should make sure to get the SignPost to announce the creation of the process! Nosebagbear (talk) 09:07, 9 May 2019 (UTC)

  @Nosebagbear: The main reason that I'm not sure about the notification format is that the newsletter would have to be written in bullet points (like the other linked newsletters), as it would make it easier for editors to contribute to and to translate the newsletter. As such it might be better to post the whole newsletter.

  The way the OSM Wochennotiz handles publishing (it uses custom software to handle item submissions and other contributions) is that the translations are published later if not completed on time; this has happened several times for the English edition, with a version in another language being substituted. The Wikidata status updates are rarely translated, even though Wikidata itself is nominally language-agnostic. Jc86035 (talk) 10:58, 9 May 2019 (UTC)

@Jc86035: Hmm, I can see that and am certainly not experienced enough in these aspects to advise otherwise. What were your thoughts as to what would be a good/viable length in terms of readability/provision of detail/(future) translatability (well known word)? Nosebagbear (talk) 12:19, 9 May 2019 (UTC)

@Nosebagbear: I'm not sure. The latest edition of the OSM Wochennotiz, published five days ago, is about 1,700 words long and has been translated into eight languages (de, en, es, fr, ja, ko, pt, pt-br), so something like that is clearly achievable with about ten to fifteen authors (although the events that it covers occur at least a week before the publication). I think a similar length and a similar level of detail would be the upper bound for a Meta newsletter, although I would probably prefer something less lengthy. Jc86035 (talk) 12:45, 9 May 2019 (UTC)

@Jc86035: - 1700 is very long! This section (excluding the collapsed bit) is about 600 words. I'd say 850 would be a good average length with an extra 200-300 when major things crop up (like the re-branding research etc)? Nosebagbear (talk) 12:52, 9 May 2019 (UTC)

@Nosebagbear: I think that sounds about right, especially considering that weeklyOSM/Wochennotiz does have a fair amount of infrastructure behind it. Jc86035 (talk) 12:55, 9 May 2019 (UTC)