Wikipedia:Village pump (idea lab)

There is currently a proposal on Phabricator to add a new feature to MediaWiki where one could link to a specific part of an article's content. When someone visits this special link, they would be scrolled down to the relevant part of the content and possibly, the specific portion would be highlighted.

Before we get started with work on this, we wanted to know if this would be useful at all or whether it would help in any way. Comments? — Preceding unsigned comment added by Vghaisas (talk • contribs) 19:04, 19 February 2015 (UTC)[reply]

I don't think this would be significantly useful, as we already can create links to any kind of section header, footnote anchor, etc. If a section is too long for such a link to be useful, it's a sign that the section should be split, not that a new kind of link is needed. It would actually be unhelpful, I'm sorry to say, because it creates yet another feature for new users to have to learn, making Wikipedia editing appear even more complicated than it already is. – Philosopher ^{Let us reason together.} 18:59, 20 February 2015 (UTC)[reply]

The proposed feature isn't really meant for editors. It's a feature that will let readers link to arbitrary portions of the content. So it won't add any complexity to the work of editors.

However, I do agree with the other objection you raised. Sections shouldn't be so long that parts of them need to be linked to. However, how many pages match that objective? If there are still enough pages whose sections are long, would it not help readers to be able to link to specific portions of the content? — Preceding unsigned comment added by Vghaisas (talk • contribs) 19:04, 19 February 2015 (UTC)[reply]

"will let readers link to" - and creating a link is an article is editing. The use of these links in articles will be inevitable (unless prohibited by a filter) and would complicate the code, confusing new editors.

As for the section length, Wikipedia is not finished. That we don't yet meet an ideal doesn't mean that we should create a tool, but that we should strive to meet the ideal. – Philosopher ^{Let us reason together.} 00:37, 24 February 2015 (UTC)[reply]

I'm not sure we're on the same page here. The feature I'm talking about will provide an interface to let a random reader of Wikipedia select an arbitrary portion of the content of an article and generate a link to that selected content. To give a crude example, I could choose to link to the words "Predominantly nocturnal" in the second paragraph of European Wildcat , which could result in a link like (completely random example) https://en.wikipedia.org/wiki/European_wildcat?specific=p2w2. When someone visits that link, they will be scrolled down to that section and the two words will be highlighted. This will not involve making any changes to wiki markup.

Were you, though, referring to the fact that then links like https://en.wikipedia.org/wiki/European_wildcat?specific=p2w2 would be used in articles for inter-article linking? — Vghaisas (talk) 12:35, 25 February 2015 (UTC)[reply]

You mean something like the way Google does it with books, like this? Squinge (talk) 13:22, 25 February 2015 (UTC)[reply]

Yes, exactly. Thank you for that example. Something similar to that. Vghaisas (talk) 13:28, 25 February 2015 (UTC)[reply]

@Vghaisas: Yes, hat was exactly my concern. – Philosopher ^{Let us reason together.} 00:26, 27 February 2015 (UTC)[reply]

Philosopher: So, your opinion is that the availability of such links will lead to an extra complication in editing of articles and hence, is not a good idea? — Vghaisas (talk) 02:33, 27 February 2015 (UTC)[reply]

Yes, that is my primary concern. If there was some compelling reason that we needed such links, it could overcome it, but as I noted above, section headers are more than sufficient for linking to specific areas of the content - our sections are significantly shorter than most Google Books! and should never be so long that it's hard to find specific content within them - so there is no such need. – Philosopher ^{Let us reason together.} 02:39, 27 February 2015 (UTC)[reply]

Vghaisas, what would happen to your link when someone removes those words from the article? Text changes more often than section headings. Or what happens when someone adds multiple copies of those words, and I meant to highlight the third instance? WhatamIdoing (talk) 00:36, 27 February 2015 (UTC)[reply]

WhatamIdoing: The example I gave of ?specific=p2w2 was very random. The challenge is developing a method that can account for changes in text, possibly by using identifiers that do not depend on how many times the words appear in the article. In addition, if the given text gets deleted, there is the option of looking at the history of pages. The basic question is, is it a good enough idea to try and attempt this at all or is there something which makes it too bad an idea to even give it a try. — Vghaisas (talk) 02:33, 27 February 2015 (UTC)[reply]

Interesting idea. Definitely more of a reader-focused feature. Not an easy problem. Throwing anchors everywhere in the wikitext is not really an option.

I think direct-linking-to-Wikipedia-sentence is interesting for Wikipedia readers: "Fact checking to resolve disagreements" is one of our biggest use cases. :-) Giving a direct link to the Wikipedia sentence and say "See i told you so" and "Wikipedia agrees with ME, see" or "You were right, according to the Wikipedia article" etc. The Wikipedia mobile app for android wants to experiment with a feature "Tweet a fact" (Example tweet), which turns the highlighted sentence in a picture (afaics). A bit, ehm, indirect for linking... I'd be interested how this sentence-level-linking could be done differently! :-) --Atlasowa (talk) 13:50, 27 February 2015 (UTC)[reply]

More tweets! Looks really good, except for the CC-BY-SA image attributions... Ping User:DarTar? --Atlasowa (talk) 22:11, 5 March 2015 (UTC)[reply]

@Atlasowa: Thanks for the interest! I've been working very closely with the Legal Team to make sure that the attribution in these images is appropriate. We have signoff from Legal for the present state that this feature is in, so we're good for now. --Dan Garry, Wikimedia Foundation (talk) 01:25, 7 March 2015 (UTC)[reply]

Dan Garry, i'm curious: There is no attribution to the photographer (CC BY 3.0 Biso, File:Fender_bw.jpg), not even a link to the image file, how did you get "signoff from Legal" for that? And on the other hand "Wikipedia®" gets a Registered trademark symbol? Really strange. Can you provide a link to this signoff/decision?

BTW, what happened to the GDFL licence in the app, how can that disappear (only CC-BY-SA, compare with licences in desktop/mobile Wikipedia edit window)? --Atlasowa (talk) 15:45, 11 March 2015 (UTC)[reply]

I am not a lawyer so am not qualified to answer your questions. These would be good questions to direct to Stephen LaPorte, the Legal Team's liaison to Product and Engineering. --Dan Garry, Wikimedia Foundation (talk) 16:21, 11 March 2015 (UTC)[reply]

Hi Atlasowa, the icons in the interface reflect the license for the text of Wikipedia articles, which may also contain media with other compatible free licenses (or public domain content). The limited amount of space in the card is our biggest design constraint. The icons provide a reasonable amount of information about the license for the card, and they communicate that it can be shared and remixed. If users wish to get the full licensing details for content, they can follow the URL that the app generates with the card. Thanks, Stephen LaPorte (WMF) (talk) 19:59, 12 March 2015 (UTC)[reply]

Linking to text in a specific revision wouldn't have any of those complications and shouldn't be to hard to do, and still useful. Oiyarbepsy (talk) 03:26, 7 March 2015 (UTC)[reply]

Oiyarbepsy, how would you do it? --Atlasowa (talk) 15:46, 11 March 2015 (UTC)[reply]

Atlasowa Well, once Mediawiki does it, it would be like en.wikipedia/wiki/ArticleName&oldid=1234567&starthighlight=78&endhighlight=85, where oldid is the specific revision, starthighlight is the character to start highlighting on and endhighlight is the character to end it on. The challenge is creating some kind of interface that makes it easy to create such a url, since without it, this would be exceedingly difficult to do. Perhaps a feature where you could select text, right-click it, choose "create link with this text highlighted" and the Mediawiki software would create the URL, with oldid and everything. Oiyarbepsy (talk) 20:10, 11 March 2015 (UTC)[reply]

Oiyarbepsy, fair point. With the revision id also included in the URL, most of the issues raised earlier aren't relevant any more. We, would, however, need to ensure that the page clearly states that "the updated version of this page exists elsewhere and may have been edited in the meantime" or something like that. In any case, you think it would be a useful feature to have? — Vghaisas (talk) 16:42, 26 March 2015 (UTC)[reply]

I remember when I had just joined Wikipedia a little over a year ago. I remember feeling really confused and wondering where I should look for information on policy, guidelines, and rules. I have spent the last year learning about these policies, guidelines, and rules, yet I am still learning new policies every day. Part of this is because there is no central collection of policies guidelines, and rules.

My proposal is to start the equivalent of the US Code and United States Reports for the English Wikipedia and if successful for the Wikimedia community at large. The Wikipedia Code (as I am calling it) shall follow the following guidelines:

1. Policies, guidelines, and rules contained in the code shall have reached consensus or for other reasons be enforceable.
2. Notable discussions shall be included to give context and usage to policies, guidelines, and rules. However, when consensus has not been reached in a discussion that shall be made clear.
3. Notable decisions by committees on cases shall be included to give context.

What do you think? StudiesWorld (talk) 19:59, 20 February 2015 (UTC)[reply]

The problem is that we don't have a "code" as is understood in government. All of our pages have exceptions, and all can be ignored if it clearly improves the encyclopedia. That said, provide more history and background to our policies and guidelines is a good idea. Oiyarbepsy (talk) 20:04, 20 February 2015 (UTC)[reply]

A list of everything would be, quite frankly, impossible, though Category:Wikipedia policies and guidelines tries. A full list would also be impossible to ever read - for that matter, it may just be impossible to read the entire Manual of Style! There are useful summaries at Wikipedia:List of policies and guidelines and the Wikipedia:Simplified ruleset. The useful templates {{Wikipedia principles}}, {{Wikipedia policies and guidelines}}, and {{Policy list}} are on both of those pages as well, and serve as a useful index. Do any of these serve the purpose you want, or is there something particular that is still missing? – Philosopher ^{Let us reason together.} 22:17, 20 February 2015 (UTC)[reply]

@Oiyarbepsy: By "code" I mean solely in the sense of an organized structure. It would also include explanatory text to take in to account the exceptions and notices explaining how rules can be ignored.

@Philosopher: I understand what you are saying but this would aim to be an all inclusive guide. Also, it would not be intended to be read in full but as a resource and reference.

Would you like me to make a draft in my userspace and move this discussion there? StudiesWorld (talk) 22:52, 20 February 2015 (UTC)[reply]

If you like. @StudiesWorld: - just be sure to ping me again when it's done! – Philosopher ^{Let us reason together.} 01:34, 21 February 2015 (UTC)[reply]

In case you hadn't seen it, Cinderella157 brought up something similar (but not, I think, the same) at WP:VPR#Suggested improvement for accessibility by editors. – Philosopher ^{Let us reason together.} 01:38, 21 February 2015 (UTC)[reply]

@Philosopher: I skimmed through Cinderella157's proposal and I noticed the community portal. I think that if this idea ever comes about it should be integrated with the community portal. Also, I will try and throw together a draft over the next few days. StudiesWorld (talk) 11:07, 21 February 2015 (UTC)[reply]

UPDATE: I started the Wikipedia Code at User:StudiesWorld/Wikipedia Code. StudiesWorld (talk) 11:57, 21 February 2015 (UTC)[reply]

I am sympathetic to this problem—I remember spending a lot of time immediately after I joined simply reading help and Wikipedia pages and getting attenuated to the sheer mass of all of the policies. However I suggest you formalize some sort of list for discussion before putting it for comment, and then look for refinements from there. ResMar 04:18, 23 February 2015 (UTC)[reply]

@Resident Mario: I am working on a example to use in further discussion. StudiesWorld (talk) 11:43, 24 February 2015 (UTC)[reply]

The Five pillars are a starting point. The other two Very Important Documents would be AGF and the MoS. Whatever you do, though, definitely emphasize AGF and CIVIL. Eman235/talk 01:41, 9 March 2015 (UTC)[reply]

Oh man, just found this! Template:Wikipedia principles Eman235/talk 01:42, 9 March 2015 (UTC)[reply]

Start it up in user space. Grognard Chess (talk) Ping when replying 00:46, 12 March 2015 (UTC)[reply]

The Original Poster has suggested that a code, in the legal sense, be developed. I would be very interested in seeing a framework or draft in user space for the code, which could consist of pointers to existing policies, or could actually work the policies together. The main criticism that I have seen is actually an argument in favor, which is that every policy has exceptions. In a legal code, the exceptions are also codified as exceptions. It is also stated that there is too much to codify. That is also an argument in favor of codification. Has anyone actually seen the entire United States Code, which took my grandfather at least ten years to codify and which occupies a whole shelf in bound form (which is seldom used anymore because it is now on-line)? The large number of disjointed policies and guidelines are an argument in favor of codification in some form, probably an index with pointers to the multiple policies and guidelines. The one problem that I see is the concept of Ignore All Rules, which does not really mean what it appears to mean anyway, but means to use common sense when the rules are too restrictive. Its problem is that it is sometimes cited by editors who don't have common sense. (Fortunately, most administrators do have common sense, and the RFA process usually gets editors who have common sense.) Some sort of a code framework seems to me to be an excellent idea, at least as a draft. Robert McClenon (talk) 16:09, 9 March 2015 (UTC)[reply]

Don't copy any categories that are reserved for Wikipedia space into user space (such as the Wikipedia content policies category). - Dank (push to talk) 20:05, 25 March 2015 (UTC)[reply]

Of all the CSDs I've seen contested the number of times I've seen it done right is a fairly low percentage, even for reasonably experienced editors. I think we need clearer, simpler and less error-prone text offered to the editors contesting CSDs. Bazj (talk) 22:07, 20 February 2015 (UTC)[reply]

@Bazj: It's simply a matter of removing the speedy delete tag, saying why in the edit summary, and optionally posting on the nominator's user talk page, right? What so you see being done wrong? Or are you talking about page authors contesting tags? Oiyarbepsy (talk) 20:17, 11 March 2015 (UTC)[reply]

Basically, there is one way for the author of the article to contest deletion - click the button on the template and give a reason on the talk page. Yes, some do copy the warning notice they received onto the article talk page, and some for some totally mysterious reason copy it onto the article page. You can never eradicate oddities like these. As to anyone else, if inexperienced in editing, they can do the same - click the button. If more experienced, they can detag and say why. Things that puzzle me are, first, why do some apparently new authors use the 'hangon' template which I don't think is anywhere to be seen in the template? And second, why do some, whose article is very clearly up for deletion on grounds of significance, make a great play of showing that it isn't a copyvio (and similar strange confusions)? Peridon (talk) 19:25, 12 March 2015 (UTC)[reply]

What about modifying the templates? Some templates work where it takes you to an edit screen with all the required information pre-filled. So, when clicking on the contest button for the a7 tag, the edit screen could be pre-filled with something like this:

<!-- Please explain why this topic is significant. The best way to do this is to show us a reliable source that isn't connected with the subject of the article.
Don't tell us that the article is correct - we're not saying that it's wrong, but that it doesn't meet our inclusion criteria.
Please explain why the article shouldn't be deleted below this line. -->

<!-- Please only type above this line. --> ~~~~

This should help new editors know what to do, and also ensures that the message is signed. Each criteria would need a different pre-filled message. Oiyarbepsy (talk) 20:16, 12 March 2015 (UTC)[reply]

@Oiyarbepsy: That is easy to do, seems like a good idea and I think you should be bold. Just in case you would not know where to find them, all of the relevant templates are at the name form Template:Hangon preload XX, with XX replaced by the letter/number combination of the criterion, i.e., A7's is at {{Hangon preload A7}} and so on. Regarding signing, it's already included in them. However, just note we had a problem back at the beginning when we implemented the contest button with commented out text – users were placing their protests inside those tags hiding their CSD contest basis resulting in this edit, but I don't think the same commented out tags issue will arise with any instructions set off above with a few lines skipped. Please note a secondary reason for providing the diff in the last sentence. It shows you the coding gyrations you must go through to place the commented out notes, so they pass through to the pages from the template (i.e.., you can't just use <!-- TEXT -->) --Fuhghettaboutit (talk) 04:15, 17 March 2015 (UTC)[reply]

• The author of a page isn't allowed to remove speedy deletion tags. Stifle (talk) 15:29, 19 March 2015 (UTC)[reply]

Hello everyone!

I'd like to share something I've been hacking on in the past few days. It's a simple tool for exploring articles with unsourced statements, currently hosted at https://citationhunt.herokuapp.com. The full code can be found at https://github.com/guilherme-pg/citationhunt. I mostly built this to explore a few technologies I wasn't too familiar with, but I hope it could be useful to the community: it seems to me that adding citations where they're needed could be a good entry point for new editors, so I tried to make that a little easier. There's lots of room for improvement, of course, but I would love to hear any feedback you might have, and I'm definitely willing to work on making this better suited for real-world usage if the idea is any good.

Thanks, and apologies if this is the wrong place to share this. -- Surlycyborg (talk) 22:36, 26 February 2015 (UTC)[reply]

This is pretty cool. One thing that would be useful to implement is stopping the tool flagging lead sections when there are other sections in the article. Lead sections don't need to be referenced if the information is sourced elsewhere in the article but the site showed me a number of sentences from article's leads. Sam Walton (talk) 23:30, 26 February 2015 (UTC)[reply]

Thanks for the suggestion! If I understand it correctly, it looks like citation needed templates should generally be removed from lead sections, right? If that's the case, then perhaps we do want to flag them, except the site could suggest removing the templates instead of adding a reference? I've filed an issue on the project so I don't forget about this. – surlycyborg (talk) 13:19, 27 February 2015 (UTC)[reply]

It's more complicated than that, unfortunately. I think you might want to look at WP:MINREF for a list of What Must Be Cited in a quick cheatsheet format. Then, if you haven't found WP:CITELEAD yet, that would be your next stop. Things like direct quotations and contentious matter about BLPs need to be cited in the lead, but for most other things, it's optional (assuming that a citation exists later on the page). WhatamIdoing (talk) 19:24, 2 March 2015 (UTC)[reply]

I see, thanks for the links! I'm still inclined to keep lead sections on the site, but with a concise note somewhere summarizing the rules – in fact, your last sentence does a great job at that! –, and links to WP:MINREF and WP:CITELEAD for further reading. Does that make sense, or do you think omitting them would be more productive (that is, if, even with these hints, newcomers are still likely to get it wrong, then perhaps they should be omitted)? surlycyborg (talk) 18:45, 4 March 2015 (UTC)[reply]

I added a short message linking to WP:CITELEAD, which seems to contain the most relevant information here. For example, here's a page in which it appears: https://tools.wmflabs.org/citationhunt/?id=01156c31&cat=all. -- surlycyborg (talk) 11:28, 17 March 2015 (UTC)[reply]

Hi Surlycyborg, that is awesome! Love it. Excellent minimalism in design. Simple and beautiful.

Your tool makes me almost wish for the [citation needed] template in German WP (we deleted this pest years ago ;-) Well, we have instead the big de:Vorlage:Belege_fehlen, 26.228 inclusions...)

I added your tool to my collection de:Benutzer:Atlasowa/ref citation tools, but it is very different, new and unique. Excellent work, Surlycyborg! --Atlasowa (talk) 21:44, 5 March 2015 (UTC)[reply]

Thank you very much, your comment made my day! Please feel free to file issues on the project page if you have any thoughts on how it could be better. surlycyborg (talk) 23:13, 5 March 2015 (UTC)[reply]

Hi Surlycyborg, could you upload a screenshot to commons? I'd like to show your tool for example to people at wikidata, who are trying to build a Primary sources tool (d:Wikidata talk:Primary sources tool), and elsewhere. I like the playfulness and concision of the tool. There have been some discussions about that kind of features (sometimes called "microcontributions" or "gamification", not the best words: it's more than micro and more than a game). We need that kind of stuff for Wikipedia. Not just for Wikidata as in Magnus wikidata-game and meta:Research:WikiGrok. And this Wiki Quiz (Wikipedia Powered) for example only works the other way around (not producing refs).

I'm starting to dream of integrating your tool with other tools. :-) For example with finding good sources from a kind of "white lists" (i'm simplifying, it's a more ambitious idea: meta:Grants:IEG/find sources 2.0). And with a tool to make ref-generation easier: Citoid. And with tools to detect copyright violations (de:user:Atlasowa/copyvio tools). etc. :-)

Anyway, a free-licence screenshot would be great! Oh, and the filtering by category is really smart and useful. --Atlasowa (talk) 11:06, 6 March 2015 (UTC)[reply]

Sure, here you go: https://commons.wikimedia.org/wiki/File:CitationHunt.png. Let me know if you need any more. Thanks for your interest in this, Atlasowa! -- surlycyborg (talk) 12:36, 6 March 2015 (UTC)[reply]

@Surlycyborg: It seems that this is a focusing application which (in principle if not practice) encapsulates and enhances the existing Special:WhatLinksHere/Template:Citation_needed. My thinking is that people looking for citation needed tags to apply effort against could be directed to either this focus app or to the whatlinkshere pages, and it would be useful in the documentation text for the application to indicate the alternative, non-wrapped approach. --User:Ceyockey (talk to me) 12:51, 6 March 2015 (UTC)[reply]

Good thinking, Ceyockey. Another approach would be to take CitationHunts filtering by category and turn it around: Every category could have a link to CitationHunt only in this category. For example Category:Comics characters would have a template:

• "1467 articles need citations in this category and subcategories! Go on CitationHunt in this topic!"

I think that would be nice to present CitationHunt with a topical interest link. But integrating/transcluding an external link into category pages like that is probably a problem (privacy, IP etc). If the tool would run on https://tools.wmflabs.org it would be no problem. Surlycyborg et all, other opinions or ideas? --Atlasowa (talk) 15:19, 11 March 2015 (UTC)[reply]

Before anything else, apologies for not replying this idea before, I've been a bit too busy these past few days. I think that the list of all articles needing citations is definitely something that would interest CH users, but I think we can provide a richer experience than just linking to it. For example, it would be nice (and not hard to implement) if it were possible to search and filter by article names from CH itself, as we currently do with categories. But yes, linking is the very least we can do, and could be a good start.

As for Atlasowa's idea, I think that sounds really great, and I'd love to see that happen. Zhaofeng Li and I have already discussed a bit the possiblity of moving CH to Tool Labs and I see no reason not to. I'll find some time later this week(end) to see what it would take to move CH there, even if keeping the static database for now instead of using queries against the live database. -- surlycyborg (talk) 16:29, 11 March 2015 (UTC)[reply]

I've just licensed CH under the MIT license and hosted it in Tools Labs, still using a static database. It is now accessible at https://tools.wmflabs.org/citationhunt/. This opens a bunch of new possibilites for using the live WP database (or, at least, auto-update CH as new dumps are released), and should address the privacy concerns Atlasowa mentioned. Let me know if you run into any issues! -- surlycyborg (talk) 22:44, 13 March 2015 (UTC)[reply]

I've just finished work to make the CitationHunt database auto-update weekly, always using the latest Wikipedia dump available on Tools Labs. It is currently using the 20150304 dump, the latest as of this writing. Assuming a regular dump schedule, we can expect CH to always contain reasonably recent information. Happy hunting! -- surlycyborg (talk) 16:19, 29 March 2015 (UTC)[reply]

Sometimes, multiple redirects should always point to the same article because they refer to the same thing. However, the way Wikipedia currently works, some redirects end up pointing in inconsistent ways. Let me explain with an example. Here are the redirects to the article Spirited Away:

• Chihiro (Spirited Away)
• Chihiro Ogino
• El viaje de Chihiro
• Haku (Spirited Away)
• Miyazaki's Spirited Away
• No-Face
• Sen To Chihiro No Kamikakushi
• Sen and Chihiro's Spiriting Away
• Sen to Chihiro
• Sen to Chihiro no Kamikakushi
• Sen to Chihiro no kamikakushi
• Sen to chihiro no kamikakushi
• Spirited Away (film)
• Spirited away
• Sprited Away
• The Art of Miyzaki's 'Spirited Away'
• The Spiriting Away of Sen and Chihiro
• Yubaba
• 千と千尋の神隠し

These redirects can be grouped by the following:

• Redirects that refer to the title of the movie
  • El viaje de Chihiro
  • Miyazaki's Spirited Away
  • Sen To Chihiro No Kamikakushi
  • Sen and Chihiro's Spiriting Away
  • Sen to Chihiro
  • Sen to Chihiro no Kamikakushi
  • Sen to Chihiro no kamikakushi
  • Sen to chihiro no kamikakushi
  • Spirited Away (film)
  • Spirited away
  • Sprited Away
  • The Spiriting Away of Sen and Chihiro
  • 千と千尋の神隠し
• Redirects that refer to Chihiro, the character
  • Chihiro (Spirited Away)
  • Chihiro Ogino
• Other redirects
  • Haku (Spirited Away)
  • No-Face
  • The Art of Miyzaki's 'Spirited Away'
  • Yubaba

It is conceivable that an article about the character Chihiro Ogino could be newly written, or essentially for any subtopic. Some redirects end up pointing to the new subtopic, while some stale redirects end up pointing to the old parent topic. Because of this, and many other ways, redirects can become stale even if editors can have a forethought of how similar redirects should point to the same target.

Solution-wise, there are several options.

• Non-text solution - define redirect groupings by GUI drag-n-drop, click-n-click
• Allow double redirects to support this use case, but only one additional hop
• Introduce a new directive: #REDIRECT_TO_RELATED. When used in page A to point to page B, it indicates that the title of A is intended to be a canonical title for topic A, but it is at one time for whatever reason deemed not worthy of an article of its own, so it points to B instead. The traditional #REDIRECT would change to more explicitly mean redirect source and target refer to the same topic. REDIRECT_TO_RELATED must point to an actual article, while REDIRECT must point to a canonical title, which may have a #REDIRECT_TO_RELATED page, or an actual article.
• Keep current syntax and UI mostly the same, but when a user tries to persist a change for one redirect, a warning and a bulk edit view appears to allow the user to edit a bunch of redirects.

--Makkachin (talk) 14:27, 4 March 2015 (UTC)[reply]

A consensus to allow double redirects if the intermediate redirect is one with possibilities was achieved at Wikipedia:Village pump (proposals)/Archive 112#Allow some double redirects. I don't know if anyone is working on implementing it.

I had an idea for a new redirect template to mark redirects that should be updated if another redirect is changed into an article. Using your example, Chihiro (Spirited Away) could include this template with "Chihiro Ogino" as parameter. The template message would depend on whether or not Chihiro Ogino is a redirect, and the template would add a maintenance category if it no longer is. That would ease correcting such redirects until the software is changed to allow double redirects. SiBr₄ (talk) 17:00, 4 March 2015 (UTC)[reply]

To illustrate what such a template would look like, I drafted one at Module:Sandbox/SiBr4. See testcase 1 (parameter is another redirect to the same title) and testcase 2 (parameter is not a redirect). SiBr₄ (talk) 21:17, 4 March 2015 (UTC)[reply]

@Makkachin and Oiyarbepsy: Any comments on this idea? A bot could figure out for itself which redirects to update, as proposed below, though it would be easier if the template dynamically changed its message and/or set a maintenance category for bots (or just humans) to patrol. SiBr₄ (talk) 15:24, 15 March 2015 (UTC)[reply]

I'm confused by your post. What the heck is that flag stuff on your testcases? And I don't know modules enough to have any comment on it, although your module seems very long and complex for a simple instruction to update a redirect. Oiyarbepsy (talk) 16:57, 15 March 2015 (UTC)[reply]

An unrelated test of a different template. The test of the redirect template is in the "Lua test 5" section. The module currently includes a number of error messages for when the template is used incorrectly; the main two messages, at the end of the "rrpos" function (note that the "fgg" function is also an unrelated test), are displayed on the testcase pages. SiBr₄ (talk) 17:15, 15 March 2015 (UTC)[reply]

Tracked in Phabricator
Task T32359

As far as double redirects, there is a complex and difficult to fix software issue holding it up. That said, double redirects would solve a lot of the problems noted above. Oiyarbepsy (talk) 19:56, 4 March 2015 (UTC)[reply]

Without double redirects, could some kind of template system work? You could have a template on a page {{same target as|other redirect}}, which bots could read and then use to automatically update the redirect if the other changes. Oiyarbepsy (talk) 19:56, 4 March 2015 (UTC)[reply]

I like this idea; and we can do this for multiple levels (a seires of movies, followed by an individual movie from the seies, followed by a character who is primarily from that movie - as soon as one of these becomes an article, the bot can update all the redirects which go through it. עוד מישהו Od Mishehu 17:55, 26 March 2015 (UTC)[reply]

It sounds like an easy enough bot task. What's the intended behavior if the "same target as" page isn't a redirect? But we could get the same behavior for redirects by calling it {{would redirect to|target}}. We'd also have to decide whether WP:CSD#G8 applies if target is deleted. Anomie⚔ 12:50, 28 March 2015 (UTC)[reply]

I think that the answer to the G8 question is simple: a page is speedy feletable only if every revision in its history is. עוד מישהו Od Mishehu 20:12, 28 March 2015 (UTC)[reply]

I BOLDly moved my draft live as Module:R avoided double redirect and made a wrapper at Template:R avoided double redirect. It probably needs some improvements to its messages, and possibly a better name, though the template will be easier to understand if it's used at an actual article redirect. See it at Makkachin's original example of Chihiro (Spirited Away). SiBr₄ (talk) 20:01, 3 April 2015 (UTC)[reply]

What do people think of this idea... Posting a message to user talk pages of users who have not edited in X amount of time but made constructive edits before to try coaxing them back into editing. An obvious factor that would exclude a user is they are on a break, either involuntarily (user is currently blocked for any reason) or voluntarily (a template in Category:Wikibreak templates is on their user page). Included in the message would be mentions of things that either didn't exist when they stopped editing, or a user may not know exist. Here's my impetus for this suggestion: I was speaking in person to a user who said that although they received a welcome template when they started in 2009, they didn't know that there are so many help resources available, specifically the Teahouse, the Help Desk or the IRC channels because they weren't mentioned in the welcome. The Teahouse was created in 2012, so it wouldn't have been. If there is opposition to bot-placed messages of this kind, is there a way of compiling a list of users who haven't edited in say, 6 months, and are not blocked or on break so it could be done manually? --Geniac (talk) 16:31, 8 March 2015 (UTC)[reply]

It's a great idea. GoodDay (talk) 18:38, 8 March 2015 (UTC)[reply]

• This would assume they are logging in regularly, but just not editing, a premise that I'm not prepared to accept without evidence. If they quit logging in, they won't see it. You could email, if they have an email, but that borders on spam. Good intention, but not sure how effective that would actually be. Dennis Brown - 2¢ 19:20, 8 March 2015 (UTC)[reply]

Actually, Dennis, I get an email anytime someone posts on my talk page. I expect this is the case for most editors. This email generally only gives the heading for the posts, so the heading would have to be chosen carefully. Oiyarbepsy (talk) 19:46, 8 March 2015 (UTC)[reply]

It isn't that I can tell, that is an opt in. Many users don't have email enabled or listed here to begin with. Until we had stats on how many opt in, it is hard to say with any authority. Dennis Brown - 2¢ 19:53, 8 March 2015 (UTC)[reply]

Yup, getting emails about edits to our own usertalkpage, are opt-in (see Special:Preferences#mw-prefsection-echo, and I just reset my preferences (on a test account) to confirm.

I support the general idea proposed. Quiddity (talk) 22:22, 8 March 2015 (UTC)[reply]

I, too, think the idea has merit. I'd like to see a structured and controlled A/B test to measure impact - which shouldn't be too hard - but I love the idea. Philippe Beaudette, Wikimedia Foundation (talk) 14:54, 15 March 2015 (UTC)[reply]

See also this 2012 experiment. Regards, HaeB (talk) 15:43, 16 March 2015 (UTC)[reply]

That's an interesting project with promising results. I don't know how to go about conducting a research project like that, but perhaps we could conduct one with similar metrics as that, and adding talk page posting as a separate group, to test results between the two methods of contact. --Geniac (talk) 20:56, 21 March 2015 (UTC)[reply]

I think if most (or even some) users can receive the message properly, it is a great idea. Good luck! Tony Tan⁹⁸ · talk 19:27, 26 March 2015 (UTC)[reply]

If any of you have ever looked at WP:Requested articles you know it's an absolute mess. The issue is there's a huge amount of pages on Wikipedia that link here, the article wizard, the navigation bar on the proposal village pump, AfC, the list goes on and on. This leads to a huge amount of article ideas listed here,

every page has an absurd amount, the thing is, there are some that are legitimately good ideas. Granted some of them aren't notable or don't have any potential content, but a lot of them are. The issue is requested articles is a never ending black hole, tons of additions are made every day but none of them are ever created, presumably because of the level of difficulty to dig into them.

The way I see it one of two things have to happen, either the entire thing has to be shut down, and all links to it across the project need to be removed, or a process that allows for a systematic review of every selection (without having to edit the entire thing by hand), and getting the lists to editors who'd be interested in doing it. I believe that latter is the better option, as this could lead to hundreds of good articles, though I'd like to hear some ideas on what the best way of going about this is, or if they entire thing should be scrapped.

Thanks! Kharkiv07^Talk 02:00, 19 March 2015 (UTC)[reply]

Yes, some form of peer review process may be needed to elevate the more notable entries to a 'preferred' status. The remainder could then be archived. The current length of the list seems prohibitive though; it could take several years to process. Praemonitus (talk) 19:39, 20 March 2015 (UTC)[reply]

We could take them to projects and advertise them. Or find prolific article writers and see if they want to address them. Graeme Bartlett (talk) 12:24, 24 March 2015 (UTC)[reply]

Nobody is going to want to deal with them in their current state though, I can try to take them to projects, or even advertise them, I'm just worried with thousands of article nobody is going to want to have to deal with them, what we need is a good way to classify them... I'm just not sure how. Kharkiv07^Talk 03:16, 25 March 2015 (UTC)[reply]

Perhaps some custom inline templates could be useful? For example, they could let others know what type of research has already been attempted for a particular topic and why no article was created. Possibly it could use small, two-letter codes with mouse-overs: [IS] → insufficient sources available; [TC] → technically complex, requiring an expert; [FL] → foreign language version available, &c. Praemonitus (talk) 17:55, 25 March 2015 (UTC)[reply]

Hmmm... that may work, I'll look into it. Kharkiv07^Talk 23:50, 25 March 2015 (UTC)[reply]

Getting these lists more integrated to their relevant wikiproject(s) would also be a good triaging step, and potentially help give interested writers/researchers a more closely connected place to find new subjects. I wonder if @Harej: is already thinking about this with regards to WP:WikiProject X? --Quiddity (talk) 16:41, 30 March 2015 (UTC)[reply]

Quiddity, Kharkiv07, Praemonitus, Graeme Bartlett: I have been thinking, at some level, about how to better integrate WikiProject lists of requested articles into WP:RA. Some discussion on IRC led to a wonderful idea of setting up a Flow board for article requests. Flow facilitates, essentially, talk page section-level categorization, so there could be a topic (Flow's version of talk page sections) for each requested article with the option to categorize in one or many categories, including WikiProjects. There would also be a triage system. I've asked the WMF to set up Flow for Wikipedia:Article request workshop here. Harej (talk) 00:31, 31 March 2015 (UTC)[reply]

@Harej and Quiddity: That sounds great! However, in the mean time MusikAnimal and I were looking into something here too, with a bot that forwarded it to a talk page. That being said a flow would work too, an easy system for reviewers that can be forwarded once approved is what's needed. That being said I'd love to see the flow, but not that the Wikiproject associated with RA is all but completly dead, with it's coordinator being long inactive. Kharkiv07^Talk 00:40, 31 March 2015 (UTC)[reply]

I 100% agree that aligning sections to a WikiProject is the best way of keeping Requested Articles organised and focused on notable material. I've done that myself occasionally for track and field and completed requests I had the knowledge and interest to do. I've no problem with there being long-standing unworked requests if the requests are still valid. They may eventually be the topic that gets a new content creator going. SFB 21:42, 3 April 2015 (UTC)[reply]

Sometimes I need to find a section which I have edited and go back to my edit history. I then click on that link (e.g. "Archive.org BOT?") but the section is no more there because it has been ARCHIVED. It would be nice to have an script that retrieves that section automatically if it has been archived. 67.83.6.149 (talk) 18:03, 19 March 2015 (UTC)[reply]

Flow will eventually solve the issue of broken links, whether due to the thread being archived, or moved to a different active page, or even just a thread-title-change. The Flow URLs still needs some improvement (phab:T59154) but the UUID element will make broken links as in those examples, a thing of the past. Quiddity (WMF) (talk) 16:36, 30 March 2015 (UTC)[reply]

I think that three articles

• Dear Boys (manga)
• Kuroko's Baksetball
• Cross over

need editing

any suggestions thanks! — Preceding unsigned comment added by NatsukiKazuhiko (talk • contribs) 23:13, 20 March 2015 (UTC)[reply]

@NatsukiKazuhiko: yes; be bold and make the edits. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:01, 25 March 2015 (UTC)[reply]

This came up on review for an article at FAC: "In some places where there are two citations covering one fact, they are not arranged in numerical order." It took a gnome to fix it, but seems like something a bot could handle, at cheaper wages. Does anyone know if that is a possible task for a bot? If so, how does one go about getting it made or learning to make it? Sorry if this is not correct forum. --Gaff (talk) 07:46, 24 March 2015 (UTC)[reply]

• I dislike putting cites inside a sentence. If a sentence has two facts supported by two cites, I would arrange the cites in the same sequence as the facts they support:

Smith obtained an MD in 1883 and a PhD in 1886.^[14][11]

A bot would not be able to see that the two cites cover two facts rather than one. Aymatth2 (talk) 13:07, 24 March 2015 (UTC)[reply]

Where dies this rule come from? -- Gadget850 ^talk 14:35, 24 March 2015 (UTC)[reply]

• I don't think there is a rule that says the cites should have the same sequence as the facts they support, or a rule saying they should be in numerical sequence. Probably it is a question of personal preference. The example above could dodge the issue by using cites within the sentence:

Smith obtained an MD in 1883^[14] and a PhD in 1886.^[11]

That seems cluttered to me. The issue can also be avoided by bundling citations. Aymatth2 (talk) 15:46, 24 March 2015 (UTC)[reply]

The numbering (and relative ordering) is subject to change when the WP:NAMEDREFS are moved around in the article as a whole. I agree it might not be that often, but the proposed task is not a one-time cleanup, and would probably need to do lots of parsing of the whole recent-changes feed to keep track. But more significantly, there might be some encyclopediac reasons to put them in some particular order, such as date. DMacks (talk) 14:45, 24 March 2015 (UTC)[reply]

We are short of new editors, particularly women. If a new editor is "bitten" as soon as they start a new article, they may give up on Wikipedia in disgust. This is to ask for feedback on the idea of adding a process to Wikipedia:Please do not bite the newcomers similar to that for Wikipedia:Vandalism, a series of escalating warnings to compulsive biters that eventually lead to blocks. The details are tentative, so any suggestions would be welcome to improve the concept before putting it to the vote. Aymatth2 (talk) 12:55, 24 March 2015 (UTC)[reply]

I would define a new editor as an editor with less than 100 edits, and a new article as one that is less than 24 hours old.

Type A bite: This kind of "bite" adds cleanup templates to a new article by a new editor, e.g.

This article needs more links to other articles to help integrate it into the encyclopedia. Please help improve this article by adding links that are relevant to the context within the existing text. (Learn how and when to remove this message)

This article may have too many links. Please review the guideline on links and help improve the article. (Learn how and when to remove this message)

This article's tone or style may not reflect the encyclopedic tone used on Wikipedia. See Wikipedia's guide to writing better articles for suggestions. (Learn how and when to remove this message)

There is nothing wrong with adding cleanup templates in general (although fixing the problem is better), but a lot wrong with greeting a new editor with a banner like this. An experienced editor would shrug it off, but a new editor may well see it as hostile, saying Wikipedia is not a friendly, collaborative site. Much better to leave a {{welcome}} note on the new editor's talk page, explain the problem and offer to help. Again, this would apply only to a new article by a new user. They make their first rough outline, save it, get a coffee, and come back to see an aggressive criticism of their work. Wikipedia does not want them.

Type B bite: This kind of "bite", more serious, is an inappropriate request to delete a new article by a new editor (Speedy, PROD, AfD). The request is "inappropriate" if it is rejected: the nominator did not do their homework. Some well-meant requests will of course be rejected, which is fine. But if an editor is repeatedly requesting deletion of new articles by new editors on inadequate grounds, they are doing damage. An inappropriate Speedy request on Natalie Smith Henry managed to get attention from the New York Times and BBC News, and a year later from Huffington Port. We do not need this sort of publicity, which may discourage potential new editors from even starting. Aymatth2 (talk) 12:55, 24 March 2015 (UTC)[reply]

We could add teeth to Wikipedia:Please do not bite the newcomers by defining an escalating series of user warning templates to be placed on the biter's talk page:

Type A bites (Cleanup banners)

	Welcome, and thank you for adding a cleanup template to Sample article. This is a new article by a new editor, so adding a note explaining your concern to their talk page would be more appropriate. See Wikipedia:Please do not bite the newcomers for a discussion of this concept.
	Please refrain from adding cleanup templates to new articles by new editors such as Sample article. See Wikipedia:Please do not bite the newcomers.
	Please stop adding cleanup templates to new articles by new editors, as you did with Sample article.
	You may be blocked from editing without further warning if you continue to add cleanup templates to new articles by new editors, as you did with Sample article.

Type B bites (Deletion requests)

	Welcome, and thank you for suggesting deletion of Sample article. Your suggestion has been declined. This is a new article by a new editor, so you should be very careful about proposing deletion without careful research and discussing your concerns with the creator. See Wikipedia:Please do not bite the newcomers for a discussion of this concept.
	Before requesting deletion please take more care to check whether a new article by a new editor such as Sample article does in fact meet the criteria for deletion. See Wikipedia:Please do not bite the newcomers.
	Please stop requesting deletion of new articles by new editors on inappropriate grounds, as you did with Sample article.
	You may be blocked from editing without further warning if you continue to add propose deletion of new articles by new editors on inappropriate grounds,, as you did with Sample article.

I do not see a proposal like this in Wikipedia:Perennial proposals. Perhaps it is crazy? Aymatth2 (talk) 12:55, 24 March 2015 (UTC)[reply]

This is unnecessary WP:CREEP. Type B, persistent bad deletion tagging, is already sanctionable as disruptive editing. Your process for type A amounts to a ban on maintenance templates; while a WP:SOFIXIT attitude is desirable, your proposal would prevent unfixed articles from being tagged for cleanup and so they would fall behind the metaphorical sofa and never see the light again. BethNaught (talk) 15:25, 24 March 2015 (UTC)[reply]

• @BethNaught: Wikipedia:Disruptive editing and Wikipedia:Deletion policy do not say anything about persistent bad deletion tagging. Is that mentioned somewhere else? I agree that Wikipedia:Avoid instruction creep is an important principle, and in a formal proposal would suggest simplifying and focusing all the rules and templates related to biting. I am trying to track down what they are. Thanks, Aymatth2 (talk) 23:16, 25 March 2015 (UTC)[reply]

WP:Disruptive editing states Disruptive editing is a pattern of editing that may extend over a long time or many articles, and disrupts progress towards improving an article or building the encyclopaedia. I would contend that repeated bad deletion tagging would fall under that definition. BethNaught (talk) 23:41, 25 March 2015 (UTC)[reply]

I suppose it does, although some might quibble. I was hoping for something more explicit. I will keep looking. Aymatth2 (talk) 00:48, 26 March 2015 (UTC)[reply]

• Remember it only applies to new articles, defined as less than 24 hours old. New editors may well create a minimal version, save it, then start adding the details. The idea is to not slam them with criticism after their first save. The person spotting the problem should leave a note on the creator's talk page, and tag the article if nothing is done in 24 hours. Or fix it. Aymatth2 (talk) 16:03, 24 March 2015 (UTC)[reply]

We already have quite a few templates... Template:Uw-bite, Template:Uw-csd, Template:Uw-hasty, as well as four levels of assuming good faith Template:agf1 and harassment Template:harass1. Besides, in general, the people who are going to be tagging this are people who you should probably talk it out on their talk page instead of templating them. Right? Kharkiv07^Talk 03:09, 25 March 2015 (UTC)[reply]

• The editors who frequently make poorly researched deletion requests on new articles, or swiftly tag new articles with clean-up templates, may not be particularly receptive to polite warnings about the damage they are doing in driving away new editors. They certainly are not concerned with Wikipedia:New pages patrol#Be nice to the newbies. But they will respond to an escalating series of user warnings that may lead to a block. Templating them when closing a declined deletion request would be a simple, optional step in the closure process, which could be done by any user. Similarly, it will be simple for any user to do a "biter" patrol to check for rapid addition of clean-up templates to new articles by new users, and to template the biter. The advantage of the proposed approach is that it does not require any one user to gather evidence and launch a case for sanctions based on disruptive editing. The escalation just happens naturally as different editors template the user for biting, like templating them for vandalism. Aymatth2 (talk) 11:32, 25 March 2015 (UTC)[reply]

• I'll reserve my opinions on the specific process proposed above, but this is certainly an issue that needs addressing. We also need to deal with the problem of AFC submissions being declined because they are not (nearly) perfect, rather than because they would fail an AfD. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:58, 25 March 2015 (UTC)[reply]

• I did not even think of that. I took a quick look at AFC and immediately found a serial decliner. I checked one article at User:Lograssolaw/sandbox, did a quick Google check, and am fairly confident that "World Head of Family Sokeship Council" is in fact notable, with plenty of sources, despite being three time declined. Maybe the way to approach this, though, is to start with a narrow focus and very clear damage such as rapid Speedy Deletes for newly created articles by newbies, then expand the scope afterwards. Not sure. Aymatth2 (talk) 15:43, 25 March 2015 (UTC)[reply]

• People forget if they don't feel comfortable accepting one a better course of action is just to comment on it... Kharkiv07^Talk 16:30, 25 March 2015 (UTC)[reply]

• AFC is a whole new world to me. I have always started articles in mainspace. I suppose some editors first need validation that their article is o.k. Presumably they are also very sensitive to negative feedback. I checked three more AFCs at random, found the same decliners, found one recently declined editor with a black "Retired" notice. This is obviously a form of biting. I am still unsure how to introduce this proposal. If it is too complicated there will never be consensus. Aymatth2 (talk) 00:48, 26 March 2015 (UTC)[reply]

• In my opinion the problem is with the AfC helper script, it provides upward of 20 reasons for rejection making it tempting to use one if it remotely falls into that category. But my problem with your proposal is the people who are making these declines are experienced editors and templating them all the time isn't probably the best way to go about it. Putting a personalized message on their talk page is probably the way to, and if needed take it to a noticeboard. So, with that rationale, my suggestion would be to make a policy that stops all the things we've mentioned. Kharkiv07^Talk 00:59, 26 March 2015 (UTC)[reply]

• The biters are mostly experienced editors who keep on biting. The policies and guidelines explain why and how to avoid biting, but the biters ignore them. Their victims do not know how to get together and appeal on a noticeboard – they are newbies. Talk page messages from the bitten newbies clearly do not work. The biters keep biting. We badly need new editors, so have to be rougher with the biters. A template-based escalation process leading up to a block, like the vandalism template process, seems the only effective way to help the biters break their bad habits. Aymatth2 (talk) 01:37, 26 March 2015 (UTC)[reply]

But currently its not written anywhere about, say AfC for example, as a matter of fact WP:Bite is extremely vague. Granted biting is a very broad topic that has so many different ways it can happen, I think if we get some of this in writing and then see how it sits we can better institute a warning system later, these people who are doing the things you're saying are borderline on the current policy, and while I completely agree with you that it's wrong, there's nothing that tells them not to at the moment. Full disclosure: I could be wrong about any of what does or doesn't exist in policy Kharkiv07^Talk 01:58, 26 March 2015 (UTC)[reply]

• Wikipedia:New pages patrol#Be nice to the newbies gives advice about hasty deletion and accompanying tags with talk page explanations. The guideline Wikipedia:Please do not bite the newcomers is a bit vague, I agree, and should give more specific examples. The guideline Wikipedia:Disruptive editing also applies, although it does not mention tagging or hasty deletion at all. It does mention "a pattern of editing that may extend over a long time or many articles, and disrupts progress", and that seems to fit. These guidelines could be clarified to discuss types of repeated biting subject to sanction. We also need an escalation process that does not rely on the newbies doing it themselves. Wikipedia:WikiProject User warnings/Design guidelines#Multi-level templates for disruptive editing discusses templating for disruption. A start could be made by extending {{Uw-csd}} and {{Uw-hasty}} into multi-level templates.

I am moving towards proposing a clarification to Wikipedia:Disruptive editing, along the lines of "Actions that tend to discourage newcomers, such as hastily nominating new articles for deletion or tagging new articles with clean-up templates, may be considered disruptive if constantly repeated without exploring alternatives on the article creators' talk pages." Something like that. If that were accepted, there should be no objection to escalation via multi-level templates. Aymatth2 (talk) 14:13, 26 March 2015 (UTC)[reply]

I see a real problem with Wikipedia:WikiProject Articles for creation/Reviewing instructions#Notability and verifiability. With deletion, the nominator is expected to first do some research to confirm that the subject is not notable. With creation, it seems that the onus is on the creator to provide evidence of notability. Endless resubmissions like Draft:Next Level Purchasing Association would be avoided if the reviewer called the shot on notability based on a web search. If the subject is notable, accept the submission. It can be improved. This is a separate issue from biting, but one that should be fixed. Aymatth2 (talk) 12:37, 26 March 2015 (UTC)[reply]

I'd propose changes on WP:Bite as well. Kharkiv07^Talk 15:21, 26 March 2015 (UTC)[reply]

• Maybe the same addition both places? "Actions that tend to discourage newcomers, such as hastily nominating new articles for deletion or tagging new articles with clean-up templates, may be considered disruptive editing if constantly repeated without exploring alternatives on the article creators' talk pages." I am looking for a proposal that really looks simple and obvious. Of course there are bound to be some editors who think biting is fun and others who think that if newbies can't shrug off biting they do not belong, so it may be hard to get consensus. Aymatth2 (talk) 15:42, 26 March 2015 (UTC)[reply]

• I believe that an article should never be tagged for speedy deletion within the first couple weeks, unless it's a blatant case of one of the general deletion criteria (excluding G4 for a deletion discussion from over a year ago); nor for PROD/AfD unless it's a borderline case of one of these criteria. Same goes for a user page within the author's on userspace, except for U1 cases. עוד מישהו Od Mishehu 17:49, 26 March 2015 (UTC)[reply]

What about an autobiography from an insignificant person? Or if somebody writes about their band, or their cat? I think CSDs are completely justified in some of these. Kharkiv07^Talk 14:34, 27 March 2015 (UTC)[reply]

The first version of a legitimate article may not look like much, but if it is not a Wikipedia:Attack page there is no great urgency to delete it: it is not doing any harm. A note on the creator's talk page is much less biting. That is particularly true with articles that do not at first give enough context, lack content or fail to indicate importance. The person may be more significant than the first draft shows, their garage band may be a huge success now, perhaps their cat is called Mr. Nuts. But if the article still looks hopeless after 24 hours, no problem with a speedy. Aymatth2 (talk) 16:06, 27 March 2015 (UTC)[reply]

How about all article csds (with the exception of the general criteria and A10) can be speedily deleted 24 hours after a friendly message is left on the creator's talk page? Kharkiv07^Talk 23:13, 27 March 2015 (UTC)[reply]

• I do not want to change the deletion criteria and processes, which have been carefully defined and tested over time, just to detect the small number of editors who consistently abuse them. A CSD or AfD request that is rejected, or a hasty A1 or A3 nomination, or excessive clean-up tagging may all be seen as bites – but may all be legitimate. If a number of different editors see biting, there may be a persistent biter that needs sanctions. Best to leave it a bit loose, so "may be considered". Aymatth2 (talk) 01:14, 28 March 2015 (UTC)[reply]

The problem with the warning system is it would be extremely subjective, unlike vandalism or test edits, this would be completely up to the reviewer's discretion which may lead to problems. Kharkiv07^Talk 01:24, 28 March 2015 (UTC)[reply]

• There is always an element of subjectivity. See Calton weavers. An editor nominated it as "G3:blatant and obvious hoax ... the deception is so obvious as to constitute pure vandalism." An admin agreed and speedy deleted the article. It was recreated and went on to DYK. In this case, if a number of different editors looking at different events see symptoms of biting that should be enough to trigger a review to determine whether there has indeed been disruptive editing. Aymatth2 (talk) 02:16, 28 March 2015 (UTC)[reply]

@Aymatth2: What if, when a page is tagged for speedy deletion and it's not pure vandalism, an admin userfies the article instead of deleting it, and leaves a notice? Kharkiv07^Talk 00:15, 1 April 2015 (UTC)[reply]

• That is always an option that an admin can follow, and that I hope they often do. I am more concerned with the impact of the deletion nomination or the maintenance template on a newbie. They walk in the room, get punched in the face, then someone tells them they came in the wrong door. Aymatth2 (talk) 01:47, 1 April 2015 (UTC)[reply]

No all maintenance tags are created equal. There are a couple issues that I pretty much always tag on new page patrol - {{linkrot}}, {{No categories}} and {{stub}}. Linkrot and categories are "just so you know" kind of tags that would apply to a very well-written article with these issues that a new editor wouldn't know about. If you tag as a stub, you shouldn't put any other tags on the article, since that is part of it being a stub. Oiyarbepsy (talk) 01:53, 29 March 2015 (UTC)[reply]

• @Oiyarbepsy: Any tags at all will be very alarming to a newbie if they pop up almost immediately after they save their first version of an article. The first version may well just be a placeholder to check that they are indeed allowed to start an article. Better to place a helpful note on the newbie's talk page instead of hasty tagging. If the newbie ignores the note, then tag the article. This makes new page patrol a but harder, but if it reduces the number of newbies that give up on Wikipedia is a valid trade-off. Comments? Aymatth2 (talk) 02:13, 29 March 2015 (UTC)[reply]

@Aymatth2: Are you saying that cleanup and/or deletion tags should not be added to new articles created by newbies? --AmaryllisGardener ^talk 00:11, 1 April 2015 (UTC)[reply]

• I am struggling to formulate this correctly, which is why I am asking for help here. I am starting from the premises that:

1. Wikipedia has a serious shortage of new editors, particularly women
2. Many potentially valuable contributors are not particularly combative
3. The first attempt by a newbie to start a new article will often result in hasty tagging for cleanup and/or deletion
4. This first attempt may be little more than a placeholder to test that they can indeed start an article
5. A newbie will often think they have walked into a room full of hostile strangers, and will turn around and walk out again
6. Wikipedia has a serious shortage of new editors, particularly women

I am thinking of imposing a delay between article creation and tagging (assuming the article is not immediately damaging to Wikipedia), using the newbie's talk page rather than clean-up templates to suggest improvements, and sanctioning editors who are consistently very aggressive to newbies. I strongly feel that something should be done. Aymatth2 (talk) 01:39, 1 April 2015 (UTC)[reply]

@Aymatth2: Then the solution would be to have a red notice (instead of a white one) at the top of the article creation page. That notice currently tells newbies to read YFA before creating an article, and it's their fault if they don't. Don't get me wrong, I think it's good to leave a personal message on their tp if you think they're confused, I speak as a Teahouse host and Co-op volunteer. I remember being a noob (back in December 2012), and guess what I did on my second edit (thirty minutes after my first)? I created an article! And guess what happened? It got tagged because it didn't have any refs!, and you know what I did then? I added a ref! I didn't get all teed off because what the tag said was true, I just wanted to fix it. Once you click that save button, it's out there, so I think it's perfectly fine to tag an article for a problem (or CSD it) as soon as it's there. This doesn't mean I don't care about newbies. --AmaryllisGardener ^talk 02:29, 1 April 2015 (UTC)[reply]

• @AmaryllisGardener: A red notice would be scary to everyone. Some newbies will respond positively to cleanup tags, as you did, but many will not. Most will be crushed by a speedy deletion tag on the first save of an article they are just starting to write. The Natalie Smith Henry tag got Wikipedia a lot of publicity, none good. Wikipedia has a serious shortage of new editors, particularly women, but is hostile to newcomers. Facebook is more welcoming and fun. Aymatth2 (talk) 02:58, 1 April 2015 (UTC)[reply]

I'm currently working on ThePhantomBot, (bot request for approval) a bot that looks for LTA and other issues that aren't as obvious as the ones found by bots like ClueBot. Since there's a lack of certainty with some of the things the bot looks for and since not all of it is something that would be handled at AIV, the bot would need some way to notify users that it has come across something needing attention. I don't think this can be done effectively by users just coming across the bot and following a page in its user space used to post reports, it would require that every time a user takes action on something the bot notices they credit the bot, which is not something users are likely to do and could bring unnecessary attention to the bot from the problematic users it targets. Here's a list of the things the bot currently detects (or will be detecting soon) and how I think it would best be reported:

• Bad page recreation - Log to user space page - These are detected very frequently and showing them to people who don't care to know would get annoying very fast
• High probability sockpuppets - Report to SPI - I don't know of any bots that currently report to SPI so it could be tough to get consensus for this
• Lower probability sockpuppets - Log to user space - These haven't been coming up very often but at a certain level of certainty human review is required
• LTA detection - Report to AIV if certainty is very high or report to AN/I otherwise
• Newly added LTA filters, including ones with very low certainty - Log to user space
• IPs using administrative templates - Report to AN/I
• Sleeper account detection - Not implemented yet so I don't know how often it will go off, if its often log to user space otherwise report to AN/I

The best idea I have so far for reporting to AN/I is to have a permanently transuded template at the top of AN/I which includes a list of reports along with a row of links to the user pages the other reports are filed on. The transclusion prevents users who don't care about the bot's reports from getting updates in their watchlist but makes users on AN/I aware the bot exists. I'm wondering if anyone has any better ideas for how the reporting should work or thinks there are problems with my current plan, after a bit of discussion here I'll decide what the best way to implement the reporting is and seek consensus at Wikipedia:Village pump (proposals). Here is the bot's current debug log and what the bot currently detects. PhantomTech (talk) 05:51, 27 March 2015 (UTC)[reply]

I'm not sure I understand why the bot is needed to do edit filter suitable tasks, could you elaborate on why it should be used in place of some on-wiki edit filters? Sam Walton (talk) 08:23, 27 March 2015 (UTC)[reply]

Quick summary for people who see the long thing I typed out after the summary and decide it's too much, the bot can

• Do more complicated checks
• Take more time on some edits
• Take infrequent cases, and lots of them

@Samwalton9: While many of the long term abuse cases could easily be handled by the edit filters, the bot has access to any information it can get from querying Wikipedia. If there was an LTA case where a user frequently made good edits to articles in a specific category to become autoconfirmed, then made problematic edits on a semiprotected article, filters would be mostly restricted to use any pattern in the problematic edits to identify them, if the problematic edits didn't adhere to a strict pattern, a filter would have to be written to catch a wide range of edits which could result in false positives. In the same situation this bot would be able to match the edit against the wide range of problematic edits performed, then check the user's contribution history to see if their other edits matched the problematic pattern and to see if the articles they edited before becoming autoconfirmed were from the category the LTA user tended to edit in. I'm not aware of this specific case existing and the LTA filters the bot currently uses aren't yet this complicated so this is more of a potential for the bot that will likely not be done until after the more simple LTA cases are being detected. Another advantage over filters is that filters cannot take infrequent cases, the time it takes to check an edit against the edit filters needs to be somewhat low because it's done on the fly. While a single filter doesn't necessarily have a big impact, putting a bunch together can, for this reason edit filters aren't setup for every case where they can stop or detect a problematic user. Not only can the bot take on many infrequent cases, it doesn't need to be quick on every edit because it checks edits after they've been made, it can take even a few minutes to check a single edit (hope it never has to) as long as it doesn't have to do that very often so that after it has it doesn't get backlogged. The LTA edit filters I can think of that the bot couldn't take are ones that need to be blocked because of what the edits contain, as someone who can't see private filters I'm not sure if any of these exist. PhantomTech (talk) 15:53, 27 March 2015 (UTC)[reply]

• Why don't you just do something like the Miszabot page archiving configuration? Make template:ThePhantomBot_config with bunch of different fields for how people can get your bot's report on their user page. So sock_prob = yes or sock_prob = daily could be used at the discretion of the editors at SPI to get a constant or daily list of probable sock puppets, while LTA_high = daily and Admin_template_misuse = daily would allow WP:ANI to get a daily report on possible long-term vandalism and IPs using administrative templates. A given editor who is interested in any or all of the information your bot comes up with can likewise have the same information delivered at regular intervals, eg all = yes, all = 12h | sock_low = no | LTA_low = no, all = daily, bad_page_detect = 2d, etc. VanIsaac_WS^cont 18:32, 29 March 2015 (UTC)[reply]

@Vanisaac: Not a bad idea but I'm not sure how well it would scale. Unlike archiving, this bot's task is time sensitive, posting to a bunch of user pages could cause a decent delay and even if that delay only happens once a day it might be an issue. I'm not exactly sure if this could be done but it might be possible for interested users to use javascript in their common.js to asynchronously check the bot's log pages for updates. Another option could be posting a message in an IRC channel, but that would be a supplement to something on-wiki. PhantomTech (talk) 19:33, 29 March 2015 (UTC)[reply]

@PhantomTech: There's nothing that prevents you from limiting the number of reports your bot has to make with a whitelist or namespace limitation - when report_X = yes is used outside the Wikipedia / Wikipedia talk namespaces, just transclude User:ThePhantomBot/report_X and give the option report_X = transclude for within the Wikipedia namespaces. That page would get the same constant updates of your ANI/AIV/SPI reports, so someone could check their user or user talk page to see whatever reports they want in real time. Periodic reports (eg, daily) could still be used in user talk spaces, and it could be as simple as doing a WP:subst of that report page onto those user talk pages. VanIsaac_WS^cont 19:47, 29 March 2015 (UTC)[reply]

@Vanisaac: Right now the plan is to have any reports that can't go to AIV or SPI go on a page with one of those pages transcluded to ANI so users transcluding any of those pages to their user page is certainly possible, making another thread (didn't think about that before) in my bot to subst reports daily on to user pages probably won't slow it down much so that's a possibility too. PhantomTech (talk) 20:59, 29 March 2015 (UTC)[reply]

Notice posted at WT:AN to get more input. PhantomTech (talk) 01:16, 4 April 2015 (UTC)[reply]

Please define this. I don't understand what it means. This has the potential to put a huge amount of useless garbage on the admin noticeboard. Oiyarbepsy (talk) 01:55, 29 March 2015 (UTC)[reply]

@Oiyarbepsy: {{Blocked user}}, {{Banned user}}, {{Sockpuppeteer}}, {{Locked global account}}, {{Uw-block}}, etc. Based on current detections this is very rare but was reported here. Ideally, anything with very frequent detections would also have a low rate of false positives and could be reported to AIV or similar to avoid spamming ANI, something with very frequent detections that doesn't have a great false positive rate or doesn't require immediate attention would probably work best by having the bot log it in its user space. PhantomTech (talk) 02:38, 29 March 2015 (UTC)[reply]

I've made a navbox at my sandbox that could be placed right under the header at ANI. My bot would log to a page (the main log) that the template gets info from along with other page's in its user space which are linked to in the navbox this way people can put the main log on their watchlist if they want updates but won't be updated if ANI is the only thing on their watchlist. The template automatically changes colors depending on if the main log is empty, has something or is backlogged and automatically collapses if it is backlogged so it doesn't take too much space on the page at ANI. I have it setup on my sandbox simulating a few "random" pages as if they were the main log to show what it looks like in its three different states and I put some placeholders in it for links to other logs so you can see what it would look like. The thresholds for page size are just rough estimates and will have to be modified depending on what format the reports are in. PhantomTech (talk) 04:48, 31 March 2015 (UTC)[reply]

To increase power-saving awareness (and actually save a lot of electricity)^{[citation needed]}, as well as to make reading easier for users in some cases, especially on mobiles phones when reading in the dark - I suggest adding a dark Wikipedia color theme, and add a button to change between the regular and the alternative color modes.

There's a Stylebot theme for Wikipedia which is called "Dark Wikipedia Rounded", and I believe this is how the dark Wikipedia theme should look. It's very nice and easy on the eyes. You can see how it looks in the style's page. — Preceding unsigned comment added by 89.138.33.253 (talk) 01:40, 29 March 2015 (UTC)[reply]

I'm all for skins for styles sake, but do you have any RS's that this is actually a power savings? techlogg.com disagrees with you for most monitors. — xaosflux ^Talk 02:15, 29 March 2015 (UTC)[reply]

After seeing a number of recent ANI discussions reach several thousand words and dozens of postings each with little or no admin input, some later archived without a single admin comment, I would like to look at possibilities for focusing ANI discussions in general. I participated in an RFC/U a few years ago and found the structure imposed by that system beneficial. I recognize that RFC/U had its problems and has been depreciated, but its highly structured design had merit. There doesn't appear to be any structure to many of the longer discussions at ANI. This is a problem because reading through and making judgements on long, tangled threads is a waste of admin time, and because large amounts of tangential commenting and sub-discussions can derail resolution of what would otherwise be clearcut issues.

Given the range of issues raised at ANI, a rigid structure could be difficult to apply, but there is a wide area between a highly codified discussion and a totally open one. A few possibilities: (1)limit post word count by non-admin users other than the filer and the target of the filing to 1000 words, perhaps a voluntary limit (2)add a default structure to new ANI posts, something like RFC/U's Statement of the dispute, Response, Additional views, Proposed solutions sections (3)put in place some limitation on posting new 'charges' outside of the scope of the initial dispute being raised later in the discussion (4)have separate sections in each ani for non-admin and admin responses. I am not proposing these, just throwing them out as a starting point, and I am sure there are other alternative solutions.Dialectric (talk) 14:38, 30 March 2015 (UTC)[reply]

I support this idea. ANI discussions are currently very messy and sometimes spin out of control. However, I do see one problem: what about routine reports, such as reporting suicide or death threats? Should we really make the reporter go through all that formality? --Biblioworm 16:08, 30 March 2015 (UTC)[reply]

@Biblioworm: I agree that edge-cases (which can be prolific on high-volume pages) need to be kept in mind. Ideally though, WP:EMERGENCY says those 2 particular situations should be reported privately. Quiddity (talk) 17:17, 30 March 2015 (UTC)[reply]

I also support a basic framework or suggested format. Anything to make the "drama board" less dramatic... --Scalhotrod (Talk) ☮ღ☺ 16:59, 30 March 2015 (UTC)[reply]

I guess one option could be similar to the one "used" in Lithuanian Wikipedia (lt:Vikipedija:Naudotojų elgesio svarstymai - lt:Specialus:Diff/4040662, lt:Vikipedija:Naudotojų elgesio svarstymai/Svarstymo šablonas - lt:Specialus:Diff/4040663) with separate sections for evidence (and a request to state what is wrong clearly - with an alternative that should have been chosen). Of course, no one has ever initiated a discussion there, but that is probably a good thing... --Martynas Patasius (talk) 00:19, 31 March 2015 (UTC)[reply]

No, per "not a bureaucracy." If you add rules to ANI, folks will just argue about the rules on ANI. NE Ent 01:43, 1 April 2015 (UTC)[reply]

This isn't a proposal, just a discussion of possible alternatives to the current one. Do you think there is no way to improve upon the current format?Dialectric (talk) 01:50, 1 April 2015 (UTC)[reply]

The other day I noticed an edit war over the music genres in an infobox, and I think I might have an idea that could all but eliminate that type of time sink. What if articles that have a long history of this kind of dispute had a dedicated template for the infobox? I don't know much about them, but if we had {{Infobox Thriller (album)}} that transuded all the agreed upon information from a fully-protected template, it would be nearly impossible to edit war over it.

Anyone wanting to make a change to the infobox template would be required to first gain consensus at the relevant talk page before asking for the change to be made at the template page. Of course not every article would need them, but editors working on pages where routine edit warring occurred over the infobox could request them on a case-by-case basis. This way we could "lock down" only the infobox during edit wars related to it. Rationalobserver (talk) 21:35, 31 March 2015 (UTC)[reply]

• I think it would be much, much, much more useful to eliminate the "genre" field entirely from any kind of music infobox. They are edit-warred from here to kingdom come on a huge number of articles, are almost never based on reliable sources, are susceptible to vandalism and modification, and in most cases reflect such micro-genres that only true aficionados of the artists involved have any idea what they mean. Further, most artists perform music from *multiple* genres or having elements from multiple genres. It's not worth it to have this stuff in an infobox. Risker (talk) 23:16, 31 March 2015 (UTC)[reply]

I agree, but that's been discussed and rejected, so this is a possible end-around. Rationalobserver (talk) 23:18, 31 March 2015 (UTC)[reply]

• (edit conflict) I somewhat agree with Risker: infobox genres don't impart much useful information (which could be said about infoboxes generally) but attract an inordinate amount of drive-by vandalism and revert wars. We wouldn't lose much (or anything) if the genre was simply eliminated. It should be based on reliably-sourced information contained in the article anyway, and it rarely is. However, full-protecting infobox templates seems to be a form of the perennial proposal to lock "finished" pages, and pages are never perfect and never finished. Ivanvector (talk) 23:23, 31 March 2015 (UTC)[reply]

Or I guess what I'm saying is that locking down just the infobox would just move the problem to the article itself, and not really solve anything. Ivanvector (talk) 23:24, 31 March 2015 (UTC)[reply]

Maybe, but at that point you might have to lock down the entire article anyway, which from what I gather is undesirable. At least this is a step before that, so the article can remain open. I think genre warriors like having influence on the infobox more than actual prose, but I could be wrong. Rationalobserver (talk) 23:35, 31 March 2015 (UTC)[reply]

No, I agree with Risker. Remove the genres in infoboxes. --AmaryllisGardener ^talk 00:05, 1 April 2015 (UTC)[reply]

I support that idea, but who is going to spearhead it? Rationalobserver (talk) 00:08, 1 April 2015 (UTC)[reply]

What about Risker himself? He She seems pretty sharp! *ba dum tss* --AmaryllisGardener ^talk 00:15, 1 April 2015 (UTC)[reply]

She. Risker (talk) 00:46, 1 April 2015 (UTC)[reply]

So are you willing to spearhead an effort to remove genres from infoboxes? Rationalobserver (talk) 15:35, 1 April 2015 (UTC)[reply]

• Support - as someone who monitors the Special:PendingChanges list daily, I have observed this as one of the most abused Infobox entries. --Scalhotrod (Talk) ☮ღ☺ 16:37, 1 April 2015 (UTC)[reply]

Ivanvector per your above comment: "However, full-protecting infobox templates seems to be a form of the perennial proposal to lock 'finished' pages, and pages are never perfect and never finished." Some aspects of article content are determined by prior consensus, and that's all this would do; lock-down the infobox when consensus has determined what info it should include. WP:CITEVAR, for example, says that you cannot change one style to another without first gaining consensus, and music genres should be treated the same way. Rationalobserver (talk) 18:59, 2 April 2015 (UTC)[reply]

But we never lock down an article to enforce consensus, nor should we, because consensus changes, and it goes against anyone can edit. The only instances I know of where pages are ever locked from editing are to stifle active disruptions (and even this is somewhat controversial), or to prevent changes to very frequently used templates which would break things (and WP:OFFICE actions, but that's another kettle of fish). Genre warriors are disruptive, but not anywhere near the level where we should take such drastic action as to preemptively prevent all music infobox edits. Perhaps I'll support this as an experiment if we use pending changes instead of full protection. However, in that case, it might just be easier to PC-protect articles where genre-warring is an issue, rather than create separate templates. Ivanvector (talk) 19:14, 2 April 2015 (UTC)[reply]

Also, I'll support taking the genre field out of infoboxes, if that is proposed. Ivanvector (talk) 19:19, 2 April 2015 (UTC)[reply]

I also support that idea, but why would locking down the infobox just turn the disruption to the article, but taking away the genre field wouldn't? Rationalobserver (talk) 19:33, 2 April 2015 (UTC)[reply]

@Risker and AmaryllisGardener: As a recent changes patroller I always come across this kind of vandalism without any clue if it's right or not and I'm more than willing to propose the change, are you guys thinking removing the genre field from all music related infoboxes, or just certain ones? Kharkiv07^Talk 01:11, 4 April 2015 (UTC)[reply]

I am going to say a few things in the same section. We know there are two separate Wikipedias : One Simple English another Main English. I haven't seen much difference between the two. Now there are lots of Wiki pages with average english(spelling mistakes , grammatical error) Pages develop over time.

If I feel an article needs better English I need to contact a volunteer with High English writing skills.

1)-If we click user rights , we can see whether they are Check User , Administrator , rollback rights , pending changes reviewer. We must add one more category "English Expert" or any other suitable name. Administrators or arbitration committee will decide who will get this facility.English barnster award should be given to senior editors who are good in English . Talk page discussion , or any other discussion is the best place where we can see the exact command over the language . Then it is upto administrators to propose him/her as "English Expert" .

2)-We must be allowed to put a maintenance template "This page requires better English" , which might get the notice of a an English Expert.Cosmic Emperor (talk) 08:19, 6 April 2015 (UTC)[reply]

Hi Wiki Team,

I request you to keep right click option on every English word if we do not understand the word, We can right click on the word and check synonyms then and there, So we would not need to go away from Wikipedia to understand a word.

Keep Synonyms option the way Microsoft kept in MS Outlook and MS word.

Please do it as soon as possible. It would be very useful for the world specially who uses English as their secondary language.