Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 64.40.54.22 (talk) at 08:42, 14 February 2013 (→‎Wikipedia:Article Incubator: p,s.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:


« Archives, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Languages on sidebar

On the left hand side of any Wikipedia page, on the toolbar, there is a section devoted to interwiki links to other language versions of an article. I want to propose a small change to the mediawiki software wording here. At current it is simply named "Languages", which is rather ambiguous and vague name. I think that when somebody less experienced at Wikipedia, usually a reader or newbie, sees that and the links below it, that if they click it they can get the whole of Wikipedia translated into that language. I propose it is changed to something short but similar to "View this page in other languages". This clears up any confusion to what you may consider to be a very minor thing but could be very hard to get their head round for readers. Rcsprinter (talkin' to me?) @ 11:27, 26 October 2012 (UTC)[reply]

"In other languages" would probably fit. But your solution does not solve the stated problem. I'm as likely to think I'll see a trasnslation of the EN page if we say "View this page in other languages" ... the operative problem being "this page". The interwiki link allows us to view the treatment of this subject in other languages. "Other language versions" might work. "Articles on other languages" also. But we're swapping brevity for perceived accuracy, which still might not be parsed by the user. --Tagishsimon (talk) 11:53, 26 October 2012 (UTC)[reply]
Why not "Other languages"? Tony (talk) 12:14, 26 October 2012 (UTC)[reply]
Funny, in my toolbar it shows as "in other languages". Lectonar (talk) —Preceding undated comment added 12:20, 26 October 2012 (UTC)[reply]
Are you using any custom code that might be overriding the default? —David Levy 12:59, 26 October 2012 (UTC)[reply]
Not that I am aware of; but still, it shows "In other languages", even on this page here. Lectonar (talk) 13:03, 26 October 2012 (UTC)[reply]
I guess you have selected "en-GB - British English" as language at Special:Preferences. Then you see MediaWiki:Otherlanguages/en-gb instead of MediaWiki:Otherlanguages. en-gb is not recommended at the English Wikipedia. See Help:Preferences. The page history of MediaWiki:Otherlanguages shows some variation years ago but not since 2007. David Levy used the Simple English Wikipedia as reason for not saying "In other languages".[1] PrimeHunter (talk) 13:38, 26 October 2012 (UTC)[reply]
Thank you for that; I guess I must have chosen it when I started may account, some 7 years ago. Never had any problems, though. Cheers. Lectonar (talk) 13:54, 26 October 2012 (UTC)[reply]
I just harmonized MediaWiki:Otherlanguages/en-gb and MediaWiki:Otherlanguages/en-ca with MediaWiki:Otherlanguages.
If the British English and Canadian English options are to remain available, we should apply the various customizations (with changes in spelling/wording where appropriate). For the messages in which no English variety issues exist (presumably most), we could use redirects. —David Levy 17:15, 26 October 2012 (UTC)[reply]
One of the Wikipedias is written in simple English. —David Levy 12:59, 26 October 2012 (UTC)[reply]
Keep "Languages". Apart from linking to this subject in another language, it also links to the whole Wikipedia in that language (with "whole" admittedly being smaller than English). You stay in that language if you follow wikilinks there, use the search box, click the logo, and so on. "Languages" is brief and about as clear or open to misunderstanding as alternatives that are not ridiculously long. PrimeHunter (talk) 12:38, 26 October 2012 (UTC)[reply]
Keep "Languages". Agree with PrimeHunter - it is ambiguous, but it's short and it won't take the reader long to find out what is meant once he actually follows the link... --Philosopher Let us reason together. 19:41, 26 October 2012 (UTC)[reply]
We will have a huge language button on top right.
The WMF is developing a huge button that says "English" on the right corner, so readers will find the articles in other languages easily. --NaBUru38 (talk) 20:09, 15 November 2012 (UTC)[reply]

Note to keep archiving bot away. Rcsprinter (yak) @ 21:43, 14 November 2013 (UTC)[reply]

Why not have it say "On Other Wikipedias"? Then it encompasses, say, Simple English, while avoiding the implication of translations. ∴ ZX95 [discuss] 01:00, 8 December 2012 (UTC)[reply]
My preference is languages because that is more explanatory than other wp's. Technically simple is a subset of English. Apteva (talk) 02:53, 8 December 2012 (UTC)[reply]
The issue was raised, however, that "Languages" is likely to make some people think that the linked articles are translations of the English one; that was why I suggested "On Other Wikipedias", which is much less ambiguous. ∴ ZX95 [discuss] 15:29, 11 December 2012 (UTC)[reply]

Simple English at top of languages

The primary question for this discussion is- Should the Simple Wiki be put at top of the languages bar? TheOriginalSoni (talk) 20:11, 29 December 2012 (UTC)[reply]

The issue was already discussed on the Village Pump and had garnered supports too, but due to an amateur mistake on my (nominator) part, it had to be closed on mainly technical grounds. Relevant discussion related to the issue may be found in the following places-

Adding an RFC to have wider community opinion- TheOriginalSoni (talk) 20:11, 29 December 2012 (UTC)[reply]

Discussion

Feel free to discuss any of the issues already discussed and add your/previous statements here.

I believe enWiki shall send a note to the developers of WikiData to customize our language sorting list. TheOriginalSoni (talk) 05:06, 22 January 2013 (UTC)[reply]
  • A thought - can we measure the success or otherwise of these links? If we switch the position, then a clear marker of success would be that a) it gets used and b) it's found useful.
a) is a simple matter of recording traffic from en.wp to simple.wp - if it increases significantly, then good. b) is a little tricker, but it seems safe to assume that if people go en.wp > simple.wp > other simple.wp - they follow an internal link to another simple page once there - then they're finding simple useful.
I don't know if we currently have the analytics data to do either of these - particularly b - but if we do, it might be worth setting up some kind of test. Andrew Gray (talk) 11:14, 23 January 2013 (UTC)[reply]

Can anybody explain how and when this is going to be closed? TheOriginalSoni (talk) 15:28, 7 February 2013 (UTC)[reply]

Voting

  • Support as nominator TheOriginalSoni (talk) 20:11, 29 December 2012 (UTC)[reply]
  • Oppose'. I'm going to say what I think, and I apologize if it sounds impolite or hurts feelings, but it's what I think. Simple English Wikipedia is mostly a failed experiment. The task that it theoretically sets for itself — explain ideas just as complicated as those of any other Wikipedia, but using simple language — is basically just not possible. There is no justification for giving it priority over genuine natural languages. --Trovatore (talk) 20:30, 29 December 2012 (UTC)[reply]
Two things. First - Simple wiki is not as good as it should be mainly because of the coverage it fails to get from users who are actually "searching" for something to edit substantially. I believe this proposal could get it some decent coverage. Second - I dont think its impossible to do what the Simple Wiki tries to do. All it envisgages is Wikipedia, but just without the technical Jargon and the sophistication in languages and sentence construction that is like a signature style of the wiki now. Challenging? Yes. Impossible? I dont think so.
And finally, Simple gives a scope for the readers who do not have the technical mind to understand the current articles, to do so - A place where everything is simple. TheOriginalSoni (talk) 09:52, 30 December 2012 (UTC)[reply]
We disagree. My view is that it is, in practice, impossible. Technical "jargon" (used judiciously) is actually the simplest and clearest language for expressing technical concepts. If you ban it, clearly explaining the concepts becomes tedious to the extent of impeding the effort of getting them across at all.
That doesn't mean that people shouldn't try, if they want to. So far they have not succeeded. Given the inherent implausibility of the goal, I do not think that we should distort the interlang listings just to advertise it. --Trovatore (talk) 18:42, 30 December 2012 (UTC)[reply]
If both of you are under the impression that Simple doe not use technical terms, then it doesn't sound as though either of you are sufficiently informed to be able to judge the success of the project... (see Macdonald-ross' reply below). Osiris (talk) 00:51, 4 January 2013 (UTC)[reply]
  • Oppose. I'm afraid I have to agree with Trovatore. Whatever it is that Simple wants to do, it has never succeeded in even clearly defining that goal, let alone making any significant headway towards achieving it. Its programmatic statements about it are largely either vacuous or self-contradictory, and its practice is chaotic. Fut.Perf. ☼ 10:50, 30 December 2012 (UTC)[reply]
  • Oppose. Unlike the other posters, I don't really have a view on Simple English Wikipedia. Sometimes, it can be quite useful; at other times, it's hopeless as a reference tool. However, it is easier to locate Simple English in the list of interwiki links if it is in the correct alphabetical order. No need to overcomplicate it. — This, that, and the other (talk) 11:25, 30 December 2012 (UTC)[reply]
    I believe the point of the proposal is not to make it easier to find, but to make people be aware of its existence at all. Being buried in the middle of the list is easy to overlook, being at the top makes it clear it's different (and it IS different) and calls attention to itself, which is what the proposer wants. Most people don't know it exists, after all (though granted, many people don't realize anything but en exists...) ♫ Melodia Chaconne ♫ (talk) 14:31, 30 December 2012 (UTC)[reply]
    Or just change the font color. Others are completely different language, "Simple English" is not!-Tito Dutta (talk) 19:48, 30 December 2012 (UTC)[reply]
  • No opinion as to whether it should be at the top or not, but I'm not sure it makes sense to be having this discussion now. As I understand it, interwikis are going to start being handled by Wikidata in a few weeks, which will probably take the issue of how to order things away from the English Wikipedia. A while later we'll probably have ULS here and have interwikis selectable through that instead of the current list display, making the point moot. --Yair rand (talk) 19:58, 30 December 2012 (UTC)[reply]
In the previous discussion, I was told that we can contact the WikiData developers (or something like that) and place a request so that Simple English comes out at the top for us. TheOriginalSoni (talk) 04:39, 31 December 2012 (UTC)[reply]
  • Oppose, really the Simple English Wikipedia was even worse an idea than Klingon. Its mostly good for laughs, and quite honestly might be the least useful link in the list. Prodego talk 06:50, 31 December 2012 (UTC)[reply]
  • Oppose - If we want to promote the simple English WP, we'll need more than this - and I don't think that we should promote it in the first place. Ajraddatz (Talk) 05:36, 1 January 2013 (UTC)[reply]
  • Oppose we do need something more sophisticated here, but it should be user driven not project driven. Ideally we need something that looks at the languages you have set in babel boxes and user preferences and prioritises those links accordingly. So if you speak two other languages and and are looking at an article that has 23 other language versions including one that you speak it should list that one first. ϢereSpielChequers 15:52, 1 January 2013 (UTC)[reply]
  • A good idea, but most people who read Wikipedia are not users. And even for users, that would probably be implausible for the Wikidata developers. Language links won't be hosted locally much longer. Osiris (talk) 00:51, 4 January 2013 (UTC)[reply]
  • Computing power is getting steadily cheaper, so I'd be surprised if the developers had a difficulty with this. As for most readers not registering accounts, if you give people features that they find useful they will create a free account in order to access them. The same argument applies to possible changes like the image filter and an American English/English toggle. I suspect we have a few readers already who have accounts in order to have a watchlist or a different skin, we certainly have lots of accounts that have been created but which never edit. ϢereSpielChequers 15:33, 8 February 2013 (UTC)[reply]
  • Support - I only recently got familiar with Simple and that was only after my attitude with En Wikipedia degraded and I sought out other projects to participate in outside this one. Had that not happened I probably would still be oblivious to it. Simple is useful and if its a failed experiment its only because access to it is hidden among a sea of links. The English Wikipedia is the prominent link and always has been since the creation of the project so naturally so its going to get more activity. Moving the link up in the interwiki list doesn't just garner traffic to simple, it lets the readers of the article know, that there may be a simpler version of it that they can start with to gain at least some familiarity with the subject. Its easy for us to discredit the site because we can all clearly read and articulate english, many of us at an advanced level. But try reading a site in another language, maybe using google translator and see how much it makes sense. Kumioko (talk) 17:00, 1 January 2013 (UTC)[reply]
  • Oppose I'm concerned about the effect this might have on contentious articles - fringe, biographies, etc as it might drive vandals, BLP violators, etc to work on the Simple version. Dougweller (talk) 15:17, 3 January 2013 (UTC)[reply]
  • Support. It is true to say that reliable articles on science and other technical subjects need non-simple technical terms, and Simple does use them. We approach this problem by 1. agreeing that accuracy is a prime objective in science communication (we have a consensus on this), and 2. by using appropriate editing techniques. A technical term can be linked to a page which explains it, to an entry in Simple wikt (our version of Wiktionary) or by explaining it in a footnote. The fact that some of the negatives appear not to know this is interesting. I think if one looks at some of the pages on molecular biology, or immunology, or astronomy, you can see some fairly good examples. Some topics are relatively undeveloped, because we have no-one with the background to handle a particular subject -- physics for example -- but that is a reflection of the problem that we have too few editors to handle the work that needs doing. On the other hand, English Wikipedia has quite different problems. There are an astonishing number of long, verbose and unreadable articles, where struggles between editors have destroyed any sense of structure. Articles wander this way and that way, everything that anyone can think of is stuffed in... The standard of prose in many articles is truly dreadful. It is very difficult to improve pages on important topics because of the time taken in endless discussions. Much of English wiki is a closed book to the many, many readers whose reading skills in English are average. Simple English is a sensible answer to a real problem. It deserves to be better known, and the proposal is one way to go about it. Macdonald-ross (talk) 22:55, 3 January 2013 (UTC)[reply]
  • Support. Not doing anything in response to all the article feedback is just not productive. Whether or not you find it useful, not all readers have a sufficient knowledge of English. To readers of this wiki, the link to SEWP is the most valuable link in the list. If they're reading this wiki, chances are good they can understand a bit of English -- if they want to read the topic described in clearer terms, they'll be able to see the link more easily. Nothing wrong with sorting it at the top at all. Osiris (talk) 00:51, 4 January 2013 (UTC)[reply]
  • Support - as expressed by so clearly by Osiris above. --Peterdownunder (talk) 23:00, 4 January 2013 (UTC)[reply]
  • Support per above.  Hazard-SJ  ✈  04:27, 6 January 2013 (UTC)[reply]
  • Support, as per nom.--TVBdxiang (Talk) 06:08, 6 January 2013 (UTC)[reply]
  • Support - As Osiris says. Yottie (talk) 16:39, 7 January 2013 (UTC)[reply]
  • Oppose, on the grounds that "Simple English" is ill-conceived. ~ J. Johnson (JJ) (talk) 22:25, 7 January 2013 (UTC)[reply]
  • Support Osiris does a wonderful job explaining what I couldn't have said any better. MJ94 (talk) 18:50, 9 January 2013 (UTC)[reply]
  • Support Basically per Osiris. AIRcorn (talk) 09:13, 10 January 2013 (UTC)[reply]
  • Support I couldn't have said it better than Osiris. -DJSasso (talk) 20:04, 11 January 2013 (UTC)[reply]
  • Oppose: Simple Wikipedia is a joke. Most of their articles are out-of-date stubs. It's not helpful to most readers, who just have to come back here to find what they're looking for pbp 05:07, 12 January 2013 (UTC)[reply]
Purpleback! Nice to see you here. :) Osiris (talk) 14:28, 12 January 2013 (UTC)[reply]
In this case, it would not appear that nothing's broken. As I mentioned in the previous discussion, many reader feedback on well known articles repeatedly ask for a simple version of the article, or show that the reader in question failed to find the necessary information from the large (and should I say excessively long) enWiki page. Exposure to the Simple Wiki would help in solving this issue. TheOriginalSoni (talk) 16:35, 16 January 2013 (UTC)[reply]
  • (edit conflict)Support. Simple English isn't a different language edition, unlike the other entries in the list, so it should be distinguished. I also agree with Madonald-ross and Osiris above - for the record other than a updating my user page there just now, my only connection with the project is a handfull of edits in 2005-6. As for Purplebackpack's comments above, we do not filter the non-English langauge edition links because of good or bad quality, so what justification is there to do so in this case - particularly as it could be a spur to improving their content? Thryduulf (talk) 16:36, 16 January 2013 (UTC)[reply]
  • Support, agree with Thryduulf. --Nouniquenames 16:46, 16 January 2013 (UTC)[reply]
  • Support echoing above supporting opinions. Small effort which could help a number of visitors. Kennedy (talk) 17:38, 16 January 2013 (UTC)[reply]
Note - I would also note a couple things that have been brought up above. Most support voted are from people familiar with Simple and its mission and purpose. Most of the oppose votes have never edited there and thus likely have no understanding of its purpose or mission. Kumioko (talk) 18:15, 16 January 2013 (UTC)[reply]
  • Conditional support - this should be done within the Mediawiki software, but not by manually editing articles. It it easy enough for the software to sort the displayed links in any order. The order of the interwiki links in the source of the page should not affect the order in the rendered page, and trying to put simple first in the source of the page is a never-ending maintenance headache. — Carl (CBM · talk) 18:34, 16 January 2013 (UTC)[reply]
I am not sure I was clear enough, but it was implied that it shall be done within the MediaWiki software. Among the discussions between those who knew the technical aspects, it was proposed to inform the WikiData developers once the proposal was passed. I intended to discuss those technical issues only once there was a clear cut consensus on the original proposal TheOriginalSoni (talk) 18:41, 16 January 2013 (UTC)[reply]
It ewas not very clear to me, but I will edit my comment. — Carl (CBM · talk) 18:53, 16 January 2013 (UTC)[reply]
  • Oppose efforts should be made at making this encyclopedia more accessible, not split off to a redundant project. --Jayron32 18:36, 16 January 2013 (UTC)[reply]
  • Oppose Jayron32 summed up my thoughts exactly. Legoktm (talk) 19:05, 16 January 2013 (UTC)[reply]
  • Comment. To most other languages, putting en in one place and simple en in another makes no sense. That can be fixed without contention. If simple englash is a worthless project it can be axxed, but there is clearly a need for a kids encylcopedia as well as an adult one, and I would see simple English more along the lines of that rather than it simply being one geared to those who do not have any three syllable words in their vocabulary.. Apteva (talk) 20:11, 16 January 2013 (UTC)[reply]
  • Oppose As much as I like the ideology behind it, I don't believe this is totally necessary.
First, no reader is required to gain a full understanding of an article. As I said in the previous discussion, they may simply read the lead and look at the pictures if they do not understand an article. We have a template to indicate that the lead does not summarize the contents well enough; it should be used more often. Other resources exist for those with insufficient knowledge.
Yes, this has the potential of destroying the ability of a Wikipedia reader to get information by looking at the images alone! But why did you say no reader is required to gain a full understanding of an article?···Vanischenu「m/Talk」 07:59, 19 January 2013 (UTC)[reply]
Second, readers who really and truly wish to gain a full understanding of an article will make a strong effort to do so. This will actually be more beneficial to them than a watered-down Simple English version, which I should note can appear to be condescending at times.Pokajanje|Talk 21:00, 16 January 2013 (UTC)[reply]
Just one point that I will like to make here. Not everybody is as proficient in English as our average Wikipedia editor here. There are plenty of places where I personally had to reread paragraphs several times just to understand what it means. It is then illogical to assume that all the articles here will be within the reach of the standards of the average reader. There will be plenty, if not many, who would not be able to gain a full understanding, despite really and truly wishing and trying to get it. And everyone certainly does not have as much time as you might think. TheOriginalSoni (talk) 21:23, 16 January 2013 (UTC)[reply]
Third, I fully agree with Trovatore's quote above: "The task that it theoretically sets for itself — explain ideas just as complicated as those of any other Wikipedia, but using simple language — is basically just not possible." It is impossible to achieve a perfect balance between getting information across and making it understandable.
Finally, I think proposal shows Wikipedia's systematic bias. Would this proposal affect the ordering on other-language Wikipedias? If so, that would be very biased, as they likely have no more use for a Simple English article than I. There is no reason not to have Wikipédia Français Simple or other Simple Wikipedias, so why not create them? Because when "Simple English" is between Norwegian Nyorsk and Azerbaijani in its article count, with only 35 featured articles and 59 good articles, it can pretty much be considered a failure.
In summary: Simple English interwiki links at the top would only be partially beneficial, for 94 English articles. Pokajanje|Talk 21:00, 16 January 2013 (UTC)[reply]
Are the Norwegian Nyorsk and Azerbaijani wikis also failures? --NickPenguin(contribs) 21:04, 16 January 2013 (UTC)[reply]
Clarification - This proposal is solely going to affect the English Wikipedia, and not any other language Wikipedia. TheOriginalSoni (talk) 21:16, 16 January 2013 (UTC)[reply]
  • I believe several editors might not realise or may forget this, and so I am going to repeat what has been earlier said in the previous discussions - There are literally dozens (possibly hundreds) of editors and potential editors, especially new ones, who fail to contribute completely to the project because they do not find anything to edit here. Most of the things that they could have edited have already been, and there is precious little for them to try their hands on.
On the other hand, we have the Simple Wiki, which is a failed project in the eyes of several users. In my opinion, this is not because it is inherently a doomed task, or anything of the sort. Its mainly because the Simple wiki does not get the due coverage it gets. I believe that once the Simple Wiki link is put at the top of the Languages, most editors who would otherwise have not been able to contribute here would come and add to the Wiki, as it is still way far from a comprehensive project. Furthermore, many readers who might benefit from a simple explanation and rules for Chess would now find something that actually makes a lot more sense to them. Do these benefits and potential benefits outweigh other concerns? I believe they do. TheOriginalSoni (talk) 21:16, 16 January 2013 (UTC)[reply]
I doubt that I am alone in thinking that the reason that Simple English Wikipedia is a failed project isn't for a lack of content or for a lack of editors. In both of those areas it would be hard to call it anything but a success. Rather Simple is a failed project because it does not provide a useful resource for readers. In other words writing simplewiki is inherently a doomed task. Prodego talk 21:32, 16 January 2013 (UTC)[reply]
We shall agree to disagree on that one. For you, its inherently a doomed task. On the contrary, I see it only because of a lack of awareness among the readers and the editors. These concerns calling the simplewiki a "doomed task" sound surreptitiously similar to similar concerns voiced by opponents of the enWiki itself. And yet, I do not think we have failed here. TheOriginalSoni (talk) 21:40, 16 January 2013 (UTC)[reply]
  • First of all, let me stress that Simple English Wikipedia is a small community, of perhaps twenty named, and perhaps another 10-15 unnamed contributors. Throughits size, the need to regulate is far less than with a big project that regular English Wikipedia. We have not limited the creation of new articles, and our admin team regularly deletes the nonsense that gets created. While we cannot agree on what the target group really is, the resulting articles are often easier to understand than the regular English counterparts. Yes, we lack editors, and yes, our target group is probably not native English speakers. Now take the example of a learned person, who simply has not learned English completely so far; would it not be helpful for those people to get the link to the "easier-to-understand" version before the others? - Similarly, wouldn't it be a laudible task to help those few editors create decent articles? - Have you ever tried explaining a scientific concept, using scientific language, but at the same time making sure that someone outside that domain of study can grasp it? -Wouldn't that be more thrilling than simply copying the formulas from the textbook you get from the library? - A purpose, perhaps? --Eptalon (talk) 23:31, 16 January 2013 (UTC)[reply]
You know: there are a lot of things about Simple that desperately need fixing. But it makes it a hell of a lot harder when it's got critics pulling it down whenever they get the chance. You don't have to help the project; this isn't a vote of confidence, and you don't have to vote either way. This is about helping the readers locate easier-to-understand information on the topics they're reading. Osiris (talk) 11:01, 20 January 2013 (UTC)[reply]
  • Comment - I don't have any first-hand experience with Simple, so I can't guess as to its current or future status, or how it should be mmarketed. However, if a decision is made to move Simple to the top of the interwiki list, please change Wikipedia:AutoWikiBrowser/IW so that AWB follows the new rule. Thanks! GoingBatty (talk) 00:47, 17 January 2013 (UTC)[reply]
  • Support I'm not the biggest fan of Simple English wiki, but it's not a different language so it shouldn't be listed in the middle of the foreign languages. Ryan Vesey 00:55, 17 January 2013 (UTC)[reply]
  • Support As CBM said above somewhere, as long as the reorder can be done within the mediawiki software rather than bots going and making million of edits. ·Add§hore· Talk To Me! 04:12, 17 January 2013 (UTC)[reply]
  • Support Simple English is different from all the other links in two ways: it isn't really another language at all, and all of our readers will be potential readers of Simple (since all of them can speak English). We don't filter the other language links by quality, and I don't see any reason why we should do so here. Hut 8.5 09:39, 17 January 2013 (UTC)[reply]
  • Support. A link to Simple English version of an article seems qualitatively different to most readers of the english wikipedia than a link to the Afrikaans version of the article: everyone here can read the former; most can't read the latter. If the point of the simple English Wikipedia is to make other Wikipedia articles more accessible to those with limited English skills, which I think is fair, then moving the link to the simple English article out of a mass of foreign languages makes sense to me – it's the most likely link to be useful. It seems poor form to deliberately bury the link to make it unlikely to be used, which seems to be the goal of those opposing the proposal out of a dislike of the simple English Wikipedia. AgnosticAphid talk 10:59, 17 January 2013 (UTC)[reply]
  • No thanks I don't feel this is appropriate at all. Interwiki links shouldn't be filtered for the dertriment/preferment of a particular project and its certainly very closed to other projects to advance the argument that simple is more useful to our readers than other projects. I would suggest that's actually not true and there are a lot of our users who have more than one language. Spartaz Humbug! 15:22, 17 January 2013 (UTC)[reply]
    But surely, generally speaking, simple English is more likely to be useful than any other individual language? AgnosticAphid talk 00:56, 18 January 2013 (UTC)[reply]
  • Support Per Ryan Vesey et al. It's not really another language, it's a supplement to this one. --GRuban (talk) 17:16, 17 January 2013 (UTC)[reply]
  • Oppose I don't like Simple English WP, and giving it prevalence atop the rest of the pedias is something I can't support. — ΛΧΣ21 23:19, 17 January 2013 (UTC)[reply]
    Why should this WP:IDONTLIKEIT view be given any weight by whomever closes this discussion? Thryduulf (talk) 09:16, 18 January 2013 (UTC)[reply]
  • Oppose If someone is viewing the regular English version of an article, why would they need to see the simple version? HueSatLum 23:32, 17 January 2013 (UTC)[reply]
    What if you do not understand the regular article, and need a simpler version? TheOriginalSoni (talk) 08:52, 18 January 2013 (UTC)[reply]
    Mathematics articles on WP are frequently far too advanced for me to understand, and I'm an intelligent native speaker of English. Simple English coverage of these topics would be very useful. Thryduulf (talk) 09:16, 18 January 2013 (UTC)[reply]
    That's true, and that's probably why the simple version exists in the first place. For me, when I was just a Wikipedia reader, I never paid any attention to the language links on the sidebar. Anyways, it's still there, just not at the top. HueSatLum 23:02, 18 January 2013 (UTC)[reply]
  • Support This could be the boost that Simple needs to get going. AutomaticStrikeout (T • C) 01:58, 18 January 2013 (UTC)[reply]
    • I'm skeptical about the idea that sending more readers over to Simple would give Simple a boost in productive editors. Simple will always fail, by necessity, because it lacks the crucial source of life blood that successful wikis have: being able to recruit your editors from your readership. With normal wikis, if you are a competent reader of the wiki's language then you are a good candidate for becoming a competent editor in it. But with Simple, if you are a reader who needs simplified English to understand things, that does not mean you are going to be a good writer in simplified English. Because writing simple English is not easier than writing normal English; quite the contrary. Taking a reliable source about something (which will obviously be in normal English) and then breaking that information down to a simplified but correct linguistic form without dumbing down or distorting the content is a hugely difficult task; it needs more than the average proficiency of a competent English speaker, not less. Those people who Simple addresses itself to as readers will invariably produce broken English, not Simple English. Fut.Perf. ☼ 09:34, 18 January 2013 (UTC)[reply]
Umm.... I believe you are making the mistake of assuming all users and editors who shall start noticing the Simple wiki shall be less than average. Also, I do not think that there are currently no editors in Simple who are more than proficient in English. Not to forget that any average and sub average editors shall not be using complicated words, which would be precisely the motive of the Simple Wiki. Experienced editors can always then copyedit for further clarity. TheOriginalSoni (talk) 10:04, 18 January 2013 (UTC)[reply]
Oh, of course there are some good editors over at Simple. But they are people who work there out of sheer idealism, not because they were guided there by their own needs as readers. And as for low-proficiency writers not using complicated words: oh yes, believe me, they do, all the time. Because the complicated words are there in the sources they work from (or copy-paste from), and they lack the linguistic skills to replace them with simpler ones. Fut.Perf. ☼ 10:14, 18 January 2013 (UTC)[reply]
I hope you do not imply that only those who "require" a simpler version of articles will notice and go to and contribute to the Simple wiki, should we decide for this proposal. TheOriginalSoni (talk) 11:17, 18 January 2013 (UTC)[reply]
  • Oppose: There should be no priorities with languages. --NaBUru38 (talk) 16:33, 18 January 2013 (UTC)[reply]
  • Oppose per NaBUru38. If a reader is not a native speaker of English, then they are going to be a native speaker of another language. If they wish to get the gist of an en-wiki article before reading it properly, why do we believe they wouldn't rather use their home-language Wiki for the purpose, rather than the simple: version? Elevating this particular sister project above others strikes me as arbitrary. It Is Me Here t / c 20:43, 18 January 2013 (UTC)[reply]
Just so you know, my native language is not English. Yet when it comes to understanding and learning things, I use English and not Hindi. For Hindi is not the language where I can understand scientific stuff like Radiation or Earth. Its English. So just in case I do not understand the English page, its only Simple which can help. And there are plenty of those who are worse off than me, who will be more helpless. TheOriginalSoni (talk) 03:33, 19 January 2013 (UTC)[reply]
I am certainly not going to dispute your personal experience of the site – but my question is, why do we think that more readers as a whole prefer simple: to de: for native German speakers / ar: for Arabic speakers / etc.? Do we actually have good data on this? It Is Me Here t / c 16:44, 19 January 2013 (UTC)[reply]
Maybe someone with more data might help. Till then, I also point out that there are plenty of native English editors who may not understand the enWiki article well enough. For them, Arabic will not really help. Simple on the other hand, will. Not to forget that since the reader has chosen to read the original article in English, they might want an explanation too in English, and not any other language. Or else they would have gone to that language immediately. TheOriginalSoni (talk) 18:43, 19 January 2013 (UTC)[reply]
  • Support: How can I oppose if it brings only good? No harm done to those readers who like not to see Simple English, and for those who like to, this is very helpful. Any reader who knows English would be able to understand Simple English. Period. Also, no one forces you to click on the link; if you like you can get there easily, and if you don't like it, then you are not much affected by this as it is not different from having the Arabic and others at the top; so why oppose it for not liking BE, simplewp, or the community?···Vanischenu「m/Talk」 07:59, 19 January 2013 (UTC)[reply]
  • Support - Most useful link to the vast majority of readers, so it makes sense that it should be a the top. There will be cases in which readers won't be able to understand an article on this project, so by having the simple version linked in a prominent position, they can easily try the simple version. Failing that, anyone who doesn't like the Simple English project shouldn't be bothered by the change. CT Cooper · talk 12:54, 19 January 2013 (UTC)[reply]
  • Support as it aids those who need it most and has minimal to no negative impact on everyone else. Having the link to Simple at the top makes it easier to find for those Simple is aimed at: "people with different needs, such as students, children, adults with learning difficulties and people who are trying to learn English". SilkTork ✔Tea time 14:44, 19 January 2013 (UTC)[reply]
  • Support as per Osiris -Cameron11598 (Converse) 00:56, 20 January 2013 (UTC)[reply]
  • Oppose: Simple is super :-/. I think we really ought to stop advertising it all. Per Spartaz, Sven, Fut.Perf, and many of the other opposers. --MZMcBride (talk) 01:39, 21 January 2013 (UTC)[reply]
  • Support - I have only made a handful of edits on Simple, and I'm not sure if I plan to edit there more; that being said, I support this proposal. Osiris sums up most of my thoughts in the relevant support - to the English Wikipedia readers, Simple is most often the most relevant "language" on that list to people who read English. This change would make Simple more accessible to people who would find it useful, even if some or most of us English Wikipedia don't. I see people opposing because Simple English isn't a language - they're right. It isn't a language by traditional standards. However, it may be one of the best ways for people to understand a topic they'd like to learn more about, coming from the English Wikipedia. A boost to the top for Simple would not only make it more accessible to readers, but it'd make it more visible. I didn't know that much about SEWP early into my wiki career, but I can certainly say the project isn't a waste. With this extra visibility, editors may find a desire to explore and build upon Simple, making it an even better resource for knowledge. Knowledge is for everyone, it's a language we all understand - English isn't. MJ94 (talk) 03:47, 21 January 2013 (UTC)[reply]
  • Support as the most useful language link to the majority of readers of the English Wikipedia. JASpencer (talk) 23:01, 21 January 2013 (UTC)[reply]
  • Oppose as per Ajraddatz.  TheArguer  SAY HI! 00:38, 22 January 2013 (UTC)[reply]
  • Support. I am not sure that the simple English Wikipedia is a good idea, but so long as it exists it should be at the top. In addition, maybe it should be followed by a number of dialects and languages very close related with English, such as Scots, Ænglisc and Norfuk. In fact, I think every language should have a set of related languages that are automatically privileged in this way. Hans Adler 00:05, 23 January 2013 (UTC)[reply]
    • Nah, no way. Things like "Ænglisc" or "Norfuk" are nothing but playgrounds for a handful of enthusiasts; they have absolutely no legitimate role as actual sources of information for anybody. The proposed argument for privileging "Simple" is that there are speakers out there who can read simplified English with more ease than normal English. But there is not a single person in this whole wide world who reads Old English with more ease than modern English. And I doubt there are any such readers of "Norfuk" either – anybody who can read "Norfuk" can also read English, not equally well, but better. Fut.Perf. ☼ 12:20, 23 January 2013 (UTC)[reply]
      • I understand your point, but I still think that these playgrounds should be grouped together rather than mixed with the serious languages. Maybe at the bottom if not at the top. Or here is a better idea: We could have a WMF-wide user option for privileging some languages in this way. Everyone could have their favourite languages on top when logged in. Hans Adler 17:02, 23 January 2013 (UTC)[reply]
  • Support irrespective of the quality of Simple English Wikipedia (note that I am not a contributor there). There is a connection between English and Simple English which doesn't exist between English and other languages. Listing Simple English under 'S' is a massive usability failure: why would new users expected to look there for a version of the current article in simpler language? I see that a lot of the oppose !votes are taking this as a decision on the quality of SEWP. That's not the point: it's about usability for readers. MartinPoulter (talk) 12:56, 25 January 2013 (UTC)[reply]
  • Oppose. Setting language priorities is a bad precedent, IMO. Kaldari (talk) 21:34, 29 January 2013 (UTC)[reply]
  • I would fully support this if and when Simple Wikipedia improves to the point that it is as good as the other top ten Wikipedias. Marcus Qwertyus (talk) 22:32, 29 January 2013 (UTC)[reply]
  • Oppose. In full disclosure, I have been editing there about three weeks. (Not because of this discussion; I followed an Alice in Chains album article over to correct something). I've made 33 edits (2 of which were to hang wallpaper on my user pages). I thought I would be useful there since I have a knack for decreasing the grade level of written text (print newspaper journalism background). Although I've only made changes to a small number of articles, I've read many, of which I've watch-listed most for possible tinkering. I will leave out of this discussion much of what I find difficult in editing and adjusting there; except to say that if there are indeed only 20 or so active editors manning the gates on Simple, if we and the public all flood over, the situations will degrade even more. This is not to say I won't continue to edit there, but I am not gazing through rose-coloured glasses. Actually, I find the articles more difficult to parse there than here and I have no lack of intelligence. As an aside, when my daughter tells me she has difficulty comprehending an article here on our full-blown technical Wikipedia, I tell her to read the article talk pages for clues. That is an avenue that not all the public is aware of, either. Cheers! Fylbecatulous talk 02:17, 30 January 2013 (UTC)[reply]
  • Oppose. Because Simple is simply crap. 188.26.163.111 (talk) 23:41, 30 January 2013 (UTC)[reply]
  • Support - Even if there are quality issues with SE articles (I've never edited there, and rarely use it myself), the simple fact of the matter is that it is also in English, therefore, on the English Wikipedia, it should always appear at the top. Lukeno94 (talk) 13:13, 2 February 2013 (UTC)[reply]
  • support This provides an obvious suggestion to people who wish to rad what is supposed to be a simpler version of the article. If there are problems there, more people working there will fix them. It's not reasonable to compare it with the top 10 WPs, because it has a different purpose--if it in any way resembled ,for example, the deWP or the frWP, it wouldn't fulfill the purpose of being simple. This particular WP is an exception to the usual rules on language versions, and should be treated specially. DGG ( talk ) 17:48, 7 February 2013 (UTC)[reply]
  • Support as a logical idea, essentially per DGG. There is a lot of en.wiki snobbery in the opposes, I'm afraid. No, not every other Wikipedia can have our resource pool, but regardless of quality, simple is more closely aligned with en.wiki than any other project. Jclemens (talk) 07:28, 11 February 2013 (UTC)[reply]
  • Great idea A lot of people find main Eng articles to complicated and this would help them easily find a simplier version. Doc James (talk · contribs · email) (if I write on your page reply on mine) 20:29, 11 February 2013 (UTC)[reply]
  • Strongly oppose. Giving greater focus to the Simple English Wikipedia is contrary to the goals of the real English Wikipedia. Our aspirations are for well-written articles. Well-written articles, even on complex and technical topics, are by definition readable. Where they are not, as is the case for many mathematics articles, for example, the solution is to improve the quality and readability of the primary project's material, not to create a fork that then requires the maintenance of two pages. Setting that complaint aside, the Simple English Wikipedia fails at the goal of providing an introductory-level interface to those sorts of difficult topics; very few of the Simple English articles correspond to deeply technical topics at .en; rather, most of them are low-hanging fruit that was relatively easy to convert down to Basic English. Taking mathematics, for example, five minutes of looking at the Simple English equivalents of challenging, but important, topics was not encouraging. Lie group has no Simple English article at this time. Hilbert space has a very non-Simple mess of an article. And differential equation highlights the condescending tendencies of the Simple project ("Although they may seem overly-complicated to someone who has not studied differential equations before, the people who use differential equations tell us that they would not be able to figure important things out without them."). Even if Simple were a potentially useful adjunct to .en, which I don't think it is, it's clear that it is not ripe to receive special benefits. Squeamish Ossifrage (talk) 15:29, 12 February 2013 (UTC)[reply]
  • Oppose. Let's give priority to this hopeless parasitical project that drains time and effort from the real English Wikipedia. Oh, wait a minute, let's not. Britmax (talk) 15:49, 12 February 2013 (UTC)[reply]
  • Strong support (non Simple editor). A person looking for French will generally find French, it's obvious. A person looking in English and not finding it easy to read may not know there is a simple english. Prioritise it. It's (for better or worse) the language of this wiki and a lot of people worldwide might benefit if a simple version is easier to notice. An influx of editors and readers may benefit that project (I disagree with arguments that simple shouldn't get extra awareness in case we might not get extra editors to cope! Same goes for any wiki promotion!). It may help that project (good!) and it's implicit in having simple that some users cannot benefit from enwiki as we would hope - the answer is not to indulge in victim blaming and how it's their fault they cannot handle our full and comprehensive articles with complex English. Point them to simple, if they want it, and make it easy. FT2 (Talk | email) 08:36, 13 February 2013 (UTC)[reply]
If there was any real chance that a user seeking a more approachable article would find it at Simple, I might be inclined to agree. But (assuming Simple is desirable at all) the articles most in need of Simple equivalents are the least likely to have them. Between Simple's "very good" (featured) and good articles, there are zero on mathematical topics, zero on core physics topics, and vanishingly few on pure science topics at all. And articles on controversial or divisive topics are typically wretched (not that our Israel/Palestine content is flawless, but ... still). In short, the things Simple is most needed for are the things it most demonstrably fails to provide. And in the few cases where both encyclopedias consider their articles on a topic to exemplify their best work, we're generally only 1 (or less) Flesch-Kincaid Grade level higher (Saturn, for example). Simple has all the problems inherent in a very small content of fork of en, with very little evidence of producing a useful encyclopedic tool with greater ease of reading. Could that change? In theory. If it does, I'd reconsider giving it a special relationship to en. But right now, its "special relationship" is that it is allowed to exist and be linked to at all. Squeamish Ossifrage (talk) 16:56, 13 February 2013 (UTC)[reply]
  • Oppose. With respect to the Simple editors who do good work there, the overall quality of that project is low. The core idea has merit - that users who are not proficient in English might find Simple English easier to understand. The problem is that Simple is not a good resource for many of the reasons already discussed above. Consequently, we stand the chance of actually leaving the reader worse off by promoting Simple. Moreover, I would argue the majority of readers who struggle are those for whom English is a second language. In theses cases, promoting Simple is far less useful than promoting their natural languages. It thus becomes a case of hubris or arrogance to assume that Simple is the best option. Resolute 17:10, 13 February 2013 (UTC)[reply]

"Editor of the day" section of main page

In the interests of encouraging more people to become editors, I would like to suggest showcasing a different editor everyday, on the main page. This would consist of a blurb by the editor, answering a simple question like "what made you start editing wikipedia?" or maybe "What do you do as a Wikipedia editor?" Then there could be a link See the changes made by this user. And maybe Leave this user a message. You could be famous for a day!

I'm imagining some kind of nomination process to become a "featured editor" selected an editor "testimonial", and of course the editor would have to consent, and brace themselves for what surely would be a surge of interest. I think this would be great for giving current editors more recognition for their hard work (the ultimate barnstar!), and it might also encourage / inspire readers to join up, by giving them something to aspire to. Two birds, one stone! :-) Mark M (talk) 21:58, 31 December 2012 (UTC)[reply]

  • Question What kind of process would be used to select this "featured editor"? Just as a well meant advice: This could also have some negative side effects if handled improperly. I think a LOT of care should be taken when developing this process (which isn't meant to discourage the overall idea). There is a lot of stuff that needs to be considered (does something like the general spirit of WP:NOBIGDEAL apply here as well etc). Perhaps similar processes at other projects (such as this one) should be examined first and look taken at how they work, how abuse of the process is being prevented etc). Just some food for thought .... -- Toshio Yamaguchi 22:29, 31 December 2012 (UTC)[reply]
Maybe "featured editor" gives the wrong idea.. I just mean editors whose brief "testimonials" are chosen to appear on the main page. I imagined the process would go: 1) Somebody would write a blurb about what they do, and/or why they think Wikipedia is great. 2) Other editors check the blurb, and check the user's recent edits to ensure they are "good" edits, and ensure the user is in good standing with the community (whatever that means), 3) The blurb / editor is approved (or rejected). I don't know how much demand there would be for such a thing, so it's hard to figure the best process beforehand.. it's just an idea. Mark M (talk) 23:26, 31 December 2012 (UTC)[reply]
Okay, thanks for the clarification. I'm not sure what exactly I think of this yet. One more thing to consider: It isn't always easy to determine whether an edit is good or not. There are editors who make a lot of edits that are controversial that are nonetheless made with the best intentions. This might not be of interest to the majority of editors of course, just saying that this could happen. I think the information given should be very basic. I like this "What made you start editing" idea. Oh, and who has the ability to approve or reject a blurb? Can any editor do that? Will there be a consensus / vote based process? -- Toshio Yamaguchi 23:50, 31 December 2012 (UTC)[reply]
I was thinking of a process similar to DYK, where there might be some obvious criteria that a testimonial would need to satisfy, as well as obvious criteria for the editor (not currently blocked, etc). Then it would be a consensus decision on whether the blurb is approved for the main page. Obviously there would be quite a lot of work involved here, and there doesn't seem to be much interest anyway, unfortunately. Mark M (talk) 18:14, 3 January 2013 (UTC)[reply]
  • Fully support Adding the humanity back to Wikipedia is the best thing we can do. We are a community of hard working volunteers - real people with real lives - and not just anonymous pieces of code that magically create content related to your latest school assignment, and who may drop by with long and scary messages full of policy shortcuts. Reminding our readers... heck, even our editors, that there is a real community out there that they are actually a part of.. man, it would be the greatest feeling ever. I know we got a teste of this during the findraiser, and I for one fell in love with it. That's exactly the sort of things we need these days, and the sort of thing that keeps on getting declined every time it is proposed... The time is now.--Coin945 (talk) 15:55, 9 January 2013 (UTC)[reply]
  • Oppose. Navel gazing at its worst. Editors can get recognition through thank yous, barnstars or other awards on their talkpages. AIRcorn (talk) 09:17, 10 January 2013 (UTC)[reply]
  • Support I don't think it should be viewed as self-promotion. I prefer to think of this as a good tool for editor recruitment. AutomaticStrikeout (T • C) 02:00, 18 January 2013 (UTC)[reply]
  • Support Why not. We do need to remember that the encyclopedia is written by real people. This stuff doesn't write itself and the contributions of some do deserve attention.--Amadscientist (talk) 11:18, 18 January 2013 (UTC)[reply]
  • Oppose In such a measure we would create the battleground for a whole new set of long and ultimately not particularly useful arguments about editor conduct that would complicate everything we currently have in place. The pressure on high edit counts means that the pool of people is bound to draw in a whole heap of controversial editors - I say "controversial" but the actual level of discontent would only have to be minor. There would be an assumption that only the absolute best (whatever that means) editors would qualify, a drive to perfection that would feed back into the disagreements and would be unavoidable. Grandiose (me, talk, contribs) 13:35, 18 January 2013 (UTC)[reply]
I tend to agree with most you say. Also I see the risk that this can create kind of a class system of those who have been featured and those who haven't (I am waiting for the first time I see a vote in an RfA like Oppose "He / She did some good article work, but hasn't been a featured editor."). -- Toshio Yamaguchi 13:50, 18 January 2013 (UTC)[reply]
  • Comment While what I said above is not enough for me yet to withdraw my support for this proposal (acknowledging that we don't have an instream of hundreds of new editors per day), I think perhaps we should use something other than a vote / poll based process. What about a bot that parses through all editors who have been active in, say, the last month and randomly chooses one of them? -- Toshio Yamaguchi 13:59, 18 January 2013 (UTC)[reply]
Which would defeat the entire purpose of this section - To recognize good quality work on Wikipedia. TheOriginalSoni (talk) 14:32, 18 January 2013 (UTC)[reply]
Okay, I agree. I suggest to develop a set of objective criteria a candidate for this has to satisfy. -- Toshio Yamaguchi 09:11, 23 January 2013 (UTC)[reply]
  • Oppose a useless waste of time and resources that will somehow end up causing strife. Let's keep popularity contest off the project. Ridernyc (talk) 05:36, 24 January 2013 (UTC)[reply]
  • Support idea, though clearly there should be a long discussion about format and implementation. The thing that always got me the most interested in Wikipedia was this idea that "hey, there are people here". I remember one time (before I became a contributor to the project) vandalizing some article or other, and being reverted in well under a minute, and politely asked not to do it again - I was actually quite shocked that there were people out there who cared enough to spend their time keeping things running. There's something elictrifying about the presence of this massive human element. The most powerful thing that we have going for us is that a snapshot of the community is always only a few clicks away from any given portion of the encyclopedia, and the more we can direct readers across that half-good-spooky/half-bad-spooky bridge, the better. My only concern is that any implementation would have to take considerable care to avoid being co-opted by any school of Wikipedians: Clearly well-roundedness would be a chief criterion, but we'd have to be careful not to prioritize any one type of editor (content-focused, project-focused, anti-vandalism, copy-editing, programmers, etc.) over any other. — PinkAmpers&(Je vous invite à me parler) 04:02, 27 January 2013 (UTC)[reply]
  • Oppose would be a massive drama magnet with little to no benefit to balance out the inevitable hurt feelings and arguments. Andrew Lenahan - Starblind 17:38, 29 January 2013 (UTC)[reply]
  • Weak oppose - Could be seen as an endorsement of that user's personal views. Marcus Qwertyus (talk) 20:56, 29 January 2013 (UTC)[reply]
  • Oppose, it shouldn't be about people, but content. Perhaps explain how the people who wrote what appears on the Main page (and others) can be found, - their user pages should tell more about them than short answers to standard questions, --Gerda Arendt (talk) 21:02, 29 January 2013 (UTC)[reply]
  • Support - Providing front-page access to average Wikipedians to air their view of the project? What could possibly go wrong? Tarc (talk) 21:03, 29 January 2013 (UTC)[reply]
  • Oppose Not necessary. We have the Barnstar program in place. Less Drama. More mileage. Less egos. More Wikipedia. GenQuest "Talk to Me" 23:04, 29 January 2013 (UTC)[reply]
  • Strong Oppose - everyone strives to be great. Everyone is great in their own way. I feel this would encourage elitism. I also can't fathom to think of the conflicts that may arise from this. There is already a project devoted to this. Wikipedia is all about Collaboration and working in teams. I think this project is too big for this proposal. Simply south...... walking into bells for just 6 years 23:15, 29 January 2013 (UTC)[reply]
  • Comment This idea reminds me of Commons:Meet our photographers, which is a page I really enjoy. Maybe that approach could be used here at English Wikipedia. The selection process would need to well thought out.--Commander Keane (talk) 07:33, 5 February 2013 (UTC)[reply]
  • Support- per PinkAmpersand and AutomaticStrikeout. Crazynas t 09:56, 9 February 2013 (UTC)[reply]

Unanswered questions - TAFI

(Moved from Wikipedia talk:Today's article for improvement.)

The TAFI proposal, which can be found here has been closed in support but cannot be implemented yet as there are still unanswered questions.

At current, it has been decided that:

  1. It is obvious that there is support to implement TAFI on the main page.
  2. The community has agreed to place the recruitment message below DYK as suggested in this image.
  3. The community has agreed to use "Help Wikipedia and join fellow editors in building _______ - today's Article for Improvement"
  4. To reduce edit conflicts, the community has agreed to constantly, randomly, display one out of several articles chosen per day.
  5. Edit notices geared towards new editors will be placed on TAFI articles.

—cyberpower ChatOnline 20:01, 8 January 2013 (UTC)[reply]

The following subsections will address the unanswered questions:

The wording of the edit notice

How should the TAFI edit notice(s) be worded and linked?

Live version

Template:TAFI(edit talk links history):

Comments

  • From WP:TAFI: "Welcome to Today's article for improvement (TAFI). Each day (or other time period, to be selected) Periodically we identify one or more underdeveloped articles that require improvement, to be linked to the Community Portal for collaborative editing, ideally to improve it to good article or even featured article quality over a short time frame, through widespread collaborative editing." -—Kvng 20:08, 8 January 2013 (UTC)[reply]
  • Comment – For context, below is how the current edit notice is worded (as of this post). Northamerica1000(talk) 20:25, 8 January 2013 (UTC)[reply]
  • It may be functional to reduce the length of the message to make it slightly less verbose. Omitting, or at least modifying the phrase "Together we can expand the world's knowledge" may be in order, because while the intent is clear, technically the "world" doesn't possess knowledge in a literal sense (people do). If to be retained, it should reworded to something such as "Together we can expand the availability of knowledge in the world." Northamerica1000(talk) 20:41, 8 January 2013
This article has been selected as Today's Article for Improvement!
Wikipedia is a free and open source encyclopedia that has been expanded by volunteers to over 4 million articles.
Please consider collaborating with other volunteers to improve this article.
Together we can expand the world's knowledge.
If this is your first contribution to Wikipedia, welcome! You will find editing instructions in the help system.
Click on the Edit tab above to start improving this article. Thank you for helping!
I like it too. AutomaticStrikeout (T • C) 02:48, 10 January 2013 (UTC)[reply]
  • Holy crap that template needs to be shortened. I've put the live version above, which seems to have gotten longer since the original post:
I'd suggest something like this instead:
Λυδαcιτγ 09:29, 11 January 2013 (UTC)[reply]
  • ALT 2

 – It's shortened while still providing editing assistance, encourages account creation and is updated with the project's logo. Northamerica1000(talk) 12:35, 11 January 2013 (UTC)[reply]

I just found out about this project when NickPenguin posted a notice about it on Teahouse talk. I strongly support this project: it's a great idea and very well thought out. However, while this template looks good in general, there is one potentially major issue. Providing a section-edit link to the Teahouse/Questions page (rather than just linking to WP:Teahouse/Questions breaks the Teahouse process, makes more work for Teahouse hosts, and isn't very helpful for new editors:
  1. this method doesn't give the user any of the important context. They're sent to an empty edit window and given no instructions (e.g. 'put your the subject field to "don't forget to sign your posts"). Pragmatically, this means that the Teahouse will get (potentially many) more poorly-formatted questions that will need to be manually fixed by hosts. New users also don't have a chance to figure out anything about the page they're posting to before asking their question, and the process for asking is potentially confusing. Say they fill in the edit form and press save: the question they just asked will not even be visible on the next screen! They wind up in the middle of a long discussion page that they have never seen before. Where did their question go?
  2. the vast majority of Teahouse questions are posted to the top of the page, feed-style, not the bottom. This is enabled by a JavaScript gadget that provides easy in-line editing. Posting to the top makes it easier for hosts to keep track of new questions, and figure out which ones have been answered. If we suddenly get a lot more questions being posted to the bottom of the page, it makes it more difficult to track.
  3. this also breaks my metrics :) I track how many questions are asked on the Teahouse Q&A board, how many answers each question recieves, and how many times the original questioner responds in their question thread. The Teahouse is an editor engagement project, and we're still analyzing the impact of Teahouse participation on new editor retention. Tracking these metrics relies on consistent edit comment strings. More bottom-posting (and more manual monkeying with poorly-formed section titles) makes my metrics less accurate.
So... can we just link to WP:Teahouse or WP:Teahouse/Questions instead? Jmorgan (WMF) (talk) 21:18, 11 January 2013 (UTC)[reply]
I removed the "by clicking here". The template has grown far too large though. Ryan Vesey 21:43, 11 January 2013 (UTC)[reply]
Thanks, Ryan. How about we just link to TH and to one of our newly-redesigned portal pages, Help or Community? Jmorgan (WMF) (talk) 22:44, 11 January 2013 (UTC)[reply]
I've shortened the live version to something inspired by ALT 2. I like the cheatsheet link being the first help link because it is plain nuts and bolds editing. I removed the link to the WikiProject TAFI, which is irrelevant to a newbie, in my opinion. The first link is now edit, as it should be, I think. Biosthmors (talk) 01:48, 12 January 2013 (UTC)[reply]
Regarding removal of the TAFI link: editors other than newbies are likely to work on TAFI articles, and the template sans the link orphans the project from where the article was decided upon to be a collaboration. Including the link provides perspective about how TAFI articles are chosen, and may encourage participation there. Northamerica1000(talk) 18:15, 12 January 2013 (UTC)[reply]
  • ALT 3
  • Here's alt 3: Teahouse link to edit page removed. WP TAFI link retained, because editors other than newbies will likely be editing TAFI articles, and the link serves to provide context to the project and how entries are chosen. Help page and Community portal links added, although this does increase the word count. Northamerica1000(talk) 18:07, 12 January 2013 (UTC)[reply]
I was actually suggesting we add (one of!) the portal links as a substitute for some of the other links. Particularly cheat sheet, tutorial, editing help and FAQ. Rationale being that these portals (particularly the help portal) links to a lot of these resources or similar ones, which offloads the responsibility from the template itself and reduces clutter. Plus, I like the way the help portal is designed :) But now we have all the other links, PLUS BOTH the portal links, so my suggestion has now inadvertently made the template longer, not shorter. I hereby retract my suggestion and excuse myself from the design committee! Jmorgan (WMF) (talk) 21:36, 12 January 2013 (UTC)[reply]
  • ALT 4

Posted ALT 4. Northamerica1000(talk) 05:50, 13 January 2013 (UTC)[reply]

Arbitrary section break - Edit notice

  • I support ALT 4 to be used as the TAFI edit notice at this time (which I composed), but this can easily change if new alts are posted. Northamerica1000(talk) 05:46, 13 January 2013 (UTC)[reply]
  • Regarding the edit notice part, I would like to clarify which is the edit notice everyone is talking of? Currently, there is one message that appears on the article page only, that introduces the reader to TAFI. But there is also another type of notice that comes up while you are trying to edit a page (just above the edit screen - I have seen it for the talk pages of several users, like AutomaticStrikeout).
That sort of notice will be a lot better than one on the normal page, as people will be more likely to be trying to find out how to work things around when they actually realise things are harder than they thought [which would be after they hit the edit button, for most users]. TheOriginalSoni (talk) 20:12, 14 January 2013 (UTC)[reply]
  • Support Audacity's short version. All the others are far too wordy and no one is actually going to read them. Kaldari (talk) 21:37, 29 January 2013 (UTC)[reply]
  • Support Audacity's short version per Kaldari. Keep it short and sweet. KillerChihuahua 17:34, 31 January 2013 (UTC)[reply]
  • Support Audacity's short version... except I'd have the "improve this article" link point to Help:Editing or something similar. People generally don't read big blocks of texts. The short notice serves its purpose of pointing out what's special about the page at the moment and nudging people to contribute. It makes editing sound fun. A big block of text with multiple links (which people will presume they need to read) gives the impression that editing is tedious. Let's not scare people away with TMI. Jason Quinn (talk) 18:35, 1 February 2013 (UTC)[reply]

How many articles are chosen per day

How many articles should be selected per day?

  • 1 article displayed randomly from a pool of 7. The oldest article in the pool will be removed and replaced with a new one at least once a week. -—Kvng 19:59, 8 January 2013 (UTC)[reply]
  • Choose and publish on a weekly basis: Have a minimum of 7 articles present in the queue each week, with 1 randomly displayed. I would prefer for all 7 articles be changed-out weekly. If the same articles are in place for weeks at a time on the Main page, editors will likely become disinterested in utilizing TAFI. Also, it may be unrealistic for articles to have to be chosen every day. Northamerica1000(talk) 22:21, 8 January 2013 (UTC)[reply]
  • Every week, we choose 7 or more articles to be randomly displayed on the main page. Like what Northamerica said, it would be to unrealistic and troublesome to nominate a new article every day.--Horai 551 (talk) 09:08, 10 January 2013 (UTC)[reply]
  • Why not have 7 articles per week on a rolling basis? The 7 would be randomized as to which gets shown at any one given time, but we could roll the oldest one of the list each day at midnight UTC and replace it from the pool. That gives each article equal access, and keeps the list slowly evolving. --Jayron32 17:08, 10 January 2013 (UTC)[reply]
  • This. —WFC— FL wishlist 19:39, 10 January 2013 (UTC)[reply]
  • At this time, I'm still for updating on a weekly basis with a minimum of 7 articles, and perhaps a maximum of 10, per the new guidelines at the project that utilize 10 categories from Wikipedia:Peer review/volunteers. Of significant concern is the likelihood that editors and administrators won't be available on a daily basis to perform daily updates for the Main page (which only administrators can edit), although a script could be developed to do so automatically. Additional concerns include daily updating being contingent upon the project continuously receiving a high degree of participation and maintenance; sometimes participation in WikiProjects begins to wane after initial interest, and using a script would still be reliant upon high participation levels. Weekly updates also serve to keep the process simplified. As a side note, if auto-updating is to occur, there would need to be a 7-day delay to provide time for the initial entries to exist. Northamerica1000(talk) 12:52, 11 January 2013 (UTC)[reply]
  • A rolling approach sounds good to me. I think we should consider a pool of 14, though, to maximize the odds that the reader will find something that interests him (or her), and to decrease the odds that dozens of people will try to work on the same article at the same time. WhatamIdoing (talk) 23:32, 18 January 2013 (UTC)[reply]

How the articles are chosen

How will the articles be chosen?

Moved from a different thread for consistency I propose that the following criteria be used when determining the next TAFI:

  • New TAFI should be chosen at least 4 weeks in advance, but no more than 8.
  • They should be chosen from articles nominated in the last 30 days.
  • Nominated articles should be unoffensive and of a large general interest so as to attract the most amount of editors
  • The article with the largest amount of support and the least amount of opposition becomes the next TAFI. Discussion will ensue in the event of a tie or a compromise
  • Unsuccessful nominations should not be nominated again for 4 weeks.
  • Articles above a C class should not be nominated.
  • Nominated articles should have the capacity to be improved up to FA
  • Successful and unsuccessful nominations will be archived after 30 days in the appropriate locations.
  • A notice should be posted on relevant wikiproject noticeboards when an article goes live as TAFI

Thoughts? --NickPenguin(contribs) 05:16, 6 January 2013 (UTC)[reply]

What does "Nominated articles should have the capacity to be improved up to FA" mean? What's an example of an article that would not meet this criteria? -—Kvng 03:19, 8 January 2013 (UTC)[reply]
In truth every article should have the capacity to become an FA, otherwise we don't need that article. What I mean tho is that the subject matter should have sufficient depth to allow for the quality we come to expect from FAs. Medical certificate is something like this; it is a notable subject, but it would likely not be among the best articles Wikipedia has to offer. Journalism, in contrast, seems to fit the bill. What I mean is that the article should lend itself to improvement because it has sufficient potential to be awesome. --NickPenguin(contribs) 03:37, 8 January 2013 (UTC)[reply]
I don't understand how "The article with the largest amount of support and the least amount of opposition becomes the next TAFI" would work. A single article is not always going to have the most supports and the least opposes. First Light (talk) 06:03, 8 January 2013 (UTC)[reply]
How about "supports-opposes" --j⚛e deckertalk 06:13, 8 January 2013 (UTC)[reply]
That would work, and is probably the simplest solution. First Light (talk) 16:08, 8 January 2013 (UTC)[reply]
I really think we need guidelines for TAFI suggestions.Horai 551 (talk) 07:38, 8 January 2013 (UTC)[reply]
I note that the criteria above makes no mention of lists, and implicitly suggests that they should be excluded (by only mentioning FA). Overlooking them altogether would be an opportunity missed in my opinion, as certain lists (such as List of food preparation utensils) really do lend themselves to this format. There are several very interesting lists in the link in my sig, some of which are at a low enough state of development to be worth considering. —WFC— FL wishlist 13:58, 8 January 2013 (UTC)[reply]
I'm not trying to explicitly exclude lists, I think they can make great TAFIs. Any article that lends itself to improvement should be a good candidate for this project. The suggested criteria should be amended so that it includes all types of mainspace content. --NickPenguin(contribs) 17:11, 8 January 2013 (UTC)[reply]
With that caveat, your suggestions look reasonably good. The fourth point would obviously need to be clarified, but presumably your intention was to keep things brief. —WFC— FL wishlist 18:07, 8 January 2013 (UTC)[reply]
I've updated the project's scope to include lists. See the Header page. Northamerica1000(talk) 20:52, 8 January 2013 (UTC)[reply]
Update: the project's main page has been updated with a guideline section. See: /Guidelines, which is transcluded to the project's main page. Northamerica1000(talk) 17:50, 9 January 2013 (UTC)[reply]
  • Comment – Regarding the proposals at the start of this section. The time frame in point 1 seems arbitrary, and creates a large, entirely unnecessary gap of time between acceptance of nominations and publishing; I oppose this. Point 2 isn't necessary, because sometimes discussion may occur for longer than 30 days about a nomination, particularly controversial ones. Point 3 goes against the grain of WP:NOTCENSORED, which is policy, although the latter "general interest" provision makes sense as a suggestion, but not as an absolute, because this can restrict topics and people can discuss matters at TAFI nominations on a case-per-case basis. Point 4 is fine, per being consensus-based. Point 5 may unnecessarily restrict editors from re-nominating after additional discussion has occurred about a topic on the project's talk page, for example. Point 6 is agreeable as far as being a general guideline, but some B-Class articles may be incorrectly assessed, and sometimes they still need significant improvement: it should not be an absolute. Point 7 is fine, but Featured lists should also be included. Point 8's time frame isn't necessary: the page has a tendency to become long, and people can easily find archived entries from the archives box, which is specific per types of nominations and content. Point 9 is all right, but it adds on more duties to the project: while this is a good idea, it shouldn't be made mandatory. Northamerica1000(talk) 18:17, 9 January 2013 (UTC)[reply]
To Point 3, I believe accepted nom should be uncontroversial, as they are going on the Main Page. I don't think the goal of WP:NOTCENSORED is to say we can't choose what to feature. The idea there is just to have editors consider the range of appeal for their nominated subject. About time frames, the time frames are completely arbitrary and probably unnecessary. I pulled them out of a hat with the intent of preventing slow down. The idea behind Point 5 is to prevent constant renomination of unsuccessful articles in order to get your horse in the race. If time based criteria are necessary at all, then we can just add something to the effect of "a reasonable time frame". --NickPenguin(contribs) 19:06, 9 January 2013 (UTC)[reply]
Hello NickPenguin. Regarding point 3 – Consensus being decided at the discussions has been functional so far. For example, the nomination for the Human body article didn't proceed to a scheduled article, due to many opposing based upon clinical nudity in the article (See this link to read the discussion). What is offensive or controversial is subjective, and I think nominations should be decided on a case-per-case basis via discussion, rather than limiting what people can post from the start, which may deter participation. Regarding point 5, I find the addition of something along the lines of "a reasonable time frame" to be acceptable. Northamerica1000(talk) 19:28, 9 January 2013 (UTC)[reply]
  • IMO,The articles choosing process be more streamlined and simplistic. We are obviously going to be nominating loads of articles, and it makes no use keeping the same way we have.
I suggest that we simply have a table for each category to be chosen. Each table shall list only the article name, the nom, the nom date, and three votes from other users. All articles with 3 supports go straight to the holding area [from where the articles per week are chosen], while articles with one or more oppose go to the discussion area, where we have a full fledged discussion and voting on opposed articles. TheOriginalSoni (talk) 14:19, 10 January 2013 (UTC)[reply]
I like the idea, but I would say that in this scenario, we can't do self supports, the 3 supports have to be from other editors. But ya, that sounds good. --NickPenguin(contribs) 17:07, 10 January 2013 (UTC)[reply]
Some sort of a table format to shorten the page is a great idea and would help to streamline it. Queues based on 3 supports from editors other than the nominator seems quite functional. I agree that nomination itself should not be counted as an !vote. Nice suggestion! Northamerica1000(talk) 23:49, 10 January 2013 (UTC)[reply]
The arts section has been converted into a table format for now. Please give your opinion on the new format on the TAFI talk page. TheOriginalSoni (talk) 15:54, 16 January 2013 (UTC)[reply]
Overall, I think that some of the proposed rules (Who cares exactly how soon the decision is made? What's wrong with picking something nominated 31 days ago?) are WP:CREEPy but not really bad as a rule of thumb to get us started.
I like the idea of including lists. Lists (especially lists that aren't in table form) are accessible to most new editors, especially if they are significantly incomplete and on a fairly popular subject (maybe something from Category:Lists of automobiles or Category:Lists of foods or possibly List of cancer types (which would benefit from very brief descriptions, like * "Astrocytoma, a type of brain cancer usually seen in children")). WhatamIdoing (talk) 23:40, 18 January 2013 (UTC)[reply]

PC1

Should pending changes level 1 be applied to TAFI articles for the duration of their post on the main page?

How to implement the random article feature

moved into this RfC for consistency

Following the closure of this discussion it seems there was consensus to run multiple TAFIs at the same time, and randomly show one of them to a visitor. How and who will implement such a feature? Additionally this raises the question about the number of article categories, and the number of articles that would run concurrently. My initial thought is we should select one article from each of the main categories found at the top of the Main Page:

  • The Arts
  • People and Biography
  • Geography and Places
  • History and Events
  • Mathematics and Science
  • Society and Culture
  • Technology and Applied Sciences

7 categories would mean that if the one week improvement time-frame is kept, a new article needs to be determined every day. --NickPenguin(contribs) 02:14, 7 January 2013 (UTC)[reply]

The random article feature was proposed to solve the anticipated problem of edit conflicts. I'm not convinced this will actually be a problem. I propose we proceed with current TAFI and solve problems as they actually appear. Looks like we must heed the fear of edit conflicts. -—Kvng 03:22, 8 January 2013 (UTC)[reply]
It probably would be easy to construct something on top of {{Random subpage}} or the like, if desired. --j⚛e deckertalk 06:11, 8 January 2013 (UTC)[reply]
What about simply selecting all 7 articles as a group at the start of the week or something? -- Toshio Yamaguchi 13:08, 8 January 2013 (UTC)[reply]
Note: the discussion here was actually closed in favor of having a single article appear on the main page at a time, chosen randomly from some pool of suitable articles. NickPenguin's suggestion above was also considered in that discussion, but it didn't make it. No need to reinvent the wheel here, guys! Cheers, ∴ ZX95 [discuss] 14:56, 8 January 2013 (UTC)[reply]
There was no previous discussion of how big the random group chose from should be. Anywhere from 2 to 7 seems like a reasonable number. TAFI is currently selected at the rate of once per week. Do we have the wherewithal to increase this to once per day? If not we can select the first N articles and then every week we can add a new one to the group and remove an old. -—Kvng 15:12, 8 January 2013 (UTC)[reply]
Ah, whoops. When I wrote that I had not read the OP very carefully; I was thrown off by the phrasing "... run multiple TAFIs at the same time ...", which, in combination with the list of categories, brought to mind a failed proposal to have many TAFIs displayed together on the Main Page. I have stricken my comment for the record :) Cheers, ∴ ZX95 [discuss] 15:17, 8 January 2013 (UTC)[reply]
I threw the 7 categories out there as a suggestion. I still think the new article posted every week is a good time frame, but I was saying that 7 articles selected a week turns into 365 a year, or an average rate of one a day. I kind of like the idea touched on by Kvng, we have a floating group number, and as articles are approved, we add them and remove the oldest items from the nominated group. --NickPenguin(contribs) 17:06, 8 January 2013 (UTC)[reply]
Is one a day doable. TAFI is currently doing one a week. I don't think there's a hurry to rotate articles out. Giving editors a prompted opportunity to improve an article more than once over several weeks does not seem to me to be a problem. -—Kvng 20:04, 8 January 2013 (UTC)[reply]

Regarding frequency, having a pool of 7 articles (one per each of the main topics at the top of the Main page), to be randomly displayed in the TAFI section on the Main page would be functional at this time. Entries could be chosen on a weekly basis here at TAFI. However, if participation drops, as often occurs at WikiProjects over time, this may have to be modified. If this is to go into effect, editors would need to be notified on this project's main page about the need for diversity in topic nominations, so that each main topical area is covered. In the event that less than 7 nominations are approved weekly, singular rotation as stated above would be functional (newest added, oldest removed). Lastly, an idea is to possibly include a purge option on the TAFI section of the Main page, to read as "View another selection." Northamerica1000(talk) 21:16, 8 January 2013 (UTC)[reply]

Regarding the implementation of random generation, utilizing wikicode similar to that used by Wikipedia's portals to view new selections could be a possibility. The following code: <div style="text-align:center; margin:0.25em auto 0.75em">{{purge|'''View another selection''' (purge)}}</div>, creates the following link below. Duplicate listings occur from time-to-time, whereby the same article is sometimes listed despite random generation, but it would likely work. Northamerica1000(talk) 21:48, 8 January 2013 (UTC)[reply]

  • Update: I've created some test pages in Portal namespace to demonstrate how this can be implemented, at: Portal:Today's article for improvement. Check out how the purge function provides randomization. It appears that the Random portal component will not function in Main namespace to provide randomization, and something likely needs to be developed that will function in it.
The relevant subpages are: Portal:Today's article for improvement/box-header and Portal:Today's article for improvement/Main page queue. Northamerica1000(talk) 21:45, 14 January 2013 (UTC)[reply]

Progress - Random generation

It appears that a similar system is possible to be implemented for the Main page area. It's a turnkey process. The "max=" section on the template's edit page: {{Random component main namespace|max=7|header=|subpage=Main page queue}} is updated per the number of weekly articles, and the subpages are updated accordingly per week. In the event of more than 10, the max can be adjusted and new subpages created accordingly. Northamerica1000(talk) 23:46, 14 January 2013 (UTC)[reply]

Should we be welcoming the new users who edit there? If so, how?

I think having some people there to patrol the TAFI article will be good. How about someone like the Welcoming Comittee or the Teahouse keeping an eye out for all the new editors coming in, so that we can give them good guidance? TheOriginalSoni (talk) 14:19, 10 January 2013 (UTC)[reply]

I posted requests for input over at the Welcomeing Comittee and Teahouse talk pages. --NickPenguin(contribs) 17:04, 10 January 2013 (UTC)[reply]
Presumably TAFI members will be visiting TAFI articles and will see edits from newcomers. We can update guidelines to remind editors that welcoming newcommers is part of the program. We can also recruit members of the welcoming committee to join the TAFI project. -—Kvng 19:23, 10 January 2013 (UTC)[reply]
These are all great ideas, and I support the notion of welcoming as part of the project's scope. Northamerica1000(talk) 23:56, 10 January 2013 (UTC)[reply]

To do list

We have already approved having a to-do list. How should we be displaying it? And who adds to the list? I think the best thing to do is to have a few experienced editors go through every article thats to go up to TAFI, and list all the potentials problems. These will be the to-do list that will be displayed to give a sense of direction to the new editors. TheOriginalSoni (talk) 14:19, 10 January 2013 (UTC)[reply]

Sounds like a good plan to me. So we establish the 7 articles for the week, then to-do lists are generated for each article on the talk page, and then everything should be ready when it goes live. --NickPenguin(contribs) 04:10, 11 January 2013 (UTC)[reply]

One line description

Now that I see the proposed template to be placed at the main page, I feel it looks a bit empty. I also find myself trying to remember what exactly that article would be about (as in most cases I would remember "A girl who dresses and acts like a boy" but not the word "Tomboy").

Voting

  1. TheOriginalSoni (talk) 22:03, 14 January 2013 (UTC)[reply]
I agree, I think we should have a one line overview of the subject. For example, suppose we nominated Their Greatest Hits (1971-1975) to go on the main page. Who's greatest hits? What's a "greatest hit"? In most cases we should include the first line from the article, or provide some context like in DYK content. --NickPenguin(contribs) 04:16, 16 January 2013 (UTC)[reply]

Where and how to place it?

In one of the discussions above, editors were in agreement to place TAFI below the DYK entries on the Main page (see this discussion). Regarding implementation, see the above Progress - Random generation for some ideas, and also check out this demo page: Template:TAFI Main page. Northamerica1000(talk) 00:30, 15 January 2013 (UTC)[reply]

By where and how, I implied where in the TAFI section - Should the description line be in a separate line, the same line or maybe before naming the article. TheOriginalSoni (talk) 14:39, 16 January 2013 (UTC)[reply]

Test page

A test page for TAFI's presentation on Wikipedia's Main page is located at:

Northamerica1000(talk) 06:32, 25 January 2013 (UTC)[reply]

Refined comment above, per new Wikipedia:Main Page/sandbox test area. Northamerica1000(talk) 04:13, 8 February 2013 (UTC)[reply]

Extra content on mobile version of Wikipedia main page.

I propose that the topics "On this day..." and "Did you know..." also appear on the mobile version of the main Wikipedia pages. The ammount of extra data is downloaded is not significant and one of the major and most interesting sections of the main page would also be available for mobile devices.

Why not make the watch option in the icons representing Village Pump sections work differently?

When you get to the Village Pump main page you have 5 icons for the 5 sections. Each proposes three options: post, watch and search.

But the way the watch option behaves is not logical: if you are already watching that Village Pump section it is simply redundant. It would be better that it be a toggle watch/unwatch. If you are already watching that section then unwatch should be displayed as an option and the option should be to remove that section from your watchlist. (Incidentally, is this proposal more appropriate for some other Village Pump section?) Signed: Basemetal (write to me here) 21:46, 27 January 2013 (UTC)[reply]

SupportI think this will ad functionality and usability to the itnerface, and shouldn't be too har to implement. Retrolord (talk) 10:46, 29 January 2013 (UTC)[reply]

Oppose. Waste of developer time with a marginal, insignificant benefit. If you know how to get to the Village Pump, you should be competent enough to manually unwatch a page. —Theopolisme (talk) 22:42, 29 January 2013 (UTC)[reply]
Then why have those options in the first place, since in every case "If you know how to do blah you should be competent enough to do blah"? None of those options is crucial. Every time there is another less convenient way to accomplish the same task. Once you start providing options and shortcuts, at least they should work logically and consistently. The benefit may be marginal on this issue and on every such individual small issue but this sort of reaction as yours in every case the interface starts looking more and more incoherent, with the rationale that each time the benefit would be marginal, will result in the end in lots of loose ends and an unpleasant experience overall.
It is not a "waste of developper time" to tie loose ends and to make an interface work in a tighter, more logical way. On the contrary letting such inconsistencies accumulate is what should not be allowed to happen. Your argument reminds me of someone who would consider that putting some used pair of socks into the laundry basket doesn't justify the effort, it's soon enough to pick them up from the floor just when they're about to do their laundry, which may be true for each one pair of used socks individually, but before long their floor will be littered with used socks the picking up of each one of which provided just a "marginal, insignificant benefit". Signed: Basemetal (write to me here) 07:39, 1 February 2013 (UTC)[reply]
Two more observations: the goal of my proposal was as much providing a shortcut to unwatching a page as making an option behave in a more logical way. If you do not like watch turning into unwatch, then how about if the watch option disappeared as soon as the page was already watched? Either possibility seems better than the way it currently behaves. Or maybe you actually like the fact that that option behaves in an illogical way?
The second observation is just the type of arguments people often use to oppose or to support proposals. "Waste of developer time". The question was basically "Would you like it better if you had an unwatch option when the page was already watched? Would you agree that it would be a more logical behavior? Or do you actually like the fact that when the page is already being watched the watch option is redundant (i.e. useless)"? That was the real question. Optimal allocation of developer time is a wider issue which is best tackled based on the whole picture of development needs, not for every micro-issue on a case by case basis.
I can't help but find comical arguments used by many (including me probably here and there) who like to micromanage, deeply worry about developer time each in their own corner. My considered opinion is that the most effective strategy in such discussions is focusing narrowly on the issue at hand rather than each participant getting involved in issues that are best tackled in a wider context. Let developers worry about how they organize their time. It's our job to make the proposals and it is their job to see where the priorities lie and which proposal is more important and which less so. Signed: Basemetal (write to me here) 08:17, 1 February 2013 (UTC)[reply]
It's our job to make the proposals and it is their job to see where the priorities lie. 'Us' and 'they' are one and the same in my case; it just didn't seem to make sense to me at first glance. Or maybe you actually like the fact that that option behaves in an illogical way? No need to get pushy. I think you definitely have some good points in your tl;dr above, but, frankly, this doesn't seem to be a used sock. The [watch] link is simply a convenience, and developing an entirely new method to add two characters seems to outweight the pluses. One could easily write some javascript to make the change, but a slower page load doesn't seem to be worth it. —Theopolisme (talk) 21:15, 3 February 2013 (UTC)[reply]
I do not know how much developer time it should take, but from the look of it, it appears a few lines of code (not more than dozen more) would be sufficient to make the change. As for the benefit proposed by this, I think having more consistency in how things behave would be considerably useful compared to the marginal amount of work required for implementing it, and a the few milliseconds extra that the page takes to load. So I'd Support this proposal. TheOriginalSoni (talk) 11:54, 9 February 2013 (UTC)[reply]

Option to watch a Section of the Village Pump

Of all of us involved in the Village Pump, some might be watchlisting it only because they want to keep track of only one or two proposals at the Pump, and not all the rest (I know I do it). So I think an option to watchlist only a particular section of the Pump might be a good and relevant opt-in feature for anyone who does not want to see all the proposals, regardless of whether it involves that person's interest or not. TheOriginalSoni (talk) 15:10, 1 February 2013 (UTC)[reply]

You can already do that: if you watchlist Wikipedia:Village pump (technical), for instance, you'll only get watchlist notifications if threads under the technical section change. Chris Cunningham (user:thumperward) (talk) 15:25, 1 February 2013 (UTC)[reply]
No. That means you watchlist only the technical. My point is that I am interested in only 3-4 topics out of 18 that make up a 200k "Proposals" page on the pump. I would want to see the changes in only those few of them, and not every time someone else changes something at the pump. TheOriginalSoni (talk) 15:38, 1 February 2013 (UTC)[reply]
That's something I'd support wholeheartedly. I made a similar proposal in the past, where I suggested that the Village pumps contain only transcluded subpages and when you edit a section, you automatically edit the subpage. (I'd need to look for the proposal in the archives). There was also a BRFA in the past for a bot that could mirror discussion threads on some other page (that bot never materialized, however). -- Toshio Yamaguchi 15:30, 1 February 2013 (UTC)[reply]
My memory was incorrect. I was thinking of Wikipedia:Village pump (proposals)/Archive 89#Subpages at TfD and Wikipedia:Village pump (proposals)/Archive 74#Change TfD to use subpages, both of which are concerned with TfD. However, I also found this. -- Toshio Yamaguchi 10:10, 5 February 2013 (UTC)[reply]
Actually, a capability along these lines could be useful in lots of places. There are times when I want to watch a thread at a particular noticeboard without watching the entire noticeboard. --Tryptofish (talk) 19:50, 3 February 2013 (UTC)[reply]
Subpages are good, but they have some limitations -
a) For systems structured on a per-article basis, they have a natural structure - WP:AFD/ARTICLENAME, WP:RFC/USERNAME, etc. Any page titles which collide are almost guaranteed to have a meaningful connection in some way and can be dealt with by hand. For something like the VP, though, we have a lot of less meaningful section titles - "Option to watch a Section of the Village Pump" is good, but things like "Fonts" and "MathJax" are going to produce a lot of title collisions.
b) They're a lot trickier for new users. "Create this page, edit this page, and add a transclusion" is a lot more off-putting than "hit edit and add something". Andrew Gray (talk) 12:47, 5 February 2013 (UTC)[reply]
c) They make it much more difficult to casually watch all discussion on the page. Right now, I just load the diff since the last time I read the page and see what changed. With a subpage scheme, I'd need to be watching and unwatching subpages all over the place. Anomie⚔ 13:13, 5 February 2013 (UTC)[reply]
I dont really think subpage is the best way to deal with this situation. Someone with more technical expertise on the same could really comment on what will be the best way to do it. What I intend is a button/star along with section headings (near the edit button) which could allow me to watchlist or unwatchlist only that section of the page. Whether or not it is done through subpages, or made opt-in (through Preferences), or be implemented on all pages could be decided by further discussion on the same. But as such, it would be a lot simpler for a lot of people if we could just have the option to watchlist only certain sections of the page. TheOriginalSoni (talk) 11:30, 9 February 2013 (UTC)[reply]
Subpages can be done as-is, but "proper" per-section watching on a single page would require some pretty heavy lifting on MediaWiki itself. This has been a requested feature since 2004 - Template:Bugzilla - and it seems that the lack of a practical way to do it is the major stumbling block. Andrew Gray (talk)

Category:All unreviewed new articles

The Category:All unreviewed new articles should have a small but dedicated task force to keep it reviewed in a timely way. A break in my effort on this category meant that it balloned in size. A more organized effort is needed, and meanwhile I would welcome some help.--DThomsen8 (talk) 15:44, 3 February 2013 (UTC)[reply]

BabbaQ is adding a lot of articles to that category. Why? Ryan Vesey 21:23, 3 February 2013 (UTC)[reply]
I was under the impression that the articles was unreviewed and that this "category" could be added by users to these articles. If that was incorrect then I do apologize. But I dont think I have done anything wrong that would make user Ryan Vesey wanting to "investigate" it. Very odd.--BabbaQ (talk) 22:09, 3 February 2013 (UTC)[reply]
No, User:BabbaQ, you can add this tag, but most of the tags are from the new articles creation process, but your articles should have talk pages with appropriate templates. My concern here is to get more editors doing the work.--DThomsen8 (talk) 23:12, 3 February 2013 (UTC)[reply]
The tag shouldn't be added to articles alone. The only reason articles exist in that category is because they contained at one point {{Userspace draft}}. This was necessary at the time, because articles newly moved from userspace into article space were not patrolled at Special:NewPages. Now, Special:NewPagesFeed does patrol articles that are newly moved into the article space. I suggest that we completely modify {{Userspace draft}} to read the same as {{User sandbox}} when it is in the article space, it no longer serves the purpose it once did. Ryan Vesey 18:44, 7 February 2013 (UTC)[reply]

Customized Welcomes

Here's an idea for welcoming new users (especially considering the latest report about most new users being greeted with automated warning templates. How about if new users were given customized welcomes, either by a bot or by people reading a bot-prepared list? For example, if someone with a French-sounding username edits an article about a museum, we invite him/her to Wikipedia:WikiProject Museums, Wikipedia:WikiProject France, and suggest some French museums in need of improvement. We could even give an invitation to look at the French Wikipedia. Thoughts? -- YPNYPN ✡ 04:44, 5 February 2013 (UTC)[reply]

Basing a welcome on their actual edits, rather than what their username "sounds like", would probably be a better idea... though, for the record, I do think tailoring the welcome templates is a good idea. EVula // talk // ☯ // 05:19, 5 February 2013 (UTC)[reply]
I sometimes tailor my welcomes by adding a wikiproject that's relevant to their editing. It is a lot of faff to do that manually but if someone could do that programmatically I'd happily use a welcome that included a line promoting any wikiproject that was relevant according to the articles categories or talkpage templates. That would only work for writers of new articles if like me you are welcoming someone whosse new article you'd just categorised, but it would work for most of that majority of newbies who start by editing existing articles. Otherwise the real point I'd make from that survey is that we aren't welcoming enough good faith newbies. Better in my view to welcome someone for their first good edit than start them with a warning for adding unsourced data. ϢereSpielChequers 15:19, 8 February 2013 (UTC)[reply]

Facebook Share Button/Like Button

I am a high school student, I use Wikipedia so much all the time. I would love it if you guys would implement facebook into your website. My reasoning behind this is due to the fact that if you were to add this people would start using it and others will read your articles. Growing the community, making people smarter by reading, and you guys will also have a higher ranking website. If this is not enough reasoning to add a fb button then please reply back to me with concerns or questions or comments.

There is no chance of this happening. Firstly, Facebook is a private company (of severely dubious repute), and it would damage the image of the charitable Wikimedia Foundation to endorse it; secondly, if we endorse one company we need to endorse its rivals, which will result in a mess of links on every page to Myspace, Bebo, Google, LinkedIn, Baidu and around 800 others. Since Wikipedia is currently the sixth most visited website in the world, I don't believe "having a higher ranking website" is something we're particularly concerned about. 84.13.26.181 (talk) 19:49, 6 February 2013 (UTC)[reply]
See Wikipedia:Perennial proposals#Share pages on Facebook, Twitter etc. This has come up many times in the past and every time it was rejected by the Wikipedia community. -- Toshio Yamaguchi 19:56, 6 February 2013 (UTC)[reply]
I checked that Perennial proposals page. It's unfortunate that it doesn't link to any previous discussion, but the reasons for rejection are very unconvincing. Like many discussions on Wikipedia, the reasons are based on the editor, not on the reader. What reader knows they can create an account and add a sharebox? The choosing the websites is the only reasonable issue, but that can be fixed by doing research on a number of news organizations and see which links they most often use. The New York Times uses Facebook, Twitter, Google+, Tumblr, LinkedIn, and Reddit. The Washington Post features Facebook and Twitter, and also has Tumblr, reddit, stumbleupon, digg, delicious, and google+. We could also do like NYT does and feature the main ones, with a share button that brings up more for the others. Ryan Vesey 20:05, 6 February 2013 (UTC)[reply]
The NYT is aimed at the US and so features those sites popular in the US; the BBC is aimed at the UK and features those sites aimed at the UK etc etc etc. Wikipedia is aimed at a world audience, so would (rightly) be accused of bias if we didn't include at the very least those sites popular in every English-speaking territory; thus as well as the usual Facebook, Twitter etc we'd need to include Baidu (#1 in Hong Kong), Bongoline (#1 in Tanzania), Bebo (#1 in Scotland), MySpot (#1 in South Africa) and …well, you get the idea. (Facebook is so ubiquitous in the US that it's sometimes hard to remember that it's not the world-dominator it likes to present itself as.) If we stuck with only US/UK sites, or gave them high prominence while relegating other countries to a "see also" button, there would be absolute uproar from the rest of the world about cultural imperialism, which is not what Jimmy Wales wants. 84.13.26.181 (talk) 20:16, 6 February 2013 (UTC)[reply]
We'd focus on the English speaking world. BBC gives Facebook, Twitter, Stumbleupon, Reddit, Digg, and Delicious. Australian Broadcast Corporation uses the same but adds LinkedIn. While I understand that there are tons of regional social networking sites, we should attempt not to weigh them too highly as they're unlikely to be useful to a majority of our readers. I checked the Scottish Sun [4] which uses Facebook, Twitter, Google+, Digg, MySpace, Fark, Buzz Up, Delicious, Reddit, and Now public. We could also do what I suggested below and only do Facebook, Twitter, and Google+ since they're the main ones. Then we wouldn't need to make any decisions. Ryan Vesey 20:25, 6 February 2013 (UTC)[reply]
In plain word, as nice a term such as social plugin may sound, the FB like button is essentially nothing more than a marketing tool. This raises privacy concerns, as it can be used to track visitors to a site, even if those users are not Facebook users at all (see Like button#Plug-in). -- Toshio Yamaguchi 20:33, 6 February 2013 (UTC)[reply]
(edit conflict)I understand the points by 84.13.26.181; however, I think this is a good idea. We're one of very few websites not to have a share button. I wouldn't see a problem with having a share button on the sidebar with Facebook, Twitter, and Google+. Ryan Vesey 19:58, 6 February 2013 (UTC)[reply]

The last major discussion is at Wikipedia:Village pump (proposals)/Archive 87#Share button where I listed 14 previous discussions and there have been a few since. Again, I fail to understand how simply sharing an article turns Wikipedia into a social networking service. Editors engaging in a collaborative work form a social network, thus Wikipedia is social networking, but we keep discussions focused on improving content. --— Gadget850 (Ed) talk 20:46, 6 February 2013 (UTC)[reply]

Over at Wikinews, they have links for linking to articles on other sites via a template at the bottom of every article. It could probably be turned into a script for those certain users that want to share articles, since it isn't needed for widespread use here at Wikipedia. --J36miles (talk) 22:32, 6 February 2013 (UTC)[reply]
That's the exact problem I mentioned above though. It focuses on the editors, without taking care of the readers. There's far more of them so they're far more likely to share articles. They can't use a script. We could create a script to turn it off for editors who want it off though. Ryan Vesey 00:07, 7 February 2013 (UTC)[reply]

Let me expand on Ryan's perspective: Wikivoyage has a great little "essay": voy:Project:The traveller comes first. That concept is at the heart of most policy discussions on WV - does the proposal benefit the traveller, who is the actual user of WV's content? In our case, we should be reminding ourselves to "put the readers first". Will our readers want this? Judging by how much use share buttons are used on other websites, yes, they will. It is standard fare on websites these days. Our readers may have privacy concerns, but these can be worked around easily (we are not obliged to use Facebook's own social plugin, and WMF probably wouldn't let us anyway). Put the reader first, not the editor. — This, that and the other (talk) 11:16, 7 February 2013 (UTC)[reply]

Two questions though. One, is there ANY language version of WP with a share button or similar? And two, are there are other major websites with said buttons that are non-profit and don't have any advertising? ♫ Melodia Chaconne ♫ (talk) 14:37, 7 February 2013 (UTC)[reply]
Just what problem are we trying to solve here? Has some web browser out there had an update that removes the ability to copy and paste URLs? It's easy to post a Wikipedia link anywhere else without giving up user privacy. Just because "other websites" don't respect user privacy doesn't mean that hosting social websites' tracking code would somehow be providing a service to our readers. Ntsimp (talk) 16:07, 7 February 2013 (UTC)[reply]
The tracking code issue is a bit tangential. While it's been brought up in the earlier discussions - and I agree entirely it's a thing we should never countenance - it seems that it would be practical to implement (eg) a Facebook share button without using any of Facebook's own code, or allowing them to track our readers in any way. There are reasons for and against a share button, but the horrendousness of some of the default-provided ones isn't an issue. Andrew Gray (talk) 18:12, 7 February 2013 (UTC)[reply]

So what exactly do people want to do with this? Is it going to be implemented or?

An WP:RFC would probably be the next step. — This, that and the other (talk) 07:04, 9 February 2013 (UTC)[reply]

Sharebox

The Sharebox user script uses the AddThis bookmarking service to add e-mail and share buttons to the Wikipedia toolbar. As of February 2013, AddThis supports 344 services. A few highlights:

In the US, there is a general belief that we currently live in an age where anything can be learned free of charge online - with Wikipedia as one of the main learning routes. While Wikipedia does contain a great deal of information that is generally reliable, this information is not always presented in a usable fashion. Other Village Pump sections address many of the reasons for this lack of usability - for example, articles that may be overly technical. However, none of these sections seem to address the need for a "recommended reading order."

As an example, let's imagine someone with close to zero background knowledge would like to use Wikipedia to learn about computer science. That person may start at the main article but not even read a full paragraph before s/he has to read other links in order to even understand an introductory article to computer science. The person may "get lost" by having to flip back and forth between so many articles. Additionally, let's image that this person had instead started at an article on computer programming without realizing that this was a subset of computer science (per se) - that person may end up reading about typing systems, programming paradigms, and memory allocation in a completely random order that also leads to confusion. While some learning styles (e.g. global learners) may excel under this "random order" format, it is generally believed by the US educational community that many other learning styles - including sequential learners, the most common learning style - struggle under these conditions. They do best if there is a recommended order in which to read topics so that a person who reads them in order will (theoretically) always understand the majority of an article that s/he is reading. To go back to our basic example, a person should be able to click on "learn computer science" and have a recommended order for reading articles that will start with basic background and lead to more complex articles in a way that ensures that the learner will thoroughly learn as much about the topic as desired in a way that is not "confusing." For those who start in less basic areas (in our example, at programming instead of general computer science), there should be an indicator that denotes that there are more basic articles (and which ones there are), as well as more advanced ones.

I think that it would be possible for Wikipedia to crowd source such a project to available experts. For example, college instructors should be able to list which articles should be "pre-requisites" for later articles. Then, these lists could be added to portals or made available on the main page. I think they would greatly improve Wikipedia as a general learning tool and would help establish Wikipedia as an alternative to mainstream (e.g. college) educational practices.

At the very top right of the Main Page, there are links to eight different portals (such as the Arts or Technology), plus a link to Portal:Contents/Portals, which is an excellent resource for anyone wanting to start at the "ground floor" for a particular topic. But for an actual education-minded path, I don't think that's a good fit for Wikipedia itself; we're a reference website, not an education website. What you're talking about seems like a much better fit for Wikibooks. EVula // talk // ☯ // 20:33, 7 February 2013 (UTC)[reply]
Sounds more like Wikiversity. Rmhermen (talk) 02:17, 8 February 2013 (UTC)[reply]
I suggest you also check out the Wikipedia-Books project. It provides sequenced lists of articles pertaining to a particular subject area, that can (as a bonus) be downloaded as a PDF or even ordered in print form. — This, that and the other (talk) 04:31, 8 February 2013 (UTC)[reply]
Structuring our content in a hierarchical way is what outlines are for. Many of them are in a poor state however and I am not sure how much support they have from the community in general. Maybe we could try to improve our outlines in a more systematic way. It would be cool if they could be made more visually appealing by restructuring them as organizational charts. I don't know how that could be implemented though. -- Toshio Yamaguchi 13:01, 12 February 2013 (UTC)[reply]

ClueBot + Welcome Committee, two birds, one stone

A couple of issues:

  • Our resident vandal-catcher bot User:ClueBot_NG would like to expand its dataset of human-reviewed edits.
  • The Welcoming Committee would like to welcome all new constructive contributors to the project, it's been noted that often the first message received by new users is unfriendly and offputting.

So...

In the course of Cluebot's operation, if could form a list of every edit from a user with a blank talk page. Welcome Committee members could then review these edits, adding {{subst:Welcome}}/{{subst:anon-welcome}} or {{subst:uw-vandal1}} (or something else) as appropriate. These reviews would also be fed back to the Cluebot dataset.

It's an idea! Would obviously require a little tech. Thoughts, tweaks? --LukeSurl t c 14:50, 8 February 2013 (UTC)[reply]

Not a good idea, with 15,000 new users a month the list will be totally unmanageable from day 1. Additionally regarding the Cluebot review dataset, it's imperative to have as little noise as possible, and there's no problem with this specificity coming at the expense of additional database size. It's very much quality over quantity in an already decent-sized manually curated machine learning dataset Jebus989✰ 15:01, 8 February 2013 (UTC)[reply]
If people are willing to welcome newbies there is no shortage of prospects at recent changes or special new pages, so I don't see the benefit of an additional list. What would be useful would be to have a bot as a backstop - if someone has made say 50 edits without being warned or welcomed then an automated welcome would be better than nothing. That still leaves welcoming as a semiautomated rather than automated process, but just uses automation to fill in the gap where we lack volunteers. ϢereSpielChequers 15:24, 8 February 2013 (UTC)[reply]

Color-coded refs

There's something I dislike about editing on Wikipedia. The ref tag contents are the same exact color as the rest of the text in the editor. When there are a ton of refs bundled in with the rest of the text, as is often the case, then it often takes some searching. I think that refs, and possibly certain other elements, should be color-coded in the editor, to streamline the editing process by making it easier and quicker to find the text you're trying to edit. Maybe make refs red or something. I'm sure there are many editors who hate hunting through a forest of refs to find the text to be edited. Just my 2 cents. --Humorideas (talk) 16:42, 9 February 2013 (UTC)[reply]

Click here, check the box that says "Dot's syntax highlighter", hit save. This would be a very bad idea for universal roll-out rather than an opt-in checkbox, as color-coding would screw up screen readers. 89.242.85.135 (talk) 16:50, 9 February 2013 (UTC)[reply]
Thanks. Doesn't seem to work all of the time, but it should do. --Humorideas (talk) 17:16, 9 February 2013 (UTC)[reply]

Wikipedia:Article Incubator

Wikipedia:Article_Incubator#Time_limit states that: Content intended for mainspace should not be kept forever on subpages.... and Pages in the incubator may be nominated for deletion through Wikipedia:Miscellany for Deletion after a reasonable time has been allowed for development. No guidelines are given regarding what is reasonable. I would like to suggest that time is of the essence and that a month should be ample for a dedicated editor to get the article into good enough shape to return to article space. I would further like to suggest that a bot identifies pages in Category:Articles in the Article Incubator that have not been edited for more than 30 days and moves them to Category:Articles in the Article Incubator nominated for deletion, by setting the parameter | status = delete in {{Article Incubator}}. These pages can then be manually reviewed and submitted to MfD. Illia Connell (talk) 01:58, 10 February 2013 (UTC)[reply]

(BTW, I notified the AI project of this proposal here. Illia Connell (talk) 00:21, 12 February 2013 (UTC))[reply]

The community essentially abandoned the Article Incubator about 2 or 3 years ago. There are still a bunch of articles in there that were updated at the time but have never been reviewed by anybody. A shame really. Part of the problems of a declining community I guess. 64.40.54.47 (talk) 17:02, 11 February 2013 (UTC)[reply]
I'll just add that most articles today are userfied instead of incubated. Also, if anybody wants to review the incubated articles, I'm sure the original authors wouldn't mind (although I doubt they are still here). 64.40.54.47 (talk) 17:08, 11 February 2013 (UTC)[reply]
Thanks for the info. Perhaps we should delete all the articles per WP:STALEDRAFT and mark the project as {{tl:historical}}. Regards, Illia Connell (talk) 17:27, 11 February 2013 (UTC)[reply]
Lets userfy anything less than 1-year old, as a practicable time limit, and delete those older than 1-year old with no activity for 1-year. Those older than 1-year old, and having activity in the last year, should be userfied as well. Any article (regardless of age) seemingly in acceptable condition for creations an article should be moved to WP:AFC and flagged for consideration. -- 65.92.180.137 (talk) 21:52, 11 February 2013 (UTC)[reply]
NOTE, WP:AFC now has a draft/working-copy process to flag under construction articles not yet ready for consideration, so perhaps AI should be merged into WP:AFC... where users improving articles created by others work on this draft-article process? -- 65.92.180.137 (talk) 21:55, 11 February 2013 (UTC)[reply]
All great ideas, although userifying and merging with AFC is above my pay grade! Also, can we compromise on a shorter time interval to send articles to MfD - how about 6 months? Regards, Illia Connell (talk) 00:18, 12 February 2013 (UTC)[reply]
I am not that much aware of the (de)merits of the Article Incubator. Yet I think that userfying is probably not a good idea. While in the Incubator it is relatively easy to search - Special:PrefixIndex/Wikipedia:Article_Incubator - and check them; and there is a (small but non-zero) chance of someone improving them. Or sending to deletion. Scattered around on user subpages they're harder to find. So I do not support the idea to userfy, I do support MfD'ing old ones. I never looked much into AFC, but the concepts are similar, so a merge may be useful. - Nabla (talk) 00:40, 12 February 2013 (UTC)[reply]
I support MfDing the hopeless old ones. I do not support MfDing any which have promise of becoming an acceptable article. And that's what I thing about AfD also. Just as there is no deadline on improvements of an existing article, there ought to be no deadline in constructing an article either, as long as it is NOINDEX and is not harmful in some positive way, such as abuse or advertising or a gross BLP violation or copyvio. Sorthing out the hopeless ones will not be rapid, because they all really need an individual check to see if they have potential, and I think any attempt at trying to remove them faster than they can be checked would be counterproductive. My advice, here as always when there's a large body of questionable material, is to start at both ends, removing the worst and improving the best. DGG ( talk ) 01:00, 13 February 2013 (UTC)[reply]

Massive Open Online Course(s) about Wikipedia

I've posted a draft Individual Engagement Grant proposal on Meta: meta:Grants:IEG/Wikipedia Massive Open Online Courses. If you're interested in the idea of a Wikipedia course on one of the new MOOC systems like Coursera or edX, please take a look and give feedback.--ragesoss (talk) 02:57, 12 February 2013 (UTC)[reply]

I've commented there, but I may as well do so here, too... I like the idea in principle but, please, anything but Coursera! --jbmurray (talk • contribs) 07:03, 12 February 2013 (UTC)[reply]
Why not Coursera? Lova Falk talk 08:09, 12 February 2013 (UTC)[reply]
Well, there are many critiques of the Coursera model out there: in short, it's part of a massively-capitalized attempt to capture the digital commons. See here, for instance. Note incidentally the last line of that post, on "Wikipedia, which, come to think of it, makes an interesting foil for the nascent for-profit MOOC industry..." It'd be sad to see Wikipedia become complicit rather than a foil to this burgeoning industry.
Me, I'm not against MOOCs per se. I'm more with Cathy Davidson's comments on the topic. --jbmurray (talk • contribs) 08:38, 12 February 2013 (UTC)[reply]
Doesn't the existence of Wikiversity make some conflict that may make the course get rejected? -- 65.92.180.137 (talk) 09:05, 12 February 2013 (UTC)[reply]

Note that discussion is picking up at the proposal talk page.--ragesoss (talk) 16:48, 12 February 2013 (UTC)[reply]

Make edit summary mandatory before submitting

I want to request so everyone have to fill up the "Edit summary" before you can submit your edit to reduce vandalism and to explain changes. As some people seem to not explain their change/s after edit on the "Edit summary" regardless if it's a vandalism or not. --Mr. Washee Washee (talk) 11:46, 13 February 2013 (UTC)[reply]

Given that edit summary prompts have been perenially proposed and rejected, I think it's safe to say that this more extreme version of the same idea is not going to get consensus. Yunshui 雲‍水 11:53, 13 February 2013 (UTC)[reply]
Question: Is this proposal to promote Help:Edit summary to guideline or policy? If not, then I'd oppose this, because there is no requirement to use edit summaries. -- Toshio Yamaguchi 13:43, 13 February 2013 (UTC)[reply]
Anyway, forcing editors to always use edit summaries might be counterproductive. -- Toshio Yamaguchi 13:47, 13 February 2013 (UTC)[reply]
There has just been a long discussion about this here. Lova Falk talk 14:43, 13 February 2013 (UTC)[reply]
Wow, I didn't know that guys, thanks. I just had a quick look and saw what you mean. Toshio Yamaguchi, in a way yes. I also wonder if some editors (mostly unregistered or new users) even recognise if it's there. But I still stand up to what I requested and hopefully one day it will pass. But I can also see why it wouldn't pass either once I had a look at what other people say on this section and other section similar to this. --Mr. Washee Washee (talk) 21:01, 13 February 2013 (UTC)[reply]
It is a good idea in theory, but check out my edit summary for this post to see why mandatory summary input isn't likely to change much. Resolute 21:23, 13 February 2013 (UTC)[reply]

Notification of NFCC enforcement task

I plan to start a large scale manually performed NFCC enforcement editing task soon. This message is being left here as a courtesy for information of the community. For details regarding the task, please see User:Toshio Yamaguchi/NFCC task. -- Toshio Yamaguchi 23:44, 13 February 2013 (UTC)[reply]

Have you thought about working with some of the editors that use WP:FURME, Some are listed here. They may be willing to simply fix the fair use rationales that need fixing. Perhaps you could post a note at Wikipedia talk:FurMe and ask for help fixing the problematic fair use rationales. Just a thought. I don't work in this area, so I'm not familiar with all the related issues. 64.40.54.22 (talk) 07:50, 14 February 2013 (UTC)[reply]
As long as WP:NFCC is policy and WP:NFCCE is part of it, the burden to provide a rationale is upon the people who want to use the non-free content. Anyway, since I publicly announced this task and the tagged files will be added to a maintenance category and stay there for at least 7 days, anybody is free to provide a rationale. Also note that I will not touch files (at least while performing this task) where there is a rationale which may simply be bad. -- Toshio Yamaguchi 08:15, 14 February 2013 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=538190871"