Policy | Technical | Proposals | Idea lab | Miscellaneous |
New ideas and proposals are discussed here. Before submitting:
|
« Older discussions, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109 |
|
On Orphan tags again
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
There is no consensus to overturn the previous consensus. I believe, though, that this RfC was started in good faith and that no disruption was envisaged or intended by the initiator. There may be some merit in some of the other proposals tacked onto the end of this RfC, but these have not been sufficiently discussed here or a consensus to emerge. HJ Mitchell | Penny for your thoughts? 20:24, 3 February 2014 (UTC)
I apologise for missing the discussion above and the Request for Comment but I would like to give some arguments that oppose the move to the talk page. Before starting I would like also to note that I am ready to follow any consensus reached. I already filled a BRFA in case the consensus reached is finally implemented.
So, I start:
- The main argument on moving the orphan tag is a general argument against all tags and has already failed many times. SeeWikipedia:Perennial_proposals#Move_maintenance_tags_to_talk_pages
- Distinguishing editors from readers is completely out of the idea I have for Wikipedia. Wikipedia is the encyclopaedia everyone can edit. Every reader is a potential editor. We should encourage readers to become editors. Tags promote the idea of editing. Almost all Wikipedia articles are incomplete and need expansion.
- Connectivity between pages is a big deal. We should rely on the fact that an article is searchable via the Search engine. We should connect articles between each other. In the past the Russian Wikipedia went a step further and checked for articles only linking from one to each other with no other connections. We should not want dead ends in Wikipedia. Reading is an endless adventure.
- 120,000 pages with no incoming links, not even from lists of pages is an issue. Not a small issue. Think that from these lists we xclude disambiguation pages, SIAs etc etc.
- Things are getting better. That things are stale is a myth. Per progress described in Category:Orphaned articles: In January 2013, there were 175,000 orphan articles and in November 121,725 articles. 50,000 less. everytime there was some effort to reduce the list we had results. If we exclude pages with 1 or 2 incomings links from the list things may be much better. In the past we were very strict about it. Now maybe it is time switch a bit and remove tags if there is at least 1 incoming link. -- Magioladitis (talk) 11:37, 23 December 2013 (UTC)
-
-
- Simple things people could do: add a link and then remove tag. -- Magioladitis (talk) 13:42, 23 December 2013 (UTC)
-
- It's not that simple. I did a little experiment. I picked the first 10 articles under A in Category:Orphaned articles from December 2013 (I've not included those under deletion considerations). They are:
-
-
-
-
- I could only link three. I linked Abdul Wali Khan University Mardan in Mardan. I also removed the tag on Gerardo Ablaza since he had been linked already. I linked A Fort of Nine Towers in And the Mountains Echoed, since both books are mentioned as being reviewed in one of the references of the latter. I won't contest it if it is reverted. Three out of ten, and all of them could only be linked once (which I think still makes them orphans, but I removed the tags anyway). The seven will retain their orphan tags indefinitely.-- OBSIDIAN†SOUL 16:33, 23 December 2013 (UTC)
-
-
-
-
-
-
- Not indefinitely. Until Wikipedia is expanded further enough. Now I am running against all articles and checking they are already linked by other pages. Still 60,000 pages to check. -- Magioladitis (talk) 17:07, 23 December 2013 (UTC)
- @Magioladitis: Yesterday I ran BattyBot over all articles tagged as orphans and removed hundreds of tags. I check the current month's articles almost daily. GoingBatty (talk) 19:04, 23 December 2013 (UTC)
- @GoingBatty: and then why I did these today: [1], [2], [3], [4] and more... -- Magioladitis (talk) 19:12, 23 December 2013 (UTC)
- @Magioladitis:
- 1 & 4 - My bot runs autotagging and then skips any articles that still contain "orphan" - these contains "orphan" in the text.
- 2 - Link was added yesterday from Phalia
- 3 - Unknown, but glad you're finding them. GoingBatty (talk) 19:28, 23 December 2013 (UTC)
- Nope. Indefinitely. We have 58,662 orphans from 2006 to 2010. These are articles which had the tag for 3 to 7 years. That's 1.3% of our total number of articles. It's very clear from that alone, that readers either don't know how to fix them, or don't care to fix them. Fixing orphans are the concern of experienced editors not drive-by readers. They're the only ones with enough know-how to do it properly. All of you here who support retaining the tag as is are bot, tool, or script users. Even without the tag, you can still accomplish these tasks. But you are not anymore the average reader, and to equate yourselves with them is a mistake.-- OBSIDIAN†SOUL 00:11, 24 December 2013 (UTC)
- Additionally, saying "Until Wikipedia is expanded further enough" is basically saying it can't be fixed. That's counter-intuitive to the purpose of maintenance tags. What's the use of those tags on top of the article urging everyone to fix the orphan status if it can't be fixed anyway? And it's not the minority either. That was 7 out of 10 that couldn't be fixed. It will just waste everyone's time every time they attempt to de-orphan it, only to find out they can't.-- OBSIDIAN†SOUL 01:39, 24 December 2013 (UTC)
- @Obsidian Soul: Just curious why you didn't add
|att=December 2013
to the seven articles you could not deorphan, which hides the article message box. GoingBatty (talk) 04:14, 25 December 2013 (UTC)- Because like our regular readers, I had no idea that I could or should hide the tags for undeorphanable files that way. It is not mentioned in the template itself. And even if it was (which would make the template even larger and more alarming than it already is), I doubt a regular reader would actually understand how to add that properly or think they have the "rights" to. The only people who know that attribute and use it, are those who do dedicated maintenance work, and they don't need the tag to tell them it's an orphan. They usually access the orphan list through the category directly.-- OBSIDIAN†SOUL 05:18, 25 December 2013 (UTC)
- @Obsidian Soul: Just curious why you didn't add
- Additionally, saying "Until Wikipedia is expanded further enough" is basically saying it can't be fixed. That's counter-intuitive to the purpose of maintenance tags. What's the use of those tags on top of the article urging everyone to fix the orphan status if it can't be fixed anyway? And it's not the minority either. That was 7 out of 10 that couldn't be fixed. It will just waste everyone's time every time they attempt to de-orphan it, only to find out they can't.-- OBSIDIAN†SOUL 01:39, 24 December 2013 (UTC)
- Not indefinitely. Until Wikipedia is expanded further enough. Now I am running against all articles and checking they are already linked by other pages. Still 60,000 pages to check. -- Magioladitis (talk) 17:07, 23 December 2013 (UTC)
-
-
-
- Oppose as original proposer of previous discussion.
-
- The previous proposal explicitly only applies to orphan tags. I have no problems with other maintenance templates (except when people are tagbombing to make a point). As pointed out, the assumption that there is a preexisting consensus not to move maintenance templates is not based on anything other than they were first implemented that way in the first place.
- Wikipedia's primary goal is to educate, not to turn everyone into Wikipedia editors. While we should encourage new editors as much as possible, we should never lose sight of the fact that we are an encyclopedia, not the borg collective. We are meant to be read first, edited second. Otherwise we might as well just display Wikipedia as an etherpad in permanent edit mode.
- Not everything can be connected. Much less connected two to three times. Several subjects (e.g. taxon articles) already had to explicitly be excluded from being orphan-tagged because of their highly-specialized nature. There are other articles like that that can't be categorized as easily, but are nonetheless similarly unlinkable to more than one other article (or none at all) even though they are undoubtedly notable. For example: non-western notable people, places, ideas, or organizations. Or companies and products even, where adding it to other articles would constitute spamming. And while they may not have incoming links, they would usually still have outgoing links, thus still fulfilling part of the connectivity requirement. To put it in analogy: when you're solving a jigsaw puzzle, you will always find instances of difficult pieces which do not fit yet or can only be slotted to one other piece. And the best way to solve that is not to force them to fit, but to find other easier pieces to work on until you eventually link up with it.
- It's a minor issue because it does not concern our readers. Again, most readers arrive through the topic through search engines, not by clicking on a link from another article. They can still find the article very easily if they wanted to.
- The fact that more orphans remain than are fixed seems indicative that a fair amount of them are permanent members of the category. As in they can't be linked yet or at all, unless someone forcefully adds it on See alsos of vaguely related articles. And I don't see that as ideal either.-- OBSIDIAN†SOUL 12:32, 23 December 2013 (UTC)
- I have argued a few times to create a "page tags" extension to MediaWiki, which would make maintenance tags (and maybe WikiProject banners and things like {{ArticleHistory}}) out-of-band (separately displayed and separately editable from article content, possibly with different permissions). And by the way, it would render this whole discussion moot, since everyone could choose to hide or show tags wherever they want, as they please. Keφr 13:52, 23 December 2013 (UTC)
- Support Keeping all of the tags on the same page. Considering the technical in-feasibility of fragmenting the tags with some on the article page or some on the talk page, it jut does not seem sensible to do so. Twinkle, AWB, AFCH, and some other scripts/tools are all having difficulties accomplishing this because it requires adding an entire new section to the code and quite frankly it's not worth it. Let's not pad a bunch of editors edit counts to fragment the maintenance tags, seems entirely counter productive. You don't like the way the tag looks on the articles page, we can change the way it looks without getting rid of it. Technical 13 (talk) 17:47, 23 December 2013 (UTC)
- Here's my thinking:
- The main argument on moving the orphan tag is that it's about a problem on a different page. No amount of editing Orphan is going to de-orphan it. You have to edit some other page. I support reducing the prominence of this particular tag (e.g., moving, hiding, or re-sizing it). I do not support doing this for any other tag.
- I agree that every reader is a potential editor. Let's focus them on tasks that can be achieved by editing the article they're reading.
- I agree that we should not want dead ends in Wikipedia—but orphans are not {{dead end}} articles.
- I agree that having 120,000 pages with no incoming links is an issue. Maybe, in addition to manually de-orphaning some, we should be looking at whether all of these articles actually belong here. We had a spate of spam-articles about Alaskan dermatologists a couple of years ago. How many of them really belong here? Do you realistically think that we can de-orphan every single article about every single dermatologist that paid someone to create an article, without creating something silly like a "List of Alaskan dermatologists"?
- I agree that things are getting better, but this doesn't imply that we need these tags to be the first thing that the reader sees on the page. Things can still get better even if the orphan tag is moved to the bottom and made small like a {{stub}} tag, or moved to the talk page, or turned into a hidden maintenance category. WhatamIdoing (talk) 18:29, 23 December 2013 (UTC)
- Comment I'm more likely to attempt to deorphan an article if I see the tag. Moving the tag to the talk page makes it less likely that I'll see it, which means I'm less likely to attempt deorphaning. GoingBatty (talk) 19:32, 23 December 2013 (UTC)
- Note that the broader consensus of the previous discussion was to move it somewhere other than at the top of the article where it breaks article layout and is the first thing that the readers see. It doesn't necessarily have to be the talk page. A hidden category on the same page or somewhere at the bottom like
{{Uncategorized}}
or{{Stub}}
were all proposed as alternatives. All of those are functionally fine, and editors have no problem sorting through them and fixing them.-- OBSIDIAN†SOUL 01:52, 24 December 2013 (UTC)
- Note that the broader consensus of the previous discussion was to move it somewhere other than at the top of the article where it breaks article layout and is the first thing that the readers see. It doesn't necessarily have to be the talk page. A hidden category on the same page or somewhere at the bottom like
- Comment if we switch the minimum links to deorphan from 3 to 2 I believe many pages will be detagged with us making no extra effort. -- Magioladitis (talk) 22:32, 31 December 2013 (UTC)
- Oppose Compare Wikipedia:WikiProject Medicine/RFC on medical disclaimer. The current orphan banner is absurdly WP:UNDUE when compared to our disclaimers which are buried at the foot of the page. I'm not too fussy how it is made inconspicuous but if I can still see it then it's going onto the talk page. Andrew (talk) 19:14, 3 January 2014 (UTC)
- Move for an immediate close of this RfC as it is disruptive (see below) -- PBS (talk) 12:50, 6 January 2014 (UTC)
- Oppose. The only argument I see here with any level of merit is the fact that some of our automated tools would require recoding. That, however, is not a justifiable reason to overturn the original consensus. It would set a very dangerous precedent to accept that consensus should be set aside for the convenience of the people who maintain the tools. As to the original comment: 1. "Past proposals failed, therefore we should treat this one as failed even though it succeeded." Uhh, no. 2. Citation needed. 3. Agreed, but I've seen no evidence that the existence of orphan tags causes people to clear them on any noticeable scale. Especially from new editors. 4. Appeal to emotion that fails to rebut the original consensus. 5. "Every time there was some effort to reduce the list we had results" - implies that some editors have dedicated some time to dealing with the issue. I commend and thank these editors, but I also know they weren't finding orphaned articles by hitting "Random Article". Ergo, the existence of the Orphan template in mainspace is not driving reduction efforts. Resolute 14:49, 6 January 2014 (UTC)
Oppose overturning the recent RfC. The proposer's arguments don't convince me. Argument 1, that the Orphan tag is like other tags, isn't true: it's not. Argument 2, that the Orphan tag is particularly good, or even any good, at getting readers into editing, is arguable. My guess is that it's probably mostly not true, but nobody knows for sure. Arguments 3, 4, and 5 are all addressed by having the tag continue to exist, but on the talk page. Against that is the argument that won the day at the original RfC: it's a big honken ugly thing that degrades the article's appearance, degrades the reader's experience, and warns the reader of nothing useful, all for little benefit. However, I'm all for a clean RfC on the question of whether the tag should appear on the talk page or just be invisible altogether. Herostratus (talk) 21:32, 6 January 2014 (UTC)
Here's an idea: Why don't we just delete the template and turn it into a hidden category. I do agree that the template itself can incite panic in new users, but moving it to the talk page helps no one if you can't see it. If you want to do maintenance in this category under the above proposal, you either have to be a user with a sophisticated understanding of how categories work (surprisingly, this is less common than most people think), or you give up because you have no idea where the template went. How about we just delete the template itself and replace it with hidden categories, so that way it can be seen on the user page, and we won't have a maintenance template appearing on a talk page. Kevin Rutherford (talk) 07:11, 24 December 2013 (UTC)
- I have no problems with that. A fair amount (most?) of deorphanings are done naturally over time as more articles are created that start linking to them anyway.-- OBSIDIAN†SOUL 05:23, 25 December 2013 (UTC)
- This makes sense to me. Putting the tag on the talkpage makes even less sense than putting it on the article page. Like others, I have also tried to de-orphan an article on seeing that tag. After all, I want to help. But it's a difficult and frustrating task that leaves me dissatisfied. As a temptation to turn readers into editors it is more likely to achieve the opposite. A reader taking up the challenge would equally find it difficult and frustrating, and from that experience may decide not to bother editing Wikipedia again. May even spread the bad news among friends and colleagues: "I tried to help out on Wikipedia once. Wasted an hour of my life and achieved nothing. Editing Wikipedia is for weird geeks who don't have a life". SilkTork ✔Tea time 16:05, 3 January 2014 (UTC)
-
- I agree, this solution is brilliant, is inline with the perennial concensus about maintenance tags on the talk page, and should be acceptable to all sides. I can think of no reason not to do this. --NickPenguin(contribs) 19:27, 3 January 2014 (UTC)
Support. 90+% of de-orphaning work is done through scripts and bots these days. There is no reason for a glaring notice at the top of each page, especially when at least half of these articles are impossible to de-orphan. Kaldari (talk) 08:10, 4 January 2014 (UTC)- @Kaldari: I'm aware of bots that remove {{orphan}} from articles that have already been de-orphaned. Could you please give an example of a bot that actually does the de-orphaning work? Thanks! GoingBatty (talk) 00:27, 5 January 2014 (UTC)
- I guess I was thinking of the bots that remove the tag. It looks like you're correct that these don't actually perform the de-orphaning. Oh well, guess you can ignore my comment then :) Kaldari (talk) 00:41, 5 January 2014 (UTC)
- I wonder how much of the de-orphaning is done by people using the "suggestions may be available" script that's is linked in the template that we're now hiding.... GoingBatty (talk) 01:22, 5 January 2014 (UTC)
- I guess I was thinking of the bots that remove the tag. It looks like you're correct that these don't actually perform the de-orphaning. Oh well, guess you can ignore my comment then :) Kaldari (talk) 00:41, 5 January 2014 (UTC)
- @Kaldari: I'm aware of bots that remove {{orphan}} from articles that have already been de-orphaned. Could you please give an example of a bot that actually does the de-orphaning work? Thanks! GoingBatty (talk) 00:27, 5 January 2014 (UTC)
- I agree, this solution is brilliant, is inline with the perennial concensus about maintenance tags on the talk page, and should be acceptable to all sides. I can think of no reason not to do this. --NickPenguin(contribs) 19:27, 3 January 2014 (UTC)
Alternate idea?
Moving the orphan tag is an inelegant and needlessly complicated process upon which the validation and ultimate removal becomes unworkable. An alternate and better option is to remove the banner portion of the template and make it function like Template:Coord missing. The end result allows direct and no-mess tagging of orphaned articles and resolves the issue of those supporting the talk page move. I personally did not know about the RFC or would have commented - others have come to the same conclusion, but were also unaware. I believe that this resolves both parties issues with a more optimal solution in terms of those who place, check and remove the tags. To put it bluntly: The tag is gone from view and the banner won't choke the talk page where validating and removing won't occur. ChrisGualtieri (talk) 06:03, 28 December 2013 (UTC)
- Question: With your suggestion, would {{orphan}} still reside within {{multiple issues}}, or be moved somewhere else? If moved, where would it reside? Thanks! GoingBatty (talk) 06:13, 28 December 2013 (UTC)
- It would no longer be a banner, the most simple solution is to make it a hidden category and that would mean it would no longer be in {{multiple issues}} unless specifically requested. At this time, I think making it completely hidden is justified given the RFC, it would still be functional and check-able like any other tracking category. ChrisGualtieri (talk) 06:24, 28 December 2013 (UTC)
- I understand that the solution proposed here is to remove the visible banner. My question relates to the code that editors use. If it would no longer be in {{multiple issues}} unless specifically requested (by whom?), where should editors add {{orphan}} in the page layout in the future? GoingBatty (talk) 18:16, 2 January 2014 (UTC)
- It would no longer be a banner, the most simple solution is to make it a hidden category and that would mean it would no longer be in {{multiple issues}} unless specifically requested. At this time, I think making it completely hidden is justified given the RFC, it would still be functional and check-able like any other tracking category. ChrisGualtieri (talk) 06:24, 28 December 2013 (UTC)
- I would prefer to have the banner hidden if only tag on the page, otherwise it should be inside the multiple issues and display a one line note. this is very technically feasible and seems like common sense to me. Technical 13 (talk) 21:50, 28 December 2013 (UTC)
-
- Technical 13, I like this idea. -- Magioladitis (talk) 22:35, 31 December 2013 (UTC)
- This idea also sounds good to me. Ramaksoud2000 (Talk to me) 06:47, 1 January 2014 (UTC)
- Piling on to say that I like the sound of this. Novusuna talk 07:58, 1 January 2014 (UTC)
- This is a great idea. I'll reiterate that the original proposal to move Orphan Tags to the Talk Page is a bad, bad idea. While we're at it, are there any other maintenance tags—that are not needed to be announced to every reader—that should be considered as well? (May help cleanup the article pages somewhat.) Just a thought. GenQuest "Talk to Me" 08:17, 1 January 2014 (UTC)
- Support this, which I feel doesn't violate the spirit of the original consensus. Sorry these great technical minds were late to join the party (better late than never!), the idea that the orphan patrol can use a custom MyPage skin to still see the template is the missing piece to the puzzle that should keep it easy for the orphan patrol to still use Find link and make everyone happy (except those who want to encourage readers to become editors by fixing orphans, but that ship has already sailed). – Wbm1058 (talk) 21:34, 2 January 2014 (UTC)
-
-
- Okay then... What I am thinking is to wrap the meta "issues" template (haven't dug in to see what it is yet) in a span with an id of whatever the calling issue is (in this case id="orphan"). The next step is to add a style="display: none;" to the span conditionally based on if:
{{{hidden}}}
|true. This will give us the option to add|hidden=true
to the orphan template (or whatever other templates we deem it would be appropriate to hide by default) which will hide it from normal view and those users that still want to see that notice can simply add some code to their common.css or skin.css like#orphan{display: inherit !important;}
which will override the fact that the tag is hidden for that specific user. Everyone okay with this? Technical 13 (talk) 23:16, 1 January 2014 (UTC)
- Okay then... What I am thinking is to wrap the meta "issues" template (haven't dug in to see what it is yet) in a span with an id of whatever the calling issue is (in this case id="orphan"). The next step is to add a style="display: none;" to the span conditionally based on if:
-
Okay, based on Mr. Stradivarius's suggestions, I've made some changes to {{Orphan/sandbox}} with examples on the testcases page. If no-one sees anything I missed there, this will be moved live in about three days. For those that wish to override the hidden nature, all you need to do is add the following to your common.css or skin.css:
.orphan{ display: inherit !important; }
I hope this satisfies what everyone wants without having to make a mess out of trying to move it to the talk page. Technical 13 (talk) 13:50, 2 January 2014 (UTC)
- If I recall chances to templates with a large set of transclusions won't pull through the changes until the update pass has happened or an edit (Even a null edit) has occured on the page. Therefore I'd like to suggest that a null edit bot be attached and set free over the Category:Orphaned articles category and it's children so that the nag disappears sooner rather than later. Hasteur (talk) 14:36, 2 January 2014 (UTC)
- It would still get run through the job queue like any other change, but that could in fact take weeks depending on how far down the queue it is. I wouldn't oppose a null bot running through the list, perhaps a ping to Joe Decker for his insight on running his Joe's Null Bot through it (yes, I know you can make a null bot for it too Hasteur, just getting another opinion on it.)? Technical 13 (talk) 14:54, 2 January 2014 (UTC)
- It appears that this solution would take care of articles that use the {{orphan}} template. Would this solution mean that we also need to convert any {{multiple issues}} templates with the old
|orphan=
parameter to the {{orphan}} template (and potentially relocate it to another part of the article)? Thanks! GoingBatty (talk) 18:16, 2 January 2014 (UTC)-
- Absolutely. It would be helpful if there was an approved bot like BattyBot task 26 to accomplish this. Technical 13 (talk) 19:19, 2 January 2014 (UTC)
- @GoingBatty: I though the consensus was to leave the Orphan template in the multiple issues wrapper so that if there were multiple issues, we'd draw attention to it. i.e. Not the primary cause for failure, but contributing to the failure. Hasteur (talk) 19:52, 2 January 2014 (UTC)
- @Hasteur: I'm not sure what the consensus is, so I'm asking. Note that I've updated Template:Orphan/testcases to show the difference between how the proposed {{orphan}} template does NOT appear within {{multiple issues}}, but the old style
|orphan=
still will. GoingBatty (talk) 20:02, 2 January 2014 (UTC) - @Technical 13: BattyBot 19 was approved to change the old style parameters to the new style ONLY when the old style was not displayed properly. GoingBatty (talk) 20:02, 2 January 2014 (UTC)
- @GoingBatty: I read the consensus proposed at 21:50, 28 December 2013 by Technical 13, and then endorsed and agreed to below that post. Personally, I like that methodology myself. Hasteur (talk) 20:09, 2 January 2014 (UTC)
- {{Multiple issues}} is one of those templates that is way overcomplicated and I have had the time to sort through and figure out how it works internally yet. Perhaps Theopolisme (who has written a Lua version of the template) or Mr. Stradivarius can help figure out why it doesn't show inside of Multiple issues? Technical 13 (talk) 21:28, 2 January 2014 (UTC)
- @Technical 13: In general, when an template is inside {{multiple issues}}, it displays the first sentence of the template text. Getting {{orphan}} to show nothing when on its own but a sentence when inside {{multiple issues}} will be new functionality. GoingBatty (talk) 23:34, 2 January 2014 (UTC)
- See Template talk:Orphan#Is it possible to have the functionality provided in the Toolbox? for a description of how {{orphan}} behaves inside {{multiple issues}}, where a shorter message is displayed. Wbm1058 (talk) 00:28, 3 January 2014 (UTC)
- @Technical 13: In general, when an template is inside {{multiple issues}}, it displays the first sentence of the template text. Getting {{orphan}} to show nothing when on its own but a sentence when inside {{multiple issues}} will be new functionality. GoingBatty (talk) 23:34, 2 January 2014 (UTC)
- @Hasteur: I'm not sure what the consensus is, so I'm asking. Note that I've updated Template:Orphan/testcases to show the difference between how the proposed {{orphan}} template does NOT appear within {{multiple issues}}, but the old style
-
- It appears that this solution would take care of articles that use the {{orphan}} template. Would this solution mean that we also need to convert any {{multiple issues}} templates with the old
- It would still get run through the job queue like any other change, but that could in fact take weeks depending on how far down the queue it is. I wouldn't oppose a null bot running through the list, perhaps a ping to Joe Decker for his insight on running his Joe's Null Bot through it (yes, I know you can make a null bot for it too Hasteur, just getting another opinion on it.)? Technical 13 (talk) 14:54, 2 January 2014 (UTC)
Looking at this more closely, it looks like we might need a new rule in MediaWiki:Common.css to make this work. The current {{multiple issues}} magic happens by using the class hide-when-compact
in all {{ambox}} text fields except |issue=
. This class is defined in common.css. However, to do what is being proposed here we would need to do the opposite, i.e. show text only when it is compact. Perhaps propose this on MediaWiki talk:Common.css? — Mr. Stradivarius ♪ talk ♪ 03:42, 3 January 2014 (UTC)
-
- And interesting technical point, if this is a barrier to its implementation then perhaps its resolution will result in a net positive because it could be extended to more or less the same type of tags in the future. This is definitely a more complex way to resolve the problem, but it does stand to be better than merely hiding it altogether - hide when compact is that functionality that seems like a great idea. ChrisGualtieri (talk) 13:42, 6 January 2014 (UTC)
- So far I see no discussion about this at MediaWiki talk:Common.css. Given that the wolves are demanding action and not foot-dragging, and the idea of keeping the message visible inside the {{multiple issues}} wrapper is the piece of this that might still be contentious and arguably against the spirit of the earlier consensus, can we just implement the solution that always hides the message? We can always revisit making it visible inside the wrapper later. Only downside I see is if there are only two issues, readers will just see one, leaving them wondering, "so what's the other issue?" - Wbm1058 (talk) 18:18, 6 January 2014 (UTC)
- Question. What's wrong with having the tag on the talk page? I haven't seen any compelling argument to that effect, except that it uglifies the talk page (so what, since it's useful) and that no one will see it (but even fewer people see it if it's not there, right?). Putting the page in a hidden category and also tagging the talk page would be OK with me, though. As to the original statement of this section, I actually can't even figure out what it means. "Moving the orphan tag is an inelegant and needlessly complicated process upon which the validation and ultimate removal becomes unworkable." Sorry, but what?. It looks like the sentence is talking about the actual process of moving the tags, which is relatively trivial I assume and I don't understand why it would be impossible to validate that this had been done properly? Herostratus (talk) 21:48, 6 January 2014 (UTC)
-
- To answer your question, all of the tools and applications that editors currently use to place the tag are unable to place the tag on the talk page (it would take a LOT of coding to be able to edit two pages instead of one for this, and is technically infeasible). This means that requiring this tag to be on the talk page instead of just hidden is essentially forcing the tag into deletion which was strongly against consensus in the discussion. Technical 13 (talk) 22:02, 6 January 2014 (UTC)
-
- Oh. Well, in that case, hmmmm. This seems odd to to me, since there are templates on talk page -- lots of them. So there must me some way place to templates there. I mean, it seems like an elementary thing -- you already know the name of the page, and the name of the talk page is very similar, the variance following a regular pattern. And I think it's possible to write to a page you're not editing, since various actions do that -- for instance, putting a speedy tag on a page (with Twinkle) writes a message to a user talk page. Are you sure you've drilled all the way down on this?
-
-
- But if it's the case that this can't be done, it is what it is and we have to move forward from there. I'd be leery of being driven too much by the technology. Heck, the tools are just conveniences). I put tons of templates on pages by hand for years. It's not that hard, so I wouldn't worry about it too much. There are tables to look these things up and it's a simple copy-and-paste operation. And anyway if these tools are that limited in how they can be configured to meet our needs, another good reason for not paying them too much mind.
-
-
-
- Again, if the case can be made and accepted that the Orphan tag ought not be on talk pages, that's different. But I haven't seen that case made very well.
-
-
-
- So I think we need to talk and think about this some more. One thing that comes to mind right off is allow the tools to operate as they do and just run [Wikipedia:Bots/Requests for approval/Yobot 23 Yobot 23] regularly; that'd solve the problem I guess. But this might degrade system performance, don't know. Another would be have the tools place the article in a hidden category, and have (as a separate thing) the visible Orphan tag remain as a talk page to be added by hand, if it really can't be automated. Probably there are other ways to deal with this.
-
-
-
- There's no hurry. It might be good to run a clean RfC with the two best options presented as binary choice, but I don't think we're there yet. Herostratus (talk) 01:07, 7 January 2014 (UTC)
- Your comparison is in the right direction, but for the wrong reason. When you put a speedy tag on a talk page to notify the user who created, you are doing a task with a very specific purpose. This is a notification and its a one-shot. The orphan tag on a page needs to meet a certain criteria to be applied (checked by AWB and some other tools including the AFC helper script). The article itself is checked, and if it was forced on the talk page, the talk page would receive the tag. This, by itself, is not too helpful, but possible. The real issue comes in knowing when the issue has been resolved - an AWB or other person who goes to the page will automatically check and remove the tag in the process of doing any other task. This will not be done if its on the talk page and to load up the talk page and load up the article to check would be a much more confusing and complex operation that is technically infeasible and inefficient. Completely hiding or having its concealment for editors who do not "opt in" is a great option, because it allows those who use the tools and do the tasks to resolve the orphan tag issue without loading up the talk page and flipping back, confirming on the article and re-loading the talk page to do the task. Or the other option would be load the talk page to check for the orphan and then the article itself, just to resolve this one issue... it creates more problems than it resolves and Coord missing is something with the exact same functionality and is a precedent that works. This is demonstrated and functional and it resolves the main issue - I don't think such an objection to forcing the talk pages to take the banner represents a net positive. ChrisGualtieri (talk) 18:29, 7 January 2014 (UTC)
- There's no hurry. It might be good to run a clean RfC with the two best options presented as binary choice, but I don't think we're there yet. Herostratus (talk) 01:07, 7 January 2014 (UTC)
-
This rfC is disruptive
The RfC that is now archived Wikipedia:Village pump (proposals)/Archive 108#Proposal to move the Orphan tags to the talk page, came to a clear consensus which was summed up by the closing admin. The alternative options being discussed here were discussed at the time and did not gain a consensus. To start another RfC over this issue so soon after a consensus was reached is disruptive. -- PBS (talk)
- PBS, unfortunately the closing consensus of that RfC was disruptive as it technically broke multiple tools and therefore has been re-discussed and consensus seems to have changed. Have a nice day. Technical 13 (talk) 13:33, 6 January 2014 (UTC)
-
- Considering multiple people called for it be hidden or given reduced notice in the original RFC, this is actually addressing the very concerns that were not fully explored. It became clear when preparing to do the actual letter of the consensus that it was infeasible for many more reasons. The spirit of it is being preserved and it will accomplish the original intended result in a far better way than discussed in the original RFC. ChrisGualtieri (talk) 13:47, 6 January 2014 (UTC)
-
- It is quite feasible to implement it as the consensus dictated. Which concerns were "not fully explored"? "actual letter of the consensus that it was infeasible for many more reasons" what are those reasons? -- PBS (talk) 14:19, 6 January 2014 (UTC)
-
- If you read the later comments closely, most support the removing of the banner, but ambivalent as to where it ends up, either category only on bottom of the article or on the talk page. My comment of "Oppose the move to talk page, Support hiding it away someway. From many years of doing maintenance backlog and tracking some of the progress, very little maintenance happens by drive by editors. Almost all happens by project or individual drives to clean out a cleanup cat. Whatever we do, the category must remain on the page, so that tools like the svick tool pick them up and catscan can be used to sort them. Moving the tag to the talk page just adds an unnecessary complexity to the sorting tasks - and will be a big task to do, compared to simply changing the contents of the {{orphan}} template. The-Pope (talk) 07:36, 30 November 2013 (UTC)" was supported by the RFC originator, but coming two weeks into the voting period, I doubt many others would have read it (TL:DR). If there are real technical issues with doing a move, rather than a template appearance change, then it is very valid to revisit it with the current knowledge. The-Pope (talk) 16:12, 6 January 2014 (UTC)
- For the record, I'm the closer of that discussion (I'm not an admin by the way) and I support this alternative idea, it even cropped up in the first discussion, but it came too late, and there wasn't a consensus at the time. Ramaksoud2000 (Talk to me) 22:32, 6 January 2014 (UTC)
I agree that technical means to hide the orphan tag on the main page would satisfy the spirit of the consensus. Our process isn't a legislative one, and closures are not usually meant to be literally binding except in extreme cases. PBS, if you have good reasons to prefer the original solution, you should just raise those for everyone to consider, rather than raising a procedural objection. Gigs (talk) 17:03, 6 January 2014 (UTC)
"The alternative options being discussed here were discussed at the time" is not true. The currently favored solution to hide the template message, but to allow overriding the hidden nature by adding specific text to your common.css or skin.css (anyone on orphan patrol will want to do this) is a key idea that was not brought up in the original discussion and will make the largest possible number of editors happy. To suggest otherwise is to imply that consensus would want to move {{coord missing}} to the talk page because editors, not readers, find it disruptive. Wbm1058 (talk) 17:51, 6 January 2014 (UTC)
It's not disruptive IMO. If you look at the previous RfC, the concern of most all of the commentors was getting the ugly thing off the article pages. The idea that having it on the talk page as a positive good did not really come into play. So this is a refinement that's reasonable to discuss. Herostratus (talk) 21:39, 6 January 2014 (UTC)
- OK, I see some concern from editors who (1) don't want to see anything on the article page, (2) want to help with de-orphaning, (3) don't want to install the custom skin that would show them the template message, so (4) need to be able to see the message on the talk page, so they can help de-orphan. Sorry, I'm dubious about the idea that tagging the talk pages will increase de-orphaning, but this issue is easily solved by just asking the bot that was going to move tags to the talk page to copy them there instead, where they could display a talk page version of the message and would not be categorized. – Wbm1058 (talk) 22:18, 6 January 2014 (UTC)
- This bot would need to run on a regular basis to pick up the new ones. Wbm1058 (talk) 22:24, 6 January 2014 (UTC)
- I would be opposed to replicating the tag on talk pages as redundant, disruptive, and unecessary. I would be more than happy to make a simple script that those people could import into their css/js in addition to it also placing the pages in a category that they could use to find orphans. I'm still working on the technical aspects of hiding the template and making it show in multiple issues... I'll work on it at the end of the week as I have a final in sociology to get done this week (a really weak subject for me). Technical 13 (talk) 23:12, 6 January 2014 (UTC)
- I agree with you, T-13. I neglected to mention above that such theoretical editors wanting to fix orphans also refuse to check Category:Orphaned articles as that's too much bother, as well as opting in to see the message is too much bother. But, somehow, checking the talk page isn't too much bother, in spite of the fact that after checking the talk page they will need to return to the article to run "what links here" and they won't be taking advantage of the tool that's built into the visible template unless they go out of their way to do so. And we are supposed to assume that such theoretical editors are so numerous as to outweigh the burden on those using the cat, opting in to see the template, using the tools... having to make a special trip to edit the talk page to remove the template, which is totally unnecessary except to fulfill the needs of theoretical editors. Sorry if I'm sounding harsh, but I'm a little annoyed that this argument continues. Wbm1058 (talk) 19:17, 7 January 2014 (UTC)
-
-
- The issue is not "theoretical editors", but simply the common practice that the eventual resolution without tag removal is not a small minority. I often remove orphan tags with AWB and I also PLACE them with AWB. Moving it to the talk page means I'd have to stop and load up the talk page to place it (a function AWB does not have) and I'd have to check the talk page to see if I could remove the orphan tag (assuming one needs to). I'll run a operation this weekend (its been awhile since I last did the task) and show why the technical matter warrants this. It has never been about checking a category - it is part of the upkeep and maintenance of Wikipedia itself. The matter of "seeing" the tag has been secondary to me because I need the actual ability to detect, check and remove the tag all at once. And the result of moving it to the talk page splits the detect, check and removal up in two minimum edits and results in lots of needless reloading and processing. ChrisGualtieri (talk) 17:14, 8 January 2014 (UTC)
-
- I do see what you guys are saying. But: going back to the very top of this section (not this subsection), you see an editor initiating this discussion (on the grounds of Hold on, we haven't discussed this enough), and she is an Old Believer -- she wants the tags to remain on the article page.(Her second point is "Distinguishing editors from readers is completely out of the idea I have for Wikipedia. Wikipedia is the encyclopaedia everyone can edit. Every reader is a potential editor. We should encourage readers to become editors. Tags promote the idea of editing...".) In the original RfC and earlier discussions, a not insignificant number of editors adhered to that view.
- So we have rump minority holding that view. They have lost their point, and I think they're wrong but not unreasonable. It's a good idea to compromise to acommodate minority views, when possible, I would say. Moving the tag to the talk page rather than deleting it from view altogether is a way to do that. So I think we should keep thinking about a way to do that. Herostratus (talk) 13:19, 10 January 2014 (UTC)
- You've acknowledged the point that some of us (including me) have made. Yes, there was a consensus to not have this tag viewed by default on article pages, the majority of people that supported that wanted them moved to the talk page, this was what the RfC was closed as for consensus. However, what was not introduced into that RfC was the fact that this is technically impossible within reasonable limits to accomplish as many of the tools (userscripts, gadgets, bots, other programs) would have to open and edit two pages instead of one and that is more trouble than it is worth to code. According to the count in All orphaned articles the {{Orphan}}, the tag is on 122,829 pages and according to Template:Orphan transcluded on 123,169 pages. That is a lot of needless busy work some editor would have to do to move them by hand, and would create more work for editors that want to de-orphan pages, as they would now have to visit an extra page. Hidden by default on the article page if it is the only tag and categorized was also supported by consensus by all that felt something needed to be changed about this tag, and I think that is the correct path to now follow. Technical 13 (talk) 16:10, 10 January 2014 (UTC)
-
- That sounds fair and reasonable. GenQuest "Talk to Me" 18:25, 10 January 2014 (UTC)
-
- Well hmmmm. How about this: would it be possible to end up with a situation where:
- The current {{Orphan}} tag is made invisible on the page, and Category:Orphaned articles becomes a hidden category, AND
- There is a new template created -- let's call it {{OrphanForTalkPages}} or whatever, which populates a category called Category:Orphaned articles (via talk page tag) or whatever -- which looks much like the current Orphan tag?
- Is that possible? Surely that's possible?
- And then the people responsible for maintaining the tools can do whatever they think best. I gather that the code for placing the (newly made invisible) {{Orphan}} tag and populating Category:Orphaned articles would remain in place. If the people who maintain the tools want to figure out some way to add some interface with {{OrphanForTalkPages}} and Category:Orphaned articles (via talk page tag) to their tools, fine, but apparently this is not reasonably possible, so then {{OrphanForTalkPages}} remains something that is listed in the lists of templates and is only put on by hand, which means it won't be used too much I guess.
- I would suppose that someone might be interested in the intersection of Category:Orphaned articles and Category:Orphaned articles (via talk page tag), and I guess someone could handle this is some manner, by some sort of query, or maybe by having a master category Category:All orphaned articles of which the other two categories are subcategories. Or something like that. Is that possible? (Ideally for parallelity we would rename Category:Orphaned articles to something like Category:Orphaned articles (via tool) and similarly rename the {{Orphan}} tag, but not if it's a big hassle.)
- The question then would be whether the bot -- Yobot 23 or whatever -- moves the tags to the talk page and populates Category:Orphaned articles (via talk page tag) or not. One thing to consider here is the political angle, in that (as seems likely) there is a general hue and cry of "What the heck happened to my Orphan tags" the answer "Moved to the talk page!" might play better than "Invisibilized them!".
- Another question is what about articles that for whatever reason end up in both Category:Orphaned articles and Category:Orphaned articles (via talk page tag). My guess is that this is not a huge deal although not optimal and perhaps can be handled by a bot that runs on now and again, or by a human, or just shrugged off.
- And there may be other repercussions that I'm not thinking of, of course. So anyway, is this possible? Herostratus (talk) 16:24, 11 January 2014 (UTC)
- It is most certainly "possible" to create a second set of templates/categories that would run in parallel to the existing set, but this would be a redundant nightmare to maintain and keep in sync. A better solution is those that want to see it on the talk page instead of the article page use a gadget or userscript that detects that the template is on the article and displays it on the talk page instead. The actual code would still be on the article page, which would make it a little harder to remove (unless a special link inside the display was added by the script displaying the information to remove the tag). This gadget could even be the default so that all users see it on the talk page, unless you turned that gadget off. Technical 13 (talk) 18:37, 11 January 2014 (UTC)
- FYI, Category:Orphaned articles is already a hidden category, as are the categories that appear on the articles themselves: Category:All orphaned articles and monthly categories such as Category:Orphaned articles from January 2014. GoingBatty (talk) 18:41, 11 January 2014 (UTC)
- Using a gadget or userscript is not going to happen for the vast majority of our readers. The vast majority of our readers do not have accounts, and I'm sure are unaware of the existence of gadgets and userscripts. So I don't see this as too helpful. So then how about this. Let's run a clean RfC saying something like this: The Orphan template is not going to be visible on the article talk pages anymore. That's been decided. There are two mutually exclusive ways to implement this. Vote for the one you prefer:
- The {{Orphan}} tag continues as before, except it is not visible to readers. Category:Orphaned articles continues to exist, and the {tl|Orphan}} tag may be still be placed and removed by tools by automated tools such as Twinkle, as before.
- The {{Orphan}} tag remains visible to readers, but is moved to the talk page. Category:Orphaned articles will continue to exist, but will consist only of talk pages. For complicated technical reasons, Twinkle and other automated tools will not be able to place and remove the {{Orphan}} tag or interface usefully with Category:Orphaned articles, and the option to place the {{Orphan}} tag will have to be removed from the automated tools. All placing and removal of the {{Orphan}} tag and maintenance associated with Category:Orphaned articles will have to be done by hand in future. (Or however it should be phrased; not sure if I have that right.)
- Or something like that. I'd be reluctant to run this RfC until we're sure we've exhausted all reasonably possible alternatives. RfC's like this run best when there's a binary option, and we're going to get some number of "Neither, keep on article page" for starters, and we're sure to get some number of "Neither, instead do both" and "Neither, instead do such-and-such" and so on, so I want to be sure that such-and-such can be easily disposed of, at least. It may well be (probably is) that Option 1 up there is the better option and if that's true hopefully the arguments for it will win the day, although I don't want to just assume that either. And if it does we'll be much better off if we can point to a clear decision if and when people start wondering what happened to the tag. There's no hurry if there's more to think about, but if and when there's not, how about a clean RfC along those lines? Herostratus (talk) 21:42, 11 January 2014 (UTC)
- Using a gadget or userscript is not going to happen for the vast majority of our readers. The vast majority of our readers do not have accounts, and I'm sure are unaware of the existence of gadgets and userscripts. So I don't see this as too helpful. So then how about this. Let's run a clean RfC saying something like this: The Orphan template is not going to be visible on the article talk pages anymore. That's been decided. There are two mutually exclusive ways to implement this. Vote for the one you prefer:
- Well hmmmm. How about this: would it be possible to end up with a situation where:
-
- I would be opposed to replicating the tag on talk pages as redundant, disruptive, and unecessary. I would be more than happy to make a simple script that those people could import into their css/js in addition to it also placing the pages in a category that they could use to find orphans. I'm still working on the technical aspects of hiding the template and making it show in multiple issues... I'll work on it at the end of the week as I have a final in sociology to get done this week (a really weak subject for me). Technical 13 (talk) 23:12, 6 January 2014 (UTC)
That is the beauty of javascript and gadgets, they can be loaded by default for all users so user do not have to log in or know anything about them or how they work for them to do their job. Those that don't like the look will be able to simply disable them for themselves (if they have an account). The tags can not go directly on the talk pages, it is technically not possible to do. Saying they have to go on the talk page essentially kills the entire orphan project and there is no consensus for that. The tags themselves have to go on the article page, but they don't have to display there. Technical 13 (talk) 02:40, 12 January 2014 (UTC)
- Well, if they're locked in by default such that the tag appears by default, then the tag appears for the great majority of our readers, and so nothing has been accomplished. Getting an account and futzing with javascript or even clicking to enable gadgets is not in the cards for most of our readers.
- I know that tags can be placed on talk pages and that talk pages can be in categories, such as {{WikiProject Biography}} and Category:Unassessed biography articles and many others. I've always assumed that a talk page category such as Category:Unassessed biography articles has some use to someone in some way, otherwise they would not exist.
- So you're telling me that {{WikiProject Biography}} and Category:Unassessed biography articles have some use and value but that {{Orphan}} and Category:Orphaned articles would, if moved to talk pages, have no value, and no reasonable amount of computer sciencey effort expended on the problem could cause them to have value. This seems... kind of magical...
- But OK. I accept that. I grant that. So fine.
- So then the question is over two competing claims to primacy:
- The needs of the orphanage project, and
- The desire to engage the general readership in dealing with orphaned articles, albeit in significantly reduced way since the tag is now only on talk pages.
- Thinking about this, for my part, in the case of orphaned articles, I'm willing to concede that the needs of the orphanage project probably do have primacy. I don't know that for sure, and to some extent it's a matter of opinion and can't be proved. But for my part I withdraw my objection to leaving the Orphan tag on the article pages and just making it invisible.
- I'm not too happy about that, since we are then moving the problem of orphaned articles entirely (instead of just mostly) into the realm of "let the relevant group of experienced and interested editors handle this, step aside please" and away from the purview of the general readership, which is a getting a little bit away from the general approach we take here.
- However, it's been pointed out and accepted that there's not really a whole lot that the general reader can usually do about orphanage, especially if the "find links" button comes up blank. Which is a good part of the reason the visible Orphan tag is being removed from the article pages. So in this case it might be better to leave it to the orphan project. (And BTW thank you guys for your service in this useful task; sorry to be obstreperous.)
- I say I remove my personal objection and for my part will cease disputing the matter. Others might feel differently though, and although I'm not going to do this I strongly recommend that you guys run a clean RfC along these lines:
- It's been accepted that the Orphan tag will no longer appear visibly on article pages. For the purposes of this RfC consider that a given and off the table. However, the original solution was to move the tag to the article talk pages. Further consideration has revealed that this would make it impossible for the orphanage project to use the tag, for technical reasons. We are thus presented with two choices. Please state your preference.
- Move the Orphan tag to the talk pages, where it will be visible (although only to readers who access the talk page), and shut down the orphanage project.
- Keep the tag on article pages, but invisible, and allow the orphanage project to continue as before.
- And be prepared to explain the technical problem clearly and succinctly, and to argue cogently why keeping the orphanage project is the better choice. I'd probably vote for #2 and I think most editors will also and so you'll be good to go, everyone will be satisfied, and you'll be protected from future sniping over the matter. And if not, then not. But if you chose not to run an RfC like this, better be prepared for some backlash. Herostratus (talk) 05:19, 12 January 2014 (UTC)
@Gigs if you read the original debate I gave detailed reasons for moving to the talk page. If you need me to link to provide links to those reasons, I can do so.
@Technical 13 "I would be opposed to replicating the tag on talk pages as redundant, disruptive, and unecessary." talk pages are for editor to editor communications, article space is for information about the subject of the article. The agreement was to remove the template from article space, so there is no "replicating the tag on talk pages".
Nothing I have seen in this section to date, changes the fact that "To start another RfC over this issue so soon after a consensus was reached is disruptive". -- PBS (talk) 10:35, 11 January 2014 (UTC)
- It might well have been disruptive as first posted, but anyway the discussion has shifted, the original poster's concern has fallen off the table, and we are now having a lively and useful discussion about how to best implement the intent of the previous RfC in light of new information re technical limitations. I wouldn't worry about it. Herostratus (talk) 16:24, 11 January 2014 (UTC)
-
-
- Of all of the proposed solutions to this problem, the least disruptive to the existing system, and the simplest to implement (besides, of course, changing nothing) is simply moving the orphan tag to the bottom of the article with the no-categories tag. The two are often worked on at the same time, and wouldn't interfere with the reading of the article. Also, if some of the automated processes which had not yet been updated were to continue putting the tag at the top because they hadn't been updated, it wouldn't be a big deal, whereas if some totally different process for identifying orphans began to be used, these processed would all have to be found and fixed right away. —Anne Delong (talk) 04:29, 12 January 2014 (UTC)
- It does not matter much where on the article page it is, as long as it is on that page directly... I'm still working on the modifications to the lua module itself to make the template hidden by default. I'm not very good with lua yet, and this is a fairly abstract template to be learning on. I've recruited what assistance I can, but it is slow going. Technical 13 (talk) 05:08, 12 January 2014 (UTC)
- Of all of the proposed solutions to this problem, the least disruptive to the existing system, and the simplest to implement (besides, of course, changing nothing) is simply moving the orphan tag to the bottom of the article with the no-categories tag. The two are often worked on at the same time, and wouldn't interfere with the reading of the article. Also, if some of the automated processes which had not yet been updated were to continue putting the tag at the top because they hadn't been updated, it wouldn't be a big deal, whereas if some totally different process for identifying orphans began to be used, these processed would all have to be found and fixed right away. —Anne Delong (talk) 04:29, 12 January 2014 (UTC)
-
This rfC is not disruptive
- I disagree that the "RFC" was disruptive, the talk on the AWB page showed multiple concerned editors over the technical implementation and work are the people who regularly clean up and manage the Orphan tags. Technical13 has worked his butt off for Wikipedia and the hidden aspect of the orphan tag was not solely my idea, another user proposed it independently and it was agreed by several others before returning to this. The discussion resulted in a clear option that resulted in the same effect (no orphan warnings on the article page) and several other editors agreed that it was the intention and spirit of the original RFC. We are having a lively debate about it, but few of us can implement either of these changes and Technical 13 seems to be the only one to do so. If it were so simple as blindly following the RFC, I could do the 100,000 articles by hand or if someone with a bot did it, but the fact it broke every method and way of checking and fixing the orphans showed that it was a net negative instead of a net positive. The coord missing tag (which is invisible to readers) was the most elegant and proper solution I found that represented the least amount of work to implement. And I think we all owe Technical 13 a big thank you for working on the ultimate solution for so long. ChrisGualtieri (talk) 15:38, 15 January 2014 (UTC)
-
- Agree with this whole-heartedly. Thanks, Technical 13, for your efforts. GenQuest "Talk to Me" 20:39, 15 January 2014 (UTC)
- Apparently we have some progress on implementing this. See Module talk:Message box/configuration. Wbm1058 (talk) 22:05, 22 January 2014 (UTC)
- The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Continuation on orphan tags
HJ Mitchell, will you agree there is also no longer a consensus to move the tags (which is technically impossible to maintain) to the talk page? I believe that there should be some clarification in the closing. Yes, everyone agrees readers shouldn't have to see this tag, but few seem to be of the opinion the tag should be moved. — {{U|Technical 13}} (t • e • c) 23:06, 3 February 2014 (UTC)
- Technical 13, I've become really frustrated with this situation. The viability of your alternate proposal is contingent on you or someone else being able to actually implement it. My last message at Module talk:Message box has not been responded to for over a week now. There is absolutely no consensus for the status-quo, and I see no evidence that you are able to hide the orphan message except when inside {{multiple issues}}. You had a solution which hid the message in all situations, including inside {{multiple issues}}, that I confirmed worked but for a cosmetic glitch which nobody had a solution for. Rather than look for a solution for the cosmetic glitch you have attempted to find a more complex solution involving a "hidden" parameter, but I cannot confirm that this more complex solution works. Hence we are now on the verge of a train-wreck here. I believe from the spirit of the earlier consensus that there is de facto consensus for your basic solution. Arguably a consensus could be obtained for the more complex solution, but that is a moot point if it can't be delivered. I believe that the consensus at this point would be to let Yobot 23 proceed with trial, if that would actually move us off the status-quo that there is no consensus for. Further delays in that bot's trial might well be considered disruptive at this point. Wbm1058 (talk) 18:50, 4 February 2014 (UTC)
- (edit conflict) Due to my personal lack of knowledge with Lua at this point, I will admit it is a slower than should be process. I've reached out for help in this, and haven't gotten much response. As a result of this, I've been trying to learn Lua on my own by practicing on building new modules to learn the basics of it before digging into some of the complexities in the modules that would require adjustments here. Yes, this could simply be done via MediaWiki:common.css and a new class introduced for orphan tags, but I think that adding such a thing to the core css file is a hackish solution, and am trying my hardest to learn the language needed to make the proper adjustments that I think would best serve the community. I again make a plea to those knowledgeable in lua to make the changes or offer whatever assistance that they can to move this along. Thanks. — {{U|Technical 13}} (t • e • c) 19:02, 4 February 2014 (UTC)
-
- What am I supposed to be fixing exactly? Jackmcbarn (talk) 19:06, 4 February 2014 (UTC)
- A new version of Module:Message box went live 01:04, 27 January 2014. It's supposed to "allow ({{ambox}}) boxes to be hidden" but I can't figure out how it's supposed to work. I asked (Module talk:Message box) if this could be tested before it went live, and was assured that "it has been tested enough." Can you figure it out? Wbm1058 (talk) 19:23, 4 February 2014 (UTC)
- Hello Jack, quite simply, {{Orphan}} is suppose to have
class="hidden-ambox" style="display: none;"
or something of that nature when used by itself, but not if it is used inside of {{Multiple issues}}. — {{U|Technical 13}} (t • e • c) 20:34, 4 February 2014 (UTC)- @Technical 13: How is self:addClass('infobox editsection') supposed to hide anything? Jackmcbarn (talk) 20:44, 4 February 2014 (UTC)
-
-
- That's a good question Jack, I honestly do not remember how I decided that was the best to use. I had found that was a class at the time that was defined something like
.infobox .editsection{ display: none;}
in one of the existing skin main.css files, but I don't remember which. Might be worth checking with Edokter for an update on his proposal and progress on re-writing MediaWiki:Common.css to be more modular and developer friendly. — {{U|Technical 13}} (t • e • c) 21:32, 4 February 2014 (UTC)
-
- Not much progress so far, and I never thought about any show/hide mechanism. If that is a usefull feature, feel free to add it to Wikipedia:New CSS framework. — Edokter (talk) — 22:27, 4 February 2014 (UTC)
- That's a good question Jack, I honestly do not remember how I decided that was the best to use. I had found that was a class at the time that was defined something like
-
@Edokter:, @Jackmcbarn: – please give your opinions on the viability of this interim stopgap solution which could be used while the more robust module techniques are still in development. The only template change is to {{orphan}}, per this diff. By default this hides the orphan messages, both when the template is used stand-alone and when it is sandwiched inside {{multiple issues}}. Using User:Wbm1058/common.css overrides the hidden feature and makes the messages visible again. See Template:Orphan/testcases for a demo. The only issue I've seen is that the bullets don't line up inside {{multiple issues}}; the orphan messsage is a bit too far to the left. Do you know how to fix that? Is this viable—at least as a temporary solution—or is it in anyway an unacceptable hack? Thanks, Wbm1058 (talk) 00:12, 5 February 2014 (UTC)
- Given that a solution is apparently technically difficult, i would favor simply deleting the template and removing it by bot from all current placements. Frankly I don't see that it adds any value, since for any given article What-links-here will supply the identical data. Failing that, a move to the talk page as originally suggested would be better -- I wasn't higjhly impressed with the reasons asserted for not doing this as the original RfC had consensus to do. DES (talk) 00:48, 5 February 2014 (UTC)
- I like T13's proposal. I don't really like DES's. Anyway, using list-item or inline (not sure which, one should work) instead of inherit should fix the misalignment. Jackmcbarn (talk) 01:11, 5 February 2014 (UTC)
- There is no need for the extra class "orphan" (there is already "ambox-Orphan"). The question is how to enable (show) it again for those that want it. Personal CSS would work, or a gadget. On the bigger picture though, I don't personally really see a need to hide it in the first place. These kind of messages are there to show all issues and motivate readers to become editors. If some particular message is not effective, it should be removed. — Edokter (talk) — 09:27, 5 February 2014 (UTC)
- Thanks, Edokter. Yes, that was setting off my "hack-alarms" but it wouldn't work without it. I changed that as you suggested, so this is the only change needed (add | style = display: none). Then the light-bulb went on; I needed this in my common.css to make it work. Jackmcbarn, I tried changing inherit in my common.css to both list-item and inline, and each had an effect, but not the desired one. Any other ideas on how to make the bullets line up? I don't really know css. I think the idea of making this a gadget, so that editors need only check a box, rather than install their own custom common.css, once we have this working right and confirm consensus for it, is an excellent idea. Thanks, Wbm1058 (talk) 15:48, 5 February 2014 (UTC)
- You must use
display: inherit !important;
as the style you are trying to override in inline. — Edokter (talk) — 16:19, 5 February 2014 (UTC)- Right, that is what I am using, see here. That is indeed overriding the line | style = display: none in {{orphan/sandbox}}, but it is also having the undesired side-effect of overriding something else as well as it is also effecting the live {{orphan}} template by causing the bullets to mis-align. Where is "ambox-Orphan" defined? There must be some other characteristic of that which I want to avoid overriding. Wbm1058 (talk) 17:11, 5 February 2014 (UTC)
- Oh, I see. class = ambox-Orphan was added here, for the benefit of Twinkle. Wbm1058 (talk) 19:31, 6 February 2014 (UTC)
- I must have dreamed about this last night, because when I woke up this morning a light-bulb turned on in my head. I'm optimistic now that I can come up with a solution, maybe later today. So hang tight for a bit, more later. Wbm1058 (talk) 16:08, 7 February 2014 (UTC)
- You must use
- Thanks, Edokter. Yes, that was setting off my "hack-alarms" but it wouldn't work without it. I changed that as you suggested, so this is the only change needed (add | style = display: none). Then the light-bulb went on; I needed this in my common.css to make it work. Jackmcbarn, I tried changing inherit in my common.css to both list-item and inline, and each had an effect, but not the desired one. Any other ideas on how to make the bullets line up? I don't really know css. I think the idea of making this a gadget, so that editors need only check a box, rather than install their own custom common.css, once we have this working right and confirm consensus for it, is an excellent idea. Thanks, Wbm1058 (talk) 15:48, 5 February 2014 (UTC)
After beating on this for over two days I have found a technical solution which makes T13's proposal to hide the orphan message only when it is not part of {{multiple issues}} possible. It's not pretty, but I think it works. Implementing a more elegant solution requires another redesign of {{multiple issues}}. That template has already been redesigned once, and the need to continue supporting the legacy design contributes to the complexity of the solution.
- First, I have cleared the backlog of edit requests for {{orphan}} and brought the template documentation up to date, so, before reading further you may want to review the template:Orphan documentation.
- To support the old syntax of {{multiple issues}}:
- Modify {{Orphan}} per this diff which adds a new parameter multi, which when set, displays the orphan message rather than hide it.
- Modify {{Multiple issues/message}} per this diff to pass the parameter multi when calling {{orphan}}.
- Modify {{Multiple issues}} per this diff to set multi = multi and pass it to {{Multiple issues/message}}
- To support the new and current syntax of {{multiple issues}}:
- Further modify {{Multiple issues}} per this diff to support display of orphan messages in {{multiple issues}} when using the new syntax.
- Review the test cases at Template:Orphan/testcases (I added more test cases to cover all the scenarios)
- Install this code in your personal common.css file to un-hide the hidden orphan messages.
- We will probably want to file a request at Wikipedia:Gadget/proposals to make this special code a gadget, so that the orphan patrol can simply check a box at Special:Preferences#mw-prefsection-gadgets to show the hidden orphan messages.
- I still see the "cosmetic glitch" in both Chrome and Internet Explorer after I activate the special "gadget code", which misaligns the bullet for the orphan message in {{multiple issues}}. I am mystified about what is causing it. I went so far as to save the html source from a page to compare the differences between the displayed html when the bullets align to when they don't. Here is the diff from that test, which leaves me clueless. But, as this glitch is only cosmetic, and would only effect those editors who opt-in to the gadget, I suppose we can live with this issue.
- Kudos to Jackmcbarn for pointing me in the right direction when I got stuck.
- No Lua required; no new CSS class required.
Please review this solution and comment on whether it is good enough. I suppose if it passes technical review then the next step would be to take it back to the general editor population to see if there is a consensus for it. Thanks, Wbm1058 (talk) 17:17, 10 February 2014 (UTC)
- As there seem to be no technical issues with my solution, I will begin composing a third Request for Comments, which should hopefully finally settle the matter of orphan tags. Wbm1058 (talk) 01:36, 13 February 2014 (UTC)
- Regarding the "technical glitch", if I remove the !important from .ambox-Orphan{display:inherit!important;} then the bullets line up, but the override to show the orphan template doesn't work. Wbm1058 (talk) 22:24, 13 February 2014 (UTC)
- Here is a screenshot taken by Mr. Stradivarius demonstrating the glitch. I'm guessing that perhaps somewhere along the cascade, something isn't correctly specified, and thus slightly incorrect display specs are being inherited by the override. Wbm1058 (talk) 16:17, 14 February 2014 (UTC)
- I updated the progress section on the Category:Orphaned articles page. The one-year reduction from 122,500 orphans on 13 February 2013 to 121,092 orphans on 13 February 2014 is not much of a reduction. We are just treading water. Most of the tagging is done by bots and tools such as AWB and Twinkle. I am concerned that if we hide all tags from day one then that could have a negative effect on de-orphaning; rather than continue treading water we could begin to drown in orphans. I know, we probably already are. Better de-orphaning tools are needed. But I'm thinking that we shouldn't hide the orphan message from day one, but rather put a time limit on it. Perhaps hide the message after three months? I'm thinking that most tagging is done to newly created articles, and the editors most motivated to find links are the editors who created the articles. If they never see the bold message at the top of their new articles, then how would they ever be motivated to help find links to it? Wbm1058 (talk) 15:09, 21 February 2014 (UTC)
-
- Wbm1058, if the tag can only be seen when used inside multiple issues or if specifically set to be seen, then why does it need a time limit? — {{U|Technical 13}} (t • e • c) 16:00, 21 February 2014 (UTC)
- In cases where it is the only issue, it will not be seen as part of multiple issues, and thus would only be seen if it was set to be seen by a dedicated patroller. Perhaps these are the only editors who find links, but we would be removing the notice and opportunity from the new editors who created the orphan (often about a person or organization) to find links for their newly created article. Maybe these new editors so typically create articles with multiple issues that most all of these will be tagged multiple for some time after creation. I was just thinking that it might be a good idea to let the tag stay up for a short time so that the article creator is made aware of the problem and has a chance to solve it if they are so inclined. If they, or a gnome, don't solve it within a given time limit, then hide the tag as a longer-term problem unlikely to be addressed in the short term. There would still be no time limit on showing it inside multiple issues, and those opting into the orphan-display gadget would always see the message. Wbm1058 (talk) 16:28, 21 February 2014 (UTC)
-
-
- I see. While I personally think the tag should always be visible to everyone except those who specifically hide the tag because they don't want it, the consensus is the opposite. As such, the current consensus is that the tag should never be seen by anyone unless they specifically want to see it (opt-in with css or a userscript), or if it is placed inside {{Multiple issues}} with at least one other issue. I believe there is currently a lot of frustration by people on both sides of whether this tag should be displayed on articles, and think the best course of action is to wait at least six months before proposing what you would like it to do here (I'd wait a year personally based on my perceived sense of the amount of tension surrounding the issue). — {{U|Technical 13}} (t • e • c) 16:49, 21 February 2014 (UTC)
-
- Wbm1058, if the tag can only be seen when used inside multiple issues or if specifically set to be seen, then why does it need a time limit? — {{U|Technical 13}} (t • e • c) 16:00, 21 February 2014 (UTC)
Wikipedia head is now floating!
I've recently done a user script - FloatHead. It makes your Wikipedia headbar floating and I think it really enhances the navigation across the wiki, especially on long pages.
Cheers! --Rezonansowy (talk • contribs) 12:49, 20 January 2014 (UTC)
- Does it only work for Vector? Neither this nor Equazcion's script works for me (using Monobook). — Huntster (t @ c) 23:40, 20 January 2014 (UTC)
-
- I use Vector and it works. It does constrict the field of view a bit (top-bottom) when editing, which will take a little getting used to. I'm giving it a try. I like having the tabs available, especially on loooooong articles. Thanks again. GenQuest "Talk to Me" 02:41, 21 January 2014 (UTC)
-
-
-
-
- I've got no complaints. The slightly smaller space'll take some getting used to, but that's a small price to pay for this! Two questions, tho: Are there other things like this? And if so, how do I find them? Supernerd11 :D Firemind ^_^ Pokedex 04:42, 13 February 2014 (UTC)
-
-
-
- I was looking for this. Now al it need is a pin/unpin button. — Edokter (talk) — 16:28, 5 February 2014 (UTC)
Open letter from EFF, Demand Progress on re-opening Wikipedia:Surveillance awareness day
EFF and Demand Progress have written an open letter to the members Wikipedia community asking them to re-open Wikipedia:Surveillance awareness day, which failed to reach consensus. I'd appreciate hearing some responses from the community to this! Thanks, ParkerHiggins ( talk contribs ) 20:42, 5 February 2014 (UTC)
- With less than a week to go before the date, i don't think there is enough time for a valid RfC on such a major issue. If one were opened I would oppose on those grounds alone. And that is leaving aside the issue of whether that kind of advocacy is proper here. DES (talk) 20:46, 5 February 2014 (UTC)
- While Wikipedia's participation would undoubtedly give a substantial boost to this campaign, which is something many of us might like, political activism is something pretty much impossible to do while remaining neutral. If SOPA hadn't been an existential threat to Wikipedia, we probably wouldn't have done anything about it. We might like to think of Wikimedia as a major player in the activities of the "freedom"-oriented online community, but our policy of neutrality gives us far less freedom of action in these areas than other communities, even those that are corporate-run. And, as DES said above, the amount of time left wouldn't be enough for a valid RfC even if it was something widely supported. Good luck with the protest. --Yair rand (talk) 22:27, 5 February 2014 (UTC)
- (edit conflict) Oh how cute... the advocates for internet rights are attempting to bully/shame us into participating in their demonstration. Perhaps if the awareness day is celebrated again next year we can hold a "Re-call the question" RFC to close no less than 2 weeks before the event to see if there is a consensus to participate in the demonstration, as Consensus can change. Hasteur (talk) 22:28, 5 February 2014 (UTC)
- Are we not here to write an encyclopedia? Period? Take the POV social-activism to a blog or somewhere else. It does not belong here. GenQuest "Talk to Me" 03:39, 6 February 2014 (UTC)
- It became clear what was going to happen (nothing) when I posted Wikipedia talk:Surveillance awareness day/Archive 2#Proposal: Endgame Timeline and most of those participating didn't bother to respond. It was a bog-standard project management proposal for meeting a deadline: figure out what needs to be done before the deadline and start negotiating a schedule by working backwards. I had a rough draft of additional previous steps but didn't bother posting them once it became clear that there was no significant interest in making a schedule, much less meeting it. Everything I wrote in that proposal is still true. No matter what the EFF desires (full disclosure: I am a regular contributor to the EFF) we as a community blew right past the 23:59, 2 February 2014 deadline, and at that moment it became impossible to make up the lost time and meet the deadline. --Guy Macon (talk) 15:24, 6 February 2014 (UTC)
23:59, 2 February 2014
- Full disclosure, I oppose wikipedia taking sides in protests. However repeatedly I (among others)said If you want to get this done, there needs to be a centralized community discussion on the basic question, does the community support taking action. Weeks ago I (among others) said that, and not one supporter started that community discussion. It's too late now, and if you support it, when casting blame look first in the mirror for not even bringing this to the community.--Cube lurker (talk) 17:23, 6 February 2014 (UTC)
- The US conducts drone strikes in Yemen, some of which are acknowledged to be errors-- that is, killing of innocent civilians based of false conclusions. If there's a 13 year old student in Yemen who wants to read Wikipedia, I can't in good conscious recommend that they should feel free to read all our articles on chemistry without fear of becoming a 'false positive' killed by US drones for reading something suspicious.
We didn't spend 10+ years making an encyclopedia that some parts of the world should be afraid to read!!!!
I don't know precisely what we should do in response, but I'm confident that doing nothing is the wrong answer. --HectorMoffet (talk) 11:37, 7 February 2014 (UTC)
-
- If you're that confident you should have taken my advice weeks ago.--Cube lurker (talk) 13:20, 7 February 2014 (UTC)
- ...or mine, which was posted much later and also largely ignored. These things don't just happen by magic. They require organization and cooperation. --Guy Macon (talk) 18:39, 7 February 2014 (UTC)
- Hey, I make a lousy leader, what can I say. I've never read main page criteria before, I don't hang out at ANI, I'm not even an admin-- I'm a gnome who wound up in a position no gnome should be in. A true organizer could have done things a lot better-- most of the time I thought Jehochman was the leader who was going to organize cooperation, but he turned out an absentee leader. There was advice from all sides, obviously I should have taken more of it. Ya got me-- someone better than me should have handled this, and I still hope somebody better than me WILL. --HectorMoffet (talk) 03:00, 8 February 2014 (UTC)
- ...or mine, which was posted much later and also largely ignored. These things don't just happen by magic. They require organization and cooperation. --Guy Macon (talk) 18:39, 7 February 2014 (UTC)
- If you're that confident you should have taken my advice weeks ago.--Cube lurker (talk) 13:20, 7 February 2014 (UTC)
- It's all about domestic American politics, thus outside the scope of the global Wikipedia community. SCOPA was a threat to Wikipedia's existence, this issue isn't. I really don't care if the NSA/FBI/CIA/<insert alphabet-soup de jour> wastes their time to read everything I have ever written here - they'll find it ridiculously boring (in the national security sense). Roger (Dodger67) (talk) 11:55, 7 February 2014 (UTC)
-
- Yeah, but what if you lived in a place where killer robots controlled the skies. Would you really feel free to read whatever you wanted? --HectorMoffet (talk) 12:11, 7 February 2014 (UTC)
- Is there any credible evidence that the "killer drones" have ever targeted anyone based purely on what Wikipedia articles they have read? AFAIK the only people who kill other people because they read "politically incorrect" literature are the radical Islamists - they kill people for possessing un-Islamic books. This is not a defence of US military policy, I'm simply pointing out the absurdity of your scenario. AFAIK the innocents killed in drone strikes have been due to simple target misidentification, none of them were actually intended targets (as your scenario requires). I'm done here - as non-American of a non-Islamic persuasion this is a total non-issue for me. Roger (Dodger67) (talk) 12:26, 7 February 2014 (UTC)
- There is a lack of evidence because the targeting is secret. However, it is publicly known that militants can be selected by these things based on "behavioral characteristics" [5]. These characteristics can include (as that source explains) being a medical professional going to the aid of someone injured in a drone strike. So no, killing people for what they read on Wikipedia would not seem beyond the controlles' moral capabilities. Wnt (talk) 17:34, 7 February 2014 (UTC)
- Is there any credible evidence that the "killer drones" have ever targeted anyone based purely on what Wikipedia articles they have read? AFAIK the only people who kill other people because they read "politically incorrect" literature are the radical Islamists - they kill people for possessing un-Islamic books. This is not a defence of US military policy, I'm simply pointing out the absurdity of your scenario. AFAIK the innocents killed in drone strikes have been due to simple target misidentification, none of them were actually intended targets (as your scenario requires). I'm done here - as non-American of a non-Islamic persuasion this is a total non-issue for me. Roger (Dodger67) (talk) 12:26, 7 February 2014 (UTC)
- So, "killer robots" and "killer drones" have become buzzwords for surveillance awareness? That's pleasant, and yes, I'm in favor of awareness. Awareness of the world is the purpose of Wikipedia. And yes, more surveillance can also promote awareness of the world and there ought to be more well organized surveillance webcams. That way, millions of people can be more aware of millions of places. However, promoting awareness through surveillance is not in our purview. The most we should do is link to a few of the webcams that are surveilling a particular place, from our articles about a place. Jim.henderson (talk) 16:29, 7 February 2014 (UTC)
- That is correct. "Killer robots" and "killer drones" have indeed become buzzwords for surveillance awareness, and rightly so. See The NSA’s Secret Role in the U.S. Assassination Program. --Guy Macon (talk) 08:12, 11 February 2014 (UTC)
- Yeah, but what if you lived in a place where killer robots controlled the skies. Would you really feel free to read whatever you wanted? --HectorMoffet (talk) 12:11, 7 February 2014 (UTC)
- I've taken the liberty of redirecting WP:Surveillance Awareness Day to WP:WikiProject Mass Surveillance. The EFF may have been misled by the "rejected" tag formerly at this page, which wasn't really the result of a consensus and applied only to some of the ideas discussed on the page. The "historical" tag doesn't belong on a page at all unless you don't blank the contents. Clearly those interested need to be redirected to the ongoing efforts. Bottom line: Surveillance awareness is no longer one day. Wnt (talk) 17:43, 7 February 2014 (UTC)
- Too Late Without even addressing the serious issue of whether Wikipedia should get involved, the timing issue is persuasive. Doing something right would take far more than a week, and doing something half-baked is worse than doing nothing.--S Philbrick(Talk) 15:53, 10 February 2014 (UTC)
- Too little, too late. Interesting, but Wikipedia does those things very, very slowly. Maybe if they keep on bringing this up we will have time to hold a wider discussion about doing this by next year. Also, it would be good if their activists would join Wikipedia:WikiProject Mass surveillance and help improve related content. Someone suggested that the best way to deal with such proposals is to write and feature related articles as DYKs/FA. I think it would be easiest to do just that, --Piotr Konieczny aka Prokonsul Piotrus| reply here 15:58, 10 February 2014 (UTC)
- Bummer. I'm not knowledgeable about how the Wikipedia politics work but I read an article today discussing major websites supporting The Day We Fight Back and it described only Google and Wikipedia as being notably absent among those who participated in the SOPA protest (and even Google may be participating now according to a Facebook spokesperson who is part of joint task force with Google and other companies). Anyway, kinda disappointing that Wikipedia couldn't get its act together to do something as simple as add a few lines of javascript to the home page for one day. I certainly would have voted for it if there had been some kind of notice to editors. Took a good bit of searching and asking around to even find this page... :( Steevithak (talk) 02:54, 11 February 2014 (UTC)
- The Wikians have voted more than 95% for Wikia to join the Day We Fight Back protests. You can too. See Jimbo's talk page. The URL for voting is http://community.wikia.com/wiki/User_blog:Semanticdrifter/Digital_Protest_Against_the_FISA_Improvements_Act —Neotarf (talk) 18:29, 11 February 2014 (UTC)
-
- You can tell it's accurate because it lets you vote even if you don't have a wikia account.--Cube lurker (talk) 18:38, 11 February 2014 (UTC)
- After getting a few requests from the EFF and similar groups to get engaged in this sort of activity, we started writing a draft guide on how organizations should approach working with Wikimedians -- you can find it at Asking Wikimedians To Support Advocacy on Meta. If you are interested in the topic, your input would be very helpful! Stephen LaPorte (WMF) (talk) 22:33, 21 February 2014 (UTC)
Restrict A class usage
Background As far as I can tell, only two WikiProjects make wide use of the "A" assessment; WikiProjects Military History and Hurricanes. These are two of the largest and best organized projects we have, and they have both the local expertise and the participation levels to sustain an in-project assessment system. WikiProject Film has an A class assessment, and a few A class articles, but they appear to be from 2009 and earlier. Outside of those projects, there is a smattering of other articles marked as A, and it is not always clear what criteria are being used and whether or not there was a formal review. Niemti has, on three occasions, started a talk page thread in articles that were already GA class, elicited support from two or three people for assessing the article as A class, and then changed the assessment. I'm not sure, but I think that these are the only three A class video game articles. Although the Video Game WikiProject is one of the few that could possibly sustain A class assessments, there doesn't appear to be a formal process. There is a smattering of Road and Television articles that also are marked as A class, but I can't even figure out how they got that way. There are also a handful of pages assessed as "A" that are a far cry from it, and were rated as A class by the author (apparently not aware that A class requires an assessment by another user.)
Proposals
- Proposal 1: "A" should only be given as the result of a formal assessment by a project that is conducting such assessments (i.e. not by talk page thread and not unilaterally). It is up to the projects themselves to determine what the specific requirements are, and how to run the assessments. Only projects that are large enough and organized enough to properly do assessments should do so; new projects have to prove that they are sustainable before they can do A class assessments.
- Proposal 2: Only the projects that have formal assessment schemes should have A class enabled as an option in their talk page templates, For projects that don't have the assessment, if "A" is stuck in the class= slot, it will appear as B class. This prevents people from unilaterally adding a rating that suggests an assessment was done because they didn't understand how the ratings work. Here is a good example of where someone has given A ranking to an article that has never been formally assessed and is generously C quality (diff shows me undoing it).
Proposal 3: A class assessments should, in cases where a GAN has not been done, count as a GAN. WikiProjects Military History and Hurricanes are fully capable of determining what is and is not GA class. Therefore, if they do an assessment of an article that has never been to GAN, and declare it A class (which ranks higher in terms of quality than GA), it should be considered a GA by projects that do not have A class assessments, as if it went through GAN.- Proposal 3A: In order to be ranked as A class, an article must have already been promoted to GA class through the standard GAN process.
- Proposal 3B: In order to be ranked as A class, an article must either have already been promoted to GA class, or must be checked against the GA criteria during the A class assessment (i.e. an article can be assessed against the GA and A class criteria at the same time, by the same person or people). A class assessments should always be done in a subpage (either of the article or the wikiproject) and transcluded to the article's talk page. If the article was not already a GA, the A class assessment should contain a formal GAN-style review, in addition to the A class review.
Please let me know your thoughts on these ideas. 3A and 3B are mutually exclusive, but 1, 2, and either of the 3s are not mutually exclusive with each other. They should all be able to stand on their own, if necessary. Sᴠᴇɴ Mᴀɴɢᴜᴀʀᴅ Wha? 21:03, 13 February 2014 (UTC)
Comments
Support all threeSupport 1, 2, either 3A or 3B as nominator. Sᴠᴇɴ Mᴀɴɢᴜᴀʀᴅ Wha? 21:03, 13 February 2014 (UTC)- Have you actually read Wikipedia:Version 1.0 Editorial Team/Assessment/A-Class criteria?
I strongly object to A-class assessment "counting" as GAN. GAN happens against the WP:Good article criteria, not according to whatever someone believes is pretty good. While an A-class article should meet those, there's no guarantee that the WikiProject reviewers will actually check those specific items. WhatamIdoing (talk) 03:53, 14 February 2014 (UTC)- Yes, WhatamIdoing, I have. It says "Only minor style issues and other details need to be addressed before submission as a featured article candidate.", which to me at least is a very high standard. I understand your reluctance, and will edit point 3 in a moment. Do you have any comment on the other two points? Sᴠᴇɴ Mᴀɴɢᴜᴀʀᴅ Wha? 05:28, 14 February 2014 (UTC)
- Comment: WikiProject Highways inherited its ACR process from two of its subprojects (the U.S. Roads and Canada Roads wikiprojects), and it requires any nominees be listed as a GA before nomination. The process is also used by other subprojects for Australia, Hong Kong and the UK. Imzadi 1979 → 03:58, 14 February 2014 (UTC)
- Support proposals 1, 2, and 3A, with the understanding that under these proposals WP:HWY would still be able to use our A-Class review system. Not sure how you missed it in your original proposal, but our ACR system has been around for longer than I've had an account on this site, and it's a historically successful system; four out of five articles that pass HWY/ACR pass their first FAC. TCN7JM 06:09, 14 February 2014 (UTC)
- To some extent, this is simple - I believe most (but not all) Wikiproject templates are based on, and substitute a standardized template. We could easily add a switch | aclassenabled= where A-class is only available if that is set to "yes". I believe some are non-standard, however.
One issue: What if an article is rated A-class by, say, WP:MILHIST, but is also in, say, a politics Wikiproject? Should it be allowed to be A-class in that case? Adam Cuerden (talk) 06:01, 14 February 2014 (UTC)
- My stance is that no, it should be listed as a GA for classes that don't do A class assessments. Unlike other ratings, which are communal, only a small number of projects both care enough to do A class assessments and are equip to do so. Allowing A class in other project's templates has and will continue to cause confusion and mislabelings. Sᴠᴇɴ Mᴀɴɢᴜᴀʀᴅ Wha? 06:28, 14 February 2014 (UTC)
- Why? What benefit is there to this? WhatamIdoing (talk) 18:33, 14 February 2014 (UTC)
- WhatamIdoing, Izno: The idea behind proposal 1 is to prevent people, predominantly inexperienced users, from unilaterally marking an article as A class, which gives the impression that the article went through an audited, peer review process. Ultimately that is what GAN, A class reviews, and FAC are. They are our peer review systems, and for them to matter, we have to make sure that things tagged at those levels meet a high standard. The idea behind proposal 2 is to remove the responsibility for enforcement from WikiProjects that are not organized enough to do so. Larger projects are able to keep track of their recognized content better than smaller projects ever will be. While we have bots that keep track of FA and GA class additions, there is no bot in place that checks to make sure that an article with an A class assessment actually went through that assessment. By making A class only an option in projects that actually do A class reviews, we remove the need for smaller projects to check their content for mistaggings. The idea behind 3A and 3B is to set a common minimum standard from which A class can build off of. Having a rating that is in between GA and FA is useless if the pages that have that rating don't meet the standards of the level below it. Sᴠᴇɴ Mᴀɴɢᴜᴀʀᴅ Wha? 01:45, 15 February 2014 (UTC)
- Because if MILHIST says it's B-class, it's safe for me to copy that to another project, but if MILHIST says it's A-class, then MILHIST probably screwed up somehow and I shouldn't agree with them? The problem with mis-assessments is when someone invents a rating that nobody agrees with, not when someone copies over a rating that another group of editors has determined is well-deserved. (Also, people don't mess with the class rating nearly as often as they declare a subject to be Top-priority for all WikiProjects.) WhatamIdoing (talk) 02:01, 15 February 2014 (UTC)
- If your only case in support of proposal 1 is that inexperienced users are a problem, this seems like a rather draconian method to deal with what again is a social issue.
"things tagged at those levels meet a high standard" – That's true, but irrelevant. It doesn't make the case for changing how it works.
"remove the responsibility for enforcement from WikiProjects that are not organized enough to do so" – Irrelevant. If they don't want to use ratings, that's their prerogative, not yours or the community at large's, and forcing the WikiProjects to do anything has never been an enjoyable endeavor (not to bring up WP:BIRDS and WP:Article names, but... birds). Also, agree with WhatamIdoing on this point.
As for 3A and 3B, that's sophistry. A is not GA and has no relation to it beyond that some projects place A articles as higher than GAs and some lower; the more meaningful relation is that A-class articles are above B-class articles.
@Sven Manguard: Please readd the status quo as an option. You have created a false quad-chotomy by forgetting to include "no change" as an option. Thanks. Additionally, you do not own the discussion and it's "rude" to assume that you do. --Izno (talk) 03:37, 15 February 2014 (UTC)
- Izno - I disagree. I made it rather clear that people were free to support or oppose any and all of the proposals. You personally are free to support or oppose anything you wish, but you should do so in a comment that is followed by your signature. You are not free, per community norms, to edit someone else's prose, which is what you did when you inserted your Proposal 0 in between the prose that I wrote and my signature. When I said "That's not an actual proposal, and while it's an option, it's still rude to do it like that", the "like that" was in regards to you putting your text into my paragraph. This isn't an article, where who authors what is irrelevant; this is a discussion thread, where - at least until Flow is launched - it is difficult enough keeping track of who said what, when, even without people sticking their comments in the middle of other people's comments. Sᴠᴇɴ Mᴀɴɢᴜᴀʀᴅ Wha? 04:50, 15 February 2014 (UTC)
-
I see nothing in any of the text that you wrote as claiming that any and all may be rejected. You never made such a positive claim about your proposals, so I do not know how you can say that you "made it rather clear".
"You are not free, per community norms..." It is normal, per community norms, not to sign your proposals (that's a rather large indicator that the initial discussion may be biased, wouldn't you agree?), and the fact that you're wiggling around that by claiming that I edited your comments is simply obnoxious. If you would like to move or amend my added text, you are free to do so, but I ask again – @Sven Manguard: Please add an option which makes it clear that there is a no change option. Thanks. --Izno (talk) 14:51, 15 February 2014 (UTC)
- Izno, sometimes we do have signed proposals, especially when (as in this case) the proposal comes from a single person. You could re-add your "Proposal 0" after his signature, if you thought it important, or you could !vote Oppose all. WhatamIdoing (talk) 17:01, 15 February 2014 (UTC)
-
- Izno - I disagree. I made it rather clear that people were free to support or oppose any and all of the proposals. You personally are free to support or oppose anything you wish, but you should do so in a comment that is followed by your signature. You are not free, per community norms, to edit someone else's prose, which is what you did when you inserted your Proposal 0 in between the prose that I wrote and my signature. When I said "That's not an actual proposal, and while it's an option, it's still rude to do it like that", the "like that" was in regards to you putting your text into my paragraph. This isn't an article, where who authors what is irrelevant; this is a discussion thread, where - at least until Flow is launched - it is difficult enough keeping track of who said what, when, even without people sticking their comments in the middle of other people's comments. Sᴠᴇɴ Mᴀɴɢᴜᴀʀᴅ Wha? 04:50, 15 February 2014 (UTC)
- WhatamIdoing, Izno: The idea behind proposal 1 is to prevent people, predominantly inexperienced users, from unilaterally marking an article as A class, which gives the impression that the article went through an audited, peer review process. Ultimately that is what GAN, A class reviews, and FAC are. They are our peer review systems, and for them to matter, we have to make sure that things tagged at those levels meet a high standard. The idea behind proposal 2 is to remove the responsibility for enforcement from WikiProjects that are not organized enough to do so. Larger projects are able to keep track of their recognized content better than smaller projects ever will be. While we have bots that keep track of FA and GA class additions, there is no bot in place that checks to make sure that an article with an A class assessment actually went through that assessment. By making A class only an option in projects that actually do A class reviews, we remove the need for smaller projects to check their content for mistaggings. The idea behind 3A and 3B is to set a common minimum standard from which A class can build off of. Having a rating that is in between GA and FA is useless if the pages that have that rating don't meet the standards of the level below it. Sᴠᴇɴ Mᴀɴɢᴜᴀʀᴅ Wha? 01:45, 15 February 2014 (UTC)
- Why? What benefit is there to this? WhatamIdoing (talk) 18:33, 14 February 2014 (UTC)
- My stance is that no, it should be listed as a GA for classes that don't do A class assessments. Unlike other ratings, which are communal, only a small number of projects both care enough to do A class assessments and are equip to do so. Allowing A class in other project's templates has and will continue to cause confusion and mislabelings. Sᴠᴇɴ Mᴀɴɢᴜᴀʀᴅ Wha? 06:28, 14 February 2014 (UTC)
- Reject options 3A and 3B per WhatamIdoing. Reject 1 as it does seem to take autonomy away from WikiProjects, which should always have autonomy to act as necessary (within the bounds of WP:LOCALCONSENSUS). Reject 2 as that seems to be a technical solution where a social solution makes more sense (education!). In fact, point 2 seems almost directed at fixing non-obvious vandalism, of which I'm not sure the occurrence is high enough to remove a WikiProject's autonomy. It would also defeat the various bots that (used to?) run to synch the settings. In other words, prefer option 0, status quo. In fact, the above proposals seem not to have any pros. It's not broken, so why fix it? --Izno (talk) 14:17, 14 February 2014 (UTC)
- Support 1, 2 and 3A, as this is the standard we use over at WP:HWY/ACR, which has a 90% success rate in promoting A-Class articles at their first FAC since 2010. - Floydian τ ¢ 22:34, 14 February 2014 (UTC)
- "1" and "3A" are mutually exclusive options. "1" says that each project gets to set its own standards, and "3A" tells them what their "own" standards must include. WhatamIdoing (talk) 23:07, 14 February 2014 (UTC)
- 3A just says the article has to be a GA. Going by WikiWork measurements, which is what a lot of projects use these days to gauge where their project or task forces of their project are at as a whole, A is higher than GA anyway. Although, I see where your concern is, and I'd advise @Sven Manguard: to change Proposal 1 to read that an article must be a Good Article before it can be assessed as A-Class...unless, of course, he was trying to do exactly the opposite. TCN7JM 23:46, 14 February 2014 (UTC)
- WhatamIdoing: They are not mutually exclusive options. Keep in mind that "A" class is considered above GA class. They're not equal, parallel ratings. The point of proposal 1 is to prevent people from just deciding that something is A class and tagging it as such, without the article going through an actual assessment. The point of proposals 3A and 3B are to establish a minimum baseline. Think of it this way: each specialty in medicine is free to determine what requirements it takes to be an accredited member of that specialty, but all of them have in common that their members had to go through medical school first. 3A and 3B are designed to make sure that, while each Wikiproject is free to choose which specific points they want to highlight in their A class reviews, in the end A class denotes something above and beyond GA class. Sᴠᴇɴ Mᴀɴɢᴜᴀʀᴅ Wha? 01:36, 15 February 2014 (UTC)
- A-class is only considered "above" GA and "below" FA by the makers of WikiWork, which almost nobody actually cares about. At least once upon a time, we had A, B, Start, and Stub, and GA and FA were unrelated, separate settings. In fact, A-class used to be considered higher than FA by some people. WhatamIdoing (talk) 02:01, 15 February 2014 (UTC)
- Sounds like nobody is really sure exactly what the agreed upon hierarchy is. I was under the impression that A was below GA, apparently I was mistaken, but it made reading this proposal especially confusing. --NickPenguin(contribs) 02:07, 15 February 2014 (UTC)
- We aren't in those times anymore. It doesn't really matter what the assessments used to be considered. A-Class is nowadays clearly not higher than the sitewide FAC process, and this proposal is for the future, not the past. Also, regarding WikiWork, speak for yourself. TCN7JM 02:41, 15 February 2014 (UTC)
- GA/FA have always, repeat always, stood separately from the A–start scheme. It's a WikiProject rating, not a wiki-wide rating. Period. Asserting that this is "for the future" is simply sophistry. That tools are configured to treat ratings in a certain fashion is irrelevant to the social aspects of WikiProjects. --Izno (talk) 03:37, 15 February 2014 (UTC)
- A-class is only considered "above" GA and "below" FA by the makers of WikiWork, which almost nobody actually cares about. At least once upon a time, we had A, B, Start, and Stub, and GA and FA were unrelated, separate settings. In fact, A-class used to be considered higher than FA by some people. WhatamIdoing (talk) 02:01, 15 February 2014 (UTC)
- WhatamIdoing: They are not mutually exclusive options. Keep in mind that "A" class is considered above GA class. They're not equal, parallel ratings. The point of proposal 1 is to prevent people from just deciding that something is A class and tagging it as such, without the article going through an actual assessment. The point of proposals 3A and 3B are to establish a minimum baseline. Think of it this way: each specialty in medicine is free to determine what requirements it takes to be an accredited member of that specialty, but all of them have in common that their members had to go through medical school first. 3A and 3B are designed to make sure that, while each Wikiproject is free to choose which specific points they want to highlight in their A class reviews, in the end A class denotes something above and beyond GA class. Sᴠᴇɴ Mᴀɴɢᴜᴀʀᴅ Wha? 01:36, 15 February 2014 (UTC)
- 3A just says the article has to be a GA. Going by WikiWork measurements, which is what a lot of projects use these days to gauge where their project or task forces of their project are at as a whole, A is higher than GA anyway. Although, I see where your concern is, and I'd advise @Sven Manguard: to change Proposal 1 to read that an article must be a Good Article before it can be assessed as A-Class...unless, of course, he was trying to do exactly the opposite. TCN7JM 23:46, 14 February 2014 (UTC)
- "1" and "3A" are mutually exclusive options. "1" says that each project gets to set its own standards, and "3A" tells them what their "own" standards must include. WhatamIdoing (talk) 23:07, 14 February 2014 (UTC)
- This is a proposal to change Wikipedia:Version 1.0 Editorial Team/Assessment. I've left notes for the Wikipedia talk:Version 1.0 Editorial Team about this discussion. Someone else left a note for WT:COUNCIL, which is a central point for people interested in WikiProjects (although it formally has no role in article assessment as such). WhatamIdoing (talk) 19:04, 15 February 2014 (UTC)
- Oppose all. A class is a project-level ranking, no different than B, C, Start or Stub. Consequently, I reject proposal 1 as the few projects that bother with A class should be permitted to set their own requirements on determining if an article is A class. And by the same token, if an article is in multiple projects and one uses an A class, that should not cascade as a rating for the other projects if they don't use it. I reject proposal 2 for the same reason. I reject both 3A and 3B because I do not hold that A class is superior to GA. At its absolute best, it could be considered parallel, but in truth, it is actually redundant. And that, I think, is why almost no projects bother with it. Resolute 02:06, 16 February 2014 (UTC)
- Support 1, 2, and 3A WPMILHIST has it right. 3A serves as a check on any individual WikiProject that the article has undergone the process from WPGA. No WikiProject should be able to overrule GA on adherence to GA rating. I'm curious about who will evaluate number 2 and how that will be done. I'm part of the semi-moribund WikiProject History (parent of all history-related wikiprojects) and we don't have a separate A-Class process. What's to stop me and three other editors from nominating and evaluating A-class for History? I'd like to see some external consensus for a WikiProject's viability for A-class. Chris Troutman (talk) 21:05, 16 February 2014 (UTC)
- Question What is the benefit to be gained by the additional bureaucracy? What is the harm caused by the WikiProjects with less formal assessment schemes? I see that the proposals may lead to a handful fewer articles in Version 1.0 as it drops their score down a lot, though I don't see that as a major benefit or loss, as there are very few informal A articles --Hroðulf (or Hrothulf) (Talk) 14:02, 17 February 2014 (UTC)
- Oppose all, for the same reasoning as Resolute. In particular, I do not see what problem this is intended to solve. There is no evidence that there is any confusion, or that anyone is being misled, or that the rating is used inappropriately. To establish guidelines to deal with non-existing problems is the very essence of bureaucracy , and a direct contradiction of the basic principle of NOT BURO. If projects are doing nothing harmful to the encyclopedia, and not disrupting other standards, or outraging the general standards of the community, let them use ratings as they see fit. It's not as if our use of ratings is that exact, or free from disputes in specific cases , and this was introducing inconsistency into the system. The milhis project is the most consistent of all projects here, and why anyone should want to interfere with it escapes me. We should encourage other projects to emulate it, and if they want to use ratings like milhis does, all the better. If they want to use them slightly differently in away which is not contradict the general system, I see nothing wrong with that either. When we actually have a problem, then we can deal with it. DGG ( talk ) 16:21, 17 February 2014 (UTC)
- Comment: Do we even need an A-class? GA means that there's the possibility of FA, an extra step in between that's rarely used just seems like it's unneeded. What if we eliminate the A status altogether, grandfathering in the current ones? Supernerd11 :D Firemind ^_^ Pokedex 17:19, 17 February 2014 (UTC)
- Support proposals 1, 2, 3A and 3B, agree with rationale by nominator, above. Cheers, — Cirt (talk) 02:57, 18 February 2014 (UTC)
- Oppose All - I favor the elimination of A-class altogether... STUB-START-C-B for self-assessments; GA and FA through a process, assuming people want to go through the process. Carrite (talk) 03:50, 18 February 2014 (UTC)
- Tentative support for 1, 2 - Although I don't like to see restrictions imposed on how WikiProjects assess, I can see there is a good case for tightening up how A-Class is assigned. It undermines the value of A-Class if someone can unilaterally inflate the assessment of an article that's outside one a the big projects, even if it's done in good faith. I don't think project size is critical - if you have three active people in a WikiProject that may well be enough to get a decent review, as long as the it's done through a formal process. However, it's clear that the "basic method" described here is not widely used. Walkerma (talk) 19:58, 20 February 2014 (UTC)
- Oppose 1, and all of the 3's, Tentative support 2. We shouldn't be telling projects what they can and cannot have for grading scales, and if they want to put the effort into creating or adopting a set of requirements for an A class article, that is entirely up to them. It also shouldn't hinge on the level of participation, as long as there is a set guideline as to what does or does not qualify, the rest is entirely irrelevant. — {{U|Technical 13}} (t • e • c) 18:12, 21 February 2014 (UTC)
- Oppose; The proposal attempts to mix together two divergent rating/grading systems, each concerned with differing parameters of the article(s) in question, and would therefore be an additional muddying of the waters surrounding the article class system currently used by wiki-projects. To begin with, the use of the "A" class rating by some projects and not others is a moot point. Even if, for instance, a project wants to come up with a class system that carries the "grading" system in the other direction (I'm all for adding "D," "E," "F", etc. classes as necessary), who are we to worry about it or try to control it? As long as the project members understand and accept the specified parameters involved, the class system is simply their tool for finding articles which need specific improvements and it should be left alone. FA and GA have nothing to do with the project classification ratings within the projects themselves. The proposal is really not necessary, and at best another example of bureaucracy creep. GenQuest "Talk to Me" 21:56, 21 February 2014 (UTC)
- Oppose all. GA and FA are project wide, and hence suitable for larger governance. There is no rational reason why any other classifications should be under the purview of anyone except the given wikiproject. If you want to create a new article class for articles that have passed some sort of site-wide review not covered by GA or FA standards, please feel free. But restricting wikiprojects from using classes is just pointless bureaucracy. VanIsaacWS Vexcontribs 22:24, 21 February 2014 (UTC)
- Strong Oppose All First off, I don't think there's a reason to make a general rule when there isn't an identifiable problem - there are a "handful" of pages that are inappropriately labeled as A? Doesn't sound like a problem that needs an added layer of formal process to solve. Second, it really strikes me as a problem to be making general rules for how WikiProjects can rate the articles in their scope. If I start WikiProject Alternative Methodology tomorrow and start rating articles on a Check, Check Plus, Check Minus system, are you going to require that I have a formal process to rate something Check Plus now? What if I start WikiProject Contrarianism, where ratings are inverted, and only FA-class articles are rated as Stubs? Would my whole scheme be disallowed? In my view, article rating on a project-by-project basis is little more than internal bookkeeping, and it seems like it's no one's business but the Project's how they want to rate articles. 0x0077BE [talk/contrib] 08:02, 22 February 2014 (UTC)
- Oppose all - as mentioned, this is a solution in search of a problem; if articles are being improperly assessed, the solution is to correctly assess them, not to suggest that an entire assessment level be tossed out or restricted. I've seen lately some articles that are not stubs having assessments changed from "start" to "stub" based on misunderstandings of what a stub is, but I don't think anyone would seriously suggest restricting or doing away with the Stub assessement because of it. - The Bushranger One ping only 08:25, 22 February 2014 (UTC)
Asking for closers
In some cases where a discussion is likely to be complex and contentious, someone (usually me) has asked ahead of time for closers at WP:AN, so that they can hit the ground running when the discussion closes (usually at the 30-day mark). This looks like one of those cases, and I'll go make the notification. - Dank (push to talk) 17:57, 21 February 2014 (UTC)
Add multiple pages to your watchlist at once
Is there a way to add multiple pages to your watchlist at once, i.e. all the links in a template on the bottom of a page? This could really come in handy for if you're into a topic that has a lot of subtopics, like Pokemon. Supernerd11 :D Firemind ^_^ Pokedex 01:34, 16 February 2014 (UTC)
- The closest way would be to edit your raw watchlist. Alternatively, you might try Special:Recentchangeslinked/Template:Pokémon (for example). --Izno (talk) 02:41, 16 February 2014 (UTC)
- These work, as well as what I was doing before (hovering over each one in the navbox on the bottom of the page and selecting "Watch" from the mouseover box), but I was hoping for something like "Watch all subpages". I don't have the developer know-how, is there someone who can do that? Supernerd11 :D Firemind ^_^ Pokedex 03:18, 16 February 2014 (UTC)
- The "Related changes" feature reports all changes to pages linked from a given page. See Help:Related changes for more information. DMacks (talk) 05:05, 22 February 2014 (UTC)
Protest proposal
Here and here, you can see that on our friendly project, Wikia, has been launched some kind of digital protest against massive surveillance by the U.S. National Security Agency (NSA). Maybe we should start something like that and send a good message to the world. Please post your opinions and ideas how that could be realised. Also, we should probably vote on this? Alex discussion ★ 21:01, 16 February 2014 (UTC)
- There were proposals to participate in The Day We Fight Back on February 11. However, like that protest in general, it failed to materialize. - Floydian τ ¢ 22:04, 16 February 2014 (UTC)
- Maybe we could try again? What is needed for that protest to materialise here? Alex discussion ★ 22:59, 16 February 2014 (UTC)
Winter sports in Category:Sports by year
Winter sports are often played autumn-spring, making one "year" span two half-years. Shouldn't they be treated that way in the year categories too? So the "year" is not like 1990 but like 1989/90 and 1990/91? Bandy boy (talk) 08:46, 17 February 2014 (UTC)
- To Bandy boy: By winter sports, do you mean snow and ice sports, or sports that are traditionally not played in the summer?
- It is already done for some sports. See for example Category:1996–97 in English football.
- What changes to which categories do you propose?
-
- I mainly thought of snow and ice sports, particulary the categories under Category:Years in bandy, but I suppose the same would go for any sport where the traditional season is autumn-spring rather than spring-autumn. Bandy boy (talk) 21:54, 17 February 2014 (UTC)
- For hockey, we put (e.g.) 2012–13 NHL season into both Category:2012 in ice hockey and Category:2013 in ice hockey. The league seasons often cross two calendar years, but most tournaments are in one or the other. Resolute 20:18, 20 February 2014 (UTC)
- I mainly thought of snow and ice sports, particulary the categories under Category:Years in bandy, but I suppose the same would go for any sport where the traditional season is autumn-spring rather than spring-autumn. Bandy boy (talk) 21:54, 17 February 2014 (UTC)
Proposed new Archive namespace
When talk pages get too long, the older comments are usually archived to subpages either manually or by a bot, with a name like Talk:PageName/Archive 1 or Talk:Pagename/Archive February 2014. There are some other pages that get archived too, but mainly it is talk pages. Archiving usually results in a redlink mainspace, which has often been redirected back to the article/userpage etc. Occasionally people add comments to these archived pages despite notices asking them to add new comments to the parent talkpage.
I propose the creation of a new set of associated namespaces called "Archive:", to serve as more organized locations for all archived pages. It would probably require a software change but I was thinking it could be attached to the talk pages, for example as a tab next to the history tab, or there could be a link from the top of the talkpage and/or the history.
The format for mainspace would be either "Archive:PageName 1" or "Archive talk:PageName 1" or "Talk archive:PageName 1". For the other namespaces it would be Archive User:, Archive W:, Archive File:, Archive MediaWiki:, Archive Template:, Archive Help:, Archive Category:, Archive Portal:, Archive Book:, Archive Draft:. Alternatively the styles could be User archive:, Wikipedia archive and File archive etc. However I'm not opposed to the idea of leaving userspace out of this proposal.
A rudimentary search suggests there are approximately 156,000 article archives, 178,000 user archives, 23,000 Wikipedia archives, and just under 8,000 for the other namespaces, although these numbers should be taken with a pinch of salt because the search includes any use of the word "archive". Green Giant (edits) (talk) 14:22, 17 February 2014 (UTC)
- There's a product under active development, called WP:Flow, that aims to create an improved "discussion and collaboration" system. Making topics (threads) archive automatically, without the incoming links breaking when the topic is archived as they do now, is just one of the core goals. (Currently they're using an "infinite scroll" model, with auto-pagination for non-js users, but active/ongoing testing and feedback from us, may lead in different directions, in the future). It is a massively complicated and long-term project, and everyone's input/suggestions/feedback (at the talkpage there, not here, to avoid more fragmentation!) is encouraged and appreciated, over the months. HTH. Quiddity (WMF) (talk) 19:37, 17 February 2014 (UTC)
- I don't see much benefit to this proposal over the current subpage method, since subpages are typically linked from the main talk page, and are often searchable. Subpage archives can be protected at user request to prevent other uses from responding to an archive. That alone isn't enough for me to oppose this proposal, but with Flow being developed to replace the current talk page system, I'm not sure it's a good time to make this change. Novusuna talk 21:01, 17 February 2014 (UTC)
- Flow is still a long way from being implemented wiki-wide, because even now there is a tentative date of "2015 and beyond". In the explanation in WP:Flow/FAQ, the stated intention is to archive current talkpages and link to the archives from the header. After Flow is implemented, the idea will be to summarise topics. With the best will in the world, there will only be so much summarizing of topics before people start asking for archiving. I am in favour anything that improves the systems but it isn't realistic to think that archives won't be needed in the long term. That's why I'm proposing that archives be given a formal space. I don't think search functionality will decrease just because they aren't subpages, on the contrary you'd be able to refine a search to the archive namespace. Green Giant (edits) (talk) 01:14, 18 February 2014 (UTC)
- I think it's more important and useful to keep "current and archive" together (page and subpages) than to keep "all archives" together. The present system makes it easy to delete/rename the whole lot of them. Is it often the case that one would want to search all archives but not the current pages? But even still, the "search only archives of a page" feature already exists:
prefix:Talk:Foo
searches Talk:Foo and all Talk:Foo/* subpages whereasprefix:Talk:Foo/
only searches in subpages. Could you explain what "Archiving usually results in a redlink mainspace" means? DMacks (talk) 05:02, 22 February 2014 (UTC)
Android Nearby
Is there a better page for this? Anyway the Android app has a nice feature to read our GPS location and show a map of nearby articles. Handy, but it could be far more useful:
- Atlantic Ocean. The first thing that comes up is a sea of blue. That's because it hasn't read GPS yet, and assumes we are at Longitude Zero, Latitude Zero, mid-Atlantic. If you're indoors or for some other reason GPS isn't giving a location, it stays that way. Needlessly confusing, hence wrong. Should show a world map until it finds a location, or at least a "No GPS yet" indicator.
- True GPS only. I generally keep GPS turned off because it drains my battery too fast. Google Maps for Android still knows where we are, presumably due to cell tower triangulation and WiFi footprints. Wikipedia app should do the same, or ask GM.
- Battery. Wikipedia app drains my battery even faster than GM does when GPS is on.
- Desert. If we're in an area that has no Wikipedia articles, it shows nothing. Or if it thinks we're in mid-Atlantic. Should adjust zoom level until there's a reasonable number of points to show, say five to thirty or some such range.
- Comeback. It's useful to tap on an article, find out that it's not one we want to visit, and use the back arrow to go back to the map for another go. Except, the map shows mid-Atlantic again because the app has already totally forgotten where we are. Should be able to remember for, like, even a whole minute.
- Nearby what? We're looking at an article when we hit the menu key, right? If the article has coords, the menu should ask something like, "Near to you, or where this article is?" If it's a list of a hundred coords, show them all and let us zoom and pan for the right ones.
- Pictures. Should have an option to see where the Commons pictures are in this neighborhood, with a different and preferably smaller icon.
Again, I hope someone can direct me to a forum or discussion place for this kind of thing. Jim.henderson (talk) 22:36, 17 February 2014 (UTC)
- You are looking for the Mobile team. In general their active discussion happens on their mailing list, but i'll ping them on IRC to read their feedback page. —TheDJ (talk • contribs) 09:45, 19 February 2014 (UTC)
Issue with the use of Columns
I don't want to cause issues and get anyone in trouble if I'm on the wrong page, but I want to discuss an issue with the use of columns. I think it causes annoyance to anyone who uses computers and laptops, regardless of what others who use cell phones and iPods say about them. I proposed that we should setup a special program that would allow anyone who uses cell phone, iPods and such mobile devices to see articles that would allow them to see sub-sections and tables without going long hauls to look over them and anyone using computers and laptops won't have to see short tables and sub-sections due to unnecessary size of columns which would annoy and frustrate many readers who use computers and such. Think about that. If I wrote this proposal on the wrong page, tell me where to put it at. BattleshipMan (talk) 03:13, 19 February 2014 (UTC)
- I don't think I understand your proposal. There is a separate mobile site, so it might be possible. But do you want to use columns for desktop computers and not on mobile, or the other way around? WhatamIdoing (talk) 04:41, 19 February 2014 (UTC)
- Count me among the confused as well. I can't tell what exactly is being proposed here. Novusuna talk 04:45, 19 February 2014 (UTC)
- What I meant to say is that columns should only be used in mobile and not on desktop computers. The unnecessary size use of columns is becoming an annoyance to anyone using desktop computers and some users are unnecessarily using columns sizes to cut down larger sub-sections and tables for mobile users, which is becoming smaller for anyone using desktop computers. BattleshipMan (talk) 05:13, 19 February 2014 (UTC)
- Still confused. Are you saying columns are not rendering properly somewhere? I haven't seen that on my laptop. Or phone, for that matter. GenQuest "Talk to Me" 05:25, 19 February 2014 (UTC)
- I apologize for the confusion here. I'll figure it out later. BattleshipMan (talk) 07:55, 19 February 2014 (UTC)
- Still confused. Are you saying columns are not rendering properly somewhere? I haven't seen that on my laptop. Or phone, for that matter. GenQuest "Talk to Me" 05:25, 19 February 2014 (UTC)
- What I meant to say is that columns should only be used in mobile and not on desktop computers. The unnecessary size use of columns is becoming an annoyance to anyone using desktop computers and some users are unnecessarily using columns sizes to cut down larger sub-sections and tables for mobile users, which is becoming smaller for anyone using desktop computers. BattleshipMan (talk) 05:13, 19 February 2014 (UTC)
- Count me among the confused as well. I can't tell what exactly is being proposed here. Novusuna talk 04:45, 19 February 2014 (UTC)
- It sounds like the problem you are having is that users have previously specified the number of columns in an embedded list (using something like {{col}}), usually 2, and you're noting that that does not render on today's larger screens very well. Is that correct? --Izno (talk) 14:33, 19 February 2014 (UTC)
- So you don't like the columns at Lists of cathedrals (for example)? I would think that would be bad on a smartphone (or any small or narrow screen), but it looks okay to me on my laptop.
- Or is there a better example of your concern? WhatamIdoing (talk) 15:17, 19 February 2014 (UTC)
- Yes, that's my problem with the use columns. When people use the huge number of columns for size on mobile devices, it's not good for anyone using desktop computers. That's why we need to do something about that problem. BattleshipMan (talk) 17:04, 19 February 2014 (UTC)
Comment I recommend using {{Div col}} for columns. It allows the number of columns to adjust dynamically based on resolution and text size. Obviously it's a bad idea to hard code the number columns, unless of course it's a table that specifically requires a set number of columns. That cathedral list could easily be reconfigured using Div col and the reader's browser settings would dtermine the number of columns. Betty Logan (talk) 18:02, 19 February 2014 (UTC)
- Let me show you guys thtee diffs on 2014 Winter Olympics. This one here and that one here shows the width of the Participating nations shows the size of it, which is not okay on desktop computers. The one I did here was the one that was originally there before the two diffs I showed you guys. This is why hard code of number of columns and size is an annoyance for anyone using desktop computers and laptops. BattleshipMan (talk) 19:35, 19 February 2014 (UTC)
- You're talking about the tables at 2014_Winter_Olympics#Participating_National_Olympic_Committees?
- Let's start with the fact that your column templates are mismatched, so you're accidentally producing invalid HTML. Go read the notes at Template:Multicol about the need to use matching column template families.
- I don't like the narrow, fixed-width approach to the second table. What if my screen were narrower than 600px? If you don't want it to be full-width (which I actually liked), then let the table pick its own size.
- Secondly, look at the bigger table. Now make your browser window really narrow (or increase your font size a lot). See what a mess you get? Now look at the same table but with this formatting. See how it automagically makes fewer columns to accommodate your shrinking screen width? That's really a better solution. (It could also IMO be improved upon by using the same suggested column widths for both tables, and by making the suggested width be a bit wider than it is.) WhatamIdoing (talk) 23:01, 20 February 2014 (UTC)
- My issues with unnecessary use of columns is that they cause some problems with anyone using desktop computers and such. Sometimes the unnecessary amount of dividing columns on any sub-section and table can annoyed and frustrate many readers using desktop computers, regardless what it does for anyone using mobile devices. The hard code of number of columns can obviously be a bad idea for anyone using desktop computers, which is why someone will have to work on proposal recommend browser settings for anyone using desktop computers and mobile devices to make sure the amount of columns wont cause issues with anyone using desktop computers. BattleshipMan (talk) 22:34, 21 February 2014 (UTC)
- I'm using a desktop computer, too, BattleshipMan. I actually think this problem would be worse for a mobile device.
- What you did was hardcode the number of columns. What you took away was a system that dynamically set the number of columns according to how much space there was on the screen.
- This is the old system (the one that you took away):
- My issues with unnecessary use of columns is that they cause some problems with anyone using desktop computers and such. Sometimes the unnecessary amount of dividing columns on any sub-section and table can annoyed and frustrate many readers using desktop computers, regardless what it does for anyone using mobile devices. The hard code of number of columns can obviously be a bad idea for anyone using desktop computers, which is why someone will have to work on proposal recommend browser settings for anyone using desktop computers and mobile devices to make sure the amount of columns wont cause issues with anyone using desktop computers. BattleshipMan (talk) 22:34, 21 February 2014 (UTC)
Countries that participated in 2010, but not 2014 | Countries participating in 2014, but did not in 2010 |
---|---|
-
-
- Now look at this table as it would appear on a narrow desktop computer screens (you know, for people who don't own expensive widescreen monitors?):
-
Countries that participated in 2010, but not 2014 | Countries participating in 2014, but did not in 2010 |
---|---|
-
-
- See how the number of columns automatically changed? There are no longer "too many" columns, because it automagically made fewer columns when it was given less space to display the table in. WhatamIdoing (talk) 23:07, 21 February 2014 (UTC)
-
-
-
-
- Some people just don't see it that way. The size of columns has always been an issue for desktop computers and mobile device, WhatamIdoing. People need to do something about that problem so it won't be an issue for desktop users and mobile users. BattleshipMan (talk) 23:18, 21 February 2014 (UTC)
-
-
-
-
-
-
- Well, most people see it that way. Static columns present a great problem for small screens, making it near impossible to read. That is the exact reason why template like {{div col}} exist; to have dynamic columns that fit all screens. Please do not remove them again. — Edokter (talk) — 23:48, 21 February 2014 (UTC)
- The problem with dividing columns for larger screens is make it too difficult for them to deal with smaller tables and such. That is why we need to balance columns for larger desktop computers and small screens and this kind of columns isn't the answer. BattleshipMan (talk) 01:00, 22 February 2014 (UTC)
- Well, most people see it that way. Static columns present a great problem for small screens, making it near impossible to read. That is the exact reason why template like {{div col}} exist; to have dynamic columns that fit all screens. Please do not remove them again. — Edokter (talk) — 23:48, 21 February 2014 (UTC)
-
-
-
Let's compare two more, then. Which of these is easier to read?
Participating National Olympic Committees (number of qualifying athletes) | |||||
---|---|---|---|---|---|
|
Participating National Olympic Committees (number of qualifying athletes) |
---|
|
On my screen, one is a four-column unreadable mess, and the other is two neat, wide columns. What do you see? WhatamIdoing (talk) 02:54, 22 February 2014 (UTC)
- Well, the number one is a not readable for sure. The second is very neat as well. BattleshipMan (talk) 03:06, 22 February 2014 (UTC)
- There you have it then. The unreadable mess is your method, the second table is using adaptive columns, which changes the number of column according to the available space on the screen. — Edokter (talk) — 03:14, 22 February 2014 (UTC)
- Hey, man. That was uncalled for on what you said to me. That wasn't my idea, nor I came up with the mess with the other tables on that page. These columns at times can cause problems with larger desktop computers, regardless of what others might say. So cut that kind of attitude with me, alright. BattleshipMan (talk) 06:10, 22 February 2014 (UTC)
- There you have it then. The unreadable mess is your method, the second table is using adaptive columns, which changes the number of column according to the available space on the screen. — Edokter (talk) — 03:14, 22 February 2014 (UTC)
- Let's compare two more, then. Which of these, based on a "normal" 800×600 screen resolution with a 186px sidebar (I measured it) is easier to read?
Participating National Olympic Committees (number of qualifying athletes) | |||||
---|---|---|---|---|---|
|
Participating National Olympic Committees (number of qualifying athletes) |
---|
|
- I'd say the difference between the two is minimal and honestly, the top one looks better when I view it on my Android Galaxy Axiom's screen in desktop mode (800x480 pixel WVGA resolution). — {{U|Technical 13}} (t • e • c) 04:06, 22 February 2014 (UTC)
- Hmm...I like the bottom one since just about almost every country is listed without jamming up space like some of the countries with larger names on the top table. BattleshipMan (talk) 06:16, 22 February 2014 (UTC)
- Guess what? The one you like better is the method that you took away. It's okay; everyone knows that you wouldn't have done that, except that you just didn't know about all of the dozens of permutations possible here. That's why we work together, with people who have different computers as well as different skills.
I don't like cramming lists into narrow columns, either. But the way to make sure that nobody has them crammed into narrow columns (not just that it looks okay on my own computer) is to use {{div col|colwidth=15em}} instead of a fixed number of columns (with the {{multicol}} template). And if you find someone using the proper div col system, and it still feels crowded, then you increase the "colwidth" amount, rather than replacing the whole system. "15em" means (at the absolute minimum) "the size needed to type 'mmmmmmmmmmmmmmm'" (15 copies of the letter m). So if that seems crowded on a page (there are some people who really like to cram it in...), then you just change the div col template to a larger number of "ems", so it says|colwidth=17em
, or whatever is needed. Edokter has already fixed this table. You should feel free to adjust the "ems" if you think it needs it. WhatamIdoing (talk) 22:24, 22 February 2014 (UTC)
- Guess what? The one you like better is the method that you took away. It's okay; everyone knows that you wouldn't have done that, except that you just didn't know about all of the dozens of permutations possible here. That's why we work together, with people who have different computers as well as different skills.
- Hmm...I like the bottom one since just about almost every country is listed without jamming up space like some of the countries with larger names on the top table. BattleshipMan (talk) 06:16, 22 February 2014 (UTC)
-
-
-
- There is another issue here: accessibility. If you use a technique like
{{Div col}}
/{{Div col end}}
(as seen at Wikipedia:Meetup/UK#London which does it through the redirects{{colbegin}}
/{{colend}}
), all of the columns form one single list. But if you use a technique where the breaks between columns are hard-coded - such as with the{{Col-break}}
and{{Multicol-break}}
templates - what happens is that instead of a single list, there are several: one for each column. This causes screen reader software to announce multiple lists when only one was intended. - There is a known downside to
{{Div col}}
/{{Div col end}}
: it doesn't work with Internet Explorer 9 or earlier, for exactly the same reason that multi-column{{reflist}}
don't work with IE9 and earlier. Instead, the columnisation is ignored, and it all displays as a single column. - But whichever technique is used, please don't mix templates from different groups. That is,
{{col-begin}}
goes with{{col-break}}
and{{col-end}}
;{{multicol}}
goes with{{multicol-break}}
and{{multicol-end}}
. Mixing them will cause an imbalance in the number of open<div>
,<table>
and other structures. Some of the examples above do mix the groups, which might have contributed to the difficulties. Also please don't omit the appropriate closing marker -{{div col end}}
,{{col-end}}
or{{multicol-end}}
- and none of these are equivalent to the table end marker|}
, so that shouldn't be used as a shorthand for any of them. --Redrose64 (talk) 23:44, 22 February 2014 (UTC)
- There is another issue here: accessibility. If you use a technique like
-
-
RfC: should the templates in Category:Redirect templates be modified now that the text is rendered on redirect pages.
Fairly recently, a change was made to the MediaWiki core that allows for content to be displayed on #REDIRECT pages. This change and a discussion that was started on Template talk:Isp has prompted me to start this RfC to see if there is support to allow these templates (Category:Redirect templates) that are designed to provide information to anyone who happens upon a redirect page and isn't redirected for some reason or visits the page directly using &redirect=no. Should these templates be modified to allow use on any redirect page as long as the categorization provided by the templates are restricted to the essence of the category. — {{U|Technical 13}} (t • e • c) 23:11, 21 February 2014 (UTC)
- The relevant software change was in mw:MediaWiki 1.23/wmf10 (about a month ago). --Redrose64 (talk) 23:28, 21 February 2014 (UTC)
Discussion
This proposal will allow someone visiting //en.wikipedia.org/w/index.php?title=Template:Isp&redirect=no to see the message "This is a redirect from a title with another method of capitalisation. It leads to the title in accordance with the Wikipedia naming conventions for capitalisation, and can help writing, searching, and international language issues." — {{U|Technical 13}} (t • e • c) 23:11, 21 February 2014 (UTC)
- I just finished (mostly) clearing out Category:Pages with templates in the wrong namespace, and will need help from an administrator to finish up some of the rest. There were hundreds of pages in this category, which T-13 didn't notice until he stalked my protected edit requests. There was a fair amount of garbage on these redirect pages and the task was made very tedious, even with the aid of WP:AutoWikiBrowser by the fact that editors insist on creating two dozen cryptic aliases for each of these redirect templates. I suppose now we can open up these pages for editors to post phone numbers and email addresses. I won't be volunteering to help clean them up, frankly I'm a little sick of redirect templates right now. I think they're mostly pointless. But at least these aren't throwing spurious {{error}}s now. Wbm1058 (talk) 00:42, 22 February 2014 (UTC)
- Redirect category templates (rcats) are just used to sort redirects into maintenance categories not into article categories. Please imagine how many more redirects will be sorted to Category:Redirects from other capitalisations if its rcat were allowed to tag all such redirects instead of just the ones from mainspace. The R from other capitalisation rcat has always sorted only mainspace "other capitalisations" to its category, so for redirects in other namespaces that are plurals or other capitalisations, I've always used {{R from modification}} (used for any-namespace redirect) to sort them, which is, I believe, how I've seen it done in the past. There are several rcats that either sort just to one namespace, or sort to all but one namespace, or sort to two either/or namespaces and so on. These sorts were initially set up for certain reasons. If we cannot figure out what those reasons are, then by all means, there is no reason why specialized sorts should exist. To me, the reasons are fairly obvious, aren't they? In the case where they sort into "mainspace only", the reason is that it is the article-space "other capitalisations", "plurals", "singulars", etc., that are tracked from those maintenance categories, and only the article ones. – Paine Ellsworth CLIMAX! 02:13, 22 February 2014 (UTC)
-
- None, that's my proposal. Show "just the text" if used outside of article space. Zero categorization. outside of redirects in article. This means there would be 0 more redirects will be sorted to Category:Redirects from other capitalisations if its rcat is allowed to be used to tag all such redirects instead of just the ones from mainspace. — {{U|Technical 13}} (t • e • c) 02:21, 22 February 2014 (UTC)
-
- Then you may be looking for a different thing, like documentation of some kind. The redirect category templates are designed to both categorize and to be read by those who come to the page. To use them to do only one or the other would overcomplicate things when all that is necessary would be text and not categorization. The main job of rcats has always been to categorize, in fact their only job up until January. Now that text appears on redirects, the only text that should appear that's generated by an rcat is the text that explains why it has been thusly categorized.
- Also, wouln't it be so much better and easier if {{R from modification}} were made more informative in the way you suggest? – Paine Ellsworth CLIMAX! 03:09, 22 February 2014 (UTC)
-
- I'm saying that redirect category templates should designed to both categorize on article pages and to be read by those who come to the page. This is a simple change. It's basically as simple as changing
[[Category:Redirects from foo]]
to{{#ifeq:{{NAMESPACENUMBER}}|0|[[Category:Redirects from foo]]}}
. This will ensure that only article pages are categorized, and only the text portion of it is show anywhere else. — {{U|Technical 13}} (t • e • c) 03:36, 22 February 2014 (UTC)
-
- That sounds good to me. Why not just sandbox it at {{R from other capitalisation/sandbox}} to see if it works the expected way? There aren't that many rcats that would need it. – Paine Ellsworth CLIMAX! 03:55, 22 February 2014 (UTC)
-
- I'll sandbox it tomorrow. It's 11PM here now and I'm exhausted. :| — {{U|Technical 13}} (t • e • c) 03:58, 22 February 2014 (UTC)
- I'm saying that redirect category templates should designed to both categorize on article pages and to be read by those who come to the page. This is a simple change. It's basically as simple as changing
- See bug 14323 ("Redirect pages should render all text"), Move redirect rendering into WikitextContent and Use WikitextContent to render redirects. This is nice in that it allows the meaning of the cryptic redirect-template-shortcuts to be translated into English, put I wouldn't want to divert project resources into further editing of these redirect pages when WP:WikiProject Merge and WP:WikiProject Orphanage are still so much needing help. And "supporting it" would only encourage editing in this area. – Wbm1058 (talk) 02:41, 22 February 2014 (UTC)
-
- Divert "what" resources? An hour of my time to change
[[Category:Redirects from foo]]
to{{#ifeq:{{NAMESPACENUMBER}}|0|[[Category:Redirects from foo]]}}
on all of the Category:Redirect templates? Seems fairly minimal to me... — {{U|Technical 13}} (t • e • c) 03:56, 22 February 2014 (UTC)- I'm not worried about the hour of your time taken to edit templates. I'm concerned with the hours that other editors will then take to actually use those, creating junk like this, this and this, that someone like me will spend hours cleaning up. I'd rather channel editors into doing something more productive. The hour of your time would be better spent on finding links for orphans. Wbm1058 (talk) 04:33, 22 February 2014 (UTC)
-
-
- Now that the initial "cleaning" is done (thank you), and the core has changed to display text (and in those cases the redlinked templates indicating there was screwup), I don't see any reason these templates can't be used to add this text description to the redirect page, as that is partly what the template is designed for in the first place. The other part of the design is categorizing articles, and it can still do that and it being used on non-articles has 0 impact on that with my proposal. Now, I'm going to finish my midnight cookies and milk, take my midnight tinkle, and go back to sleep. — {{U|Technical 13}} (t • e • c) 05:40, 22 February 2014 (UTC)
-
- Divert "what" resources? An hour of my time to change
Reimplementing functionality to tag articles with Template:Non-free review
{{Non-free review}} is a template used to tag non-free files which are being discussed at WP:NFCR. The template had been changed to be usable for tagging articles with multiple non-free files as well. That functionality has been removed from the template (see discussion at Template talk:Non-free review#RfC: Should the non-free review template be added to articles?). I propose to add that functionality again. Informing the visitors or watchers of a page that non-free content on the page is being discussed at NFCR seems to be useful. Not all editors watching a specific article might be watching all the files used in the article. -- Toshio Yamaguchi 15:25, 23 February 2014 (UTC)
- Support Several times recently I've noticed (via my watchlist) files being removed from articles, they had been deleted after failing a NFCR - but the first that I knew of the NFCR was the removal from the article. I had no opportunity to comment. --Redrose64 (talk) 23:07, 23 February 2014 (UTC)
- Comment as a point of note: there was a small discussion at NFCR to adapt the current non-free review template to include page-notification functionality about a year ago. About 4-5 months ago, after the template was tagged on a page, editors of that page and its related project questioned the consensus of that template and initiated an RFC which ended that there was no consensus to make the initial change to include notifying the page (via the article page itself). This RFC thus can be seen as (if agreed by consensus) validating the initial decision to add the page notification function. --MASEM (t) 03:43, 24 February 2014 (UTC)
Talk:Persecution_of_Hindus#Request_for_comments
I have requested comments from others at https://en.wikipedia.org/wiki/Talk:Persecution_of_Hindus#Request_for_comments. Please support or oppose the survey going on there.—Khabboos (talk) 17:16, 24 February 2014 (UTC)
Find a way to have almost all comments on article feedback pages get resolved or marked as not useful.
Those feedback pages seem to be getting ever so little attention. It should also be possible to add hyperlinks to those pages unlike Special:ArticleFeedbackv5/Cavitation. Blackbombchu (talk) 18:29, 24 February 2014 (UTC)
- Feedback is being completely disabled in the next few days. There's no sense in making improvements to it now. Jackmcbarn (talk) 19:28, 24 February 2014 (UTC)