Svoboda | Graniru | BBC Russia | Golosameriki | Facebook
Jump to content

Wikipedia:Village pump (proposals): Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
→‎RfC: Article Wizard Redesign: closing RFC per SNOW
Line 36: Line 36:


== RfC: Article Wizard Redesign ==
== RfC: Article Wizard Redesign ==
{{atop|Closing per [[WP:SNOW]] - unanimous support, and the minor formatting notes don't necessarily need an RFC to implement. [[User:Primefac|Primefac]] ([[User talk:Primefac|talk]]) 14:01, 14 October 2017 (UTC)}}

{{rfc|prop|rfcid=360C465}}
In light of the positive feedback from the new user [[WP:LANDING|landing page]], I [[Wikipedia talk:Article wizard#Simplification Proposal|expressed]] a need to redesign the article wizard primarily in an attempt to combat the common issues seen at AfC, with the secondary purpose of it "flowing" better in conjunction with the new user landing page.
In light of the positive feedback from the new user [[WP:LANDING|landing page]], I [[Wikipedia talk:Article wizard#Simplification Proposal|expressed]] a need to redesign the article wizard primarily in an attempt to combat the common issues seen at AfC, with the secondary purpose of it "flowing" better in conjunction with the new user landing page.


Line 101: Line 100:


While "Reviews can take a long time, and are reviewed in somewhat of a random fashion, so please be patient and know that your draft will be reviewed eventually." Is true, there must be a way of saying this that sounds less off-putting and dispiriting. Something like: "When you create your draft, it won't be publicly viewable. However, when you finish, you'll be able to submit it to be reviewed. Article drafts from new editors are reviewed by experienced editors to check they are compatible with our policies. Because everyone is a volunteer this may take some time, so please be patient, rest assured your article will be reviewed in time" or something [[User:AlasdairEdits|AlasdairEdits]] ([[User talk:AlasdairEdits|talk]]) 16:39, 11 October 2017 (UTC)
While "Reviews can take a long time, and are reviewed in somewhat of a random fashion, so please be patient and know that your draft will be reviewed eventually." Is true, there must be a way of saying this that sounds less off-putting and dispiriting. Something like: "When you create your draft, it won't be publicly viewable. However, when you finish, you'll be able to submit it to be reviewed. Article drafts from new editors are reviewed by experienced editors to check they are compatible with our policies. Because everyone is a volunteer this may take some time, so please be patient, rest assured your article will be reviewed in time" or something [[User:AlasdairEdits|AlasdairEdits]] ([[User talk:AlasdairEdits|talk]]) 16:39, 11 October 2017 (UTC)
{{abot}}


== Lint errors discussion place ==
== Lint errors discussion place ==

Revision as of 14:01, 14 October 2017

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:


RfC: Article Wizard Redesign

Closing per WP:SNOW - unanimous support, and the minor formatting notes don't necessarily need an RFC to implement. Primefac (talk) 14:01, 14 October 2017 (UTC)[reply]

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.

In light of the positive feedback from the new user landing page, I expressed a need to redesign the article wizard primarily in an attempt to combat the common issues seen at AfC, with the secondary purpose of it "flowing" better in conjunction with the new user landing page.

I would like to propose that we adapt this redesign as the new article wizard. Drewmutt (^ᴥ^) talk 01:58, 4 October 2017 (UTC)[reply]

Survey

Threaded discussion

Finer issues are:

  • Standardization of colour of buttons (blue=we want you to do this;white=we do not care;red=look before you leap)
  • Introduction to the word notability somewhere in the wizard
  • Wording of the buttons(should they all be next or should they say some thing about what is to follow)
  • A emergency help button somewhere in the wizard linking to either WP:TH or live help chat.

These issues need to be resolved .On the whole it is certainly better than the old wizard.-(User:Forceradical on a mobile)-150.107.215.6 (talk) 11:27, 5 October 2017 (UTC)[reply]

The Create Draft page states that "When you create your draft, it won't be publicly viewable." However, drafts are in fact publicly viewable, just not searchable. Perhaps we could reword this sentence so new editors are not misled? Otherwise, this is awesome. Thanks! Tony Tan · talk 17:49, 6 October 2017 (UTC)[reply]

I don't feel like the proposed wizard addresses notability sufficiently. While it is mentioned that articles need good sourcing, I don't think it gets the point across that article topics need to be notable to be accepted (it doesn't even mention notability, I believe). Thoughts? Darylgolden(talk) Ping when replying 00:54, 7 October 2017 (UTC)[reply]
I think what Drewmutt was trying to do was simplify it and get away from the wall of text approach of the current wizard and WP:YFA. Those approaches haven't been working in actually improving draft and article quality IMO. I think we could have a For more informations see Wikipedia notability type thing, but we need to remember that most people who create new articles as new users aren't going to be the type of people who regularly visit project space and are aware of the minutia of WP policy. Some people read the manual, others just want a summary. I think the redesign does a good job of getting the basics (you need high quality sourcing) without turning people off with in-depth policy discussions. TonyBallioni (talk) 01:46, 7 October 2017 (UTC)[reply]
Not to mention, if they can't find good sources about something (as the proposed wizard asks them to do), it's likely that it isn't notable anyway. — Gestrid (talk) 18:17, 7 October 2017 (UTC)[reply]
But practically speaking 95% of people submitting drafts are going to be told that "this subject does not meet the notability criteria for blah blah blah..." The current wizard is far too complex and confusing, but there needs to be a step (probably the first step) that says something like,
Wikipedia is an encyclopaedia built on verifiable information from existing reliable sources. Not every topic is suitable for inclusion.
Has the topic you want to write about already been written about by multiple, reliable sources that are independent of the subject?
Otherwise we're simply not being up-front about the number one criterion the draft will be reviewed on. – Joe (talk) 12:23, 12 October 2017 (UTC)[reply]
  • Yes, I agree the colour of the buttons needs to be standardised, for example at this page the blue could be taken as an encouragement for users that saying that they're unconnected is the "right option" and "I'm being paid to edit" is the "wrong" option. Additionally, at the welcome page blue is used as the "escape" option, whereas later on it's used as the "proceed" option. jcc (tea and biscuits) 21:56, 7 October 2017 (UTC)[reply]
Added link at CD to generate more community involvement since this is a major change affecting a lot of people

Feel free to revert if inappropriateForceradical (talk) 11:15, 11 October 2017 (UTC)[reply]

There's a lot to like about this draft:

  • Cleaner
  • I like the encouragement to try out their own sandbox
  • I like the handling of COI and paid disclosures

There's always a tension between clean design and walls of text. Many such things start out clean, then many editors want "just one little thing" and it becomes a wall of text. Rinse and repeat.

That said, my primary concern is the list of things that are not acceptable references, with "not" being emphasized. Some of those things "do not count" when assessing notability, but are not forbidden as references. I ought to suggest alternative wording, but I haven't come up with anything acceptably succinct. One possible option (which might also address some concerns of others), would be to say something like "Your article will be rejected, unless you provide references to independent, reliable sources which demonstrate Notability." Then modify the list description to clarify that those things do not demonstrate notability.

I also concur with the comment that the phrase "When you create your draft, it won't be publicly viewable." needs tweaking.--S Philbrick(Talk) 15:47, 11 October 2017 (UTC)[reply]

While "Reviews can take a long time, and are reviewed in somewhat of a random fashion, so please be patient and know that your draft will be reviewed eventually." Is true, there must be a way of saying this that sounds less off-putting and dispiriting. Something like: "When you create your draft, it won't be publicly viewable. However, when you finish, you'll be able to submit it to be reviewed. Article drafts from new editors are reviewed by experienced editors to check they are compatible with our policies. Because everyone is a volunteer this may take some time, so please be patient, rest assured your article will be reviewed in time" or something AlasdairEdits (talk) 16:39, 11 October 2017 (UTC)[reply]

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.

Lint errors discussion place

There should be an official place for discussions regarding Lint errors. There are numerous issues I would like to discuss, and, not to start those discussions here, but just to give a sense of some of the scope, here are some:

  • Is there a way to run an individual page through all lint tests, or just one lint test? If not, how soon can this tool be constructed?
  • Each page's "Page Information" link provides a page that tells how many errors of each type of lint error the page has. This should be enhanced to provide some further information such as what is displayed on each of the Lint errors page, e.g. edit link, some error text, and "Through a template?"
  • Some of these Lint errors would be relatively easy to fix with bots, especially Multi colon escape. Are there plans to create such bots?
  • Why, when a new type of Lint Error is added, do the numbers continue to grow for an extended period? Is it that it takes a long time for the linter to process every Wikipedia page, or that the definition of the error expands, or other factors?
  • For each type of Lint error, should Wikipedia editors attempt to correct these errors at all, or just wait for a bot to fix at least some of them?
  • Are there pages that should not be fixed, for example, sandboxes, user talk pages, Wikipedia talk archives? If there were an official reference on this, then editors would not worry about others objecting, and they would also be able to say to anyone who objects
  • Which pages should the user be reasonably certain of fixing correctly on the first try? For example, if it is OK to edit User pages, it might be good etiquette to get each fix right the first time (if necessary, by experimenting in the editor's own sandbox).
  • Are there plans to improve the ordering of errors? If page information reports that there are "Misnested tag with different rendering in HTML5 and HTML4", it can be a major search effort to find the indication on Special:LintErrors/html5-misnesting, in order to fix the errors.
  • The Wikipedia edit page, upon "Show preview" and "Save changes", should warn Wikipedia editors of any newly-added lint errors. Arguably, new High Priority errors should prevent a page from being saved.
  • Can we make the help link more prominent on each Lint error page?
  • Can we enhance the help pages to discuss other errors, such as unclosed tags or unclosed tables, that are known to frequently trigger the topical lint error?
  • Can we improve the diagnostic to better localize the error?

Again, I don't want to have these discussions here. I just want a unified place to have these and other discussions. —Anomalocaris (talk) 07:23, 4 October 2017 (UTC)[reply]

Sounds useful, feel free to start up Wikipedia:Lint errors and an associated talk page or the like. We can link to it from MediaWiki:Linterrors-summary that displays at Special:LintErrors. — xaosflux Talk 12:12, 4 October 2017 (UTC)[reply]
Alternatively, we can have the discussion first (probably better at WP:VPPOL or WP:VPT) and then start a page with a working set of rules. --Izno (talk) 12:24, 4 October 2017 (UTC)[reply]
Put it at VPT not not VPPOL if you have the discussion. I'm sure there are many of us who have no earthly idea what a lint error is. I'm currently imagining Wikipedia being full of exploding cloths dryers ;-) TonyBallioni (talk) 14:29, 4 October 2017 (UTC)[reply]
That's... not far off in actuality. --Izno (talk) 14:38, 4 October 2017 (UTC)[reply]
If there are questions related to bad / incomplete documentation, would you be able to add it to mw:Help_talk:Extension:Linter? For feature requests for the linter, either a phabricator ticket or a request at mw:Extension_talk:Linter would be useful. For now, I'll pick up things from the list above and add it to the appropriate places and/or make fixes and update here when I am done. PS: Thanks for the exploding clothes dryers humour. :-) SSastry (WMF) (talk) 15:06, 4 October 2017 (UTC)[reply]
User:Anomalocaris didn't want the discussion here, so will wait on responding to some of these things, but mw:Help:Extension:Linter#Tools might be useful. SSastry (WMF) (talk) 16:12, 4 October 2017 (UTC)[reply]
We just deployed a couple of fixes that reduce the false positives categorized in the html5-misnesting linter category. Most of those errors will now go back to being missing-end-tag errors or misnested-tag errors. SSastry (WMF) (talk) 21:17, 4 October 2017 (UTC)[reply]

Just a note, but my bot (NihlusBOT) was handling some misnested errors. I received some assertive feedback from some users about it clogging up their watchlists. This should be considered when tackling these in the future. I am open to working on these as I have been manually tracking some of them. Nihlus 15:22, 4 October 2017 (UTC)[reply]

I have a bot, Fluxbot that works on one of these as well (well technically it works on Category:Pages using invalid self-closed HTML tags, but that is basically an overlay of Special:LintErrors/self-closed-tag. The backlog is done, but there are new entries occasionally. — xaosflux Talk 15:32, 4 October 2017 (UTC)[reply]

Xaosflux above suggested that I start up Wikipedia:Lint errors and an associated talk page or the like. Are there objections or reservations on this? —Anomalocaris (talk) 04:27, 10 October 2017 (UTC)[reply]

dewiki has this de:Hilfe:Wikisyntax/Validierung page with help and discussion in case it is useful here. SSastry (WMF) (talk) 22:47, 10 October 2017 (UTC)[reply]

The legacy of User:Allen3

User:Allen3 has died. He was for many years a vibrant and active editor and admin. He was kind. He was helpful. The last edit he ever made was to give helpful advice in a discussion.

When a productive Wikipedian leaves us, we remember them, and we preserve their legacy. We strive to finish their work. Allen3 was a busy content creator. He left over forty drafts in various stages of production. As we would hope for any of our drafts, let's finish his. Let's get them into mainspace, maybe even into DYK, which Allen3 loved, and into the best quality we can muster.

They are:

Thanks. bd2412 T 22:36, 5 October 2017 (UTC)[reply]

Very sorry to hear about this. I am generally interested in history articles of any sort, so perhaps I could work on a few of the drafts. Biblio (talk) 16:16, 8 October 2017 (UTC)[reply]
Great! There are 42 of these, so if we could get a dozen editors to each adopt a handful, they would be covered. Fortunately, Allen3 got most of these off to a good start with a rough outline of the notability of the individual, and sourcing to support it. bd2412 T 16:52, 8 October 2017 (UTC)[reply]
I'll take Stoddard. What's the procedure to "claim" these? Just move the page? MB 01:38, 9 October 2017 (UTC)[reply]
@MB: that is fine, certainly use move and not copy to maintain attribution. Moving User:Allen3/Stoddard to Draft:Isaac Taft Stoddard for example is perfectly fine. — xaosflux Talk 01:59, 9 October 2017 (UTC)[reply]
I deleted User:Allen3/Camp Grant that was just an infobox for an article we already have (Camp Grant massacre). User:Allen3/gosper was a substantial expansion of the pre-existing John J. Gosper, so I hist-merged it to there. It needs cleanup of some sentence fragments if someone wants to do some simple editorial work; I'm out of time at the moment. DMacks (talk) 05:37, 9 October 2017 (UTC)[reply]
I will take the E. B. Gage draft into my userspace and work on it for the next few months. RIP, Allen3. A Traintalk 12:38, 9 October 2017 (UTC)[reply]
I will pledge to work on Clark Churchill. I've got a deadline looming this week, will get it up there next week. Carrite (talk) 17:14, 12 October 2017 (UTC)[reply]
I'll do User:Allen3/l zeckendorf. Eddie891 Talk Work 01:26, 13 October 2017 (UTC)[reply]
User:Allen3/Mac exists. RIP Allen. Eddie891 Talk Work 23:57, 13 October 2017 (UTC)[reply]
Dibs on User:Allen3/diamond please. ♠PMC♠ (talk) 01:59, 13 October 2017 (UTC)[reply]

Features for readers

From a readers perspective it would be awesome if there would be a feature where I can put different articles on a "to-read" list, and also have a "read" list of all the articles I already read on wikipedia. Right now as far as I can see, registering on wikipedia is only useful for editors. LuxMaryn (talk) 12:06, 6 October 2017 (UTC)[reply]

@LuxMaryn: This will soon be available in the mobile app. Please take a look at mediawikiwiki:Wikimedia Apps/Synced Reading Lists. --Izno (talk) 12:56, 6 October 2017 (UTC)[reply]

Proposal to go back to calling "Main" "Article" on edit count on Wikipededia

If one goes to "Contributions" one can then do an Edit Count. If one goes down far enough on this page displaying one's edit count, one will see a pie chart listing percentages of the different contributions one has made. I am sure that there used to be a section of this pie chart called "Article", but I now think it is called "Main". My proposal is that we go back to calling this section of the pie chart "Article" - calling it "Main" may confuse some Wikipedians into thinking it is to do with Wikipedia: Main Page. Vorbee (talk) 16:38, 8 October 2017 (UTC)[reply]

Hi @Vorbee:, that chart is from an external link to the xtools utility. You can use this link to request changes to xtools. — xaosflux Talk 02:03, 9 October 2017 (UTC)[reply]

RfC: Proposal - Removal of signature fields

Survey

  • Support as proposer. Beyond My Ken (talk) 00:02, 9 October 2017 (UTC)[reply]
  • Support Tony (talk) 03:18, 9 October 2017 (UTC)[reply]
  • support --JohnBlackburnewordsdeeds 04:02, 9 October 2017 (UTC)[reply]
  • Support Alex ShihTalk 04:03, 9 October 2017 (UTC)[reply]
  • 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)[reply]
    Tony hasn't offered a rationale, though.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  19:57, 9 October 2017 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support --Blackmane (talk) 05:41, 9 October 2017 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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 - 2¢ 12:28, 9 October 2017 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support, they're usually copyvios anyway. Stifle (talk) 16:13, 9 October 2017 (UTC)[reply]
  • 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)[reply]
    I think you mean "Support for BLPs".  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  19:57, 9 October 2017 (UTC)[reply]
    I like dead people too, although I can't say I'm particularly proud of it. ―Mandruss ☎ 20:52, 9 October 2017 (UTC)[reply]
  • 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)[reply]
    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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
  • Oppose- These are sometimes appropriate, sometimes not. No need for a draconian rule like this. Carrite (talk) 05:18, 10 October 2017 (UTC)[reply]
  • 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)[reply]
  • Support per Fortuna Imperatrix Mundi. - SchroCat (talk) 19:06, 10 October 2017 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)❤T☮C☺M☯ 23:08, 10 October 2017 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support. We already have a severe case of infobox bloat and the autographs served little purpose. Kablammo (talk) 16:54, 12 October 2017 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose signatures are a notable characteristic and worth mentioning. --Tom (LT) (talk) 05:23, 14 October 2017 (UTC)[reply]

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)[reply]

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)[reply]

  • @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)[reply]
    • @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)[reply]
      • 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)[reply]
  • 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)[reply]
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)[reply]

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)[reply]
Sure, but those of us with this view are already inserting it into the !voting section above.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  19:59, 9 October 2017 (UTC)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]

I propose that WMF begin work on my rewards incentive system

Absolutely no chance that this or anything like this will be adopted here, as has already been stated by Iridescent, so continuing this thread is pointless. BencherliteTalk 23:48, 10 October 2017 (UTC)[reply]

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.

This is not paid editing, on the contrary. I am opposed to paid editing because it is wrecking parts of our encyclopedia. My proposal and its design is explained here. - Shiftchange (talk) 18:50, 10 October 2017 (UTC)[reply]

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.

Adding license information to image

I would like to propose a license captions on the image across Wikipedia. It may be same as found on Wikimedia blogs. As Wikipedia follows Attribution-ShareAlike 3.0 Unported {{Cc-by-sa-3.0}} License the term of ATTRIBUTION too will satisfy by this step. As the pixels of image in info box is around 220px only the license on commons or fair use shall be displayed. Further comments on improvement shall be accepted --✝iѵɛɳ२२४०†ลℓк †๏ мэ 05:15, 11 October 2017 (UTC)[reply]

Oppose: A well intentioned proposal, but I see little likelihood that we are going to clutter every image with a text overlay. Alsee (talk) 07:14, 13 October 2017 (UTC)[reply]
Oppose: The information is generally one click away. —PaleoNeonate – 09:30, 13 October 2017 (UTC)[reply]
Oppose per both of the above. License information of no use or interest to 99.9% of readers. ―Mandruss ☎ 09:57, 13 October 2017 (UTC)[reply]

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)[reply]

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)[reply]

Survey

  • Support, as proposer. Headbomb {t · c · p · b} 12:27, 11 October 2017 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose - 100k is nothing. As written, this is a bad idea. Dennis Brown - 2¢ 21:13, 11 October 2017 (UTC)[reply]
  • 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)[reply]
How is having 100 sections of newsletter on the talk page is better? Headbomb {t · c · p · b} 23:14, 11 October 2017 (UTC)[reply]
  • 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)[reply]
  • 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)❤T☮C☺M☯ 23:28, 11 October 2017 (UTC)[reply]
  • 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)[reply]
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)[reply]

@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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]

Discussion

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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

More than once I've enquired (not here) about whether it would be feasible to create an automated list of redlinks, which would appear much the same as Special:AllPages, except all the entries would be red.

One could peruse the list, and finding that there are, say 20 redlinks for Pope Donald III throughout WP, and having established that they are not vandalism or typos, one could set about either creating an article for said Pope Donald III (assuming notability can be established), or delinking the redlinks - in either case eliminating 20 redlinks. This would serve a very useful purpose.

The first time I raised this idea, some years ago, it was knocked on the head immediately as being beyond the capacity of the system at that time. Have things marched on, technologically speaking? Is this now a goer? It seems a glaring omission from the wiki-way of doing things. -- Jack of Oz [pleasantries] 19:33, 12 October 2017 (UTC)[reply]

Jack of Oz you could try Special:WantedPages, however that list is not restricted to mainspace, and redlinks-in-templates get counted for every instance of the template. The (current) top result is Talk:Jay Obernolte/GA1‏‎ (48,618 links). A Wikiproject Games template spamed that link on every game's talk page. You'll probably find WP:Most-wanted_articles more useful. It hasn't been updated in 17 months, but it has close to a thousand links. Only about 16 of those links have turned blue. Special bonus for Sumo fans! 1953 in sumo through 1984 in sumo are all in demand! :D Alsee (talk) 07:02, 13 October 2017 (UTC)[reply]

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)[reply]

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)[reply]
(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))[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]

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)[reply]

Survey

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)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=805306983"