Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
  Policy   Technical   Proposals   Idea lab   Miscellaneous  

New ideas and proposals are discussed here. Before submitting:

« Older discussions, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142

RfC: Proposal - Removal of signature fields

  • Proposal: Images of signatures in infoboxes have little or no encylopedic value, so all infoboxes which have signature fields should have them removed. Beyond My Ken (talk) 00:02, 9 October 2017 (UTC)

Survey

  • Support as proposer. Beyond My Ken (talk) 00:02, 9 October 2017 (UTC)
  • Support Tony (talk) 03:18, 9 October 2017 (UTC)
  • support --JohnBlackburnewordsdeeds 04:02, 9 October 2017 (UTC)
  • Support Alex ShihTalk 04:03, 9 October 2017 (UTC)
  • Support per Tony, basically. No reason to have it unless there is something actually notable about it, in which case write about it in the article, not the infobox. ansh666 04:26, 9 October 2017 (UTC)
    Tony hasn't offered a rationale, though.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  19:57, 9 October 2017 (UTC)
  • Oppose such sweeping and unspecific guidelines. This would alter almost 90,000 pages and provide little to no guidance. Signatures such as those belonging to individuals signing historic documents (John Hancock, George Washington, and anyone else who can enact laws with their signature) and those belonging to famous artists are just some of the cases that require discretion that this proposal doesn't address. I'm not necessarily opposed to moving them out of the infobox and don't believe we should be including them for graphoanalysis, but just unilaterally removing them is problematic. Nihlus 05:09, 9 October 2017 (UTC)
  • Support Given that an infobox is supposed to be a quick summary of a person's bio, I cannot see how a signature fits that. In the body, it can be used, but not infobox. --MASEM (t) 05:21, 9 October 2017 (UTC)
  • Support --Blackmane (talk) 05:41, 9 October 2017 (UTC)
  • Support - Very sensible proposal. Even without the concerns presented below, from a content-to-space ratio perspective it does not make sense to include the signature in the infobox. That is not useful overview information, and says nothing about the subject as the other fields in the infobox do. -- Ajraddatz (talk) 06:38, 9 October 2017 (UTC)
  • Oppose something so broadly constructed. My feeling is similar to Nihlus, I think. I completely get why we have signatures for American presidents, whose signatures are the instrument by which laws come into force. There are probably other good examples that are beyond my info horizon. But do we need Pedro Pascal's signature? No. So I would enthusiastically support this if it was construed more narrowly. A Traintalk 06:45, 9 October 2017 (UTC)
  • Support. Not key information about a person. Also can aid in attempting forgeries of documents (though that's not my principal objection, the content's irrelevance is).  Sandstein  07:13, 9 October 2017 (UTC)
  • Support. Notable, authentic signatures for non-BLPs can always be added directly into the article if necessary: removed from an infobox doen't equal can't be used anywhere, anytime. Fram (talk) 08:27, 9 October 2017 (UTC)
  • Oppose as written - Support omission as default per first sentence at MOS:INFOBOX - not a "key feature of the page's subject" in most cases. Omit signature from the infobox unless there is discussion-based consensus to include it. Oppose outright ban from the infobox. My approach would mean that a signature could be removed from any infobox without local discussion, based on this consensus, pending discussion-based consensus to include it. ―Mandruss  09:13, 9 October 2017 (UTC)
  • Oppose though I'd be open to prohibiting it for living persons who are non-public figures. This is actually fairly normal to see in short biographical articles off Wikipedia as well and does add encyclopedic value in my opinion. I'm particularly thinking of heads of state, heads of government, religious leaders, noted authors, etc. where their signature is publicly known and very much associated with who they are. As always, I appreciate BMK's efforts here, but unfortunately I cannot support this specific proposal. TonyBallioni (talk) 10:01, 9 October 2017 (UTC)
  • Support There may be certain figures whose signature is relevant to their encyclopaedic value (someone mentioned presidents- good example, per thatthey sign off laws. Artists might be another, as they stick em at the bottom of their works on a regular basis). But the current position which is that since their is an IB parameter, it must be filled, even if the only way of doing so is to effectively forge the thing. Madness. This is completely unencyclopaedic behaviour. The use of signatures should be governed by our usual policies of WP:VNT and WP:RS; if the sig is covered in sources, there's something that makes it notable, so we use it. Otherwise, our default position should be no signature, and the argument should be made on a case-by-case basis for inclusion. On edit let me clarify per below. The IB parameter encourages inclusion of the sig. It aso means that the onus is on us to patrol articles to ensure that a sig is not inserted without consensus. This is not good. So what we do is, we prevent a sig being inserted by default (per this proposal), yet we allow sigs to be used in articles (as per WP:MOSIMAGE) on a case-by-case basis. So noooo.... definitely not an !oppose  :) — fortunavelut luna 12:06, 9 October 2017 (UTC)
  • Oppose. I understand the sentiment and a lot of signatures are superfluous for our needs, but this proposal is way too sweeping and would mean the deletion of many signatures that are worth keeping. If it was narrowed down to limiting signatures to a specific criteria that allows for case by case examination (ie: demonstration that the signature itself is important), I would be more open. Dennis Brown - 12:28, 9 October 2017 (UTC)
  • Strong oppose, oh come on, these are always interesting. Signatures and autographs carry a personal historical imprint. They directly link the reader with the page's subject. Consider the signatures as human touchstones, a work of art in themselves. To see Jeanne of Arc's signature, or that of Shakespeare, brings the topic more fully alive and real to many readers. Degas, Picasso, Dali, their signatures are part of what they are and how people "know" them. To see so many editors supporting this reminds me of the adage that too many rules eventually bring down what they are meant to hold up. Hopefully the closer will see keeping the signatures as worthwhile, and take the common sense reasons why they should be kept. This is a sad one, and I feel that if "passed" it will hurt the project more than help it, and I hope the nominator and support editors will reconsider. Randy Kryn (talk) 12:29, 9 October 2017 (UTC)
  • Support these signatures are really just a bit of decoration and add nothing of encyclopaedic value in the infobox. If the signature adds real value to the article for some reason there is no problem with including it in the main body of the article like any other information or image, subject to all the usual rules for inclusion, of course. - Nick Thorne talk 13:46, 9 October 2017 (UTC)
  • Support Privacy issues with live people. No encyclopedic benefit for (almost all) dead people. On the rare occasion it does merit attention in the article it can be explored in the body. I can see an argument that painters would deserve an exemption. Only in death does duty end (talk) 14:58, 9 October 2017 (UTC)
  • Oppose I don't object to a guideline on when to include signatures but there are many examples of signatures that are of encyclopedic value: Those of presidents, artists, writers etc. The infobox should be the place to have them because that is where people will expect and find them the easiest. Disallowing signatures from living people who are non-public figures as TonyBallioni suggests above for various reasons is not a reason to remove them alltogether. Readers expect to find Barack Obama's signature with the quick facts about him, not somewhere buried in the 330kb long article and we should not make it harder for readers to access information they look for. Regards SoWhy 15:09, 9 October 2017 (UTC)
  • Oppose - At least in the Western World, signatures are a central personal identifier, and I expect in many if not most cases, of an almost default encyclopedic relevance. In cases of living people, signatures may already be routinely removed for privacy reasons as a matter of courtesy, although I would be in favor of adding that specifically to WP:BLPPRIVACY. Other than that, this is just overkill. GMGtalk 15:47, 9 October 2017 (UTC)
  • Support, they're usually copyvios anyway. Stifle (talk) 16:13, 9 October 2017 (UTC)
  • Oppose for BLPs Due to concern of privacy issues. When it comes to dead people, I'm going to proudly state that I like them. As noted by SoWhy above, some of these signatures are quite famous and quite notable. An all out removal is not going to work here. My name continues to not be dave (talk) 19:16, 9 October 2017 (UTC)
    I think you mean "Support for BLPs".  — SMcCandlish ¢ >ʌⱷ҅ʌ<  19:57, 9 October 2017 (UTC)
    I like dead people too, although I can't say I'm particularly proud of it. ―Mandruss  20:52, 9 October 2017 (UTC)
  • Oppose per WP:CREEP and WP:NOTLAW. If we have ~90000 pages like this it's clearly our policy to do so. A handful of curmudgeons have no mandate to issue an diktat forbidding them. Andrew D. (talk) 19:27, 9 October 2017 (UTC)
    We had spoiler tags in an even higher proportion of articles, and both ethnicity and religion parameters in even more bio infoboxes, yet ditched those as well.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  19:57, 9 October 2017 (UTC)
Andy, do you think it's possible to state your oppose with more reasoning and less referral to those who have a different opinion as curmudgeons and their idea as a diktat? (I think you missed the point of this thread, but I may be mistaken.) ----Sluzzelin talk 21:40, 9 October 2017 (UTC)
  • Support for BLPs, since they're a privacy problem. Most do appear to be copyvios, ripped from books or from websites that ripped them from books. Except for cases like John Hancock, they verge on trivia, but are harmless for deceased subjects when properly sourced and licensed. Should probably have instructions in the template documentation to not include one that's not properly licensed and not to include one just to include one but because it's unusually relevant.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  19:57, 9 October 2017 (UTC)
  • Comment. Tending to oppose, as per Dennis and SOWHY; but also leaning to support for BLPs as per Stanton. For most authors they seem kind of irrelevant. Signatures of painters or other graphic artists might be more "useful", but I guess the copyright issues with those might be even more challenging? Martinevans123 (talk) 20:05, 9 October 2017 (UTC)
  • Support the may have some encyclopedic value. but they are not basic factual information--especially as the one used may or may not be a representative sample. They are absolutely a privacy problem for BLPs--where they normally should not be used anywhere in the article except for the most public of figures, such as presidents, , and I am amazed we continue to use them. As for licensing so, I do not think there is copyright in a signature. DGG ( talk ) 23:37, 9 October 2017 (UTC)
  • Oppose I don't see what we lose from having it. I do agree and I may support a more specific guideline for inclusion, such has holding a political office or something. But I feel the signature gives the user a sense of the style of person, much as their photo does.Drewmutt (^ᴥ^) talk 01:38, 10 October 2017 (UTC)
Support - if someone forged a signiture using our digitized version, wouldn't that make us morally responsible for helping him/her do that? עוד מישהו Od Mishehu 04:03, 10 October 2017 (UTC)
Oppose; I agree with other users who say that for at least some persons, such as U.S. presidents and famous painters, their signatures are notable and important enough to be in the infobox. I also agree with other users who say that for persons who are not notable for signing stuff, their signatures don't belong in the infobox (or anywhere else in the article), and I would encourage editors to remove signatures from infoboxes about anyone not famous for signing stuff. —Anomalocaris (talk) 04:50, 10 October 2017 (UTC)
  • Oppose- These are sometimes appropriate, sometimes not. No need for a draconian rule like this. Carrite (talk) 05:18, 10 October 2017 (UTC)
  • Oppose making a blanket rule about this. This can be discussed on a per article basis. (I also oppose the "rule" that if we have a signature, it must be included in the infobox). —Kusma (t·c) 08:24, 10 October 2017 (UTC)
  • Support per Fortuna Imperatrix Mundi. - SchroCat (talk) 19:06, 10 October 2017 (UTC)
  • Support - in most cases signatures are not encyclopedic, but I could see exceptions for political figures or famous artists. Kaldari (talk) 19:40, 10 October 2017 (UTC)
  • Oppose it should be up to the article's main author, or group of main collaborators, to decide, via the medium of a talk page discussion if necessary. There is no reason for a blanket ban. jcc (tea and biscuits) 20:01, 10 October 2017 (UTC)
  • Oppose, although guidelines about smaller display size would be reasonable. It's too strict to consider them as lacking in encyclopedic value. --Tryptofish (talk) 21:42, 10 October 2017 (UTC)
  • Support as someone who has even added them before, I agree that this is really not one of the most basic overview facts that you want to know about a person. The argument about copyrite is silly. ―Justin (koavf)TCM 23:08, 10 October 2017 (UTC)
  • Support per Fortuna Imperatrix Mundi and DGG, notably re BLPs. Where there is special artistic, political or social significance to the signature, it should be depicted and explained within the article text. -- Euryalus (talk) 23:21, 10 October 2017 (UTC)
  • Support A photograph or portrait of the subject is expected and is useful for identification; additional forms of ID such as signature, fingerprints, blood type, etc. seem overkill. In the case of artists: if the artist signs his/her works, the signature is seen in any jpgs included in the article; if the artist doesn't sign his/her works, the signature is of no special interest. If editors want to give encyclopedic attention to a signature, it's better presented in context as in Albrecht Dürer or William-Adolphe Bouguereau. Ewulp (talk) 00:31, 11 October 2017 (UTC)
  • Support; easy. I've never understood the point of the signature in the infobox; if the point of an encyclopaedia is to include every possible piece of trivia and by the way information about or loosely linked to a subject, then i suppose i understand: For us, however, surely we are selective in the information we present, and in how we present it, and someone's signature, while perhaps of interest, is not really of encyclopaedic value ~ it doesn't help the reader understand more about the subject. Essentially, per Sandstein. Happy days, LindsayHello 09:27, 11 October 2017 (UTC)
  • Oppose. There are many cases where a signature is relevant and should be in the infobox (e.g. a politician/statesman/monarch who signs legislation to bring it into effect, a central banker whose signature appears on national currency, an artist's signature on their work, being probably the biggest three). However, a narrower provision it is removed for BLPs where there is no prima facie reason to have it could work. ---- Patar knight - chat/contributions 16:15, 11 October 2017 (UTC)
  • Oppose only a Sith deals in absolutes. On a more serious note, there are some articles where this field adds value. Mr Ernie (talk) 18:23, 11 October 2017 (UTC)
  • Support I agree with others. If a signature is important then place it somewhere in the article where it is discussed. Otherwise it is just pointless decoration. AIRcorn (talk) 23:06, 11 October 2017 (UTC)
  • Oppose The collecting of autographs has been a field of study for centuries. This is one of those items that fits very nicely in an infobox and we should continue to do as we have. The suggestion that they hold no encyclopedic value forces me to question if the nominator ever read an encyclopedia (in print). I enjoy having them featured, where applicable. Chris Troutman (talk) 02:44, 12 October 2017 (UTC)
  • Support for BLPs only There is no issue for historical figures and in those cases they are often interesting and if not, at least harmless. BLPs are a different matter and they should only be included when their encyclopaedic value (whatever that may be) justifies it. Jschnur (talk) 03:01, 12 October 2017 (UTC)
  • Strong support per nom, this should have been done long ago. If the signature is particularly notable for the person (looking at you, John Hancock), there is nothing stopping editors from including the images in the regular article. Ed [talk] [majestic titan] 03:03, 12 October 2017 (UTC)
  • Support with an exception for rare but reasonable uses like John Hancock. There's no need for this with the exception of figures of major significance like US Presidents. Most uses strike me as crass and fanboyish. Also support Guy Macon's compromise below. Gamaliel (talk) 05:32, 12 October 2017 (UTC)
  • Support. We already have a severe case of infobox bloat and the autographs served little purpose. Kablammo (talk) 16:54, 12 October 2017 (UTC)
  • Support - As I said at ANI "What encyclopedic value do these actually serve?"..... there is no actual purpose to these and as such these should be done away with (with all sigs then deleted), Why would anyone care how a BLP signs their name ? ..... –Davey2010Talk 20:47, 12 October 2017 (UTC)
  • Oppose. Does the reader "need" to see a person's signature? No. But so what? It catches the eye; it adds visual interest. It "personalizes" the subject somehow. If there are cases where it's actually problematic to have a signature, then write a guideline to clarify those, but I see no reason to ban them from the boxes globally. --Trovatore (talk) 01:58, 13 October 2017 (UTC)
  • Oppose hard rule - Perhaps it's better to treat this on a case-by-case basis, meaning inclusion would depend on whether or not the signature adds to the article as a whole (personally, I don't really consider signatures of living people as a BLP problem as long as such signatures are known to the public anyway, like in autographs). But an outright ban seems too much. Narutolovehinata5 tccsdnew 02:03, 13 October 2017 (UTC)
  • Oppose. The signature is a means of self-identification; most people don't have logos or any other visual means of identifying themselves to others (aside from plain text versions of their names), except for their signatures. Plus, even if there's a problem with including a signature image in some articles, that doesn't mean that we should remove it from all. If you think that one article shouldn't have it, then start a discussion, but don't remove large numbers of signatures with AWB or a bot, and definitely don't remove them all by cutting the parameter out from the template. Nyttend (talk) 22:55, 13 October 2017 (UTC)
  • Oppose signatures are a notable characteristic and worth mentioning. --Tom (LT) (talk) 05:23, 14 October 2017 (UTC)
  • Oppose per User:Nihlus -- œ 04:42, 15 October 2017 (UTC)
  • Oppose: far too broad. In many cases the signature may have educational value for some readers. Jonathunder (talk) 04:52, 15 October 2017 (UTC)
  • Strong Oppose: The proposal seems to be in two parts - a) an assertion that no signature is ever relevant to an encyclopaedia. b) a move to strip signature images from every Infobox. I disagree with the assertion in a), but if that were ever to be the consensus of the community, so be it, and we would need to convert the essay WP:AUTOGRAPH into policy and ban use of all signatures or autographs in any article. Until such time as that happens, I firmly believe the Infobox is absolutely the right place to expect a signature to be located. It's akin to an infobox image of a person in visually summarising their identity. There's nothing to stop a signature/autograph being used elsewhere on a page, but we should not forced their removal from the most logical place to locate them by default - the Infobox. Issues relating to the uploading and appropriate use of signatures and autographs of living persons are best dealt with elsewhere and not in a discussion about Infobox data fields. Nick Moyes (talk) 09:06, 16 October 2017 (UTC)
  • Oppose: way too broad. If an article shouldn't have one, start a discussion there. Removing the parameter from the infobox makes no sense. Raystorm (¿Sí?) 16:53, 16 October 2017 (UTC)
  • Support in principle but Oppose as written; whilst there's a very good case for getting rid of these things, there are instances where they have encyclopedic value, and so a more nuanced proposal is needed. Yunshui  09:02, 17 October 2017 (UTC)
  • Oppose: This is a content matter, to be dealt with on a case-by-case basis, on article talk pages. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:39, 18 October 2017 (UTC)
  • Oppose "No encyclopedic value" is just another way of saying WP:NIME: That info got there because people cared enough to put it there. Jclemens (talk) 05:24, 19 October 2017 (UTC)
  • Weak oppose. I agree with the OP that signatures are generally not relevant to the encyclopedia. However, in very limited cases, the opposite may be true. The standard should be to not include them, with the burden of proof of encyclopedic value and notability on those who wish to include them. A minimum requirement should be discussion of the signature in the article text. James (talk/contribs) 15:56, 20 October 2017 (UTC)

Threaded discussion

  • Removing the field from BLP infoboxes would curb this practice. My issues:

    No verification is provided of whether these signatures are the real ones, and if so, how they were acquired; surely the file description pages should state whether they were copied from the original or a copy of it.

    Risk of invasion of privacy.

    Risk of security breach: the display presumably makes it a proposition to forge the BLP's signature in real life.

    Query over what it adds to readers' understanding of the topic. Tony (talk) 03:20, 9 October 2017 (UTC)

Tony1 has summarised the case for removing them well. I would add that if a signature is to be added it makes sense to do so in the body of the article, alongside the sourced content that justifies its inclusion. I can think of only a couple of cases (without checking the articles) when a signature was noteworthy. Richard Nixon’s, which deteriorated over the course of Watergate. Shakespeare who signed his name with a different spelling each time. But those are exceptional. The default should be not to include it.--JohnBlackburnewordsdeeds 04:02, 9 October 2017 (UTC)

  • @Nihlus: I'm not sure I understand your objection. How are those examples of signatures more worthwhile of being in an article infobox? And if the consensus was that the vast majority of signatures should be removed from infoboxes, what would be your recommendation be for defining those that you believe should be kept there? Why, specifically, should the ability to enact laws make the signature of that person more worthy of being displayed in an infobox? It's not as if the signature in one of our infoboxes is a determiner of whether those laws are legitimate or not, or that Wikipedia would be used as a source by a serious scholar investigating possibly forged signatures. I guess I just would like to hear some more on your point of view, since I don't believe the encyclopedia would be in any important way harmed by eliminating signatures in infoboxes altogether, and allowing the rare instance (John Hancock, for instance) where the signature has historic value in and of itself to be presented in an image in the body of the article. Beyond My Ken (talk) 05:27, 9 October 2017 (UTC)
    • @Beyond My Ken: My last sentence says I am not opposed to their removal in general; rather, I am opposed to their removal without guidance. You are going to see many users wonder where they are and wonder where they should go. I don't believe this proposal adequately (if at all) addresses that concern. Nihlus 05:33, 9 October 2017 (UTC)
      • My concern was (and is) eliminating signatures in infoboxes, which is why the RfC addresses only that issue, but I have absolutely no objection to people having a discussion either here in this section or in a new section about what the standards should be for use of signatures in articles. However, I do see that as a separate matter. Beyond My Ken (talk) 05:49, 9 October 2017 (UTC)
  • Since the proposal has a little traction, I've added a link to it on WP:Centralized discussions. Beyond My Ken (talk) 05:55, 9 October 2017 (UTC)
  • In principle, I support the above proposal, but would like to ask whether an exception could be made for Template:Infobox_royalty? I've always liked the fact that our articles on Ottoman sultans include their tughras in the infobox. No big deal, however. ---Sluzzelin talk 09:38, 9 October 2017 (UTC)
  • "Removing the field from BLP infoboxes" What's a "BLP" infobox? How is that different from a "dead for decades" infobox? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:41, 18 October 2017 (UTC)

Alternative proposal:

Many of the support !votes have focused on privacy issues. and a fair number of the oppose !votes think that signatures are a good addition to articles about historical figures. How about only removing signatures from BLPs with an exception for individuals who have self-published their signatures? Nobody is going to use John Hancock's signature to commit identity theft, and if someone publishes their signature on their website or in a book they wrote, having it in an infobox doesn't increase the risk of it being used for nefarious purposes. --Guy Macon (talk) 15:24, 9 October 2017 (UTC)
  • That would take me from oppose to support very easily. A Traintalk 16:21, 9 October 2017 (UTC)
Sure, but those of us with this view are already inserting it into the !voting section above.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  19:59, 9 October 2017 (UTC)
Yes, that would be appropriate, to limit the BLP question. Some living persons have used their signatures on books (Jimmy Carter, if memory serves me, and HRClinton), and wouldn't most American presidents and other world leaders' signatures be given public domain status due to their signature releases on official documents? Trump would be an example of a useful and interesting signature to keep in the infobox, and his official documented use should qualify as an aspect of public domain. Check out the {{John Hancock}} template, one of my favorites. Randy Kryn (talk) 21:50, 9 October 2017 (UTC)
Good approach. EEng 03:58, 18 October 2017 (UTC)
  • Comment When I read the article on Picasso, I fully expect to see an image of his signature within an infobox, almost as a matter of course— and if I saw none I would suspect there had been some oversight. A signature field (whether filled or not) seems appropriate for those professions in which signatures are regularly recorded as either indicators of authorship (artworks, works of notable literary fiction) or highly-visible markers of participation/ group membership/ social roles (the Declaration of Independence, presidential acts, baseball player's sigs on baseballs, kings, queens, sultans, however not the signatures of most academics/ researchers, medical doctors, singers, drummers, producers, writers of non-fiction, etc.) and should probably not be encouraged in the latter by the presence of an empty signature parameter begging to be filled. Can't we maybe do that? KDS4444 (talk) 22:26, 9 October 2017 (UTC)
  • You expect it to be there because you're used to infoboxes having them; if they didn't, you wouldn't be. Your argument is essentially one for never changing anything, because "it's always been that way". Beyond My Ken (talk) 02:00, 10 October 2017 (UTC)
  • KDS4444 more likely expected it to be there because Picasso's infobox should have his signature display, so the editor was surprised when it didn't. It certainly should be included, this is Picasso for Monet's sake. The argument isn't "it's always been that way" but more about the readers who, at least speaking for myself, like them and find some of them really interesting. Nothing is broken here, except for maybe the BLP issue which could be addressed as a separate topic if this discussion gets consensus to allow signatures of very notable he's-dead-Jim subjects (which seems to be the way it's heading). Randy Kryn (talk) 02:08, 10 October 2017 (UTC)
  • I would disagree with the statement "nothing's broken here". What's broken is that infoboxes are intended to be a quick summary of the subject of the article, and -- in my opinion, of course, and apparently in the opinions of quite a few other editors -- the subject's signature is not basic key information in the same way that, for instance, birth and death dates and an image are. (I'd also disagree with your statement up above "These are always interesting" - no, actually, with rare exceptions, they're not really interesting at all, they're pretty darn uninteresting -- again IMO.) Beyond My Ken (talk) 05:14, 10 October 2017 (UTC)
  • Oppose It is interesting to see the differing handwriting between some historical figures and celebrities. In many ways it speaks about their character. --Penpalthe (talk) 07:49, 10 October 2017 (UTC)
  • So why did you just oppose an alternative proposal that keeps the signature of historical figures and celebrities? --Guy Macon (talk) 20:04, 10 October 2017 (UTC)
  • Weak and watery support. I'm sure the reader should be encouraged to move on to more important things in an article. Martinevans123 (talk) 19:37, 10 October 2017 (UTC)
  • Support—sensible. Tony (talk) 01:39, 11 October 2017 (UTC)
  • Support: as proposer. --Guy Macon (talk) 02:49, 11 October 2017 (UTC)
  • Comment. I'd be fine with a requirement that the signature be openly published elsewhere before we can use it here. In fact, that would also be in keeping with the spirit of our WP:NFCC policies. --Tryptofish (talk) 17:24, 11 October 2017 (UTC)
  • Supportish - Not sure there is such a problem, but if we limited this solely to living persons, with an exception of when that living person has published their signature elsewhere (artists are a good example), then the restriction makes sense as it addressing potential privacy issues. Dennis Brown - 16:13, 12 October 2017 (UTC)
  • Meh. Better than a global ban, I guess. I'm not convinced there's a real problem. If WP editors can get their hands on a signature, then the bad guys can probably do it independently, and I'm not sure it would do them that much good anyway. I would certainly support respecting takedown requests from the interested party. --Trovatore (talk) 02:03, 13 October 2017 (UTC)
  • Comment This RfC has transmogrified from a proposal on stripping a data field from a template to one on the circumstances in which a signature image is ok to be used. Seems an entirely different discussion to me. Nick Moyes (talk) 09:22, 16 October 2017 (UTC)
    • You are correct, but often this is helpful to truly get a consensus on how editors feel about signatures in article, and gauging whether or not there is really a problem, and what that problem is. The RFC won't likely pass, but the extended content still provides useful information. If the alternative had strong enough support, it would create the basis for a whole new RFC, for instance. Or if it isn't, would demonstrate why a new RFC would be pointless. Dennis Brown - 21:21, 16 October 2017 (UTC)

Making differences clearer

Is there any way that the "Differences between revisions" page can make the revision more obvious? Sometimes I look but I can't see anything. See, for example, this delta – I don't see anything highlighted. Praemonitus (talk) 16:57, 10 October 2017 (UTC)

There is User:Cacycle/wikEdDiff, which can be enabled at Special:Preferences#mw-prefsection-gadgets: wikEdDiff: improved diff view between article versions (not needed if wikEd is used). Nihlus 17:03, 10 October 2017 (UTC)
Thanks. I tried that but it doesn't actually show any differences. Perhaps nothing actually changed? Ah well. Praemonitus (talk) 18:59, 10 October 2017 (UTC)
There's an extra full stop: Graves, Genevieve J. M was changed to Graves, Genevieve J. M. -- John of Reading (talk) 19:02, 10 October 2017 (UTC)

Some time ago, the whole diff'd paragraph had a color background. I think that the diff'd character background should have a color background, not just the characters themselves. --NaBUru38 (talk) 19:34, 16 October 2017 (UTC)

Sometimes the revisions are only minor revisions and this would be evident if the revision is marked with an m. Vorbee (talk) 19:48, 16 October 2017 (UTC)

RFC on automatic archiving of long user talk pages

How should we deal with the problem of long user talk pages (e.g. User talk:ThaddeusB) which makes them very slow to load and extremely slow to edit, especially on older machines (WP:CHOKING). This is particular relevant for inactive/retired editors that are subscribed to newsletters and such. Headbomb {t · c · p · b} 12:27, 11 October 2017 (UTC)

Proposal (2)

This is something that bothered me for a long time, but I'm getting around to tackle it today. Some people have truly massive talkpages (e.g. User talk:ThaddeusB). The problem grows worse over time, since they may be subscribed to newsletters and various twinkle/bot notices. To help remedy this, I propose the following (the exact numbers can be tweaked to something more suitable, if those are off).

Active editors (at least 1 edit in the last year)
  • If a user talk page is over 250K (based on 2.5×WP:SIZERULE, see below for rationale)
  • If a user talk page has more than 25 level 2 sections (==Section==)

Have a bot send a notice, reminding editors that archiving bots exists, with relevant links explaining how to setup archives.

Inactive editors (no edit in the last year)
  • If a user talk page is over 250K (based on 2.5×WP:SIZERULE, see below for rationale)
  • If a user talk page has more than 50 level 2 sections (==Section==)
  • Look for User talk:Foobar subpages with "Archive(s)" in the title
    • If none are found, automatically setup basic archiving ([[User talk:Foobar/Archives/<YYYY>]])
    • If archives are found, list the user talk page on a master list of 'long user talk pages in need of manual archiving', and empower editors to setup an archiving scheme on behalf of the inactive editor (or archive things manually on their behalf).

Headbomb {t · c · p · b} 12:27, 11 October 2017 (UTC)

Survey

  • Support, as proposer. Headbomb {t · c · p · b} 12:27, 11 October 2017 (UTC)
  • Support all of it as proposed, per WP:SIZE. Pages that are much over 100k are literally impossible to edit and/or load at all on some older devices and slower connections, I'm talking a year or two old, not people editing on their Apple II. Long user talk pages especially are a serious detriment to collaboration. However I suggest allowing a {{nobots}}-type flag for users like EEng (sorry to single you out) who deliberately keep their talk pages long for the lulz, so they don't get unnecessary notices. Or maybe they want the notices, so their pages will be even longer? Ivanvector (Talk/Edits) 12:56, 11 October 2017 (UTC)
  • Oppose as written - the #of section headers to send notices and force archiving is too small - getting 25 sections is no big deal, especially if the page size is small. — xaosflux Talk 13:16, 11 October 2017 (UTC)
  • Oppose User talk:ThaddeusB is positively brief compared with the talk pages of some distinguished Wikipedians (at least one is highly distinguished). Leave people alone please on their talk pages. Interventions will just create fuss and bother. I wouldn't object to a single message asking if they want help with archiving if they have no archives already.Thincat (talk) 17:14, 11 October 2017 (UTC)
  • Oppose - 100k is nothing. As written, this is a bad idea. Dennis Brown - 21:13, 11 October 2017 (UTC)
  • Oppose I don't want archives of old newsletters. It might be better to arrange for newsletters keep themselves tidy by automatically deleting their previous edition. Andrew D. (talk) 22:19, 11 October 2017 (UTC)
How is having 100 sections of newsletter on the talk page is better? Headbomb {t · c · p · b} 23:14, 11 October 2017 (UTC)
  • Oppose I archive my talk page every year whether it needs it or not. Face-smile.svg It is currently at 832 KB. There are 237 sections. Hawkeye7 (discuss) 22:34, 11 October 2017 (UTC)
  • @Hawkeye7: Why don't you archive it earlier? At some point, a page that long will become unnavigable for someone else. ―Justin (koavf)TCM 23:31, 11 October 2017 (UTC)
  • Oppose - I'm not seeing this as a problem needing a solution forced on editors against their will. Beyond My Ken (talk) 23:22, 11 October 2017 (UTC)
  • Support in principle The number of sections is ultimately irrelevant but yes, we should have *any* content here ultimately capped somewhere or else it will become unusable/unnavigable to other readers. In user/user talk namespaces, we can be more lenient but user talk is not a personal playground or personal hosting--it's made for others to interact with you. ―Justin (koavf)TCM 23:28, 11 October 2017 (UTC)
  • Oppose overzealous policing of user's own territory. For inactive users, it is unnecessary, and active users have the right to display their obnoxiousness if that is their choice. Sure, you can send active editors with talk pages longer than 800k (comparable to the longest page at Special:Longpages) a polite notice, but enforcing restrictions is only going to cause completely unnecessary drama. —Kusma (t·c) 09:12, 12 October 2017 (UTC)
It certainly matters for inactive users. E.g. User talk:La Pianista has 223 sections, exceeding 336 KB, with the vast majority those populated by newsletters. It grows at a rate of roughly 30 KB/year, and has doubled in size since she's effectively retired in 2012. It's taking 12+ seconds to load on my Pixel on university wifi (which is usually extremely fast here) by comparison, my own talk page took about 2 seconds. This may not matter a whole lot to me, because I live in a wealthy nation with access to faster technology and solid wifi, but it will matter a whole lot more to someone in a developing nation, with crap wifi, and lesser phones, or those limited by data caps (see WP:CHOKING).

And no one is proposing forcing any active users to do anything. But a reminder that their page is getting out of hand will alleviate the issue in many pages. If we feel 1 years is too little to inactivity, then go to 2 years, or if 250 KB is too little, then go to 500 KB. But 2.5 times WP:SIZERULE seems like a reasonable thing to me. Headbomb {t · c · p · b} 17:23, 12 October 2017 (UTC)

@Headbomb: If you're using SIZERULE as a guide, be aware that those numbers refer to "readable prose size", which is generally far smaller than page size/file size. E.g. Donald Trump currently has readable prose size of 80K (as measured by User talk:Dr pda/prosesize.js) and page size of 317K. Prosesize.js has its limitations and I haven't found a good way to measure prose size with much accuracy. That would appear to make SIZERULE problematic as a guide; I'd suggest abandoning it and just choosing a reasonable page size. This advice is worth about what you paid for it. ―Mandruss  17:45, 12 October 2017 (UTC)
I'm aware it's prose size, but on talk page, wikitext and prose do match a lot closer than on articles. The code-to-prose ratio of templates (and references) in the mainspace is very high, which is not usually the case in talk pages. The proze-to-size ratio seems about 2.5:1 from what I can tell by doing some limited test with prozesize.js on simplified pages (try it here, I get a ratio of 2.32 on my page), so it suggests to me that 2.5 times × 100 KB is a reasonable treshold. I'm certainly open to any other reasonable yardstick. WP:CHOKING say 32 KB = 5 seconds on dial up, which ignores images and the rest of the Wikipedia interface. 250 KB would be 39 seconds just to download the page on dialup, and if you have dialup, chances are you're not running the most recent of computers either, and you'll need quite a while to render the page as well. Headbomb {t · c · p · b} 18:02, 12 October 2017 (UTC)
  • Support in principle, with the precise numbers to be hashed out. Stifle (talk) 09:57, 12 October 2017 (UTC)
  • Oppose. EEng would NOT be amused. KMF (talk) 13:54, 13 October 2017 (UTC)
So? We shouldn't hold on making Wikipedia more accessible and user friendly (especially to those who lack advanced technological resources) because one person insists on having a long talk page (a choice they'd still be allowed to have). Headbomb {t · c · p · b} 14:16, 13 October 2017 (UTC)
  • Oppose. We have no business imposing this kind of thing on editors, especially since there's no policy that says that it has to be this way. Moreover, if the auto-archiving bot comes around during the middle of a discussion, it might archive the first part of the discussion and force an un-archive; whether or not to archive is something that should never be done by a bot, except when the bot's following the instructions of the user in question. Nyttend (talk) 23:00, 13 October 2017 (UTC)
I don't think you understand how archive bots work. They can't 'coming in the middle of a discussion', or archive parts of one. Headbomb {t · c · p · b} 21:35, 15 October 2017 (UTC)
  • Oppose it's annoying AF, but annoyance is a "me" problem not a "them" problem. No need to force this to happen. --Jayron32 19:39, 16 October 2017 (UTC)
  • Oppose. Even 250kb is nothing; it's not unusual for my talkpage to get up to that kind of length just because there happen to be a few lengthy discussions taking place simultaneously (as I write this it's on about 120kb), and I can't imagine anyone being pleased to keep being pestered by a hectoring nanny-bot ordering them to comply with a non-existent maximum size policy. If you find someone's talkpage annoying for whatever reason, feel free to tell them to their face that you find it annoying, but don't insist that everyone else comply with your personal preferences. ‑ Iridescent 19:48, 16 October 2017 (UTC)
  • Oppose - At most, a user could nudge newer editors in the right direction. No need to codify or harass users over something such as this. Nihlus 19:51, 16 October 2017 (UTC)
  • Oppose - Because you have rejected out of hand fixing a main driver of the problem, subscriptions, even though mentioned "The problem grows worse over time, since they may be subscribed to newsletters and various twinkle/bot notices." Instead you want to save/store/preserve the advertising brochures rather than stopping them in the first place? Shenme (talk) 23:39, 22 October 2017 (UTC)
  • Support but do it at 2MB when it will become actually impossible to save the page. Jc86035 (talk) 03:44, 23 October 2017 (UTC)

Discussion

  • Just a thought: Since the main problem seem to be newsletters and bot notices, wouldn't it be easier to add a {{nobots}} template to the pages of inactive editors and add them to Category:Opted-out of message delivery? Regards SoWhy 13:56, 11 October 2017 (UTC)
The problem with that is that some people may be inactive on Wikipedia, but still read the newsletters/want to be notified by RSS, or whatever. Headbomb {t · c · p · b} 21:03, 11 October 2017 (UTC)
Yet, the most effective action to motivate users to "clean up" would be to simply stop automatic posting from subscriptions, when pages get "too large". Taking responsibility is no bad thing. Shenme (talk) 23:43, 22 October 2017 (UTC)
  • Comment: AFAIK, the number of sections in a talk page does not affect usability. Size is the issue, so let's focus on size. In any event, my talk page currently has 23 level-2 sections, is archived regularly, dates back less than four months, and is only 30K, yet by the criteria above, I would get a notification with only two more sections added. That would be a problem. The example page given above, User talk:ThaddeusB, has 266 sections and is 393K. Headbomb, please consider revising the criteria based on a purely technical rationale. – Jonesey95 (talk) 14:11, 11 October 2017 (UTC)
What about x number of headings which haven't been edited in so many days? That's how the archiving bots determine staleness. Say, if you have more than 25 threads which meet CB3's basic staleness criteria, you get a notice? But also, Headbomb, the bot should check for existing archives for both active and inactive users, then pages like Jonesey95's wouldn't get flagged for a notice. Ivanvector (Talk/Edits) 16:05, 11 October 2017 (UTC)
Jonesey wouldn't get flagged for a notice, since his talk page is well below 100 KB (as are pretty much any page with archives setup). I suppose it wouldn't hurt to check for archives though, in the odd chance that his talk page somehow more than triples in size before the archive bot has a change to do its job. Headbomb {t · c · p · b} 17:38, 12 October 2017 (UTC)
Agreed. The worst case I'm aware of currently has 480 sections and it takes me about 7 seconds to scroll through the TOC. Annoying? Yes. Significant problem? Not really. Currently #171 on my Wikipedia Annoyances List. ―Mandruss  16:32, 11 October 2017 (UTC)
Actually, CB3's default staleness age is 0 hours, so I guess we would have to define it differently for this. Ivanvector (Talk/Edits) 16:08, 11 October 2017 (UTC)
  • Comment: I think that I remember at least one previous RFC about this. It may be worth checking its results. —PaleoNeonate – 14:14, 11 October 2017 (UTC)
  • Comment: So, for very large talk pages belonging to active users, you're proposing something that will make their pages grow faster... ghytred talk 14:42, 11 October 2017 (UTC)
Yes, but increasing a page's length by 1% to prompt them to cut it down by 90%+ is worth it. Headbomb {t · c · p · b} 21:09, 11 October 2017 (UTC)
  • Comment: I support this idea in principle, but how many pages are affected here? Are we talking about ten pages, or 10,000 pages? Let's at least have a sense of the scale of this problem. I think that makes a difference. I request a histogram of the number of pages of a given size, perhaps something like 100K to 250K, 250 to 500K, 500 to 750K, 750K or more. That might help us determine a good breakpoint for a rule. – Jonesey95 (talk) 00:32, 16 October 2017 (UTC)
    • It'd help knowing yes. I don't have the skills to do that, but I'm sure it'd be an easy thing to find out based on WP:DUMPs. Headbomb {t · c · p · b} 00:36, 16 October 2017 (UTC)

Proposal: Time-release watchlist items

Occasionally, Wikipedians tend to put things on our watchlist that we only intend to watch for a limited amount of time, such as a particular move request, deletion discussion, user talk pages of editors to whom we have made a specific inquiry, articles undergoing a particular editing process, etc. Presuming this is technically feasible, I would like to be able to watchlist items like these with an expiration date, so that after, say, six months, they automatically disappears from my watchlist. In terms of design, I am thinking that the default would remain "no expiration", which would require no additional action, but that an editor could choose expiration option from a dropdown menu. I would further propose the option of changing preferences to reverse this situation, allowing a particular editor to choose a preset expiration time for all watchlisted items, except those for which "no expiration" is specifically selected. Thoughts? bd2412 T 03:13, 13 October 2017 (UTC)

bd2412 the request for this feature dates back to at least 2006, and has been submitted for the 2014 WikimediaGermany wishlist and the 2015 WMF Community Tech wishlist. The primary Phabricator item is T100508. Some progress has been made in May of this year upgrading backend systems to support this,[1] however it seems to be lingering again as an "open task" with no indication of when anyone is going to work on it.
The WMF has just been too busy with more important tasks: Renewing Flow development, providing a "wikitext edit mode" inside VisualEditor so that they can deprecate the current wikitext editor, and damn near crashing Wikipedia itself with new Wikidata rollouts. (I tried to resist the temptation to be snarky, but I failed badly.) Alsee (talk) 06:23, 13 October 2017 (UTC)
(I tend to be careful of where I'm spending our painfully crowdsourced money, but in case anybody else missed that "The current wikitext editor is not going anywhere, at least for the next few years." - per documentation, now you know! I am unaware of current plans to remove it, but hey, please do keep me posted if you hear otherwise. Elitre (WMF) (talk) 14:25, 13 October 2017 (UTC))
If wikitext is not going anywhere, then someone should have time to implement the feature proposed above. bd2412 T 20:25, 13 October 2017 (UTC)
Or maybe this ten-year-old watchlist bug which has been partially responsible for multiple ArbCom cases. Snuge purveyor (talk) 22:57, 13 October 2017 (UTC)
Elitre (WMF) per your link, the WMF wants to terminate support for the current editor due to the cost of "multiple parallel work streams". Given that the WMF already ignores or neglects community requests for "high impact"(random example) work on core wikitext infrastructure because you're too busy chasing visual-butterflies, and given the intention to terminate support for the current editor, I expect the current editor would be even more neglected. I expect your work on other things will cause incidental breakage or crippling of the current editor extremely quickly. However that is almost irrelevant. There is a far far bigger problem here:
The WMF is repeating a bad old problem. The WMF effectively built the NewEditor in secret. The WMF built the NewEditor with zero community input. Once the prototype was available, the WMF was immediately notified that there were going to be serious community objections. For the last year the WMF has been unwilling or unable to constructively address the issue. There is currently a consensus that the NewEditor is unacceptable.[2] Unacceptable as the default for existing editors. Unacceptable as the default for new editors. Either:
  1. You need to change the community's mind and build a new consensus that we want the NewEditor promoted to default; or
  2. You need to throw the NewEditor in the garbage; or
  3. You keep supporting our primary editor as the primary editor, AND you support the secondary VisualEditor, AND you add maintenance load supporting a pointless tertiary NewEditor; or
  4. You go to war with the community trying to force out a NewEditor as the default against consensus.
I would like to note that MediaViewer was a rather petty squabble over an essentially cosmetic feature. It blew up because the WMF was unable to constructively engage the community, it blew up because the WMF had zero respect for the consensus process, and it blew up because the WMF committed one of our most serious crimes. The WMF abandoned discussion and Eloquence abused technical protection trying to win a petty dispute by force. If the WMF were to engage in warfare over our core editing platform, things could escalate far worse. The default editor is not a petty issue. Sabotaging wikitext-editing by trying to force out an inferior&sabotaged default-wikitext-editor is a threat to Wikipedia itself. The fact that it's an obsessive-compulsive effort to force everyone into VE just adds insult to injury.
I have been seriously worried about this situation for a year now, and the WMF just keeps ignoring the situation. Jdforrester just goes non-responsive, and Whatamidoing is unwilling or unable to give a constructive response. So since you're here, please don't waste time discussing how the current editor will stay as opt-in "for years". That is irrelevant. The dispute is whether the default is going to be changed at all. Please tell me the WMF has some plan for addressing the WMF-community conflict on this issue. Please tell me the WMF isn't going to blindly ignore the issue until "deployment day". Please tell me the WMF isn't going to try to force out the NewEditor as default against consensus. Please tell me we're not all just waiting to discover how big and destructive the fireworks are. We should have sorted this out before writing code for a NewEditor. At worst we should have sorted this out immediately after the prototype was built. Alsee (talk) 13:26, 14 October 2017 (UTC)
Per that link, the Foundation does indeed want to remove support for some "multiple parallel workstreams". But you will not find any plans, on any page, for removing the 2010 wikitext editor (nor the 2003 editor, for that matter), as you have been told repeatedly (on at least three separate occasions by me personally).
For those who haven't been told many times already, you can find out just how many editing environments the WMF is currently supporting by looking at the long table at mw:Editor. The only "removals" associated with VisualEditor involve converting the codebases for CX and some of the mobile editors, while leaving the end-user experience the same. Completely unrelated to mw:Extension:VisualEditor, the WMF will stop supporting the 2006 Javascript wikitext editor (probably before the end of this calendar year), but it looks like a volunteer at the French Wikipedia will convert it to a user script, in which case I'm not sure that it's accurate to say that anyone is actually "removing" it, even though the Foundation will stop fixing it when/if it breaks. Whatamidoing (WMF) (talk) 21:05, 16 October 2017 (UTC)
Whatamidoing (WMF) I am not interested in a Crystalball debate on how long or how well the WMF will support a deprecated editor at the level of functioning expected of a first-rank-editor. It's irrelevant. I will ask, for far more than the third time, for you or anyone from the WMF to address the the #1 #2 #3 #4 issue I posted above regarding default editor, in light of the overwhelming consensus against deploying Visual Editor's new "wikitext mode". Alsee (talk) 12:56, 18 October 2017 (UTC)
Your entire premise is wrong. The editing environment you prefer is not deprecated. I would appreciate it if you would quit claiming or even implying that it is.
Your numbered list offers false choices. When and whether it will be offered by default to which users at which wikis has not been decided. The only things that I can say with certainty are:
  • The Foundation will not be scrapping VisualEditor's wikitext mode.
  • It won't be offered outside the Beta Feature at this wiki until sometime after (possibly long after) the current performance audit is completed. Whatamidoing (WMF) (talk) 16:33, 18 October 2017 (UTC)
  • Sounds interesting. There must be an essay somewhere (?) about the inefficiency of editing based on watchlists. It often seems to lead to accusations of hounding and "following". I'm sure it contributes significantly to edit warring. I often wish I could see my Watchlist in reverse time order (is that a editting setting already?) I'm often reminded of an under-10's football match where they all follow the ball round in a tight clump. Martinevans123 (talk) 20:36, 13 October 2017 (UTC)
  • There's already a solution to meet this need! Well, a work-around actually. I totally agree that Watchlists are pretty useless as editing tools except to receive email alerts of new changes to pages. Cleaning them out down to just key articles of interest can be a pain. So I installed Page Collector script, and now have two additional, and much more useful watchlists, though you can have more. One is my 'To Do' list to flag up pages I encounter that I'm far too busy to edit right now, but which I definitely want to go back to later and make changes myself. The other is a chronological 'To Monitor' list of pages that I only want to keep an eye on for a short while, often as a result of encountering a page under WP:NPP and seeing how others have handled it where I'm not too sure myself (- a great way to learn). It can also be great for monitoring user contributions to check for persistent vandal activity or to watch someone's talk page for an ongoing topic. You can manually insert a marker date, but there's always the page history to show when items were added. So it's relatively easy to remove 'watched' pages. Adding a page is done from a Tab next to the search bar at the top of the page. If anyone thinks this would meet their needs, here's the link to install it. Nick Moyes (talk) 01:31, 15 October 2017 (UTC)
  • BD2412, I'm told that this project is about a million dollars' worth of engineering work. But I still want it.  ;-) I encourage you to consider adding it to the next m:Community Wishlist, which I believe will start in about three weeks. Whatamidoing (WMF) (talk) 19:20, 16 October 2017 (UTC)
    • Thanks, I will keep that in mind. Cheers! bd2412 T 19:29, 16 October 2017 (UTC)

RfC on bot/template for dating redlinks automagically

Pursuant to this discussion, I'm opening an RfC to hopefully gain consensus on the creation of a bot that will automatically date redlinks.

My idea is that, similar to how Template:Citation needed without specifying additional params will lead a bot to automatically date the template, a similar template be created to mark redlinks, which a bot (perhaps even the same bot) could then tag with the current month and year (if there's a way to forego the template and just have a bot detect and tag redlinks, even better). I feel it would be useful to be able to see, when editing an article, whether a redlink has been relatively newly-created, or has existed for some time, so that editors can make more informed decisions as to whether a redlink is really merited. Even if this was only applied to redlinks going forward (i.e. no searching through existing ones) I feel it would be an improvement over the current approach, where it can be difficult if not impossible to determine when a redlink was created.

The linked discussion includes some thoughts on indexing redlinks and more advanced functionality, but for the purposes of this RfC I would consider that out of scope. If others feel the advanced options should be pursued, I would encourage them to say so in any ensuing discussion, or initiate a subsequent RfC.

Please indicate your support or opposition for the creation of such a bot (and associated template if necessary), and feel free to bring up any questions or concerns in the discussion section. Thank you for your participation! DonIago (talk) 19:45, 13 October 2017 (UTC)

Survey

  • Support as proposer. DonIago (talk) 19:45, 13 October 2017 (UTC)
  • Oppose as I don't see the problem this is solving. There is no deadline. How long a link is red is meaningless. Many will never be articles. None will instantly become articles just because of a date. They will become an article once someone with sufficient knowledge and desire decides to remedy the redlink. Having a bot traveling around and dating doesn't change that nor improve the experience for the reader. We could probably do a better job of making a list of red links that anyone can see, as many should probably be removed or converted into links to other articles or subsections, but dating them doesn't help that. Dennis Brown - 01:05, 17 October 2017 (UTC)

Threaded discussion

To be clear, I have no opposition to the more advanced functionality brought up at the original discussion, but those weren't my ideas, and I don't want to assume the responsibility of speaking to them as the RfC creator. DonIago (talk) 19:45, 13 October 2017 (UTC)

I note there are around 2,623,323 articles (i.e. mainspace, namespace 0) with at least one redlink. I have no way to easily determine how many of these are due to links in navigation templates or the like. Anomie 19:51, 16 October 2017 (UTC)

  • If Wikipedia:Most-wanted articles is not doing what is wanted, the solution would be to fix it. That link is one of three at Wikipedia:Red link#Lists of redlinks. However, there should not be more bot edits obscuring watchlists and adding bogus entries to complicate article history. At least, not unless a very strong benefit has been demonstrated. A script analyzing page dumps could work out what pages exist and which links are red. It could (if run monthly for a year or two) build a history showing when new red links were added. Johnuniq (talk) 22:09, 16 October 2017 (UTC)
    • I'm not sure how Most-wanted articles is relevant to my coming across a redlink in a film article, or such, and not knowing how recently the redlink was created? DonIago (talk) 05:34, 17 October 2017 (UTC)
  • I don't see any value in knowing how long a red link has been there when editing an article. ie the proposer's rationale. The main one here is red links that really should be blue, but are not, usually because of misspelling or different disambiguation. (Similarly, the date on the "citation required" is of zero use so far as I know - if someone would care to enlighten me, that would be welcome.) However, there is a situations when the this might come in handy:
    • When a red link goes blue. I created an article today on the physicist John Corner. When I checked "What links here", an unexpected article came up. Julia Corner linked to it, but wanted the more famous (but apparently not on Wikipedia) 18th century engraver. I removed the red link; a disambiguation will be required and anyone writing about him will want to link to Julia, so this will be okay. The problem here is that the link goes blue without notifying anyone, so the change is easily missed. Hawkeye7 (discuss) 02:49, 17 October 2017 (UTC)
      • To me, the value, as an editor, is that if I see a redlink that's been sitting around since 2010 or so, I feel reasonably justified in removing it on the grounds that it's unlikely to be de-redlinked anytime soon. OTOH, if the redlink was added a month ago, I'd be likely to leave it alone, reasoning (perhaps fallaciously, perhaps not) that there's a chance someone may write an appropriate article. I find the dates on CN tags useful for the same reason. If a CN tag has been in place for months/years, it's time to remove the challenged material. If it's a fairly recent tag, editors deserve more time to try to locate appropriate sourcing. Maybe it works, maybe it doesn't, but I'm not aware of any studies determining whether date-stamping is useful or not, so if it's a minimal effort, why not implement it? DonIago (talk) 05:30, 17 October 2017 (UTC)
        • Why would you want to remove a redlink based in it having existed for a long time? That is no indication of whether an article is needed.· · · Peter (Southwood) (talk): 04:22, 23 October 2017 (UTC)

Policy or accepted standard behavior regarding Reverts.

I have just read some of the content on 'Dispute Resolution'. I read about the three revert rule in context of 'edit-warring', and that you should attempt to resolve your disputes when your changes are reverted.

While I agree on the aim to achieve a peaceful consensus, I do think that the currently accepted standards of behavior regarding 'Reverts', favor the editors 'watching' the article and do not put two editors(one that has made the change and the one that has reverted those) at equal footing.

While an editor makes any change and in doing that deletes or modifies existing content instead of just adding some, he/she is not specifically targeting a particular editor. But in case of 'Reverts', exactly that is happening ie one undoes changes done by a particular editor. 

While doing a 'Revert' it is 'assumed' that the 'changes' are disruptive and unconstructive, without even trying to make a contact or asking the editor for the reasons for the change. It is entirely plausible that the changes are in fact constructive and that the article was in a vandalised state beforehand.

So, I do think that 'Reverts' are more offensive and aggressive as compared to some ad-hoc changes made to an article, and hence have a much greater potential of igniting a chain reaction of aggressive and warring behavior.

If talking/conversation is the behavior being promoted or encouraged by Wikipedia, then it should be promoted/encouraged right from the start. So, before making a 'Revert', one should try to talk to the editor and try to achieve consensus.  One cannot expect the editor making the first change, to do this, as it would be very difficult to go and find out in the 'History' exactly who are the editors, the content of which he/she is trying to modify/delete, and to find out about all the editors 'watching' an article and then try to talk to each of them and achieve consensus.

I think that 'Reverts' should be entirely discouraged, and should only be allowed in exceptional cases where the vandalistic or disruptive nature of the 'change' is very obvious. If Revert is done, then one should always specify an 'as objective as possible' reason for the 'Revert'.

One more reason for above policy change is the difference between the knowledge of editors 'watching' an article and the editors making first change.  You see, editors who 'watch' an article, in most probability, are somewhat familiar with Wikipedia and probably would know about such thing as 'Dispute Resolution'.  Given that they know about the expected procedures/actions to be taken in the case of 'Disputes', they are less likely to take 'Disputes' as threatening or feel helpless/powerless when it happens. On the contrary, the editor who is making the first change, could be someone entirely new to Wikipedia and knows nothing about 'Dispute Resolution'. When someone 'reverts' his/her changes, he/she is more likely to engage in aggressive behavior and feel threatened or enraged at the perceived injustice of 'Revert' done to his/her changes.

Editors who 'watch' an article should not be automatically assumed better/more neutral than others, and should not be given undue benefit of doubt. 

When I do make a change to an article and someone 'reverts' it, and then when I read the message in my notifications, this is what I(and probably many others) think:-

  • Why my change has been reverted? Why is it 'assumed' to be disruptive? Who decides whether it is 'disruptive' or 'constructive', given that supposedly everyone can edit Wikipedia?
  • Who the hell he/she(the editor who has made the revert) thinks he/she is? Is he/she some kind of authority? What does he/she thinks of him/herself that he/she can decide about whether a 'change' is disruptive or constructive?
  • Why am I the one, who is expected to go through all this shit(talk pages and stuff) and try to gain approval? Why doesn't he/she has done or tried that already? Am I inferior to him/her? No I am not, and I will fight for this!

You can see where it's going. Add to this, the message: "Continual disruptive editing may result in loss of editing privileges", only seems more threatening and a sign of partiality/discrimination in built in the 'System'. Because you see, as per my thought process, why is it that my editing is assumed to be disruptive and that the 'Reverts' made by the other editor are assumed to be 'constructive'? — Preceding unsigned comment added by Manubhatt3 (talkcontribs)

I think your suggestion is completely non-viable and based on a misunderstanding. Reverting is an integral part of the editing process, not a form of "targeting", unless it is in the form of dealing with a problem editor or wikistalking. A revert simply means you are going to have to obtain a consensus for the change. If both editors break 3RR they are both likely to be blocked, unless the revert is exempt from sanctions (i.e. reverting clear vandalism, reverting a blocked editor etc). If both editors become embroiled in a cycle of reverting each other without a technical 3RR violation they may also be blocked, depending on the level of engagement on the talk page and the level of support from impartial editors. A decent admin should only base their decision to block on the level of disruption and the efforts undertaken to resolve the dispute; for example, if the editor attempting to implement a change provides a very detailed rationale on the talk page and an article "watcher" constantly reverts without leaving so much as an edit summary, I would expect only the non-communicating editor to be blocked even if the number of reverts for both parties are similar. Ultimately though we all face this: the burden of obtaining consensus is on those seeking to effect change. It's not a perfect system, and it is sometimes abused, but it is an essential part of quality control. Betty Logan (talk) 17:57, 14 October 2017 (UTC)
Another important reason is that a high proportion of reverts are to deal with vandalism or other totally non-constructive editing. It would be ridiculous to have to obtain consensus before undoing such edits. Peter coxhead (talk) 17:59, 14 October 2017 (UTC)
What they said. Correct me if I'm wrong, Betty Logan, but I think you're referring to the first revert, a la WP:BRD. We can and do debate what constitutes the first revert, but we shouldn't be discussing turning BRD on its head. ―Mandruss  18:07, 14 October 2017 (UTC)
Betty Logan I can understand your argument, but you must understand that I am talking from the point of view of people/editors who are not much familiar with such concepts and processes. AFTER reading your comment, I can NOW understand that a 'Revert' is a signal to obtain consensus, but that is probably not the message sent across to someone who is relatively somewhat new to this and making changes. If you read my full post, that is what I am trying to say there. Peter coxhead I am not against 'Reverts' done to obvious cases of vandalism and disruptive editing(read my full post), but what I am saying is that the editor making the change should be given benefit of doubt.— Preceding unsigned comment added by Manubhatt3 (talkcontribs) 02:57, 15 October 2017 (UTC)
That is why we also have an Undo button with the ability to add your own customized edit summary explaining your action so as to not WP:BITE newcomers. Certain scripts such as WP:TWINKLE also have an option to do a "Good faith revert" to soften the blow even more. Of course, not everyone takes advantage of these features. -- œ 05:04, 15 October 2017 (UTC)

NOTNEWS – discussion about deleting part of it as "no longer policy"

FYI: Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:What Wikipedia is not#Paragraph 2 of NOTNEWS. The gist: it's suggested that the part in it about Wikipedia not being here for the reporting of breaking news is ignored by a sufficient number of editors that it isn't really a policy and should be deleted.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  21:19, 17 October 2017 (UTC)

The key word here is "enduring" and if an event or incident fails to prove enduring, it could always get discussed at Wikipedia: Articles for deletion. Vorbee (talk) 07:38, 20 October 2017 (UTC)

Bot requested to finish up the WP:JR moves

See Wikipedia:AutoWikiBrowser/Tasks#Admin_help_wanted and Wikipedia:Bots/Requests_for_approval/JJMC89_bot_14.

After a couple of years of manual effort to move and edit articles to better follow the consensus guidelines about punctuating names in bios (at WP:JR), we're down to a shortlist of exceptions and a long tail of about 1,650 obscure names (see User:Certes/JrSr/titles). So we got some help, including a bot that's ready to finish this. The Bot Approval Group asked that we advertise this here for a week before executing it. If interested, take a look at the lists at User:Certes/JrSr/titles and say if you see any issues. Dicklyon (talk) 17:01, 18 October 2017 (UTC)

Disclosure: I know Dicklyon's work, and usually support his efforts. So all I can say is that I my opinion were sought, I'd support this. Tony (talk) 03:07, 19 October 2017 (UTC)

SUL username cross platform solution

The complicated issues arising around the current RFC non-language characters in usernames has a lot of comments around being hard to ping, hard to refer to in 'plain language' form and such like, complicated even more by the issue of arabic and asian charater sets among others. A possible solution to the problem could be to automatically assign a secondary username to ALL usernames as an alias, using a simple number string (say 8 or 10 characters) that serves as an alternative method of referring to, or communicating with, problematic usernames. Pinging the number would do exactly the same as pinging the username. I see this as a simple look-up, whereby each username is backgrounded with the number in the same way you have easy access to a user's contributions, userlog, blocklog etc when hovering over a name. A bot could easily run through assigning exisitng usernames the number and auto-create it on new ones. On the presumption there are existing usernames that consit only of numbers, prefixing it with something like "~" (tilde) would distinguish it as an alias. Eg, My username being ClubOranje would have an alias like ~27504667. I'm sure there is someone clever over at Meta that could acheive this. ClubOranjeT 20:10, 18 October 2017 (UTC)

This should probably be on Meta somewhere, but I can't find an equivalen tpage over there... ClubOranjeT 20:19, 18 October 2017 (UTC)
Such an idea would likely require some rather significant changes to the MediaWiki software to support these aliases for pings and to show them in the places you propose. BTW, your alias would probably be either 2184171 or 17366057. Anomie 21:08, 19 October 2017 (UTC)

Opt-in "Edit source" for new accounts?

Closing per WP:SNOW: Given the circumstance, Wikipedia:VisualEditor, and the lack of any supporting evidence, the consensus is against this proposal. Alex ShihTalk 17:15, 20 October 2017 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Visual Editor is becoming more and more popular and is very stable. Since Visual Editor is Wikipedia's future, we should educate more and more editors to directly use and editing wikicode is expected to fade out at some point. In that frame, what do you think of making "Edit source" opt-in for all accounts created from now on? -- Magioladitis (talk) 08:19, 20 October 2017 (UTC)

"Visual Editor is beoming more and more popular": evidence? "Visual Editor is Wikipedia's future" Er, no. "editing wikicode is expected to fade out at some point" again, no. In recent changes, article namespace, bots hidden, 500 recent edits took 12 minutes now (i.e. changes from 08.31 to 08.43 are shown). Only taking visual editor made changes (a subset of the previous list). 500 edits, taking only those made by visual editor, ranged from 04.32 to 08.44, or 172 minutes. Counting it differently, among the last 500 article space edits, made between 08.34 and 08.46, there were 18 visual editor edits. That's 3.6% of the edits.

If after 5 years the adoption rate of VE is so low, I doubt that it can be considered the future of Wikipedia or that it should be pushed on new editors by default (or evn at all). Fram (talk) 08:49, 20 October 2017 (UTC)

Perhaps, by pushing it, we create a huge pool of volunteer software testers which will probably help programmers improving it? Moreover, this will reduce the various blanking vandalism. -- Magioladitis (talk) 08:58, 20 October 2017 (UTC)

(ec)So you have no evidence for your original statements that it is "becoming more and more popular" or "wikicode is expected to fade out" and so on? You just want to push VE and used false pretenses to support your point. Are you deliberately trying everything you can to get banned from enwiki, or does it happen by accident? Please stop this nonsense and simply withdraw this proposal now that you can do so with some dignity left. Fram (talk) 09:05, 20 October 2017 (UTC)
You added "Moreover, this will reduce the various blanking vandalism." while I wrote my reply. So, having been caught on starting a proposal with utter bollocks arguments, you decide to add another one. Why do you think that making things up on the spot will somehow convince people of anything but your utter unreliability? Fram (talk) 09:06, 20 October 2017 (UTC)
Fram This is the impression I get from people I know. Is there any study that says the opposite? I don't understand why you are so agreesive in a question I made. WMF has invested a lot to Visual Editor and had been improved a lot these 5 years. For the vandalism: I have seen removing of brackets in wikilinks and categories. Or even broken tables. This can't happen via Visual Editor. You say that in your random test 3.6% of the edits were with VE. Maybe last year this was much lower.-- Magioladitis (talk) 09:11, 20 October 2017 (UTC)
WP:ANI#Propose indef ban for Magioladitis. You are totally out of your depth in way too many discussions, and are ruining even the most simple tasks now. I'm done discussing things with you. Fram (talk) 09:23, 20 October 2017 (UTC)
I wrote "editing wikicode is expected..." not just "wikicode is expeted..." -- Magioladitis (talk) 09:37, 20 October 2017 (UTC)
  • I might not have worded it that way, but Fram is correct that proposing something based on a false premise is a bad idea. Personally, I think it is horrible software but it is up to the public to decide, and it appears that the public is choosing to just edit the source. You want (your words, mind you) to push defective software onto the masses in the hope of attracting the attention of a pool of "testers" so our software engineers will fix the defective software. Perhaps that should have been the actual proposal. In that event, I would oppose. Dennis Brown - 11:47, 20 October 2017 (UTC)
  • Oppose Prima facie any proposal based on demosntratedly false premises have no justification for proceeding. --Jayron32 11:49, 20 October 2017 (UTC)
  • Oppose this is a hypertext encyclopedia, not simply a encyclopedia that happens to be on the internet. Expecting people to learn half-a-dozen syntax features if they contribute regularly ([[wikilinks]], <ref>s and {{cite}}, '''bold''' and ''italic'' are probably enough) is not an unreasonable burden. Besides, there's already a dialog asking whether users want to "Switch to the visual editor" when they start editing. power~enwiki (π, ν) 15:19, 20 October 2017 (UTC)
  • Evidence needed. Jo-Jo Eumerus (talk, contributions) 15:28, 20 October 2017 (UTC)
  • Oppose pending evidence - proposal makes no sense at all as it stands. - Sitush (talk) 15:40, 20 October 2017 (UTC)
  • Oppose - Mostly per WP:CIR. —PaleoNeonate – 16:03, 20 October 2017 (UTC)
  • Oppose I use Lilypond over Finale, too. --SarekOfVulcan (talk) 16:12, 20 October 2017 (UTC)
  • Oppose; we're not going to change our most fundamental workflow based solely on the impression I get from people I know, and you've yet to provide any actual evidence for your claims (unsurprisingly, since they're patently untrue). Magioladitis, please withdraw this; given the amount of disruption you've spent the last few months causing, a proposal this idiotic is sailing very close to outright trolling. ‑ Iridescent 16:45, 20 October 2017 (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.

New Pages Team?

Basically, the idea is that we could have a "Team" of people who sit at the new pages feed and, after finding an article which isn't CSD-able, making rapid changes to turn it into at least a stub. (Fixing grammatical errors, adding a dozen or so sources, tagging the issues, and expanding the article) Terrariola 12:04, 20 October 2017 (UTC)

Isn't this what WP:NPP does? Darylgolden(talk) Ping when replying 12:13, 20 October 2017 (UTC)
Strictly speaking, no. It's a triage, not a field hospital. It's difficult enough to get the 430 reviwers to do the bare minimum. In fact about 90% of the reviewing is done by about 10% of the reviewers. Kudpung กุดผึ้ง (talk) 12:51, 20 October 2017 (UTC)
Well... ideally when NPP comes a cross a page with obvious and easily fixable errors, they should take a few seconds and fix them, which I normally do. You know, put on a tourniquet and tag them with a casualty card for the MASH unit. But if we can't get NPP to do at least that, I don't see a reason why we should expect to be able to assemble some other team to do it instead. GMGtalk 12:55, 20 October 2017 (UTC)
NPP is almost 100% CSD-ing, my idea is not for simple grammatical fixes, but turning "Substub" articles into proper stubs with reliably sourced text and the appropriate images, infoboxes, audio, etc.— Preceding unsigned comment added by Terrariola (talkcontribs) 13:36, 20 October 2017 (UTC)
The idea that NPP is mainly CSDing is a misconception. Since ACTRIAL, to be honest, most of the work I do there when I'm reviewing new pages is stuff like formatting references. Even before ACTRIAL it was never mostly CSD for me, but there was a lot more of it. But to your idea: that is in theory what the tags do: let people know an article is unreferrnced or whatever so they can fix it. We see how well that actually works, but I don't think creating a team to work on new pages after they are triaged would really do anything much more than we have now. TonyBallioni (talk) 13:47, 20 October 2017 (UTC)
Can it do any harm? · · · Peter (Southwood) (talk): 16:41, 20 October 2017 (UTC)
It wouldn't do any harm, but Terrariola not being a New Page Reviewer may not be aware that it's chicken/egg. We need interested reviewers and we urgently need some enhancements to the system, and without one we don't get the other. Kudpung กุดผึ้ง (talk) 16:59, 20 October 2017 (UTC)
This sounds like a good idea for a "task force" under NPP, but like Kudpung said above, NPP is already sorely understaffed and fixing that is much more impactful to readers. — xaosflux Talk 17:08, 20 October 2017 (UTC)

More dynamic search bar?

I was wondering if it could be possible to have a more dynamic search bar than what we have. The search bar present automatically looks for the most popular/clicked upon page based on the letters you type in first, but this isn't what I want. I want it to be based on my watchlist, as they are the articles/pages that I frequent the most. For example, if I type in the phrase 'Jack', I come up with File:JackDelanolocomotiveshop.jpg, File:JackXArik.png, Jack Dempsey, Jacksonville, Florida, Jacksonville Jaguars, Jackson, Mississippi, Jackie Robinson, Jackie Chan and Jack Kirby. None of these pages are any that I edit or look at. However, the Jack Gallagher (wrestler) page is on my watchlist and I frequently edit it. Is there a way to make it so that I could see this article at the top of my search? Pages I frequently edit and are on my watchlist, I use the search bar to quickly navigate to and I feel like they should pop up at the top of searches as something that is on my watchlist. If there is a way to do this, please let me know. Regards, — Moe Epsilon 16:22, 22 October 2017 (UTC)

That would be useful. · · · Peter (Southwood) (talk): 18:30, 22 October 2017 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=806621588"
This content was retrieved from Wikipedia : http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)
This page is based on the copyrighted Wikipedia article "Wikipedia:Village pump (proposals)"; it is used under the Creative Commons Attribution-ShareAlike 3.0 Unported License (CC-BY-SA). You may redistribute it, verbatim or modified, providing that you comply with the terms of the CC-BY-SA