Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
  Policy   Technical   Proposals   Idea lab   Miscellaneous  

New ideas and proposals are discussed here. Before submitting:

« Older discussions, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155

Time to incubate the substubs

NOT DONE:
I think everyone here appreciates that Dr. Blofeld is trying to remedy an issue they perceive with their own work. However, in the weeks this has been open a consensus has emerged that any mainspace content is better than hiding it away in draft or user space (The article incubator having been closed for some years now) He is of course still free to tag them individually for speedy deletion, but mass userfying/draftifying is not supported by the community at this time. Beeblebrox (talk) 19:19, 9 December 2018 (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.

I propose that any stub I created which is below 200 bytes of readable prose/a one line stub without actual information be incubated/moved to user space until they can be fleshed out properly. Most will be at least 5 years unexpanded. It was wishful thinking at the time but there's a lot of currently unacceptable ones which really shouldn't be swamping the categories. There's enough crap content here as it is. There's a lot of "xxx is a village in xx. As of xxx it had a population of xx". Those are bare minimum useful with one fact but I think if there's hundreds of them like that in one category redirect and listify it by district into an A-Z table with population would be more sensible rather than incubate. I was browsing through some places in Nepal etc I created and to be honest a lot of them have degraded with local ips adding dubious, unsourced factoids. Small villages in the developing world are off most people's radars. In a lot of cases we're better off having a list with the population until somebody can write a half decent article and watch it.♦ Dr. Blofeld 12:48, 14 November 2018 (UTC)

Absolutely not. Some places (which are automatically notable) have stub articles <200 bytes long. 'Incubating' these stubs isn't going to help if they just languish in draftspace forever. If they're not being improved now, there's even fewer chances that they'd be improved later. It's a bad idea. Thanks for your suggestion, though -- I'm prone to some less than stellar ideas at times, moreso than most editors. ProgrammingGeek talktome 14:46, 14 November 2018 (UTC) Okay, so apparently I didn't read the proposal closely enough, sincere apologies! Striking in favour of new comment below. (15:59, 14 November 2018 (UTC))
Oppose - I am with ProgrammingGeek on this one, if you see a stub under 200 bytes that fails WP:N then just send it to WP:AfD. - Knowledgekid87 (talk) 14:52, 14 November 2018 (UTC)
I'm not a renowned fan of mass stub creation, but fact of the matter is, it's easier for a new editor to improve an existing stub than it is for them to create one. GMGtalk 14:53, 14 November 2018 (UTC)
I'd also like to see automated or semi-automated stub-suggestions for new editors, but I'll let you know when someone somewhere cares about my opinion. No luck so far. GMGtalk 14:54, 14 November 2018 (UTC)
I think you can configure SuggestBot to do such a thing, but haven't ever really tried. Ivanvector (Talk/Edits) 14:56, 14 November 2018 (UTC)
Well, I meant for example, if someone registers an account, and their first edit is on a rugby player, something like SuggestBot comes by (probably using category information) and says "I see you know that rugby is a thing that exists, here are some stubs (read: things we know you can work on that probably won't get deleted)". But if the user has to configure SuggestBot themselves...well...if they could do that then they know enough of what they're doing that they ain't the target audience. Having said that, queue 4.5 million angry comments about how that is too close to automated welcoming and perennial yadda yadda yadda (even though we've long identified finding work as a barrier to entry for new users). GMGtalk 15:01, 14 November 2018 (UTC)
I think we've hit on a separate discussion here, but I for one like the idea of automatically welcoming new users (or, say, newly autoconfirmed users) and offering them some "getting started" suggestions, like filling out a stub or de-orphaning something or I don't know what. Or make something so more experienced users can trigger suggestions, like putting some derivative of a SuggestBot template on their page along with a welcome template. Ivanvector (Talk/Edits) 16:09, 14 November 2018 (UTC)
  • Could we just be clear that the stubs concerned here are only those created by Dr. Blofeld. Maybe if he could give us a few representative examples that would be helpful. – Uanfala (talk) 14:58, 14 November 2018 (UTC)
Dr. Blofeld is in the top 50 by edit count not sure exact number but over 350,000 which means XTools doesn't work for finding a list of article creations. One can find them using this but it also includes redirects and page moves. The limit=5000 will work .. probably a huge number in total. -- GreenC 15:04, 14 November 2018 (UTC)
Comment I've come across Dr. Blofeld stubs over the years on obscure topics (regional German language poetry awards) and they have been useful for creating blue links when backlinking or filling in a few details. Sometimes the titles need to be adjusted for English. Not sure it would be helpful to delete unless there are some known cases of bad ideas like every fire station in Belarus. -- GreenC 15:01, 14 November 2018 (UTC)
@ProgrammingGeek, Knowledgekid87, and GreenMeansGo: I think you've misread the question. What Dr. Blofeld is asking for is authorisation to conduct a mass transfer of any stub I created which is still below 200 bytes of readable prose (my emphasis). Dr B would be the first to admit that some of his earlier stubs have problems with sourcing and accuracy, and because there are so many of them (I don't have the numbers but at a rough estimate we're talking between 10,000 and 100,000 pages, many of which are genuinely unexpandable substubs bot-created from databases with no text other than "X is a building in Y" or similar) it would require a bot to perform a bulk move of the relevant pages to a {{noindex}}ed space where the sourcing and prose issues can be cleaned up at leisure, and such a bot would require community consensus. What the three of you are effectively saying is that you're better placed than him to assess his own contributions. ‑ Iridescent 15:08, 14 November 2018 (UTC)
No, I understand the question. I also understand the Dr. B is so prolific it's hard to separate an attitude toward his stub and an attitude about stubs. GMGtalk 15:15, 14 November 2018 (UTC)
I've not been prolific in a very long time, I used to create an enormous number of placeholder stubs pre 2012 which if they've not been expanded this since probably won't soon. My attitude means all stubs not my own but I can't control those.♦ Dr. Blofeld 16:04, 14 November 2018 (UTC)
But other than the fact that they are your stubs, that's not really an argument that doesn't apply equally to all stubs, of which we have 3.2 million (about half the project). If they're non-notable, then yeah. They should be deleted and never should have been created. If they're notable, then it's a waste of time to delete them when they need to at some point in the future be recreated. Besides that, I'm fairly confident in saying that automatically deleting tens or scores of thousands of articles is probably not what the community had in mind when authorizing G7. GMGtalk 16:17, 14 November 2018 (UTC)
Yes, that's exactly what happened. Sorry. ProgrammingGeek talktome 15:59, 14 November 2018 (UTC)
The vast majority are notable, but there's a lot of things like one liners on small rivers, obscure villages etc with no real information, a lot which are hardly vital articles and more marginally notable. A great deal of them might be better listified. If G7 is a problem then they can be moved to user space of course.♦ Dr. Blofeld 18:13, 14 November 2018 (UTC)
But again, you're mostly making an argument against stubs in general, and not some critical flaw in these stubs in particular. GMGtalk 21:42, 14 November 2018 (UTC)
  • Support in case it's not obvious from my comment above. That we automatically delete any article without question from the mainspace if requested in good faith and provided that the only substantial content of the page was added by its author has been a basic principle of Wikipedia for a decade; all that's being requested here is that it be done by technical means rather than Blofeld be forced to manually move 10,000+ pages and tag the resulting cross-namespace redirects for deletion. ‑ Iridescent 15:12, 14 November 2018 (UTC)
  • Sure We can incubate (do you mean draftify?) these stubs that only you worked on. That way anyone who wants to work on one and get it main worthy can do so. Alanscottwalker (talk) 15:22, 14 November 2018 (UTC)
Some way of removing what we would call "sub stubs" from the mainspace. If they've not been expanded in six years plus years they're unlikely to be soon. I say under 200b as a lot are fleshier and decent. Basically anything which is a one liner xxx is a bla bla bla, get shot of, if it's that notable somebody will write it later. I did mostly create notable subjects but a lot are ones which most people will hardly be looking for information on. I just think it's time we took this project by the scruff of the neck and had a giant cleanup.♦ Dr. Blofeld 15:55, 14 November 2018 (UTC)
Yes, (and next up, how can we get NSPORTS to listify all those player stubs (say, what!?!)) -- Alanscottwalker (talk) 16:02, 14 November 2018 (UTC)
  • (edit conflict) Changed to Support per Iridescent, provided that Dr. Blofeld is the only user that has contributed to the draft. If there's consensus and you need someone to write the bot, just ping me. Best, ProgrammingGeek talktome 15:59, 14 November 2018 (UTC)
  • Oppose Yes a lot of the sub-stubs are bad and cannot be expanded, and when this occurs they can be individually deleted for lack of notability. I do not see why they should all be deleted because of this, many of the articles are presumed notable. This would set a precedent to delete in excess of a million articles. Maybe more. — Frayæ (Talk/Spjall) 16:11, 14 November 2018 (UTC)
  • Support On reflection I think a certain level of minimum quality would be reasonable given what we hold as the standard at AfC. None of these articles would meet the requirements we insist on there so deleting/incubating them is reasonable. — Frayæ (Talk/Spjall) 17:00, 14 November 2018 (UTC)
    • I don't think you understood the proposal. Natureium (talk) 16:13, 14 November 2018 (UTC)
Yes, nothing is being deleted, just moved behind the scenes until they have adequate information. I did identify a lot of notable subjects but if they're still placeholders after years then they're not going to be developed soon.♦ Dr. Blofeld 16:23, 14 November 2018 (UTC)
If you approve a bot capable of moving substubs to draftspace then it can potentially be used to remove maintenance backlogs to draftspace as well. Incubated articles are deleted after 6 months via G13. This is a bad idea. — Frayæ (Talk/Spjall) 16:30, 14 November 2018 (UTC)
Then we'll put them in a special category so nothing gets deleted and they're linked in a place people can work on them if they wish.♦ Dr. Blofeld 17:08, 14 November 2018 (UTC)
There are no exceptions to G13 and looking at previous RfC discussions on the subject it is going to stay that way. If you want to keep the pages more than 6 months you should make sure they are put in your userspace where you have some say on the matter. — Frayæ (Talk/Spjall) 17:17, 14 November 2018 (UTC)
Move to user space then.♦ Dr. Blofeld 17:30, 14 November 2018 (UTC)
  • Support. Much better than going through all of them. Natureium (talk) 16:13, 14 November 2018 (UTC)
  • Support. Deletion criteria should take into account number of backlinks to non-dab mainspace articles; number of external links; byte count of plain-text article body. -- GreenC 16:22, 14 November 2018 (UTC)
  • Comment. I do not have a strong opinion either way, but if this gets closed as oppose or no consensus, we might still want to make a list of such articles so that interested parties could work on it.--Ymblanter (talk) 16:37, 14 November 2018 (UTC)

A typical stub of mine will look like Thüringische Muschwitz, that's 7 years old. Has an infobox and length but little else and the whole category is flooded with ones like it. I think ones like that would be better off in a List of rivers in Thuringia with a table giving information on source and mouth and length so no information is lost until somebody can write a better article.♦ Dr. Blofeld 17:50, 14 November 2018 (UTC)

  • Comment I thought we had generally considered that WP functions as a gazetteer, and thus justifying stubs of any officially recognized town/village or natural landmark, with the basis that local sources potentially could be used to expand these (keeping in mind, no deadline exists for that). I understand if we were talking stubs on persons or other less permanent elements to userify them, but places seemed to have been handled differently in the past. --Masem (t) 18:08, 14 November 2018 (UTC)
True, but the issue I think is people searching through categories and wanting to read and find decent articles and finding almost every entry is xxx is a village and no real information. I've been browsing some and it is frustrating when viewed from a reader's perspective. For a lot of those you could currently represent the same information in one list instead of having to browse dozens of articles just to retrieve one figure.♦ Dr. Blofeld 18:22, 14 November 2018 (UTC)
I can see listifying these then by logical groupings to give better context to readers, but this would still demand that redirects be left behind (as a gazetteer, these are searchable terms) and to that end, it doesn't make sense to necessary userify them and instead just appear a redirect to the history. --Masem (t) 18:27, 14 November 2018 (UTC)
Note that I expanded Thüringische Muschwitz a bit and now it is slightly longer than it was when Dr. Blofeld wrote the above comment. If we stick to 200 bytes, it is not eligible now to be moved.--Ymblanter (talk) 19:12, 14 November 2018 (UTC)
  • Oppose - I think removing them on grounds of quality (vs normal deletion grounds) is incorrect - I don't think it functionally harms Wiki and they can be beneficial if and when someone does want to write on one. Obviously most go a long time without being edited, but there are so many the rate of at least some having edits made must be reasonably high. Nosebagbear (talk) 18:34, 14 November 2018 (UTC)
  • Leaning oppose. I honestly don't see what's the problem with having these mini-stubs in mainspace, as long as the factual correctness is not in dispute and they have a minimum of sourcing. I would have found Thüringische Muschwitz useful (even in its pre-Ymblanter state), not least because there's the language link to the more developed version on deWP. Also, as noted above, expanding a stub is easier than creating a new article. And every so often someone comes along who does specialize in Nepalese hamlets, even if it does take longer than 6 years - why not make it easy for them to get going? --Elmidae (talk · contribs) 19:24, 14 November 2018 (UTC)
  • Oppose - if you don't like that they are so short, then you can always just expand them... Thanks. Mike Peel (talk) 20:00, 14 November 2018 (UTC)

Redirecting these villages to the district where we can put a list of all of them would be the preferred way to go. Don't dump them all in userspace or draft where no one will work on them and they will just need to be managed with the tens of thousands of other abandoned pages there. Legacypac (talk) 21:58, 14 November 2018 (UTC)

A huge number did get expanded though, I'd forgotten how many valuable subjects I'd started too! Yeah maybe the ones with hundreds of villages and one liners belong in a list.♦ Dr. Blofeld 23:01, 14 November 2018 (UTC)

Oppose deletion of the stubs. Even if they're low-quality and very short, at least it's not actual garbage, unlike some examples of mass creation... SemiHypercube 23:52, 18 November 2018 (UTC)

  • Oppose deletion or moving to userspace/draftspace or anything else. If the subject of the article is sufficient to survive deletion discussions, there is no reason to delete or move or do anything to such sub-stubs. If the article should exist, there's no reason to delete beyond the obvious (copyvio, etc.) and just "being too short right now" is not a reason. If the article shouldn't have existed in the first place, by all means, delete it, but if it could be expanded properly, but merely hasn't, please don't.--Jayron32 03:47, 19 November 2018 (UTC)
  • Oppose moving them to draftspace or userspace. Firstly, it could mean we end up with two articles for some subjects, one in draftspace/userspace and another in mainspace when someone recreates it. Secondly, it drastically reduces the number of people who are likely to improve the stub. If you want to improve them, then improve them in mainspace and give others the opportunity to help. If the vast majority are notable, then it is inappropriate to delete them. I like the suggestion that some articles be changed into redirects to lists where the small amount of information can be preserved, avoiding the issue of the articles being recreated by editors who might be unaware of the previous article or this discussion. If the information in the list is expanded, it would be easy enough to split it and replace the redirect. Jack N. Stock (talk) 05:01, 19 November 2018 (UTC)
  • Oppose removal of stubs: When the info is presented neutrally, a bit of information is better than no information. Also, the mere existence of the article is also informative as it tells the world that a certain topic exists (a town, for example). Moreover, from the editors perspective a stub is more inviting for multiple editors to make small contributions that collectively add up to a better article. In contrast, removing the article from the main space makes it more daunting for any one editor to have to draft a more fleshed out article before publication. Thank you. Al83tito (talk) 18:42, 21 November 2018 (UTC)
  • Oppose More users are likely to edit and improve these stubs if the are in the mainspace. —Eli355 (talkcontribs) 21:56, 22 November 2018 (UTC)
  • Strong Oppose. Outside of articles with serious issues, a short article is much better than no article. In the case of a town, for instance, even a substub can tell you where a place is located, what state/province/county it's in, and basic facts like its elevation and postal code (which may be in the infobox and not the readable prose). A short article also makes a topic more likely to be expanded, especially by new editors (who can't write new articles, probably won't find drafts as easily, and may think anything without an article isn't notable). TheCatalyst31 ReactionCreation 22:27, 1 December 2018 (UTC)
  • Oppose These stubs can be useful even if they are short. Doing this would likely remove any possibility of improvement on the vast majority on them. Linguistical (talk) 07:12, 2 December 2018 (UTC)
  • Oppose as incubating is an almost useless process. Being in place they are more likely to receive the heat of editors. They has some small use, so geographical stubs are better there than not. Graeme Bartlett (talk) 08:03, 2 December 2018 (UTC)
  • Oppose Whats the harm of the article? As above, these articles would likely not be touched for improvements, so readers and new editors who may want to expand the content of this stub won't be able to find it. If the article is that small that it needs to be moved to draft space, even when the article is 5 years old and isn't likely to be expanded on, then it should be sent to AfD. 17:34, 2 December 2018 (UTC)
  • Oppose moving out of namespace 0. If they're a definite net negative, delete them (this can be a good decision if, for instance, a bot could easily create them from scratch from Wikidata data in the near future). Otherwise, keeping them in namespace 0 is the only way for them to have a chance to be improved and attract contributors, while in another namespace they would just rot and amass dust which makes the site less healthy. Nemo 16:24, 9 December 2018 (UTC)
    • For what it's worth, a quick query lists about 43k small articles on settlements by Dr. Blofeld which according to TreeViews end up having over 1.5 million pageviews per month, distributed rather evenly. Nemo 17:37, 9 December 2018 (UTC)
      • 1,500,000 divided by 43,000 gives 34 pageviews per article per month, or one view per day. That's lower than the traffic one would expect just from search engine crawlers and people clicking Special:Random; to put it another way, each of these pages is averaging ​130 of the traffic our article on Cats That Look Like Hitler gets. ‑ Iridescent 17:52, 9 December 2018 (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.

GlobalFactSyncRE/DBpedia project proposal

DBpedia, which frequently crawls and analyses over 120 Wikipedia language editions, has near complete information about (1) which facts are in infoboxes across all Wikipedias, and (2) where Wikidata is already used in those infoboxes. GlobalFactSyncRE will extract all infobox facts and their references to produce a tool for Wikipedia editors that detects and displays differences across infobox facts in an intelligent way to help sync infoboxes between languages and/or Wikidata. The extracted references will also be used to enhance Wikidata. For more see https://meta.wikimedia.org/wiki/Grants_talk:Project/DBpedia/GlobalFactSyncRE

Please let us know what you think, your opinion is important to us! Thank you! — Preceding unsigned comment added by M1ci (talkcontribs)

Should IPs be barred from turning redirects into articles?

Hello everyone, I am going to propose that redirects should plausibly be expanded into an article by registered users and not by IPs. I've noticed many serial sock puppeteer and even paid editors often use IPs to turn redirects into articles. --Saqib (talk) 15:21, 2 December 2018 (UTC)

  • We have been adding lots more restrictions as of late (article creation to autoconfirmed, removal of patroller from autoconfirmed, removal of admin rights to unblock themselves) isn't the page curation enough since that lists redirects converted into article as far as I'm aware (example). Crouch, Swale (talk) 15:30, 2 December 2018 (UTC)
  • It would be very consistent with WP:ACREQ Legacypac (talk) 15:42, 2 December 2018 (UTC)
    The concerns about speedy deletion and being bitey don't (generally) apply with redirects, if a redirect is converted into an article and its not fit for inclusion, it can just be changed back to a redirect. Crouch, Swale (talk) 15:50, 2 December 2018 (UTC)
  • Do we have some recent examples where this has been an issue? Nosebagbear (talk) 19:34, 3 December 2018 (UTC)
  • Do we have recent examples where there wasn't an issue? Jo-Jo Eumerus (talk, contributions) 19:46, 3 December 2018 (UTC)
  • I don't know if there are stats on this specifically, but generally it's an extremely low percentage of logged-out editing that turns out to be problematic, like less than 2%. There are stats on that number, but I don't have them at hand. As for ACREQ, a redirect is kind of a predetermination that a title might be expandable to an article at some point, if anyone comes along that wants to bother doing the work. I think we should not impose new restrictions on the very large majority of logged-out users expanding redirects constructively because there are a relatively tiny bunch doing small amounts of harm. A while back we identified an issue with anons hijacking dabs and redirects to get around ACREQ, but we mostly dealt with that. In this case it seems the proposal would bring more harm than benefit. Ivanvector (Talk/Edits) 03:52, 4 December 2018 (UTC)
    There's some stats that could be imported from WP:PERENNIAL, actually, but they're about a decade old and based on very small samples. The page gives 76-82% constructive edits from logged-out editors. I know there are better stats than "I picked the most recent 250 IP contribs and judged which among them were constructive" but that's all I can find right now. Ivanvector (Talk/Edits) 03:55, 4 December 2018 (UTC)
    I would propose that there should be some kind of a public log that gets updated every time a redirect is retargeted or converted into an article, and indicates which editor or IP carried out the retargeting or conversion. That would give us a quick and useful sense of the scale of this as a problem. If there already is such a log, I'd love to know about it. bd2412 T 04:15, 4 December 2018 (UTC)
    This filter tags redirects being changed into non-redirects. They appear in recent changes as "Tag: Removed redirect". Ivanvector (Talk/Edits) 04:20, 4 December 2018 (UTC)
    I see. And this one catches the same, but limited to IPs. Some of these I can immediately see are bad. bd2412 T 04:55, 4 December 2018 (UTC)
  • Why? The case has not been made that this is needed. --Jayron32 18:37, 6 December 2018 (UTC)
  • As someone who frequently patrols these articles for NPP, I'm pretty ambivalent; if we keep the current method fine and I wouldn't object if we changed it. On the one hand it's easy to fix in the ways many other new articles aren't - simply restore the redirect. On the other hand many of the articles appear instantly in Google because of the age of the redirect which is less than ideal. These are fairly easy to patrol on the whole but NPP is also getting progressively further backlogged so not spending time on these could be good. It is consistent with ACPERM, but again restoring the redirect is very simple and sometimes we might get new notable encyclopedic content out of it. Best, Barkeep49 (talk) 05:14, 13 December 2018 (UTC)

Proposal- Allow song pages on Wikipedia to have lyrics

Should we provide lyrics to songs that have a Wikipedia page? I was thinking we provide, after the lead-in and background/composition/content section, a Lyrics section that provides the full lyrics to the song, retrieved from any one of the multiple lyrics site on the web today? Schoolbus777 (talk) 02:40, 4 December 2018 (UTC)

  • No can do. Lyrics are copyrighted. -- RoySmith (talk) 02:45, 4 December 2018 (UTC)
    Generally, lyrics from after 1923 are copyrighted. --Izno (talk) 03:10, 4 December 2018 (UTC)
    True. We have the full lyrics for Jingle Bells, for example. bd2412 T 05:06, 4 December 2018 (UTC)
  • We can't include full lyrics. What we can do is provide snippets of the lyrics to the extent that reliable sources quote and discuss those lyrics, and explain what the sources say about them. A good example of this can be found in Sympathy for the Devil. bd2412 T 02:56, 4 December 2018 (UTC)
  • Copyright restricts this but where discussed by RS and where copyright is not a problem, on a case by case basis it is ok. Legacypac (talk) 05:24, 4 December 2018 (UTC)
  • No for the most part, since lyrics to songs published after 1923 are often copyrighted. SemiHypercube 21:58, 4 December 2018 (UTC)
  • Comment I would say, as a general rule, it's not appropriate to provide full lyrics even when copyright is not a problem. That's more what Wikisource is for than Wikipedia. That said, I don't see any need for a blanket rule against it. --Trovatore (talk) 23:27, 4 December 2018 (UTC)
  • Comment Apply established policy. For national anthems, for example, lyrics are generally included, and are not subject to copyright. Bellezzasolo Discuss 23:32, 4 December 2018 (UTC)
    and are not subject to copyright Not particularly true. --Izno (talk) 05:06, 5 December 2018 (UTC)
    Could we have an example of a national anthem under copyright? Specific performances of a national anthem, sure, those are copyright but the closest I'm seeing to any legal restrictions is that some countries make parodies of their national anthem illegal. Ian.thomson (talk) 17:23, 6 December 2018 (UTC)
    If the copyright hasn't expired because of age, and the country has passed no special legislation passing the song into the public domain as a national symbol, then a national anthem is copyrighted like any other musical work. As an example, the Swiss National Anthem was updated only three years ago and rewritten by a living person. GMGtalk 17:35, 6 December 2018 (UTC)
  • Lyrics for songs that are out-of-copyright should go on Wikisource, with a link to them in the article. Short extracts can be quoted on arcticles, to illustrate points being discussed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:57, 5 December 2018 (UTC)
  • Comment I understand your points regarding Wikisource and copyrights. Thank you for responding to my proposal!Schoolbus777 (talk) 01:09, 6 December 2018 (UTC)
  • Question I'm aware that lyrics are copyrighted, but why are there so many lyric websites on the Internet at large? Surely they're violating copyright by publishing them, and are probably not paying any sort of royalties. — Frεcklεfσσt | Talk 16:39, 6 December 2018 (UTC)
    Comment Yes, Frecklefoot, they mostly are infringing copyright. Wikipedia doesn't do that. --ColinFine (talk) 16:42, 6 December 2018 (UTC)
    In theory, it is possible that sites like Genius and YouTube have purchased an ASCAP and/or BMI license, which is what radio stations and clubs have in order to be able to play copyright-protected music. I see no reason why such a license would not also permit republication of the lyrics. For the most part, however, lyrics-republishing sites seem a bit dodgy. Wikipedia can't republish lyrics subject to a license, because then our own articles could not be freely licensed. I think we should expand Wikipedia:Lyrics and poetry to provide a more thorough guideline specifying, both legally and stylistically, when and how it is appropriate to present portions of song lyrics. bd2412 T 16:51, 6 December 2018 (UTC)
    Not just theory; as you can see from the Genius article, it acquired licenses in 2014. As I understand it (and mentioned in the cited New York Times article), the music publishers started cracking down at that time. LyricWiki, for example, was acquired by Wikia and entered a licensing agreement with Gracenote. (On a side note, there are lots of different rights in play. As I recall, radio stations pay for a license to perform a recording; this covers the rights for the lyrics, the music, the specific recording, and in some countries, the performers who were recorded. It wouldn't allow for publication of the lyrics themselves.)
    Regarding YouTube, I imagine it doesn't worry as much about lyrics as the actual audio and video. YouTube has its content ID program, where it scans uploads looking for copyrighted material, and blanking out audio for unlicensed music, or blocking the video entirely. Some music publishers opt to allow the uploaded video in exchange for getting a cut of the advertising revenue. isaacl (talk) 18:29, 6 December 2018 (UTC)
    After exerting no real effort for all of two minutes to find the WHOIS data for lyrics sites, the only one I nailed down was Panama, which has a reputation for not being especially strict on copyright and has a nominal GDP per capita about a quarter of the US's. Whoever set up the site I was looking at could be quite well off locally but still well under what any record company would consider worthwhile to sue for lost royalties. They also make a "fair use" claim that wouldn't hold up in a US court but I could well see a non-US court accepting as being US law. And this is all assuming that it's not just a shell company running through Panama. Ian.thomson (talk) 17:23, 6 December 2018 (UTC)
  • No Even ignoring the copyright issue, printing full lyrics of songs is outside of what Wikipedia should do in its articles anyways. It isn't really the realm of Wikipedia, which should have encyclopedia articles and not merely be lyrics. Wikisource would be more suited for this. On top of that, add the copyright issues, and that's a double "hell no". --Jayron32 18:36, 6 December 2018 (UTC)
  • A big fat no for the most part. This is Wikipedia, not Wikisource. Unless the lyrics in question is needed for commentary, e.g. fluff about why is it impactful or controversial, that is. Blake Gripling (talk) 09:32, 7 December 2018 (UTC)

Proposal: Pending changes for reference desks, admin requests and other areas.

NOT DONE:
I think we'd all like to see soemthing that would curb this, but PC is not the right fit for the job. Beeblebrox (talk) 19:21, 9 December 2018 (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.

This may seem like feeding the troll or something along the lines of pre-emptive protection, but wouldn't it hurt to place them under pending changes protection to keep the flood of trolls from disrupting the normal flow of things? Of course, semi-protecting them indefinitely wouldn't cut it as there may be anonymous users who would like to ask a legitimate question or two, but there are those who have a gross sense of schadenfreude and delight at creating drama 4chan or Dramatica-style. Blake Gripling (talk) 09:35, 7 December 2018 (UTC)

No, it would be pointless because his shit will still be in the history until we rev-delete it, and also no because the nature of his attacks is to rapidly hit the desks over and over until they are fully protected. PC stops exactly none of that. --Jayron32 15:06, 7 December 2018 (UTC)
Additionally, between the high level of his activity and the high inherent activity level of these pages, PC becomes rapidly unworkable as it is exponentially more complicated to keep good edits and remove bad ones as they get inter-mixed in the pending queue. Nosebagbear (talk) 19:24, 7 December 2018 (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.

Request for Ideas About Mediation

On 12 November 2018, in this project, a Request for Comments was closed which shut down the Mediation Committee. The question, was asked by the minority who opposed the shutdown, what would happen when there was a dispute that would have been handled by MedCom that was beyond the scope of DRN. Some of the answers were that DRN could be expanded, or that something would be done if an issue arose for which heavy-weight mediation was in order. I have a time-sensitive question for those who supported the shutdown (and also for those who cautioned against it) of how to resolve a specific open dispute. The content dispute, which is waiting for a moderator at the Dispute Resolution Noticeboard, concerns Origin of the Romanians. It is clear from the record and the number of times that issues about this article have been around that improving the article will take longer than the one to three weeks that disputes at DRN take. It appears to be a content dispute, not much affected by conduct issues, but too complex to be easily addressed in one to three weeks. In short, this is just the sort of dispute that the Mediation Committee used to handle when it had a workload and mediators. So my question for anyone is: Does anyone have any suggestions for how this dispute should be resolved?

I have asked for a volunteer to conduct heavy-weight mediation, possibly lasting several months. I haven't found one. I have one volunteer who is willing to try tag-team mediation with two or three volunteers taking turns mediating, but I don't have the second or third volunteers. So my question for anyone who said that we did not the Mediation Committee is: How should this dispute be resolved? Does anyone have any creative ideas for how to handle this? Does anyone have any obvious ideas that have been overlooked? What should be done next? There is a dispute waiting for a mediator.

Robert McClenon (talk) 03:53, 10 December 2018 (UTC)

  • From a cursory glance at the relevant dispute, all that needs to happen is enforcement of the existing discretionary sanctions. What's happening there is not a 'content dispute', it's groups of nationalist editors fighting to push their respective points of view. No matter how much you 'mediate' such a dispute, some vested party will not be satisfied. RGloucester 04:39, 10 December 2018 (UTC)
I don't think the Mediation Committee would've helped at all. In these sort of nationalistic battlegrounds, everyone involved in the dispute aren't going to agree to mediation nor are they going to accept the result if it doesn't go their way. Galobtter (pingó mió) 07:34, 10 December 2018 (UTC)

Patriarch is not misogyny (see misogyny)

Closing as a clearly unproductive thread. --Yair rand (talk) 06:56, 13 December 2018 (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.

Create a layman option for the people that do not know all the rules but see a glitch that needs fixing. Example: Misogyny list PATRIARCH as a word that defines it. This is wrong. {Biblically} Patriarchy is not meant to be misogynistic. It is the one person in every family that is the head of that family. There can only be one head of family responsibilities. It was the God of all mankind that assigned the man to be head of the family. So each man must treate his family with love. Man is commanded to treat his wife as he would treat his own body. This is a direct contrast to misogyny.

It is the PERVERSION of patriarch that makes it misogynistic. — Preceding unsigned comment added by 107.77.219.86 (talkcontribs) 23:00, 10 December 2018 (UTC)

No, that's still pretty misogynistic. GMGtalk 23:02, 10 December 2018 (UTC)
When you make an edit to an article, Patriarchy in this case, and it is reverted, the best place to start the discussion is at Talk:Patriarchy. The edit summary of the revert cited Wikipedia:No original research as the reason. --Dennis Bratland (talk) 23:23, 10 December 2018 (UTC)
Misogyny and intolerance wrapped in religion is still misogyny and intolerance. Depending on the faith, it can also be seen as heresy. —A little blue Bori v^_^v Bori! 20:50, 11 December 2018 (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.

Tagging fair use images with the date of their freedom

As I'm sure most on here know, in just three weeks, for the first time in the history of Wikipedia, the United States will see a year's worth of copyrighted works become public domain. There are a number of images currently being used under a claim of fair use that will be able to be re-tagged as public domain (for example, most any image in an article in Category:1923 films). Something that would be nice to help with that effort would be if we can start tagging images with the date that they will become public domain (if known). Obviously, some things won't be known because their authors are still alive and others are not easily ascertainable because we have no idea when it was originally published, but for those things with a clear publication date, it would be nice to have Category:Public domain in 2019, Category:Public domain in 2020, etc. Perhaps a bot could go through and tag all fair use images as Category:Public domain date not assessed and then if it's unknowable, we move it to Category:Public domain date unknowable, but otherwise put it in a correct yearly category. That will facilitate uploading or restoring high-res versions and retagging it as public domain once the respective date hits. --B (talk) 20:39, 11 December 2018 (UTC)

It doesn't sound too bad of an idea, but there are some questions on how far would the bot tag into the future. I would not want different categories for every single year, as that would be kind of unnecessary. Instead, the bot could do something like Category:Public domain by year/2020, like how many bots sort alphabetical lists. I would also appreciate some information on how you would plan on making the bot functional? Integral Python click here to argue with me 14:37, 12 December 2018 (UTC)
@IntegralPython: A human is going to have to review a lot of them, maybe even all of them. In the fullness of time, the various templates and the upload form could be modified to incorporate the necessary fields (publication year, publication country, author's death year) so that the templates can be self-tagging. For example, for File:HairyDawgSanfordStadium.jpg until Thomas Sapp (the guy who designed the mascot) dies, we have no idea when the copyright will expire. Or for File:Batman181.JPG, it doesn't give us the publication date in anything machine-readable (or the publication country for that matter), but a human can see that it was published in the US in 1966 and so the copyright will expire January 1, 2062. So for that case, if the upload form and templates allowed you to specify such things, the date could be calculated automatically. But for now, a first step is to create the categories and allow things to be moved there manually (with the goal that templates can automatically categorize images in some cases). --B (talk) 19:11, 12 December 2018 (UTC)
Commons does something like this. The "Undelete after" categories in c:Category:Undeletion requests span from 2019 to 2138‎. – Finnusertop (talkcontribs) 15:52, 14 December 2018 (UTC)

Proposal: Applying Value-Sensitive Algorithm Design to ORES

ORES has been out and served for the Wikipedia community for a while, for the purpose such as counter-vandalism. Having seen the wide usage and effectiveness of ORES in the community, we'd like to continue working on ORES development. We plan to improve and redesign ORES algorithms by incorporating feedbacks of all the stakeholders involved in the entire ORES ecosystem, such as ORES application developers, ORES application operators, etc. We want to understand their concerns and values, and come up with effective algorithmic designs that can balance trade-offs and mitigate potential conflicts of interests (such as edit quality control v.s. newcomer protection) to further improve ORES performance.

We will work with Aaron Halfaker (User:EpochFail) and his team to make improvements on ORES quality control models, and identify its limitations. Here is the project proposal on Meta-Wiki. If you are interested or have any thoughts, please feel free to reach out to me. Thanks! Bobo.03 (talk) 14:43, 13 December 2018 (UTC)

See mw:ORES for more information about ORES. In short, ORES is a machine learning platform that my team maintains. It helps with vandalism detection, new page patrolling, WikiProject task lists, and a few other types of Wiki work. --EpochFail (talkcontribs) 14:48, 13 December 2018 (UTC)

Accessibility of links in header at the administrators' noticeboard for incidents

I have started a discussion on the accessibility of the links in the header box labelled "Administrators' noticeboard/Incidents" at the top of the noticeboard. Feedback is welcome. isaacl (talk) 21:31, 13 December 2018 (UTC)

New UW template

This is my idea for a new user warning template under uw-selfarticle.

Concept

Information icon Hello, Village pump (proposals).It seems from your contributions that you are attempting to write an article about yourself. This will cause a conflict of interest (COI). Editors with a conflict of interest may be unduly influenced by their connection to the topic. See the conflict of interest guideline and FAQ for organizations for more information.


Also please note that editing for the purpose of advertising, publicising, or promoting anyone or anything is not permitted.

Any thoughts or should I just make this? [Username Needed] 14:14, 14 December 2018 (UTC)

Well, there's already Template:Uw-autobiography. This may be approaching the same issue simply from a different angle. DonIago (talk) 15:35, 14 December 2018 (UTC)
I was not aware of that template. [[[User:Username Needed|Username]] Needed] 10:02, 17 December 2018 (UTC)
While the autobiography template already exists, what would be nice is a template to tell people to stop inserting papers that they themselves have written as references. Natureium (talk) 19:39, 17 December 2018 (UTC)
{{uw-coi}} gets pretty close. --Izno (talk) 00:20, 18 December 2018 (UTC)

Any use for a "rare character" index?

Request for comment: Periodic table article as three-peat TFA

I've posted a request for comment—on whether our periodic table article could become a TFA for the third time—at the Wikipedia talk:Today's featured article page. Please post any feedback there. Sandbh (talk) 01:35, 16 December 2018 (UTC)

Closing Wikipedia for certain hours

I'm closing this down per WP:SNOW. It is eminently clear that this will not be done. Mz7 (talk) 22:59, 16 December 2018 (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.

I want to make a suggestion that Wikipedia only be open for non-admin editing M-F 6am-10PM UTC, Saturday and Sunday 8AM-4PM UTC. Except, weekend hours should apply on major holidays, Christmas Eve, and NEw Years Eve. The site should be locked from non-admin editing all day Easter Sunday, Thanksgiving Day, and Christmas Day. 2602:306:3357:BA0:E529:2E38:525C:E658 (talk) 22:50, 16 December 2018 (UTC)

Unfortunately, this probably won't happen (also, 12 am what time zone? UTC?) SemiHypercube 22:39, 16 December 2018 (UTC)
I want to make a further suggestion that Wikipedia only be open for non-admin editing M-F 6am-10PM UTC, Saturday and Sunday 8AM-4PM UTC. Except, weekend hours should apply on major holidays, Christmas Eve, and NEw Years Eve. The site should be locked from non-admin editing all day Easter Sunday in the US, Thanksgiving Day in the US, and Christmas Day.2602:306:3357:BA0:E529:2E38:525C:E658 (talk) 22:38, 16 December 2018 (UTC)
What are all of the wikipedians that don't celebrate Christmas going to do while they're bored because all the stores are closed? Natureium (talk) 22:45, 16 December 2018 (UTC)
Have you considered the time zone question? Otherwise, we can only assume you mean all time zones. Jack N. Stock (talk) 22:44, 16 December 2018 (UTC)
Not everyone observes Christmas, and Wikipedia has not burned to the ground despite accepting edits the last seventeen Christmases. Mz7 (talk) 22:45, 16 December 2018 (UTC)
And I assume the proposal would only lock WP for Thanksgiving in the US, of course. Jack N. Stock (talk) 22:46, 16 December 2018 (UTC)
Don’t worry IP, vandals are mostly kids who are bored at school. There’s little vandalism on public holidays. Adrian J. Hunter(talkcontribs) 22:48, 16 December 2018 (UTC)
UTC time zone would be used, and it would only be locked all day for Thanksgiving in the US, Christmas Day, and Easter Sunday in the US. 2602:306:3357:BA0:E529:2E38:525C:E658 (talk) 22:48, 16 December 2018 (UTC)
So block only US-based IP addresses (unless they are being used by admins) for Thanksgiving and Easter, but based on UTC time zone? My observation is that Easter is not a holiday in the US, it's basically just another Sunday, so why should this apply in the US? Jack N. Stock (talk) 22:52, 16 December 2018 (UTC)
Easter is a holiday in the US, and when wikipedia closes, it would be world-wide, not just the US. 2602:306:3357:BA0:E529:2E38:525C:E658 (talk) 22:53, 16 December 2018 (UTC)
Easter Sunday is not a federal or state holiday in the U.S. (especially since it falls on a Sunday) – it is a religious holiday observed by Christians worldwide. We have plenty of non-Christian/non-American users who do not observe Thanksgiving, Christmas, or Easter who would be happy to fill in for recent change patrolling on those days. Even on New Year's Day, we have plenty of users who would be happy to do recent change patrolling not because they feel any kind of obligation to do so, but because they want to. Mz7 (talk) 22:58, 16 December 2018 (UTC)
Leaving aside the time zone issue, for what reason does this need to be done? Also, many people work third shifts or other odd hours that this idea does not account for. 331dot (talk) 22:55, 16 December 2018 (UTC)
This needs to be done so the RC patrollers and admins don't get exhausted. 2602:306:3357:BA0:E529:2E38:525C:E658 (talk) 22:57, 16 December 2018 (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.

Can we have an AfroCine deletion sorting list?

If its not against any guideline, I think it will be a smart idea to have an Africa cinema AFD list. I think this will increase participation of Wikipedians in AFDs, especially for African countries that do not have an active on-wiki WikiProject. Another thing is that aside few AfroCine countries, the cinema industry are similar in terms of their online coverage. What I mean is that we should have something like Wikipedia:WikiProject Deletion sorting/AfroCine, where topics related to African cinema should be listed. Pinging the initiator of AfroCine for if he has inputs cc @Jamie Tubers: HandsomeBoy (talk) 09:47, 17 December 2018 (UTC)

  • I totally agree with you regarding this! It's something I intended to bring up in the long run....so nice that you've brought it up now.--Jamie Tubers (talk) 19:37, 17 December 2018 (UTC)

Wikipedia interaction redesign

This is the Wikipedia minor UI & UX redesign with boosting user interaction and usability. Please check out the below GIF animations.

Nomadash (talk) 10:51, 17 December 2018 (UTC)

You view the complete post on my Dribble account: https://dribbble.com/shots/5603289-Wikipedia-Redesign/ [1]

References

  1. ^ https://dribbble.com/shots/5603289-Wikipedia-Redesign/
You know what would be really useful? The ability to turn off the sidebar on the left. If it could turn into a "sidebar" tab so that clicking the tab brings it back, that would be icing on the cake. --Guy Macon (talk) 13:13, 17 December 2018 (UTC)
T163098 may also be of relevance to this issue. --Xover (talk) 13:32, 17 December 2018 (UTC)

"Datebot" (limited scope)

This is a proposal to increase date consistency in citations, per MOS:DATEUNIFY. Specifically, a bot would look for templates like

and bring present dates in line with desired usage on that specific article. I would make a WP:BOTREQ for this, but I'd rather go in with a consensus that this is desired, and what scope is OK with the community. Note that the below is just the general idea/goal, there will be odd cases and kinks that need to be ironed out. That's what the bot trial would help with. If nothing reliable can be made, then the bot wouldn't get approved.

Option A: extreme conservativeness

Under this option (if option B is not accepted), the bot would not touch dates elsewhere in the article, quotes, or mess with valid format (21 Jan 2009 → 21 January 2009), it would simply those in |date=/|access-date=/similar parameters of the various {{cite xxx}} templates. For example, if {{Use dmy dates}} is used in an article, then the bot would convert

  • Smith, J. (2006). "Article of things, part 1". Journal of Things. 1 (2): 3–4. Retrieved March 10, 2009.
  • Smith, J. (March 23, 2007). "Article of things, part 2". Journal of Things. 2 (2): 3–4. Retrieved March 10, 2009.
  • Smith, J. (2008). "Article of things, part 3". Journal of Things. 3 (2): 3–4. Retrieved 2009-10-29.
  • Smith, J. (Jan 21, 2009). "Article of things, part 4". Journal of Things. 4 (2): 3–4. Retrieved March 29, 2017.

to

  • Smith, J. (2006). "Article of things, part 1". Journal of Things. 1 (2): 3–4. Retrieved 10 March 2009.
  • Smith, J. (23 March 2007). "Article of things, part 2". Journal of Things. 2 (2): 3–4. Retrieved 10 March 2009.
  • Smith, J. (2008). "Article of things, part 3". Journal of Things. 3 (2): 3–4. Retrieved 2009-10-29.
  • Smith, J. (21 Jan 2009). "Article of things, part 4". Journal of Things. 4 (2): 3–4. Retrieved 29 March 2017.

and if {{Use mdy dates}} is used, then it would convert to

  • Smith, J. (2006). "Article of things, part 1". Journal of Things. 1 (2): 3–4. Retrieved March 10, 2009.
  • Smith, J. (March 23, 2007). "Article of things, part 2". Journal of Things. 2 (2): 3–4. Retrieved March 10, 2009.
  • Smith, J. (2008). "Article of things, part 3". Journal of Things. 3 (2): 3–4. Retrieved 2009-10-29.
  • Smith, J. (Jan 21, 2009). "Article of things, part 4". Journal of Things. 4 (2): 3–4. Retrieved March 29, 2017.

If no {{Use mdy dates}}/{{Use dmy dates}} is found, the bot would do nothing.

Option B: enforce majority use

In addition to the above, the bot could also determine the majority use and further normalize the article. For instance, if 23 citation used something like |date=21 January 2009 /|access-date=25 February 2011, 2 citation used |date=21 Jan 2009, and 3 citations used |access-date=2013-02-25, then it would bring the minority cases in line with the majority. For example the above would be normalize to

  • Smith, J. (2006). "Article of things, part 1". Journal of Things. 1 (2): 3–4. Retrieved 10 March 2009.
  • Smith, J. (23 March 2007). "Article of things, part 2". Journal of Things. 2 (2): 3–4. Retrieved 10 March 2009.
  • Smith, J. (2008). "Article of things, part 3". Journal of Things. 3 (2): 3–4. Retrieved 29 October 2009.
  • Smith, J. (21 January 2009). "Article of things, part 4". Journal of Things. 4 (2): 3–4. Retrieved 29 March 2017.

Ties would result in no action since the bot could not determine which variant is preferred.

Option C: Status quo

Leave the mess to be dealt with by humans.

!Vote (Datebot)

  • Support both A and B as proposer. Headbomb {t · c · p · b} 21:25, 17 December 2018 (UTC)
  • Support both A and B - good idea. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:01, 17 December 2018 (UTC)
  • Support both A and B – sounds like a good idea, little potential to go horribly wrong, hopefully "Datebot" would not be confused too often with DatBot. SemiHypercube 22:10, 17 December 2018 (UTC)
  • C at least until questions below are gone through. — xaosflux Talk 03:29, 18 December 2018 (UTC)

Discussion (Datebot)

The description seems deficient. For option A, for the first list of changes, there is no indication whether one of the use xxx dates template is present. I oppose option B because the bot could encounter the article at a moment when it does not reflect the long-standing consensus. Also, it would be inappropriate to have different criteria for bot edits than for manual edits; if a bot were allowed to change on the basis of the majority of the dates in citations, it would be OK for manual edits too. But currently it not OK for manual edits. Jc3s5h (talk) 21:54, 17 December 2018 (UTC)

Jc3s5h (talk · contribs) I clarified a few things. Some words were missing. Also, it is not only ok, but encouraged for humans to do those sort of changes. Headbomb {t · c · p · b} 21:58, 17 December 2018 (UTC)
The expectations in MOS:DATEUNIFY would indicate an editor should not change an access-date from 2008-11-18 to November 18, 2008 just because the majority of all citation-related dates was mdy, so long as all or nearly all access-dates used the YYYY-MM-DD format. Also, if the article almost exclusively used mdy in the article overall, because most of the citations only gave a year, just counting a handful of citations that did give a month, date, and year could easily give a false result. Jc3s5h (talk) 22:21, 17 December 2018 (UTC)
If the citations don't match the body of the article, then the body didn't really make the article worse than it was before, since it was already inconsistent. If it normalized the citations the 'wrong way', just slap either {{Use dmy dates}} or {{Use mdy dates}} on it and you'll ensure the long-term stability of the article dates. Headbomb {t · c · p · b} 03:48, 18 December 2018 (UTC)
We have had a recent discussion which rejected the expectation that the access date be in the same format as any other dates (only that the access dates be unified among themselves was a consensus there). That's this discussion, which, probably should have been closed as "consensus against" the proposal rather than the "no consensus" close by Compassionate. --Izno (talk) 00:25, 18 December 2018 (UTC)
Uggh is this really a mess that needs to be dealt with at all? Citation parameters aren't "prose" they are "data" - they should just be in ISO format. Can you show some good examples of versions of an article that have this "problem"? — xaosflux Talk 03:30, 18 December 2018 (UTC)
ISO/YYYY-MM-DD are relatively rare in dates save for accessdates. But for a good example, see Cancer, with several inconsistent dates the bot could fix. Headbomb {t · c · p · b} 03:51, 18 December 2018 (UTC)
@Headbomb: OK, so in Cancer we have:
A few examples
Bast RC, Croe CM, Hait WN, Hong WK, Kufe DW, Piccart-Gebhart M, Pollock RE, Weichselbaum RR, Yang H, Holland JF (3 October 2016). Holland-Frei Cancer Medicine. Wiley. ISBN 978-1-118-93469-2.

Kleinsmith LJ (2006). Principles of cancer biology. Pearson Benjamin Cummings. ISBN 978-0-8053-4003-7.

Mukherjee, Siddhartha (16 November 2010). The Emperor of All Maladies: A Biography of Cancer. Simon & Schuster. ISBN 978-1-4391-0795-9. Retrieved August 7, 2013.

Pazdur R, Camphausen KA, Wagman LD, Hoskins WJ (May 2009). Cancer Management: A Multidisciplinary Approach. Cmp United Business Media. ISBN 978-1-891483-62-2. Cancer at Google Books. Archived from the original on 15 May 2009.

Tannock I (2005). The basic science of oncology. McGraw-Hill Professional. ISBN 978-0-07-138774-3.

Schwab M (23 September 2008). Encyclopedia of Cancer. Springer Science & Business Media. ISBN 978-3-540-36847-2.
What will be changed there - the access date in #3? — xaosflux Talk 04:10, 18 December 2018 (UTC)
@Xaosflux: diff. Headbomb {t · c · p · b} 04:39, 18 December 2018 (UTC)
@Headbomb: thanks for the example, any idea what sort of volume you are trying to address? I'm only seeing this minimally beneficial to readers, with month names already spelled out it isn't fixing any ambiguity. — xaosflux Talk 14:13, 18 December 2018 (UTC)
@Xaosflux: honestly it's pretty hard to gauge. I'd guess that in the ballpark of 10% of articles have date inconsistancies, but I don't know how much of that could be fixed by bot before things are trialled.Headbomb {t · c · p · b} 16:25, 18 December 2018 (UTC)

"Editnotice manager" user right

I propose a new right the sole ability to edit editnotices. Currently this is appended onto filemover, and I find this a bit odd that you would have to request a completely different user right to get the ability to edit editnotices. Surely it would be useful to have a right that simply allows editing of editnotices and nothing else. — Preceding unsigned comment added by Username Needed (talkcontribs) 10:14, 18 December 2018 (UTC)

Filemovers have it as a byproduct of the (very) recent addition to override the title blacklist; previously, only template editors had the ability, which makes sense. Don't see a need. ~ Amory (utc) 11:59, 18 December 2018 (UTC)
Page movers can override the title blacklist. File movers can't. (see Special:ListGroupRights) Galobtter (pingó mió) 12:52, 18 December 2018 (UTC)
  • What about editors who need to add editnotices regularly but won't pass an RfA [Username Needed] 12:50, 18 December 2018 (UTC)
    Both page movers and template editors have this access already, and there is generally no backlog on edit requests in this area. — xaosflux Talk 14:17, 18 December 2018 (UTC)
Nope. A solution in search of a problem. WBGconverse 15:30, 18 December 2018 (UTC)

"Watch this page" should be the default behavior when editing

the proposal

Let's say I edit a wikipedia page. A few month later, somebody modifies my version (not using "undo", just overwriting what I've done). By default, there will be no alert about this. The basic setting should be to alert you, that's it to have the checkbox "Watch this page" checked by default each time you edit a page.

the cons

"Power" editors, editing thousand of pages, would of course get a lot of notifications. But firstly it's not sure that it's unpractical for every power editor and secondly this kind of editors knows how to find their way to disable this option globally (by Preferences>Watchlist>Add pages and files I edit to my watchlist). This option is a bit buried in the options so most users will probably never use this option it but that's probably not the case for "power" editors.

the pros
  • It's Counterintuitive

That's what you'll find on most internet boards, blog comment sections and I guess that's the expecting behavior for any user on this kind of sites. You don't have to rummage through the settings to find the option to get notified.

  • It's Harmful

It's harmful because it misses the opportunity to encourage "not regular editors" to become regular editors. I guess people editing page quite rarely will completely forget their modification. If they're not alerted for further modifications, most will probably never know that and never come back on the page.

Linuxo (talk) 12:14, 18 December 2018 (UTC)

Thanks for the suggestion, but I don't think it is needed. Some pages I edit, I check the little blue star and others I don't. You soon get into the habit. When your edit count grows you will no longer remember what you add to individual pages and you will learn to trust others to be sensible. There may be corners of WP where I don't tread where this is different- if you are working there check the star. ClemRutter (talk) 12:31, 18 December 2018 (UTC)

"remind me" bot

Overview

Former discussion: Wikipedia:Bot_requests#Remind_me_bot.

The idea is to create a bot/template pair that sends on request a reminder to go back to a particular page. The case use is typically to check back on a discussion on high-traffic pages where a watchlist is inefficient or (on the contrary) when the discussion has very little participation and you want to make sure to come back one week afterwards to assess consensus.

As the reminder would likely take the form of an in-wp post, such a bot needs consensus per WP:BRFA. I believe VPP to be the best (or least worse) forum for that discussion, but do tell if I missed something obvious.

Envisaged technical implementation

A template (e.g. {{remind me}}) that takes one argument, either a fixed date or a duration of time, is left by a user on the page they wish to be reminded of. Template transclusions are watched by a Toolforge bot (running every hour or so?). When the time is up, the bot posts a notification to the requesting user's talk page.

Asking for a notification by this process is public (i.e. other editors know that you asked for an update, when you asked for it etc.).

Depending on the technical details, and if that template gets widespread use, it might become necessary to put limits on the use. I would suggest no more than X pending notifications per user (so that you can put hanging notifications for Christmas 2118 but it eats up one of your slots); I think X=10 is a reasonable starting value if it comes to that, but I do not think it is needed outright.

Possible objections

  1. While the bot postings themselves are fairly innocuous (you get 'em only if you ask for 'em), there could still be some clutter in the reminder request templates: e.g. if 100 posters drop just a "remind me" template in a discussion where 5 people are actually participating. I believe (1) that is quite speculative and (2) if it ever becomes a problem, it might be solved by conduct guidelines (e.g. "avoid using this template outside an overwise meaningful post, as this can be considered disruptive").
  2. As pointed in the previous discussion, that might duplicate a Community Wishlist item that was among the top 10 (and hence will be worked on by WMF staff). I believe the use case is slightly different (that one is targeted at talk pages, as opposed to articles), and even if it is indeed redundant, I do not see the harm. (As I will be the one handling the bot coding, time wasted duplicating a system can be ignored: I think it would be fun to code. The only question is whether having two systems might be harmful, not useless.)

Comments

I have a better design.

Make a bot that you place on your own talk page (or on a special page if that makes the bot easier to write) with the same fixed date / duration of time arguments.

If I put

 {{remindme|03:14, 19 January 2038 (UTC)|Check [[Talk:Cockcroft–Walton generator]] for replies}}

on the appropriate page It would wait until January of 2038 and then post the following to my talk page:

Remindme bot reminder notice
On 00:00 1 January, 1970 03:14 (UTC), you requested a 03:14, 19 January 2038 (UTC) reminder. The text of the reminder is:
Check Talk:Cockcroft–Walton generator for replies
-- [Bot signature]

That way you could be reminded of anything. I have a similar reminder set locally that I use to remind me to check the edit history of blocked IP vandals a week after the block expires. That way I can report them if they go right back to vandalizing.

To reduce abuse:

The reminder should happen even if some vandal deletes the request.

There should be a way to cancel a reminder.

Users or admins should be able to cancel reminders for that user.

Reminders should be limited to 255 characters.

Users should be limited to no more than 32 open reminder requests.

A FAQ should explain that this is for Wikipedia-related use only; no "don't forget to buy more Vegemite" reminder requests.

If possible, it should be impossible or at least difficult to set a reminder to be shown on someone else's talk page.

--Guy Macon (talk) 14:06, 18 December 2018 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=874334254"
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