Jump to content

Wikipedia:Village pump (proposals)/Archive 73

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 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, 213, 214

Automatically move-protect user talk pages

I bring this proposal forth for community consideration. Flat out, I really don't see the need for anyone to move a page that is supposed to endorse the collaboration of the community and the criticism of ones actions. While it is not hard to request this at WP:RFPP or go to an administrator, It would be even easier if they were automatically protected. Wikipedia basic principles are that the collaboration of users is vital to the growth of the community. In full disclosure, I found it interesting that this was not proposed already. I may not be familiar with the technical aspects, MediaWiki software, etc. but I would prefer that this, if good community consensus is received, be initiated for a 3-6 month trial term and, if everyone is agrees that is a good idea, it can be implemented fully. Thanks to the community for your consideration. mauchoeagle (c) 22:55, 6 May 2011 (UTC)

Help:Archive#Move_procedure. Rd232 talk 23:00, 6 May 2011 (UTC)
(edit conflict)I can think of two examples of legit reasons to move a user talk page. First sometimes new users create a draft article there rather and want it moved to article space (or AFC). Second, it is one method of archiving talk pages. Is this really a problem or unneeded policy creep? Monty845 23:03, 6 May 2011 (UTC)
I have to oppose this proposal, because I agree with Monty845.  Hazard-SJ  ±  03:56, 7 May 2011 (UTC)

Also, some user "archieve" their talk pages by moving it. --Tyw7  (☎ Contact me! • Contributions)   → Careless edits costs reputations 12:00, 8 May 2011 (UTC)

@MauchoEagle, what is the problem that you are trying to solve with this proposal? I have never seen where the moving of user talk pages has caused a problem. GB fan (talk) 12:37, 8 May 2011 (UTC)

Post-FA stage

I'd like to propose that Wikipedia:Article development guideline include a section detailing suggested post-FA activities. Please see the discussion here. Thank you. Regards, RJH (talk) 15:43, 9 May 2011 (UTC)

You mean where people complain about ownership problems and that more accuracy is needed, the article is improved and improved, goes through featured article review again and then is attacked by Fuerzas Armadas Revolucionarias de Colombia (FARC) and destroyed? Do we need to dwell on that in the development guideline? Dmcq (talk) 16:44, 9 May 2011 (UTC)
Heh, yes that's one possible scenario.—RJH (talk) 20:46, 10 May 2011 (UTC)

A Proof of editorship for CV

I feel useful editing wikipedia, however it is a charity work and everyone says I am wasting my time. I think it would be more rewarding if there was a document one could request for a fee —in a similar way to a police report— for CVs (resume) or progress reports for academics. It may be useful for academics only, but that is the group of people most needed. Basically, I am picturing an official looking document which has an automated data analysis report, say time dedicated to gnomish work, expansions/creations or community involvement, timecourse of edits/bytes, barnstars and other awards. Is there anything remotely like this? --Squidonius (talk) 21:05, 10 May 2011 (UTC)

Nice idea. -- Eraserhead1 <talk> 21:09, 10 May 2011 (UTC)
"Excels at reverting penis vandalisms within 30 seconds" --Golbez (talk) 21:14, 10 May 2011 (UTC)
There are a number of edit counters, some of which generate nice charts giving a breakdown of a user's edits by time and namespace. --Cybercobra (talk) 21:18, 10 May 2011 (UTC)
Writing an FA/GA or working with others are both useful skills, and having something formal would probably be useful for some people, Wikimedia could make some money out of it too. -- Eraserhead1 <talk> 21:20, 10 May 2011 (UTC)
Having served on promotion and tenure committees at various levels, I seriously doubt the usefulness of such a document when being evaluated for promotion at a major university. It could be a bonus if someone was already a strong candidate. But for a borderline case the likely response would be "they should have put more effort on their teaching and research instead of wasting their time on Wikipedia." Short Brigade Harvester Boris (talk) 21:25, 10 May 2011 (UTC)
Oh sure, but it would probably be good for someone applying to University. -- Eraserhead1 <talk> 21:31, 10 May 2011 (UTC)
Eh, maybe. Students already come in with tons of extracurriculars but I guess it couldn't hurt. Short Brigade Harvester Boris (talk) 21:39, 10 May 2011 (UTC)
It could serve as evidence of being capable of engaging in online communities with visible outcome and documentation of influencing skills. That could serve as a plus when applying for positions which are popping up for monitoring social media for trends or recruiting talent through use of social media. Another thing is the potential to demonstrate consensus building or conflict resolution skills in an online medium, something which people certainly aren't born with but learn and hone through practice. --User:Ceyockey (talk to me) 00:09, 11 May 2011 (UTC)

The "should have spent more time doing research than editing" is a key issue... Having witness an UG intern reading a page I had written in front of me I may find that editing is actually a way better (for the world) use of my knowledge than my experiments, but my thesis committee does not (as it does nothing for my funding body and the institute). It is similar issue to having a science blog. I am pretty sure that if the document showed the constructiveness of one's efforts, it would be worth it though... --Squidonius (talk) 01:30, 11 May 2011 (UTC)

Put your real name on your user page. Done. /ƒETCHCOMMS/ 02:12, 11 May 2011 (UTC)
For most purposes, I think it is far more important and effective to provide real identity through a professional interaction site such as LinkedIn rather than here. Nonetheless, I've followed suit ... though it is not obvious where you have placed a statement about your real identity, fETCH. --User:Ceyockey (talk to me) 00:55, 12 May 2011 (UTC) (p.s. I had my real identity here for a couple of years after initially joining, then removed it, so this is a "back to the future" move.)

Making it clear in article history whether an article is a response to a request

Some time ago, I requested a new article on Harvey Carr at the place where one requests for new articles. Synergy's good work soon met request. However, I noticed in the article's history there was nothing to suggest the article was a response to a request for a new article. Would it be possible to show whether articles are responses to such requests in their history, please? ACEOREVIVED (talk) 19:56, 10 May 2011 (UTC)

The edit summary of the first edit would be a good place, or there could be a talkpage template. Rd232 talk 22:09, 10 May 2011 (UTC)
I like the idea of a talkpage template. It would always remain easily visible, not getting "lost" as the edit history surpasses 50 edits, and may encourage more utilization of Wikipedia:Requested articles.--JayJasper (talk) 16:56, 11 May 2011 (UTC)


JayJasper, thank you, I agree with you, I too think that to have talkpage template seems like a very good idea. ACEOREVIVED (talk) 23:12, 11 May 2011 (UTC)

How about this: {{Was requested article}}? Rd232 talk 03:04, 12 May 2011 (UTC)

Well, what do you know? There already is such a template. I never knew that existed. Check it out on the talk page of the article linked above.--JayJasper (talk) 03:49, 12 May 2011 (UTC)

That template is {{Was requested article}} linked above by Rd232 who created it an hour ago. PrimeHunter (talk) 03:53, 12 May 2011 (UTC)
Yes - I guess that wasn't clear! :) If anyone wants any tweaks or parameters adding, let me know. Rd232 talk 03:57, 12 May 2011 (UTC)
Oh, I saw the "2008" in the example and thought that was when the template was created. Very good job, Rd232!--JayJasper (talk) 04:16, 12 May 2011 (UTC)


Thank you for all your comments, every one who has contributed here - it looks as if this proposal may have resulted in a welcome change for the Wikipedia community! Many thanks again, every one. ACEOREVIVED (talk) 19:57, 12 May 2011 (UTC)

Trustees May 2011 update

This seems like something that should stimulate discussion at the village pump, though I'm not sufficiently a regular here to be sure this subpage is the right one. I'd be interested to see ideas from other editors for ways to assist with the problems identified in the trustees' update. One idea (which I know is a perennial suggestion, with multiple archived discussions) is to limit tags in some way. A new user whose new article is a mess is not encouraged to continue contributing by a slew of tags at the top (assuming the article is not CSDed immediately). I'm aware of the productivity benefits that tags bring, but it seems to me that we are at the tag-heavy end of the spectrum as things stand, and some changes could help.

I'd also be interested to hear any other ideas that could help encourage new users. Mike Christie (talk - contribs - library) 23:37, 12 May 2011 (UTC)

  • (ec) I've only skimmed the surface of the recommendations but plan on digging in more later. I think that the appropriate place to discuss is really at the recommended location as the issues transcend en.wikipedia. It might well be that the Wikimedia Resource Family can't be well addressed as an aggregate and there will be Project-specific solutions and recommendations. Those en.wikipedia-specific facets of the recommendations would be quite appropriate to discuss here ... as long as they can be kept in general alignment with the thrust of the pan-Wikimedia effort. (As a recommendation—maybe a WikiProject should be launched to address "response to the Trustees' Recommendations") I'm generally happy to see this, but it does dwell much more on numbers of editors and drivers related to those numbers than more semantically deep issues such as whether the trend line of editing depth has changed over time or the specialization of topic treatment has plateaued or continues to drill down to the most sophisticated of topics. Personally, I think these are issues of more long term impact on the Projects than issues related directly to editor count and retention. --User:Ceyockey (talk to me) 00:49, 13 May 2011 (UTC)

BLP redirect

WP:Bacon, Lettuce, and Potato redirect to WP:BLP? Ian.thomson (talk) 00:42, 13 May 2011 (UTC)

Maybe on April 1st, but not the rest of the year. The Blade of the Northern Lights (話して下さい) 03:20, 13 May 2011 (UTC)

Operation: Enduring Encyclopedia

I propose we make a page for this. I mean, come on, like 350 users are participating in this fictitious operation, yet there's not the slightest fact of what it is or what's happening. Darkjedi10 (talk) 21:43, 8 May 2011 (UTC)

The CVU is a massive waste of time. Want to scrub vandalism? Great. The neo-militaristic jargon (and using as a template for the name the operation started by Bush the Lesser to subjugate Iraq is, at best, in shockingly poor taste) and sense of 'mission' is, to make a minor understatement, radically misguided. We should publicize it more because... we want more kids pretending they're on 24 fighting Teh Terrahsts? Please. → ROUX ₪ 23:07, 8 May 2011 (UTC)
Party pooper. Killiondude (talk) 22:50, 9 May 2011 (UTC)
How is CVU a massive waste of time?...just curious. The militaristic approach might not be half bad...maybe someone will frag Wikipe-tan if we're lucky.
⋙–Berean–Hunter—► ((⊕)) 04:18, 10 May 2011 (UTC)
The insane amount of time they waste in the militaristic nonsense and templates and (on and on and on) could be better used to do what they claim they actually want to do. As it is, what's really happening is they're more interested in the trappings than the actual task they volunteered for. → ROUX ₪ 21:38, 10 May 2011 (UTC)

Fine, go tell the 350+ users that their all kids cause that's just what you called them. And, hey, that's not a bad thing, being on 24. 67.142.161.33 (talk) 23:11, 8 May 2011 (UTC)

I agree with most comments posted here. I think WP:deny recognition is important when dealing with vandals. Having "Operation Enduring Encyclopedia" just glorifies the whole business too much. As a joke between vandal fighters it is unfortunate... but actually creating a page about it would be counterproductive. Yaris678 (talk) 15:23, 9 May 2011 (UTC)

I totally disagree. Darkjedi10 (talk) 15:54, 9 May 2011 (UTC)

You have yet to revert a single bit of vandalism, so I have no idea what you are basing your opinion on. Your proposed wikiproject also shows you do not understand how vandalism fighting works at all. Yoenit (talk) 21:09, 9 May 2011 (UTC)

Listen, I'm "Reverter" on the Simple English Encyclopedia, and in two days, I've reverted over 20 vandalism edits. I do not do it here because somebody always beats me to it, and the trouble of refreshing the Recent changes page every second it just plain bad. At the Simple English one, there's like one edit every three minutes. Darkjedi10 (talk) 21:12, 9 May 2011 (UTC)

I have may have come off a little harsh. I understand you want to help fight vandalism, but you have to understand it is not black and white. Sometimes you may revert something and warn somebody when that person was only trying to help. For example, you reverted this edit on simple english wikipedia. That is not vandalism. That shooting really took place in Alphen aan den Rijn, Daniel Catan did die (although on 8 april) and Seve Ballesteros also recently died. The person who made that edit was trying to improve wikipedia, but you reverted it as vandalism. That person might now be angry and sad that his edit was reverted and never make another edit again. This is a real problem with fighting vandalism, innocent civilians get hit by stray bullets (to stick with the military theme). We fear that if we treat vandalism fighting as though it is military or policework, more innocent users are going to get hit. Yoenit (talk) 22:36, 9 May 2011 (UTC)
And I've reverted the reversion. -- Eraserhead1 <talk> 21:42, 10 May 2011 (UTC)
Actually, he didn't revert it as vandalism, he undid it as "iffy". Nothing at all wrong with that. --SarekOfVulcan (talk) 17:30, 13 May 2011 (UTC)
I completely missed his edit summary (thought he used none). I still think the revert is unacceptable though, as there is nothing "iffy" about it. Yoenit (talk) 18:02, 13 May 2011 (UTC)
  • Oppose Quite frankly, people treat Huggle like a toy as it is and cause plenty of damage themselves. No one bats 100% with vandalism fighting, but the goal of the CVU and OEE is to be dramatic and get noticed. The goal should be to make vandalism fighting more effective and sink into the background while doing so. Sven Manguard Wha? 09:05, 11 May 2011 (UTC)
In terms of sinking into the background... has anyone got any thoughts on User:Yaris678/Deny automated recognition? Yaris678 (talk) 14:54, 11 May 2011 (UTC)

Y'know, there's more vandalism than ever before now. Darkjedi10 (talk) 22:28, 13 May 2011 (UTC)

Hasty generalization. Killiondude (talk) 22:50, 13 May 2011 (UTC)
That's far too much credit. 'Something I made up so I can get something I want and ignore what everyone is telling me' seems more accurate. → ROUX ₪ 22:53, 13 May 2011 (UTC)

Wiki-schools

To whom it may concern,

I am a teacher with a proposition: create Wikipedia entries/sub-entries specifically aimed at children of different ages. It will still follow the Wiki-principles of anyone and everyone adding and editing, but would encourage people to contribute information that young people of varying abilities could access.

Current issues: While Wikipedia is a phenomenal resource with entries so detailed that university students can get good degrees off the back of reading enough articles (I know, I watched some people do it!), I constantly watch my pupils (aged 11-16yrs) copy and paste large chunks of text about the relevant topic they've been asked to research. However, they don't generally do this because they are lazy - it is because they do not understand what they are reading. For example, say they are asked to research some key words to do with stars and galaxies. Search 'nebula' and you get a wonderfully detailed explanation. However, the pupils in my class are unable to lift the key information from it. Although they need to develop such skills, it is a step too far for most people with a reading age of below 13-14yrs. A similar issue arises with diagrams. It is surprising how difficult it is to find good quality, but basic, diagrams to do with science (particularly biology) anywhere on the Internet. I bet with the right encouragement, the millions of contributors to Wikipedia would unearth the 'best of the basics'.

BBC Bitesize: The default site for science classes to search instead is BBC Bitesize. This is a fantastic resource but has its limitations. Due to its old fashioned editorial nature, it has limited amounts of information and is more like a textbook than an encyclopedia. Pupils with below-average reading ages (a huge number) struggle to access even this information and many dislike being locked into a couple of pages - Wikipedia is more fun to search through.

Ideas: So how about having a linked page or sub-section for each word/topic where people are encouraged to contribute basic definitions with easy to understand diagrams? There is huge scope for development - nothing comes close to BBC Bitesize at the moment. There could be 'scaffolding' for authors to write definitions and facts for a range of reading ages (e.g. Key Stage 1, KS2, KS3 etc.) - a simple link to a reading age checker site would suffice. Basic diagrams, short descriptions, accessible language - all peer written, edited and reviewed. Older school pupils could even get involved by updating pages they think they can explain better.

I think Wikipedia is a symbol of the power and depth of the Internet. With the addition of a structure that allows people of all ages to access most of the information it could have a massive influence on education from a very early age.

I look forward to hearing your thoughts on this idea and whether we/you can take it any further.

Kind regards Ewen Bailey —Preceding unsigned comment added by Ewen.bailey (talk • contribs) 18:49, 9 May 2011 (UTC)

The Simple English Wikipedia sounds perfect for your students, [1]. There is also this page, [2] aimed at teachers to help you introduce your students to both using and editing wikipedia--Jac16888 Talk 19:02, 9 May 2011 (UTC)
Related: wikibooks:Wikijunior --Cybercobra (talk) 07:19, 10 May 2011 (UTC)
There's another problem as well that Wikipedia has a rather strong and inflexible stand against censorship whereas schools like their content censored. The editors here reject even support for schools to self censor pages. The foundation will collaborate on extracts for CDs or separate sites with censored content but it does mean schools will have strict controls over the use of the straightforward encyclopaedia in many cases. Dmcq (talk) 11:43, 13 May 2011 (UTC)

Extra tab for protected pages

MediaWiki:Protectedpagetext is shown on the "View Source" tab of protected pages; it contains various useful info, and a link into the Edit Request system. "View source" isn't a terribly inviting name to click. A while back I suggested changing the name of the "view source" tab, but that didn't wash. How about adding an extra tab, using Javascript, which says something like "Page info" and displays MediaWiki:Protectedpagetext? [On a related note, I suddenly wonder if it wouldn't be a good idea to just have an extra tab "about editing" for all pages which presents some of that sort of help info.] Rd232 talk 12:14, 13 May 2011 (UTC)

  • Personally, I think we don't really need any more tabs (and in Vector, it sticks everything in the drop-down on narrow screens). However, I do agree that the information there is useful—is there any way we can add the drop-down menu by default for all readers and then stick some extra links in there like "page info", "about editing", etc.? /ƒETCHCOMMS/ 22:06, 13 May 2011 (UTC)

Improving edit summary use

Note: these sections were originally part of the "prompting for edit summaries by default" discussion above, but the inclusion there was starting to cause confusion. Rd232 talk 15:40, 24 March 2011 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
I was asked to close this. Closed with consensus to implement a drop down with a range of common summaries below the edit summary box. --Errant (chat!) 20:10, 10 May 2011 (UTC)

What about providing a dropdown with a range of common edit summaries below the edit summary box? This would help new users figure out what they're supposed to do, and would also help make edit summaries less cryptic for people reading them. (If it's as quick to add a standard "Grammar correction" as to type "gr", surely that's more accessible for newcomers.) [In case it's not clear, this suggestion involves no compulsion to use the dropdown, merely to make one available for use.] Rd232 talk 08:49, 21 March 2011 (UTC)

  • Support. Encouraging editors to make edit summaries is a good thing for the encyclopedia, helping editors make edit summaries is even better Murray Langton (talk) 09:46, 21 March 2011 (UTC)
  • Support. I Support the 'dropdown with a range of common edit summaries' idea from above. IPs would be compelled to use them, but newbies and registered users should be let off with a few misses on bussy pages (like those on the resent Egyptian rebellion). Wipsenade (talk) 10:00, 21 March 2011 (UTC)
  • Support. This is a good alternative to the above proposal given the concern about making it harder for newcomers to edit.--Danaman5 (talk) 11:35, 21 March 2011 (UTC)
  • I would support this. Perhaps we should also consider giving a little more emphasis to the edit summary (bold text, larger text, colors, etc.) area as well. As Fetchcomms noted, it can be missed in all the other text around the edit box. Mr.Z-man.sock (talk) 14:50, 21 March 2011 (UTC)
  • Support as well, if made obvious what it's for, so new users understand what to pick if they want to (maybe start with a default of "what did you change? (pick below or type it in)" sort of thing). This isn't going to get around the "vandals using false edit summaries" and "no automatic edit summaries" problem but it seems like a reasonable compromise—especially if it's on by default but users can still turn it off in their preferences. /ƒETCHCOMMS/ 15:01, 21 March 2011 (UTC)
  • Support whether or not we decide to prompt, etc. This suggestion is quite elegant, really, this has the value of both making it easier to enter a lot of edit summaries, and teaching by example. --joe deckertalk to me 18:03, 21 March 2011 (UTC)
  • Support. I still support the default-to-mandatory-summary proposal above with or without this, but this would be a good idea if the default-to-mandatory-summary proposal is accepted. (If the default-to-mandatory-summary proposal is not accepted, this dropdown-box suggestion becomes less useful or important and perhaps not worth the effort, since the only people who ever see it would be users who have specifically turned on mandatory-summary.)
    • "the only people who ever see it would be users who have specifically turned on mandatory-summary" - no, the dropdown would be shown to all, regardless of whether a summary is mandatory. (Possibly with the option to hide it in preferences, if people want, but certainly shown by default.) Rd232 talk 10:15, 22 March 2011 (UTC)
  • Comment - I've seen a similar mechanism used in some wikia wikis, where you can choose the type of edit summary you're using. I'm not sure how it exactly it works and whether newbies in EBTHK use edit summaries more often, though. Kayau Voting IS evil 15:36, 22 March 2011 (UTC)
  • Support whether or not we do the above. It would even be helpful to experienced users. --Tryptofish (talk) 17:15, 22 March 2011 (UTC)
  • Support - per rationale of proposer and others expressing support. Helpful to new and experienced users alike. Should be implemented regardless of the outcome of the "prompt" disussion above.--JayJasper (talk) 17:50, 22 March 2011 (UTC)
  • Support - on its own merits, either in addition to, or independent of, the above proposal. This seems a good ides either way. Doc Tropics 18:00, 22 March 2011 (UTC)
  • Against (but with an alternative that I would support) - I'm an experienced editor who almost never logs in. I supply edit summaries almost all the time. A "dropdown" sounds like a list of choices I'd be forced to select from, and I want to have the option of customizing the summary. What I would support is an expansion of WP:Automatic edit summaries by generating a default edit summary based on an analysis that is similar to what Special:Tags does. If I don't replace the default, it becomes the summary; if I don't supply an edit summary, the default becomes the summary. 67.100.125.139 (talk) 02:11, 23 March 2011 (UTC)
    • Well I guess I wasn't clear enough: I envisaged a dropdown below the edit summary box, where selecting it would enter the text into the edit summary box. You could therefore ignore the dropdown for the many cases where a standard summary isn't appropriate, or possibly use a standard one and then customise it. Rd232 talk 12:27, 23 March 2011 (UTC)
  • Support the dropdown menu but the dropdown options must be very carefully thought through. --Anthonyhcole (talk) 10:14, 24 March 2011 (UTC)
  • Comment. I want to see how it will look like before I support/oppose. Ruslik_Zero 15:05, 24 March 2011 (UTC)
  • Mild oppose In reviewing my lengthy watchlist (>4000 articles), I find the lack of an edit summary a good clue that an edit should be checked. I don't have time to review every edit, so this is a useful filter. Vandals almost never provide an edit summary so why prompt them to do so?--agr (talk) 15:46, 24 March 2011 (UTC)
    • Well I could be wrong, but I suspect it's a pretty small minority of vandals who would be nudged by the existence of a dropdown to use a false edit summary, but aren't sophisticated enough to do it without that. Certainly understanding the significance of a missing edit summary is rather more advanced than most vandals get. (BTW You're not mixing this up with the "prompting" proposal above are you?) Rd232 talk 18:37, 24 March 2011 (UTC)
  • Comment—This would only work for me if the list was short and concise. I don't want to have to chase down the reason in a long menu with verbose entries because it would be faster to just type in a brief message.—RJH (talk)
    • Well the list would be populated from an editable MediaWiki page, so we could do whatever we want; the list does need to be easily navigated or it won't be much used. And I've idly wondered if it would be possible to use keyboard shortcuts somehow. Rd232 talk 18:28, 24 March 2011 (UTC)
  • Support An added benefit is that we can run bots to make, for example, statistics regarding edit summaries, so will have a better understanding of the editing process. Suddenly the information in the summaries gain more structure. Randomblue (talk) 06:41, 25 March 2011 (UTC)
  • Support This is a boon for every editor and it may establish a de facto standard for writing edit summary. I still have no idea whether we should use sentence, infinitive or participle for edit summary.--Netheril96 (talk) 17:19, 25 March 2011 (UTC)
  • Oppose—this simply overcomplicates matters. What is a 'common summary'? There's an infinite variety. And this would open the floodgates to misleading summaries, by accident or by design ("Oh, sorry, I meant to click rm but ended up choosing added refs...") ╟─TreasuryTag►Captain-Regent─╢ 07:29, 26 March 2011 (UTC)
    • "What is a 'common summary'?" - anything Wikipedians have evolved abbreviations for in edit summaries. "There's an infinite variety." - yes, but the dropdown is supposed to provide common edit summaries. As to accidental clicking: the dropdown should add its text into the edit summary box, so that merely clicking the wrong thing in the dropdown doesn't submit the wrongly chosen edit summary (i.e. you have the chance to amend it). Rd232 talk 10:55, 26 March 2011 (UTC)
  • Oppose per WP:PEREN#Automatically_prompt_for_missing_edit_summary. Choosing a (perhaps randomly selected) edit summary would suppress critical WP:Automatic edit summaries. Also: Why would I need this? Firefox, at least, has this functionality built in. Every edit summary I've used is automatically available to me; all I need to do is to start typing. You will, for example, find that the edit summary "One list of multiple items, rather than multiple single-item lists, per WP:ACCESS#Lists" appears repeatedly throughout my contributions. I assure you that I'm not typing that out every time. WhatamIdoing (talk) 17:18, 26 March 2011 (UTC)
    • What are the chances of a blanking test edit having a 'fixed typo' summary? ;-) Not too big IMO. This is just to tell good faith newbies about it, not make it more convenient for experienced editors. Kayau Voting IS evil 17:23, 26 March 2011 (UTC)
    • Whilst that's useful for experienced and high-volume editors, (a) that's not the main target market here (b) it doesn't work very well for section editing, since the section name is part of the edit summary field and so the browser doesn't recognise it unless it happens to be a common section name and you've previously used the edit summary you're going for in a section of that name. Rd232 talk 04:52, 27 March 2011 (UTC)
    • Re the Automatic Edit Summaries - AFAIK that currently watches for blank edit summaries on submission of the page; in principle it could check for Common Summaries too, and override it or add the "blanked the page" etc. Also I've wondered in the past if it shouldn't just label all summaries, like that at least for the key "blanked page" and "replaced all content" ones. I also wonder if some interaction with the edit filter tag system is out of the question, so the Auto Summary software could record a "blanked page" tag. Rd232 talk 05:05, 27 March 2011 (UTC)
  • One demerit of this proposal is that one may no longer be able to hit tab to get straight to the summary field. Kayau Voting IS evil 17:23, 26 March 2011 (UTC)
    • Well that's something to watch out for, but the tab order it depends on how the 'tabindex' property works out in the HTML. I'd imagine the dropdown below the edit summary field (so tabindex higher and tab goes to edit summary field first), but tabindex can also be set manually in HTML (not quite sure how this would be done in MediaWiki, but where there's a will...). Rd232 talk 04:58, 27 March 2011 (UTC)
  • Comment (I do apologise if I've missed it posted by someone else). In some wikis, like Russian, right below the summary field there's a row of buttons like wikification, spelling, using which one can easily describe the changes. Shouldn't it be better than a dropdown menu (where, as I conjure up, only one option can be chosen)? --Microcell (talk) 17:33, 26 March 2011 (UTC)
    • Ah, I see, that's nice that something quite similar is already in action. I have to say though that whilst it might be easier to sell that button approach (e.g. you're not the first person to think the dropdown would restrict you to one option - but it need not, it would work just like the buttons in terms of adding text into the edit summary field), I think the dropdown could work better in terms of making it clear to newcomers what's going on, because you can have a description of the dropdown within it, rather than needing to take up space next to the buttons. (The Russian WP foregoes a description.) In addition, the button approach encourages short single words, whereas I'm envisaging at least some of the common summaries being slightly longer, more helpful phrases. Rd232 talk 04:52, 27 March 2011 (UTC)
      • Yeah, I see your point. The idea is to make the design handier in terms of the number of pressed buttons - in this instance, the aforenamed row is at an advantage to the detriment of detailed explanations (or the menu mustn't drop down - then it's all right, but too much place is taken up). So, maybe it's better to invent something like a button row with full descriptions emerging as a mouse cursor is placed over the respective option? --Microcell (talk) 12:05, 27 March 2011 (UTC)
  • Support - this would work similar to the deletion screen (non-admins can see a screenshot of that here) - if you leave it at "Other reasons", it inputs nothing into the final result. עוד מישהו Od Mishehu 08:18, 28 March 2011 (UTC)
  • Support for a very limited range only. This would help to address the problem of too many blank edit summaries. However, I agree with TT that there are too many variants to attempt to cover every common scenario. Using a very small range - say just "rvv", "spelling fix", "link fix", "grammar" and "added references" to start with - would give the most benefit for the least risk. Alzarian16 (talk) 09:19, 28 March 2011 (UTC)
  • Support -with the first 'option' being blank; this wouldn't make it any harder for people who want to use the standard options, would make it a lot easier for people who like to customise all the time, and would make 'no summaries' stand out from the crowd. Pesky (talk) 05:39, 29 March 2011 (UTC)
  • Support, but how about checkboxes instead of a dropdown list? I'd like to be able to tick several boxes for things like "fixed spelling", "fixed grammar", "revert vandalism" etc. These checkboxes could append or pre-pend the abbreviations (e.g. "sp", "gr", "rvv") to the edit summary you would additionally/optionally type in. Zunaid 17:11, 30 March 2011 (UTC)
  • Support: if it makes it quick and easy for experienced editors to add less cryptic edit summaries, (and if said editors take advantage of this!) this will help new editors and make WP more welcoming to them. Checkbox idea is appealing, too, for multi-job edits. PamD (talk) 18:49, 2 April 2011 (UTC)
  • Support – Definitely, this is a very nice way to select common edit summaries without having to abbreviate something as rvv or the like. —mc10 (t/c) 23:36, 7 April 2011 (UTC)
  • Support (with a bit of a shrug) — Ched :  ?  02:54, 13 April 2011 (UTC)
  • Support Yes, it gives new editors an idea of what edit summaries are and saves time for experienced editors. Though I suppose we need to determine how many and what options the list should include. Zlqq2144 (talk) 23:42, 17 April 2011 (UTC)
  • Conditional Support So long as it doesn't override the auto edit summaries. —James (Talk • Contribs) • 10:11pm • 12:11, 18 April 2011 (UTC)
  • Support With the first (or would last be better?) item on the drop down list having no text and leaving the edit summary blank. Guy Macon (talk) 02:48, 20 April 2011 (UTC)
  • Support. This could improve the edit summary use of new constructive editors, which would make patrolling recent changes more efficient. There should be an option in the preferences to hide the drop-down list, though. Jafeluv (talk) 11:33, 23 April 2011 (UTC)
  • Support, wondered some time ago that there isn't any gadget for that. mabdul 15:54, 27 April 2011 (UTC)
  • Comment the auto-edit summary already gets in the way by covering up the minor edit checkbox, and if there is more than one in the list, the save page and preview buttons as well. I would be against this if it is something else that will cover up buttons forcing an additional click to get rid of it. SpinningSpark 13:34, 30 April 2011 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Reminder design

I think the missing edit summary warning would get a lot more use if it was designed better. I used to use it but it slowed me down too much, so I disabled it. Here's what I don't like about it: If you forget to enter an edit summary, the entire edit page still gets submitted, and then the entire edit page gets reloaded with the warning, and then you enter your edit summary and submit again. If you're on a slow connection and/or editing a large page and/or WP servers are slow that day, the last thing you need is to wait for the entire edit page to load again just to display a warning. Why couldn't we change it so that a dialog alert box pops up and says "You haven't entered an edit summary. Are you sure you want to continue?" with an OK and Cancel button. Or, even better, a dialog alert box with a similar message, with a field where you can type in an edit summary, hit OK, and be on your way. I think we could get a lot more support for prompting for the missing edit summary by default if the prompt itself was less intrusive and annoying. —SW— gab 15:39, 21 March 2011 (UTC)

I don't know about more support, but it would be worthwhile objective in itself. Can we Javascriptise it? Rd232 talk 16:50, 21 March 2011 (UTC)
This is kinda where my brain was heading too. While I'm not sure that popups will work across all browsers/platforms, I'd think it would be possible to load a new page that only displayed the question, instructions, etc., and an edit box, and carried along any other form data we need to pass on (in particular, the article edit) as hidden data. This would take a lot less time to load, but would eliminate a huge amount of the distractions, which I think is one of the bigger sources of cognitive load affecting usability here. --joe deckertalk to me 18:10, 21 March 2011 (UTC)
I think it's important to find a solution which doesn't involve loading a new page. Just about any Javascript-enabled browser would be able to display a simple alert box. If you're using a browser which doesn't support JS, then you're losing a lot of functionality on Wikipedia. I'll see if I can find some time to try creating something in js. —SW— squeal 18:58, 21 March 2011 (UTC)
This also would be fine, in my opinion. Either the drop-down list (suggested in the subsection above) or this idea, where the edit summary box is directly in the user's field of view, are fine and probably more or less equally good. Either one is much preferable to the current system where you have to go hunt for the edit summary box, and which we must upgrade if we are going to turn on default-edit-summary-prompting. Herostratus (talk) 06:39, 22 March 2011 (UTC)
"Either one"? I think we should have both, regardless of what happens with default-prompting. Rd232 talk 10:17, 22 March 2011 (UTC)
  • I took a look at the situation, and I believe it would require a MediaWiki update in order to allow a javascript to do this. The edit form's HTML needs to have an "onsubmit" parameter to call a javascript function when the user clicks Submit. That javascript function would pop up the alert box if there was no edit summary, and then proceed from there. Currently, there isn't a way (that I know of) to make this happen without some level of developer support. —SW— communicate 22:10, 23 March 2011 (UTC)

Comments

Is it possible to also add edit summaries to new sections ? Just because you can enter a title doesn't mean that you don't want to enter a larger summary. (applies to pages where there is a new section button/tab) 65.93.12.101 (talk) 06:36, 25 March 2011 (UTC)

You can't add a fuller edit summary if you use the add section button, but you can edit the full page and add a new section at the bottom of the page with a full edit summary. GB fan (talk) 20:41, 25 March 2011 (UTC)
Let me clarify: Is it possible to ADD FUNCTIONALITY to allow edit summaries when you create new sections ? (also, editing the entire page cause problems with very large pages, and edit conflicts in general, since every edit will now conflict with you.) 65.93.12.101 (talk) 02:13, 26 March 2011 (UTC)
The software currently doesn't allow it - but you can request it, see Wikipedia:Bug reports and feature requests for how and where. עוד מישהו Od Mishehu 08:21, 28 March 2011 (UTC)

This proposal is more or less already in use at some of the wikis over at Wikia.com For instance, the Runescape wiki uses a rather nice implementation of it. The javascript code that makes it work is located at runescape:MediaWiki:Common.js/standardeditsummaries.js. That script is loaded (jQuery?) with the following code added to runescape:MediaWiki:Common.js:

/* Standard Edit Summaries */
importScript('MediaWiki:Common.js/standardeditsummaries.js');

Finally, the dropdown list itself is maintained on that wiki at runescape:Template:Stdsummaries. — SpikeToronto 03:58, 10 May 2011 (UTC)

hm, interesting, thanks. I've tried importing it (User:Rd232/stdes.js and User:Rd232/stdesdata) and it doesn't quite work. Any ideas? Rd232 talk 04:26, 10 May 2011 (UTC)
To be quite honest, I work on a wiki over at Wikia.com, and added all the coding to the appropriate MediaWiki files and imported the template, but could not get it to work either. The little pulldown box simply would not appear when editing. I have a suspicion that one has to add something to to the LocalSettings.php file, or some such ".php" file. I suspect this for two reasons: (1) Using Special:Version, I compared our installations and they are virtually the same, with what few differences there are being unrelated to this; and (2) I went through all their runescape:Special:Allpages/MediaWiki: files and found only Common.js and Common.js/standardeditsummaries.js to have anything in them to do with this. My next step is to try and contact someone over there who has recently worked with that particular script and ask him/her what implementation step I am missing. — SpikeToronto 07:29, 10 May 2011 (UTC)
P.S. Of course, it could be as simple as one small part of the JavaScript needing to be changed (e.g., a variable/parameter name). But, I know as much about writing JavaScript as I do about reading ancient Egyptian hieroglyphs! — SpikeToronto 07:39, 10 May 2011 (UTC)
OK, if you can get any help with this, thanks! Rd232 talk 13:41, 10 May 2011 (UTC)

Now what

Looks to me like a consensus to implement (with appropriate testing and tweaking). So, is there is any way to actually make this happen, or is the only option to submit a bugzilla request and then ... wait? Can we, for instance (someone Javascript-savvy, that is) adapt the similar Sourcewatch Javascript here? Rd232 talk 01:43, 5 May 2011 (UTC)

My JS is reasonable, and I can get this working using JQuery - but I don't have the skillz to implement this without. And I don't think MediaWiki uses JQuery by default. If I am wrong then let me know :) --Errant (chat!) 20:55, 10 May 2011 (UTC)
Errant, could you take a look above in the Comments section and see if you could perform the task using the Runescape coding discussed there? I am not sure whether it is straight JavaScript or if it uses jQuery. Thanks! — SpikeToronto 05:47, 11 May 2011 (UTC)
Yeh, that is the JS I tried, without much luck. I can get it to work fine in my Vector.js, but once I moved it to an import it dies a death :( --Errant (chat!) 08:16, 13 May 2011 (UTC)
Aha, ok my JS foo was a little stronger this morning :) seems to be working. Add importScript('User:ErrantX/defaultsummaries.js'); to your skin javascript to test it out. Next question; how can we install this wiki-wide? And how much testing needs to be done? --Errant (chat!) 08:37, 13 May 2011 (UTC)
Fantastic! It works for me - without even purging my cache. We can install it wiki-wide by adding it into MediaWiki:Common.js - but we should probably come up with a Gadget to turn it off (in Preferences), and we need a place to discuss the edit summary list. For instance, I think the summaries should be categorised under a couple of headings (eg Major/Small/Minor), and the number kept low - lower than it is right now, I think (some can be merged, others maybe removed). Rd232 talk 12:03, 13 May 2011 (UTC)
I'm cautious of installing it in common.js myself :) If we made a gadget, and ultimately enabled it by default would that still work for logged out users? Because that would be my preffered approach. The list of options is just dumped from the original source ;) I can add "categories" into it, and tweak/change as needed. Do you have a suggested list? --Errant (chat!) 12:20, 13 May 2011 (UTC)
Is there a way to section the dropdown list? If we look at the implementation at the Runescape wiki, the dropdown list divides into sections of various types of edits. The files involved in their implementation are runescape:MediaWiki:Common.js/standardeditsummaries.js and runescape:Template:Stdsummaries. Thanks! — SpikeToronto 20:29, 13 May 2011 (UTC)
P.S. You can see their implementation by editing any random article there. Thanks! — SpikeToronto 20:51, 13 May 2011 (UTC)
Yes, easy enough to do - I'll have a look over the weekend. Also the box currently appears on the "new topic" page too (under the header bar) so I need to remove that --Errant (chat!) 20:55, 13 May 2011 (UTC)

Errant, is it permissible to remove the following code from User:ErrantX/defaultsummaries.js: 

// Prefix the edit summary with "SW" or "CP"
// depending on whether it's a SourceWatch or Congresspedia page.
// To determine this, look for a link to "Template:Congresspedia"
// on the edit page.
function editsummAddSubProjectPrefix()
{
    // Using the document.links array and the href prop seems to give
    // the best cross-browser results.
    var allAnchors = document.links;
    if (allAnchors)
    {
        var prefix = "SW: ";
        for (i = 0; i < allAnchors.length; i++)
        {
             var anchorHref = allAnchors[i].href;
             if (anchorHref)
             {
                 if (anchorHref.indexOf('Template:Congresspedia') != -1)
                 {
                    prefix = "CP: ";
                 }
             }
        }
 
        document.forms.editform.wpSummary.value =
            prefix + document.forms.editform.wpSummary.value;
    }
}

It doesn’t seem to apply. I also figure that that routine will never be triggered. So, removing it will mean having to page-load less. What do you think? (Sorry if I used any of those words incorrectly.) Thanks! — SpikeToronto 04:46, 14 May 2011 (UTC)

Removed. And categories support added. I cut the current list of things down a lot for the demo - but we can discuss the exact ones to include. --Errant (chat!) 12:37, 14 May 2011 (UTC)

Global article editnotice

Template:Editnotices/Namespace/Main is currently used to display {{TFA-editnotice}} on Today's Featured Article, as an extra feature to welcome new editors. The thought occurs that we could, to help welcome new editors, use a similar "welcome new editors" editnotice on every article, if it was combined with a Gadget (available in Preferences) to enable registered users to disable it (with a little note or link in the editnotice itself on how to do that). To the best of my knowledge we've never tried anything remotely like this, and it could make a big impact in terms of pointing editors at things like the sandbox, tutorial, newcomers help page, etc. etc. (without going crazy - it should remain brief - 1 or max 2 lines). Thoughts? Rd232 talk 02:49, 10 May 2011 (UTC)

If there's a non-gadget way we can show it just to new users/IP users, or even a javascript way so it's dismissable, that would be good, I think. /ƒETCHCOMMS/ 02:14, 11 May 2011 (UTC)

How about something like this: {{Welcome editnotice}}? We'll soon be able to auto-hide it for autoconfirmed users, and I suppose we can wait til then to implement it. Any thoughts? Rd232 talk 01:09, 15 May 2011 (UTC)

Add ipblock-exempt to Bots

Resolved
 – Bugzilla completed. —mc10 (t/c) 04:55, 16 May 2011 (UTC)

I propose that the ipblock-exempt userright be bundled into the Bot usergroup. More often than not, autoblocks or hardblocks tend to disrupt many active bots out there in the case that should happen. Moreover, we know to block any bot that goes haywire and that Bureaucrats keep tabs on those accounts who are flagged as Bots. Finally, most of our active bots already have IP block exemptions, so I think it would make sense to simply bundle the userright into the group instead of having to request it from a sysop. Thoughts? –MuZemike 00:54, 6 May 2011 (UTC)

Agreed. IP range blocks may unintentially block bots creating headaches to the bot master in trying to figuring out what is wrong. --Tyw7  (☎ Contact me! • Contributions)
Seems sensible. Any reason it might not be a good idea? Rd232 talk 01:30, 6 May 2011 (UTC)
Agreed. Seems very reasonable, and it would make things uniform rather than haphazard. ···日本穣? · 投稿 · Talk to Nihonjoe · Join WikiProject Japan! 06:20, 6 May 2011 (UTC)
Support. Ruslik_Zero 06:39, 6 May 2011 (UTC)

An unfortunate measure

Per the recent events at Brink (video game), and the fact that this happens just about every time a video game comes out, I propose that as a preventive measure, that the articles for all video games are given semi-protection for six hours prior to and 72 hours after those games are made avalable for sale to the public. Quite frankly, while there are good IP edits to those articles within the timeframe, brand new games are a target of persistant vandalism from multiple, unconnected vandals just about every time. I don't tkink this will be popular, but it will save us future headaches. Sven Manguard Wha? 08:57, 11 May 2011 (UTC)

Special events, whether in the real world or here on Wikipedia (such as being Today's Featured Article), are one of the main things that bring new users to both read and edit. It's the lifeblood of the project. I think putting up with a temporary spate of vandalism is the price we pay to attract new people. Ntsimp (talk) 14:50, 11 May 2011 (UTC)
Sometimes, it doesn't happen that way. However, I do agree with your observations. Even the mere hinting of a new video game or sequel is enough for the fanboys to go OMG OMG OMG OMG OMG gotts to create a wikipedia article on this OMG OMG OMG OMG OMG OMG!!!!!! That is happening right now with the imminent development and release of the next Call of Duty game. –MuZemike 15:07, 11 May 2011 (UTC)
Someone made a similar suggestion for films at Wikipedia talk:Requests for page protection#Semi-protection for newly released films. I will make no comment on whether either is a good or bad idea per se. However, I think games could also be used as a way to test WP:Pending changes, but I wouldn't suggest that yet... people are still dealing with the effects of the last RfC.
Yaris678 (talk) 15:57, 11 May 2011 (UTC)
A wiki which is an encyclopedia does remain a wiki and the desire to create an article based on rumor or conjecture and/or inserting content based on same should be treated like any other content and held to the same standard. I do not think that we should treat excitement about a topic resulting in reflexive editing activity in the same way we treat vandalism, which is — in some ways — what proposals of this kind do. I think it is a very good thing for people who are aware of a popular topic to bring attention to the community at large that topic X may soon be impacted by a huge increase in editing activity. In this area there is something of a gap in the task management of mop-holders. Some communication mechanism which provides a "tsunami warning" would be useful. --User:Ceyockey (talk to me) 00:41, 12 May 2011 (UTC)

What about creating a custom editnotice modelled on {{TFA-editnotice}}? If you have an editnotice template available (maybe one for games, one for films), you can slot that in as needed, with an appropriate expiry time. (Also, on a somewhat related note, can I point out the "global editnotice" thread a couple of threads up?) Rd232 talk 02:43, 12 May 2011 (UTC)

A custom editnotice! That's a great idea! Let's do it! Yaris678 (talk) 13:43, 12 May 2011 (UTC)
I could get behind the edit notice. Sven Manguard Wha? 18:31, 12 May 2011 (UTC)
Well if someone familiar with the situation could draft some appropriate text, I'm sure someone can be found to turn it into a working template. This idea shouldn't be difficult or controversial, and it could be quite effective. Rd232 talk 03:20, 13 May 2011 (UTC)
Cool. I would suggest that it could be the same as {{TFA-editnotice}}, apart from it wouldn't need {{PAGENAME}} is [[Wikipedia:Today's featured article|Today's featured article]].<br>
Yaris678 (talk) 09:22, 13 May 2011 (UTC)
Well here's a first draft: {{New release editnotice}}. Rd232 talk 00:32, 14 May 2011 (UTC)
That looks good to me. What do you reckon we should do next? Make a new proposal on this page? Start an RfC at Template talk:New release editnotice? Just mention it at WP:AN? After all, only admins can apply the notice to articles. Yaris678 (talk) 17:53, 15 May 2011 (UTC)
Make a new proposal, possibly. After that, it needs promoting eg at appropriate WikiProjects so that people can request it as needed (an edit request on the talk page of the article requesting an editnotice would get an admin's attention - {{Edit protected}}). Rd232 talk 22:48, 15 May 2011 (UTC)
Good point. I have just started a new thread at the bottom of this page and left a message on the film and videogame WikiProject talk pages. Yaris678 (talk) 23:16, 15 May 2011 (UTC)
Things appear to be pretty calm and civil over at Assassin's Creed: Revelations so far though. There was initial disagreement over the name of the city, but other than that, smooth sailing. Mostly because AC is awesome ofc. However in some games that aren't recieved well like Homefront, and Dragon Age II (especially DAII), vandalism does become a huge problem when fans rage at EA or whoever they feel is responsible for "destroying the game" etc before and after release. I agree with your idea of pre and post release semi-protection to curtail "OMFG YOU SELLOUTS RUINED EVERYTHING! DIE IN A FIRE!" and such things. Heck, even AC:R will probably disappoint some people or you'll have dudes who feel obligated to post some inane message about themselves or their girlfriend in the lede. Sir William Matthew Flinders Petrie | Say Shalom! 23:25, 15 May 2011 (UTC)

HLT Bot?

I have another idea for this. We could have a bot look at the release date infobox fields of all books, movies, and games and assemle a list of items that are set to be released within 48 hours or have been released within the past 72 hours. This would become a resource for vandalism fighters, a kind of 'high likelihood target' for them to watch. Anyone behind this kind of idea? Sven Manguard Wha? 18:31, 12 May 2011 (UTC)

  • Sounds interesting. If you can write an information gathering bot which would post links to items conforming to the parameters, that would at first provide raw material for observing what happens to the articles. I'd advocate not using the resource to guide editing at first, but observe for a while. Editing using the information as a guide will impact the lifecycle of the articles listed and would obscure what "normally" happens. --User:Ceyockey (talk to me) 00:31, 13 May 2011 (UTC)

Uncapitalize user's login bar

In Vector, the user's login bar looks like this:

McUser      My talk      My preferences      My watchlist      My contributions      Log out

I think it once looked like this in Monobook too but it was changed to look like this:

McUser      my talk      my preferences      my watchlist      my contributions      log out

This style then stayed for years. During the "upgrade" to Vector it went back to being capitals. I remember minor griping about it and figured it would eventually revert but it never did. In fact, the menu bar is inconsistent across the Foundation's various projects depending on if they use Monobook or Vector. Monobook and Vector have no reason to disagree about about the capitalization in the login bar. I put forward that it is much less distracting when lowercase is used. I propose it is changed in Vector. Jason Quinn (talk) 00:01, 12 May 2011 (UTC)

Vector != Monobook. All links outside the content area are capitalized. Changing it for all Wiki's requires a bug report, that needs approval from the devs, and then it may take months before being implemented. Changing it only here needs consensus from the community, but I haven't seen anyone complain before, so that may not happen soon. — Edokter (talk) — 00:24, 12 May 2011 (UTC)
You can probably change it in your CSS using text-transform:lowercase. ---— Gadget850 (Ed) talk 01:15, 12 May 2011 (UTC)
I didn't understand your "Vector [does not equal] Monobook" comment. What was your point with that? Jason Quinn (talk) 15:08, 12 May 2011 (UTC)
My point is that Vector is not meant to look like Monobook. Each skin has it's own merits. Modern for example uses all-caps for it's user links. — Edokter (talk) — 16:37, 12 May 2011 (UTC)
There are no Wikimedia wikis that use monobook, afaik. How could there be inconsistency? --Yair rand (talk) 02:40, 12 May 2011 (UTC)
My comment about this may have been based on a bug. I only recently switched to Vector. I was using still using Monobook. When I visited more obscure wikis, I saw a mixture of Vector and Monobook being used. Sometimes I'd get Vector, sometimes Monobook. I assumed that many wikis hadn't adopted Vector yet. I just checked and they all now seem to use Vector. I don't know what exactly is going on. Jason Quinn (talk) 15:08, 12 May 2011 (UTC)
Per them, Monobook is a personal option, so there is no need to do this. Ajraddatz (Talk) 03:29, 12 May 2011 (UTC)
This is not a good reply. It ignores the possibility that all the themes are better with the login bar uncapitalized. It true, Vector would better if it incorporated the change. The fact that Monobook still uses lowercase is irrelevant. Short myopic quips like this are really frustrating at the Village Pump because they clearly show no attempt was made to understand a person's suggestion. Jason Quinn (talk) 15:08, 12 May 2011 (UTC)
No, what isn't a good reply is to spend five hours reading into and debating what is obviously a simple, and needless proposal. This is a personal option - and as such, there is absolutely no need to change an inconsequential aesthetic component of the vector skin to accommodate..... nobody! Those that like to use monobook will continue to do so, and those that like vector will likewise use vector, so what is even the issue here that is trying to be fixed? Ajraddatz (Talk) 22:11, 12 May 2011 (UTC)
You know it is needless how? You don't. You are just pulling that out of thin air. Suppose that a usability study were done and 55% of users preferred lowercase. For almost nothing in effort this change of a "mere" 5% translates into a slightly better experience for millions of users. You and others here are arguing a position which is tantamount to dismissing the entire field of UI design. It is not a matter of "personal preference" because we are talking about the default skin. The default skin should be as "good" as possible. "Good" can be quantified. Suppose it were true that lowercase is slightly preferred? This irrational dismissive attitude that says "let's not worry about small changes" would never discover this. Jason Quinn (talk) 12:55, 13 May 2011 (UTC)
I'd actually argue that 99% of users couldn't care less, and I'm sure that a usability survey would likewise agree. Beyond that, if you feel the need to continue here, fine. I'm not going to, though. Ajraddatz (Talk) 01:41, 14 May 2011 (UTC)

What's wrong with having different capitalization among different skins? I like Vector, and I like the capitalized links. If you don't, then don't use Vector. /ƒETCHCOMMS/ 15:12, 12 May 2011 (UTC)

Nothing. Different skins can use different capitalization. If, however, you care about user experience, the default skin's choice should be the better of the two choices if one can be justified over the other. (Isn't this obvious?) My personal experience is that the capitalized version draws the user's attention too strongly in such a way as to be unpleasing and slightly distracting. I highly suspect that if a usability study were done, that people would prefer the non-capitalized version. I reiterate that I seem to remember some people did complain about the change in some of the discussion prior and during the change to Vector. I recall nobody however discussing reasons why capitals should be used or anybody expressing a preference for them before Vector became the default. My statement that lowercase is better is a testable claim. Personally, I think the outcome is predictable and not worth the effort of a usability study (no study was done to decide on the present choice) but would be willing to abandon my hypothesis if the results of a study proved otherwise. Is this a "major" issue? No. The difference is very slight. I suspect that lowercase letters are ever-so-slightly perceptibly better so this change would not merely be lateral. When a website has hundreds of millions of users, even a small improvement has a positive impact on success. Jason Quinn (talk) 15:47, 12 May 2011 (UTC)
I presume the caps are deliberate to be able to seperate the links, as they are too close together. In fact, for that reason, I submitted a bugreport that would add a small devider between the links, and makes the user link appear more as part of the Vector skin; it is more consistent with the styling of the other link outside the content area (the portal area on the left side). — Edokter (talk) — 16:37, 12 May 2011 (UTC)
I think this proposal may also be a good one, especially in conjunction with mine ;-). I'd like to point out that every objection raised here by other editors could also be applied to this bug report: "It's too inconsequential to worry about", "you can change this via CSS", "it's only a matter of personal preference so nothing should be done". This sort of poco curante attitude is not the one that built Wikipedia or a company like Google. Improving everything, including the small things, is what leads to greatness. Jason Quinn (talk) 13:07, 13 May 2011 (UTC)

What Fetchcomms said. I'd recommend trying Gadget850's advice. There does not seem to be a consensus of people that want this change, and Wikipedia isn't going to change a feature for everyone to meet the personal desires of one user. Even Jimbo doesn't have that kind of pull anymore. Sven Manguard Wha? 18:23, 12 May 2011 (UTC)

I'll reply to each of your statements in turn: A) What Fetchcomms said. I'd recommend trying Gadget850's advice. Their comments were that I should change it for me, which miss my point completely. I have clarified my position several times and so it should be clear by now. I'm not arguing that this is just a change to suit me. I already knew how to change it for me. I'm arguing that it's a change that will suit the average user. I can't help but feel that this is a point that should be obvious. The user interface should be designed to maximize usability for the average user. Is this such a novel and obscure concept? B) There does not seem to be a consensus of people that want this change And you are basing this on what? I just printed out two versions of an article. I edited the one to be lowercase. I just asked the person next office to me what version of the bar they liked more if they had to choose. They liked the lowercase one better. I just OFFICIALLY have the only scientific unbiased metric of this and "lowercase is better" is the conclusion. C) ...and Wikipedia isn't going to change a feature for everyone to meet the personal desires of one user. Sigh... D) Even Jimbo dosen't have that kind of pull anymore. Irrelevant. Jason Quinn (talk) 12:37, 13 May 2011 (UTC)

I knew nothing about CSS before I started editing here. I learned because I wanted page elements to look right and I wanted to personalize my viewing and editing experience. I'm not an expert, but I know how to poke those who are. This should resolve your issue, just add it to Special:MyPage/skin.css. —Preceding unsigned comment added by Gadget850 (talk • contribs) 

/* Transform personal tools to lowercase */
#pt-mytalk,
#pt-preferences,
#pt-watchlist,
#pt-mycontris,
#pt-logout {
    text-transform:lowercase;
}

Jason, I don't know why you're arguing right now. If you want this to be changed for everyone, you need to a) get consensus and b) file a bug. Until then, please either fix it for yourself or forget about it. /ƒETCHCOMMS/ 22:00, 13 May 2011 (UTC)

Eventually I will file a bug report. There's no rush. I have now polled 3 people about this. The current vote is 2-1 in favor of lowercase. The one vote pro-uppercase may have been because of a language-based preference (apparently capitals would be more appropriate in German. That is an interesting aspect of the question. As per another comment above, I agree the bulk of people don't care. Luckily such indifference is mathematically accountable. Jason Quinn (talk) 19:19, 15 May 2011 (UTC)
Put me on your list as (1) not caring whether the links are capitalized or not, and (2) caring very much about wasting even 60 seconds of the devs' limited time on something so trivial. I can think of a dozen "simple" things I'd rather have changed in the highly unlikely event that they had enough free time to worry about trivia like this. WhatamIdoing (talk) 05:43, 16 May 2011 (UTC)

Wikipedia talk:Articles for deletion#Request for Discussion concerning the future of AfD

I would appreciate your thoughts. - jc37 23:19, 14 May 2011 (UTC)

Unexpectedly, this proposal is not the perennial "Can't we switch to a vague name like Articles for discussion?" The proposal is to have AFD discussions appear on the nominated article's talk page in some form (possibly by transcluding the standard AFD page). WhatamIdoing (talk) 05:50, 16 May 2011 (UTC)

Possible solution for the attribution problem with category renames?

Feel free to join the discussion at Wikipedia talk:Categories for discussion#Possible solution for the attribution problem with category renames?, where I brought up a possible solution to the problem. עוד מישהו Od Mishehu 10:04, 15 May 2011 (UTC)

Citation templates— anchors

Originally misplaced at Wikipedia:Village pump (policy)#Citation templates— anchors

I have been working on User:Gadget850/Citation templates— anchors. Should this be moved into Wikipedia space somewhere so it can be used and updated? ---— Gadget850 (Ed) talk 23:52, 13 May 2011 (UTC)

I would suggest moving it to Wikipedia:Citation templates and reference anchors, categorizing it to Category:Citation templates and add a note about the existence of the new page at Wikipedia talk:Citation templates. --User:Ceyockey (talk to me) 03:40, 15 May 2011 (UTC)
Seconded. Rd232 talk 02:41, 17 May 2011 (UTC)

Heads up

Due to past restrictions I need to post here to get approval for this task. Ive made over 2,000 edits cleaning up a mess, with renamed files. Normally people would use WP:NOTBROKEN to dismiss my edits, however, that really does not apply to file redirects. Due to the complexity of how mediawiki stores file links, it makes it very difficult to run reports on files, especially the usage of non-free content. One of the largest issues that I have uncovered and have had resolved was the mass over usage of File:Ltte emblem.jpg which was used on 50 different pages in violation of our non-free content policy. This issue had remained hidden due to the fact that File:Tamil-tigers-flag.svg, (a redirect) was the name of the actual file being used. Cleanup up the file names makes it easier to track NFC usage, unused NFC, and makes wiki code cleaner by using the correct file names. My plan is to go ahead and correct all of the related uses of file redirects in order to make monitoring our files and related issues easier on all of the people involved in the related processes. ΔT The only constant 05:54, 14 May 2011 (UTC)

Will this 'redirect' fixing be done manually or via a an approved bot ? Sfan00 IMG (talk) 13:03, 14 May 2011 (UTC)
Manually, Ive run into a few weird cases where a bot would screw up, and thus do not think it would be appropriate for one. ΔT The only constant 13:04, 14 May 2011 (UTC)
Seems to be a good idea, for tracking purposes more than anything. If I understand correctly, file usage of redirects doesn't appear as a usage of the actual image, so in essence, the redirect is kinda broken. Ideally, this would be fixed at a MediaWiki level, but until that is fixed, this seems to be the best option. [stwalkerster|talk] 13:10, 14 May 2011 (UTC)
The 'What links here' for the image does give where it appears as a redirect. what is the actual problem with the redirects thanks? Dmcq (talk) 15:55, 14 May 2011 (UTC)
Its an issue with file links, and the in-ability to easily combine the usages of the two files together. Unlike page redirects, files have an additional category of telling you where they are being used. With file redirects you need to check both the file and its redirect for usage, which doubles the work load, and makes running database reports for different issues very complex. Until the software is changed (if ever) this is the best solution to making working with files feasible. ΔT The only constant 16:00, 14 May 2011 (UTC)
So it is a question of making database queries simpler even thout 'what links here' already gives everything required. In the case of this file I agree because the redirect was for the same thing, however I only agree with the idea of generally always replacing redirects with direct link in the case where the topic isn't changed. Sometimes the topic is different and could be made into a separate article but people have just pointed at another topic for the moment which will get an enquirer further along their path. Dmcq (talk) 17:19, 14 May 2011 (UTC)
"What links here" isnt the issue, its the "what pages are using this file" that breaks with redirects. With file redirects its a matter of checking file usage, what links here for redirects, and then querying the redirects for their usage, for every non-free file to determine if in fact the image is orphaned. If we cut out the file redirects from the equation the work is cut to a third of what it would be. In doing that it also makes managing the usage of non-free content easier due to not having to run multiple checks for each file, and making the lives of NFC monitors easier. It also has the potential to provide access to files that are on commons but are being overridden by local files of the same name. (Ive discovered several interesting files that way) ΔT The only constant 02:32, 15 May 2011 (UTC)

Seems a good idea. Rd232 talk 03:49, 15 May 2011 (UTC)

This has been a lot of good work. File redirects are a pain when you need to figure out where images are used. There have been a few bots ignoring redirects and tagging images as unused. ---— Gadget850 (Ed) talk 14:34, 16 May 2011 (UTC)

Proposal for content protection bots

A discussion that started on the policy board at Wikipedia:Village_pump_(policy)#A_new_idea may actually be more relevant here, so I am just putting a link here. The idea is a proposal for a larger-scale bot for anti-vandalism and content protection in general. I think it will be needed in the next 2-3 years. . Comments will be appreciated. History2007 (talk) 15:14, 16 May 2011 (UTC)

  • I'm really not sure what you are proposing, what exactly would this new bot do that existing ones don't already do, or how would it do them better? Monty845 17:32, 16 May 2011 (UTC)
  • The current bots catch N-percent of vandalisms. I do not even have a number what N is. Are some of them good - yes, for a single person effort they are. Can they be improved? Certainly. Are they perfect? Far from it. Do they miss various items? Absolutely. As is they are good starting efforts. This happens all the time in software: various single-person items appear, but eventually team-based, more comprehensive pieces of software offer more advanced solutions. Remember brief? It was a nice little early editor, but we have come a long way since then. I see the current bots at that level, nice early systems - but a long way ahead of us. So 5-7 programmers will probably do a good job building an "industrial grade" bot that catches many items that current bots miss. At the moment there is not even a central design, and all bots are adhoc. So there is plenty of room for improvement with suitable resources. History2007 (talk) 19:50, 16 May 2011 (UTC)

New release editnotice

What do people think of the {{New release editnotice}}? It could be used for computer games and films immediately before and after their release. These articles get a lot of attention and we may be able to head off unconstructive edits as is done with the WP:Editnotice for the featured article on the main page.

Yaris678 (talk) 23:09, 15 May 2011 (UTC)

It looks ok but its too "staring" or "bold". --Tyw7  (☎ Contact me! • Contributions) 23:12, 15 May 2011 (UTC)
Be bold! Change it to what you think would be better. It's just a first draft. Yaris678 (talk) 23:20, 15 May 2011 (UTC)
(edit conflict) It does look too bold, especially the "Yes, you really are editing Wikipedia right now!". I don't know if that is necessary. I'm sure they know as they hit the edit button that they are editing the article. :P Something like this is a good idea, and maybe it will help some with IP edits during new releases. —Mike Allen 23:26, 15 May 2011 (UTC)
How's that? --Tyw7  (☎ Contact me! • Contributions) 23:31, 15 May 2011 (UTC)
"I'm sure they know as they hit the edit button that they are editing the article." - not necessarily. A substantial proportion of newcomers, even in 2011, don't really entirely believe that they can actually edit articles. Rd232 talk 00:02, 16 May 2011 (UTC)
@Tyw7, how's what? @Rd232, so after they hit edit and is in the edit field, they don't believe they are editing Wikipedia? —Mike Allen 00:14, 16 May 2011 (UTC)
You get some people thinking they're not supposed to (like Wikipedia's security is bad, or they shouldn't because they're not qualified). You get a lot of disbelief that "anyone can edit" really means "if I press save right now it will be live on Wikipedia". Upping the very low percentage of people who get it is worthwhile, and I think it might. Rd232 talk 01:25, 16 May 2011 (UTC)

I was under the misapprehension that the proposal being discussed up the page was to provide a method for alerting Wikipedia editors about the potential for high-traffic / high-editing at particular articles based on events in the real world, not revision of the edit notice for editors once they start editing. --User:Ceyockey (talk to me) 23:41, 15 May 2011 (UTC)

The thing about HLTbot was about bringing things to people's attention. The suggestion by Rd232 was for an edit notice. Yaris678 (talk) 23:48, 15 May 2011 (UTC)

BTW, the version before Tyw7#p started editing it was based on {{TFA-editnotice}}, which is what appears at the top of the screen when you edit the day's featured article. Yaris678 (talk) 23:44, 15 May 2011 (UTC)

And btw my username is just User:Tyw7 without the #p. The #p is used for skipping to the relevent section ie skip the top. --Tyw7  (☎ Contact me! • Contributions) 23:49, 15 May 2011 (UTC)
The issue was dealing with some specific situations where high traffic comes from newcomers to some kinds of article. A temporary editnotice (for maybe a week around the projected release date) is one option. Rd232 talk 00:02, 16 May 2011 (UTC)
How's my edit? --Tyw7  (☎ Contact me! • Contributions) 00:04, 16 May 2011 (UTC)
Well, 1. I wouldn't use REVISIONUSER since it will address anonymous users with their IP address, which is probably confusing. 2. More specific is better, but the template was intended to cover a range of new releases, including films, so wording should take that into account, or the template split into more specific subtemplates. 3. It now seems longer and harder to skim, and mentioning ref format is surely too much (though a link to WP:CITE or perhaps Wikipedia:Tutorial/Citing_sources would be OK. Rd232 talk 00:12, 16 May 2011 (UTC)
Why don't you modify the template and perhaps we can compare revisions --Tyw7  (☎ Contact me! • Contributions) 00:25, 16 May 2011 (UTC)
I was fine with the original version as I left it. TBH I'd rather go back to that and see if others have comments. Rd232 talk 01:26, 16 May 2011 (UTC)

If we want to test this on a live article I know a good place to put it. --Ron Ritzman (talk) 01:46, 16 May 2011 (UTC)

I have reverted the template to an earlier version. However, I have added something on the importance of citing sources, which Tyw7 did mention in his version. I think it is especially important for this type of article, where a lot of newbie editors will want to add a lot of information. I have tried to make the reference to citing sources as light-touch as possible. If we make it sound really onerous we will put people off. Yaris678 (talk) 12:28, 16 May 2011 (UTC)


Discussion is now continuing at Template talk:New release editnotice. Yaris678 (talk) 13:48, 18 May 2011 (UTC)

Suggestion in regards to file moving

Given the discussion in the #Heads up section, I think we should have a bot that would replace file redirects with a direct link to that file (and if possible, delete the file redirect once done), of course the bot would do this for every namespace, since this problem doesn't affect just the article namespace. If the bot were to be made people wouldn't have to cleanup their own mess and everything will be kept smooth and running efficiently. Thoughts? —James (Talk • Contribs) • 5:52pm • 07:52, 16 May 2011 (UTC)

No. A lot of redirects are on purpose. I want the Girl Scouts of America to redirect to Girl Scouts of the USA, so that when folks search for Girl Scouts of America, they get properly redirected instead of creating a new article. Similarly, Girl Guides of America redirects as an historical name. ---— Gadget850 (Ed) talk 14:31, 16 May 2011 (UTC)
I believe James is talking about files, not articles. 28bytes (talk) 14:34, 16 May 2011 (UTC)
Right. I can't read today. ---— Gadget850 (Ed) talk 00:59, 17 May 2011 (UTC)
Given the complexity of wiki syntax doing this via bot has too high of an error rate. Ive ran across a few cases where I have to take two or three looks to figure out the code. However Im doing the work myself, and this should resolve itself. ΔT The only constant 01:02, 17 May 2011 (UTC)
Oh ok, thanks Delta! —James (Talk • Contribs) • 6:32pm • 08:32, 18 May 2011 (UTC)

Create a new CSD - G:13 Unsalvageable WP:NOT Violations

Moved to Wikipedia talk:Criteria for speedy deletion/Archive 42#Create_a_new_CSD_-_G:13_Unsalvageable_WP:NOT_Violations

Let 'em like 'em

I just checked out the new article on the Georgia Peace Bridge (The Bridge of Peace (Georgia)) and I wished there was a button to click to "like" it like on Facebook. This might seem kind of corny but it also might help highlight outstanding articles if readers were given a way to do this. What do you think? Steve Dufour (talk) 00:16, 14 May 2011 (UTC)

Absolutely not. Wikipedia already has assessment scales for articles; they're based on quality, not on what topic happens to be flavor-of-the-month. This isn't Twitter. – iridescent 00:18, 14 May 2011 (UTC)
I wasn't suggesting replacing the official article assessment process. Steve Dufour (talk) 00:21, 14 May 2011 (UTC)
If I understand correctly, you were suggesting something more along the lines of being able to insert Wikipedia articles into your FB newsfeed by 'liking' them? It's not a terrible idea in concept, but I can see all sorts of godawful nonsense arising from it, especially given FB's nomenclature of 'like.' I think that's what iridescent was getting at. → ROUX ₪ 00:30, 14 May 2011 (UTC)
You can already post the link to a WP article on Facebook. I do it myself sometimes. What I was suggesting is have a popularity vote on articles, and maybe featuring the most popular of the day on the main page. I know it's different from what WP usually does but it might give a way for readers (non-editors) to do something, as well as being fun. Steve Dufour (talk) 01:40, 14 May 2011 (UTC)
Yeah, a popularity contest is exactly what Wikipedia doesn't need. A 'share' button would be great; a 'like' button not so much. → ROUX ₪ 02:14, 14 May 2011 (UTC)

This has been proposed before. I think the idea closest to getting consensus was having a default-off "share" gadget. But I don't think that's been created yet. /ƒETCHCOMMS/ 03:11, 14 May 2011 (UTC)

Sharebox is a script that reorders your toolbox. It adds new buttons that make it easier to mail, print or share an article on Facebook or another linksharing service. You must have an account to add Sharebox to the sidebar. See User:TheDJ/Sharebox for more information. ---— Gadget850 (Ed) talk 11:29, 14 May 2011 (UTC)

See also this thread on Foundation-l (containing examples from other projects, such as n:template:Social bookmarks). For the Signpost stories, we introduced a very inobtrusive version of such a link block a while ago, see here.
Last month, the Commons Picture of the Year vote used a very conspicuous (overlay) version, which generated some controversy.
Regards, HaeB (talk) 12:02, 14 May 2011 (UTC)

I am not quite as negative about the notion of registering popularity of an article as some folks. However, I think a better solution would be to improve the traffic analysis. As far as I know, the only "in house" solution for this is via the resource which reports views via a link such as http://stats.grok.se/en/latest/Wikipedia:Village_pump_(proposals), which homepage is located at http://stats.grok.se/ . As noted on the homepage "This is very much a beta service and may disappear or change at any time." --User:Ceyockey (talk to me) 03:29, 15 May 2011 (UTC)

My own humble response to this is that (to the original proposal) is that to say that one "likes" an article is rather too subjective and vague an evaluation and response to be encyclopaedic. A better, more objective and more analytic way of rating articles would be needed here, such as that which surrounds whether articles become featured articles - they must be well-written, comprehensive and factually accurate. Rather than simply have people put in the rather vague premise that they "like" an article, would it not be better to give Wikipedians a number of criteria on which they can rate an article, such as how up-to-date it is, how wide a range of the subject it covers, whether it is factually accurate and how good the English is in the article? ACEOREVIVED (talk) 18:50, 18 May 2011 (UTC)

You mean, like we already do? – iridescent 19:47, 19 May 2011 (UTC)


Thank you for that - I had not seen the Article Feedback Dashboard before now! ACEOREVIVED (talk) 19:59, 19 May 2011 (UTC)

It's only active on around 100,000 of our 6,906,382 articles at the moment; I have no idea how those 100,000 were chosen. – iridescent 21:21, 19 May 2011 (UTC)

Making ANI and other discussion pages like a forum so as not to cause edit conflicts

Edit conflicts add to the tension at ANI as the defendant try to make their voice heard. I propose a forum like system where all edits would not result in edit conflicts (and easier to follow). --Tyw7  (☎ Contact me! • Contributions) 12:40, 15 May 2011 (UTC)

How do you suggest we do that, then? ╟─TreasuryTag►First Secretary of State─╢ 14:31, 15 May 2011 (UTC)
(edit conflict)Isn't LiquidThreads already in the pipeline? [stwalkerster|talk] 14:32, 15 May 2011 (UTC)
It's in the pipeline and I really hope it will stay there. In my experience it's immensely complicated and counterintuitive. Worst of bold words. Hans Adler 14:45, 15 May 2011 (UTC)
Agree with Hans Adler. LiquidThreads is not the solution. —GFOLEY FOUR— 17:27, 15 May 2011 (UTC)
Is there a page for me to "try out" the pipelines? --Tyw7  (☎ Contact me! • Contributions) 17:37, 15 May 2011 (UTC)
The Village Pump of Strategywiki uses, it, if you want to see it in action. I for one concur entirely with Hans Adler above, and will go so far as to say that the moment it goes live on en-wiki will be the moment I deactivate my account, since it preserves all the worst of both MediaWiki and chat forums for no apparent advantage. – iridescent 17:47, 15 May 2011 (UTC)
In my opinion the main problem is that it destroys all sense of location. On Strategywiki I have no idea where the discussions are located, how they are related to each other, or even which pages (or discussions? does one watch discussions separately?) I am watching. A normal forum, parallel to the wiki, allowing us to use MediaWiki code – that would be acceptable and might even be an improvement. But Liquid Threads appears to be an over-engineered design-by-committee result. Hans Adler 17:59, 15 May 2011 (UTC)
(Hm, I suspect no one who has commented above about how LQT is bad has actually had real experience using LQT...) Discussions are "watched" when you participate in them or click the watch button, though you can technically still watch the entire page. New posts don't show up on the watchlist, the show up on the "New messages" page, highlighted until they've been marked as read. The number of unread posts shows up next to the "New messages" link in the bar on the top right. This is at least how it works in the current design; LQT seems to be getting a complete redesign: see mw:Extension:LiquidThreads/Redesign. IMO, LQT is clearly the perfect solution. --Yair rand (talk) 18:51, 15 May 2011 (UTC)
I suspect that you didn't read the post to which you responded. One year ago I took part in some discussions on Strategy wiki and it was absolutely painful because of LQT. This is why I know it's totally broken. It takes little bits and pieces from discussion pages and moves them around, making it very hard to remember what is where. Once I had marked a thread as read on the new messages page, I found it practically impossible to find it again because I didn't remember the name of the corresponding page. And although I was automatically watching the threads where I commented, I wasn't even notified of new threads about the same page. Totally ridiculous. Hans Adler 19:45, 15 May 2011 (UTC)
If you wanted to be notified of new threads on the same page, why didn't you watch the page? (And a couple of posts on strategywiki apparently aren't nearly enough to get a decent understanding of LQT...) Discussion of the current version of LQT is not a particularly productive use of time, given that the current version isn't going to be used on ENWP, and the only people who will really have much use of it are Wiktionarians, Wikinewsies, and those who work on Mediawiki. LQT, in whatever form it takes once it's finished, is almost certainly going to be implemented around Wikimedia, so this discussion doesn't really make a lot of sense. --Yair rand (talk) 20:14, 15 May 2011 (UTC)
On a side note, I actually like the liquid thread system and endorese it! Is there any way of testing ECs with the liquid thread system? --Tyw7  (☎ Contact me! • Contributions) 19:06, 15 May 2011 (UTC)

We could just make more intelligent use of subheaders. Rklawton (talk) 18:01, 15 May 2011 (UTC)

(ec) I think a much better solution would be to fix the handling of edit conflicts. One shouldn't be presented two versions of the full ANI page just because while one commented in a little section in the middle someone else did the same. Even an almost empty page saying: "Sorry, there was an edit conflict, please use your browser's back button, copy your contribution, go further back and click 'edit' again" would be more helpful than these monster forms. Hans Adler 18:05, 15 May 2011 (UTC)

Or a forum system/some sort of system whereby BOTH edits get through WITHOUT edit conflicts. --Tyw7  (☎ Contact me! • Contributions) 18:57, 15 May 2011 (UTC)

In the meantime (while the devs try to find a solution that is satisfactory to everyone), I personally use an "intentation threading" function which is currently being used on the French Wikipedia (for example on how it's used, see fr:Discussion Wikipédia:Accueil principal), where indented comments are given separate, alternating colors, which at least makes following discussions and threads easier. It's all located in in all the "dl"s and "dt"s in my common.css if anyone wants to look at it or check it out. –MuZemike 03:41, 16 May 2011 (UTC)

There is an improved version of that CSS at User:Gadget850/talkhighlight.css. ---— Gadget850 (Ed) talk 03:23, 17 May 2011 (UTC)


I agree with the original proposal - it can be so irritating to receive the message "Another Wikipedian has started to edit this page since you began to edit, resulting in the possibility of edit wars". My own guess - although, at preseent, it is mere conjecture - is that most of the time, when this happens, there are no edit conflicts or edit wars. However, beyond scrapping the tag, I was not really sure what to do about this. I just wanted to say that I think it is good that this issue has been raised. ACEOREVIVED (talk) 09:27, 19 May 2011 (UTC)

Editnotice for the Main namespace

Proposal: that the editnotice for the Main namespace (Template:Editnotices/Namespace/Main) have a "welcome new users" type editnotice added. This will be fully possible fairly soon, when r82285 goes live. Then MediaWiki:Group-autoconfirmed.css will be available to automatically hide the notice from all autoconfirmed users, using the usual CSS mechanism which editors currently use to hide notices on a per-user basis (see WP:CSSHIDE). In the mean time, we can debate the concept and kick around a draft. I've made {{Welcome editnotice}} to get the ball rolling. Rd232 talk 04:21, 17 May 2011 (UTC)

Don't like it, unless it's specifically only visible to newly-registered accounts and not IPs as well. A surprising number of people dislike logging on except to perform tasks which can only be done when logged in (admin actions, editing protected pages etc, RFA voting…)—if they all get "welcome new user!" messages every time they try to do anything we're likely to get a barrage of complaints. – iridescent 08:17, 17 May 2011 (UTC)
Well it could be tweaked to be a bit less definitively introductory/welcoming, and more about pointers to help. And I suppose in theory we could think about using a cookie-based approach to allow users to dismiss it (like watchlist notices), though that would be a whole other kettle of fish implementation-wise. And showing it only to new accounts not yet auto-confirmed ought to be possible as well (not sure how hard), but would make it a lot less useful. How much of an issue is this really? People should be logging in if they have accounts, and if they don't have accounts, they should be encouraged to register. Rd232 talk 00:47, 18 May 2011 (UTC)
Why should they be encouraged to register? It's not all that useful for most visitors. -Atmoz (talk) 15:18, 18 May 2011 (UTC)
Erm, I think you're missing that we're talking about an editnotice (WP:Editnotice). That addresses editors, not visitors (taking that as meaning "readers"). Rd232 talk 19:14, 18 May 2011 (UTC)
I know what an editnotice is. To me, an editor is someone who spends way too much time on WP... like me or you. A visitor is someone who looks something up, sees something wrong and fixes it. They may have edited, but they have no intention of making it a regular habit, and they shouldn't be pressured into registering an account for no reason. -Atmoz (talk) 22:49, 18 May 2011 (UTC)
Fine, but there is every reason for people to edit with accounts. It's more - pun intended :) - accountable, and it gives them more control over preferences, access to tools, ability to create and move pages, etc - plus, not incidentally, privacy (by not recording their IP - "anonymous" is such a bad name for IP editing). The reason we don't force people to edit with accounts is primarily concern about scaring people off from taking the trouble to register. Gentle nudging to register, on the other hand, ought to be entirely acceptable. Besides which, a constant requirement for Wikipedia to not die is to keep turning new readers into (halfway competent) editors, and creating an account is (while not essential) normally part of that process. Rd232 talk 23:56, 18 May 2011 (UTC)

Your proposal, unless I have misunderstood it, seems to suggest that when a user clicks on the tab or link that says "edit" and the editing interface opens, that user then needs to be told that they are editing a page? Perhaps I have been mislead by your example. I might support something that was more similar to a very compact display of helpful links, but not what you have proposed. It seems like a solution devised for a problem that may be imagined and will likely not be solved in this way. Delicious carbuncle (talk) 19:27, 19 May 2011 (UTC)

The proposal is for an editnotice. Sorry you don't like my draft (the bit you don't seem to like comes from the well-established {{TFA-editnotice}}; the other part is more in the direction of what you suggest) - feel free to do something different. The proposal is not at all tied to my draft; I just find it helps a lot to have something for people to look at, if only to criticise (otherwise there's a certain "can't imagine it" tendency to be non-committal or not say anything). Rd232 talk 01:07, 20 May 2011 (UTC)

New user rights

Superseded by this discussion. All further comments should go there. —James (Talk • Contribs) • 10:22am • 00:22, 21 May 2011 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Given that account creators are no longer able to create or edit editnotices, a new user right should be created to allow users who have the right, but weren't active at ACC to continue to create editnotices. Also a discussion I started last year about creating a new user-right to allow redirect suppression never really got anywhere (it got off-topic and went on about OTHER user rights). —James (Talk • Contribs) • 12:29pm • 02:29, 15 May 2011 (UTC)

Account creators were never supposed to create or edit editnotices - that they could is because of a technical limitation in the way mediawiki impliments blacklisting, and that we've implemented edit notices. Account creators weren't supposed to use the technical ability to edit edit notices, because it was unintentional and never discussed. I'm not convinced edit notices need to be admin only, but de facto bundling it with account creator is not a good solution. Prodego talk 02:32, 15 May 2011 (UTC)

Edit notices shouldn't need editing that often, or be added willy-nilly all over the place, and we have the edit request system. In addition, if there are any editnotices that need editing frequently for some reason, the content can be spun off into a template transcluded by the notice. In short, I'm not sure there's an enormous need here. Rd232 talk 02:46, 15 May 2011 (UTC)

Note this change (when it goes live) will break User:AnomieBOT II's updating of Template:TFA title, unless such a userright is created and is granted to the bot. Anomie⚔ 13:47, 15 May 2011 (UTC)

It isn't a software change, I just created an edit filter to stop it. But AnomieBOT isn't editing an edit notice, so it should be fine anyway. Prodego talk 14:27, 15 May 2011 (UTC)
Oh, I thought we were talking about T24141. Anomie⚔ 20:24, 15 May 2011 (UTC)
Oh yea. I should get them to switch that over. Prodego talk 04:56, 16 May 2011 (UTC)
I agree with what you say, but for recent events edit notices are particularly important and need constant updating, I was going to make a comment about not using WP:LDRs on the Death of Osama bin Laden article, but I found this new edit filter, editing edit notices is relatively harmless and for users like myself who just look around WP for somewhere to help and for those who were granted the account creator user rights to edit editnotices, I think that this is a setback, also account creators are now also unabled to edit their group edit notices. —James (Talk • Contribs) • 5:35pm • 07:35, 16 May 2011 (UTC)
  • I agree, a new group for editing editnotices should be created, or the ability to do that should be tied into some other group that makes sense (autopatrolled?) Ajraddatz (Talk) 04:10, 18 May 2011 (UTC)
    • That's the only way to do it since the edit filter checks to see if the user has the blacklist override right and is not an administrator, like I said most of the users with account creator but don't work at ACC are some such users who edit editnotices, also while editing editnotices was one of the by-products of having the blacklist override user right, I don't recall seeing any community discussion about the creation of such an edit filter and I think that the creation of such an edit filter though warranted is quite arbitrary. —James (Talk • Contribs) • 5:34pm • 07:34, 18 May 2011 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

A-Class

The Assessment scheme for articles has a list of 7 status for the articles. The first 4 (stub, start, c and b) are applied by users without following any specific process, and the last three (good, a and featured) involve a certain process, which may be passed or failed. But there's an issue: the GAN and FAC nominations are "official" steps, but the A-Class is applied by wikiprojects. Many problems arise from it: only a small number of wikiprojects work so well as to be able to maintain it, wikiprojects may have varying criteria or procedures, a given article may not have a related wikiproject with a working A-Class check, etc. Wouldn't it be better to prepare an official A-Class procedure, unique for all the project? Cambalachero (talk) 22:53, 16 May 2011 (UTC)

I don't think this would be a good idea. A-class status remains independent of the other two in this category, and was a couple of defining features. Before I mention them, though, I assume the intenton is to create a third on in the {GA, FA} set. These are indiciated by icons (since a while back) on the article itself, and FAs in interwiki links (at least on some WPs, not sure if it's global), also that one can see a list of GAs and FAs more easily. This matches well with the differing purpose of A class in what is admitted only a few wikiprojects (most notably MILHIST) that use it, but just like C class, it gives them more flexibility. Making A class project wide would remove the choice, we'd probably need another class any way. As it stands, I think two members of {GA, FA} is enough: one to look at outstanding articles, another to demarcate one we're proud of as a project and would stand by. In other words, transferring A class to project-wide status would remove the inherent flexibility there, and create an additional level in the projectwide system, one I don't think we need (but others may disagree, it is in a sense an independent issue). Grandiose (me, talk, contribs) 09:33, 17 May 2011 (UTC)
  • Comment - We should leave the "Good Article" and "Featured Article" nonsense for Citizendium and make A-class the one and only "top level, formally approved" status. But there's too much emotional energy invested in the status quo, I suppose, which is why the current system will remain forever and 98% of serious content-creators at WP won't give the proverbial rat's patooie about anything after B. Carrite (talk) 04:32, 18 May 2011 (UTC)
And leave no motivation whatsoever to try and improve articles? –MuZemike 05:01, 18 May 2011 (UTC)
Well, there are those who like to improve articles simply for the sake of making them better. I personally stopped being motivated by gold stars oh, about third grade or so. But yes, there are people who thrive on such recognitions and rewards so it would be helpful to have some way to motivate them. Short Brigade Harvester Boris (talk) 05:20, 18 May 2011 (UTC)
Monetary awards usually work. I bill at $200/hr if anyone wants a FA on their favorite topic. -Atmoz (talk) 15:11, 18 May 2011 (UTC)
I don't disagree. There have been a few articles which I improved that will likely not see past C or B-Class, and I can live with that. That being said, some people are motivated differently, but it is unreasonable to expect that everyone should be motivated in the exact same manner. –MuZemike 18:07, 18 May 2011 (UTC)
I like my gold stars, actually. But more importantly, going through the GAN and FAC processes have been a considerable help in improving my writing and editing. There are definite values to those processes, especially the peer review aspects inherent in them. Resolute 19:54, 19 May 2011 (UTC)
Let's not forget the value to Wikipedia of knowing which articles are of what quality. - Jarry1250 [Weasel? Discuss.] 15:02, 19 May 2011 (UTC)
Both FAC and GAN struggle to attract enough reviewers to function properly. Adding a third process will only exacerbate the issues. IMO, A-Class is completely redundant to GA, and should be deprecated. Resolute 15:05, 19 May 2011 (UTC)
Definitely get rid of A-Class it doesn't make sense to me. -- Eraserhead1 <talk> 17:49, 19 May 2011 (UTC)
While we're talking about it, I'm a fan of merging "C" class and "Start" class as well.
— V = IR (Talk • Contribs) 18:07, 19 May 2011 (UTC)
I think getting rid of A-class would be an improvement. It seems a bit odd that there is an extra rating only for certain types of articles, and seems even more odd that GA class is wedged in between A and B. If A-class was removed we would have more manpower to review GA articles, where there is regularly a massive backlog. doomgaze (talk) 18:19, 19 May 2011 (UTC)
I think C class is still fairly useful, the difference between Start and B class isn't small. -- Eraserhead1 <talk> 19:10, 19 May 2011 (UTC)
Agreed. As an example, on a hockey bio, if I have a developed section on the player's career but very little on personal, I'll rank C. If I can cover most or all areas, I'll rank B. Start would be an article that only covers parts of either. Resolute 19:51, 19 May 2011 (UTC)
But is there any evidence that the readership pays any attention at all to the Start, B, etc. class stuff? I can see FAs maybe, since they are rotated on the main page, but am doubtful as to the rest. I'm not trying to be a curmudgeon or a smartass (at least this one time) but am curious as to whether anyone has hard evidence. Short Brigade Harvester Boris (talk) 20:01, 19 May 2011 (UTC)
What I was saying was that it might be good to drop either "start" or "C", using the one that's retained for both ratings. However, I'm kinda with SBH (if I'm reading his opinion correctly) and others here, in that there's really not much distinction between all of these lower rankings. I understand what you're saying Resolute, I will rank things the same way, but... there's no objective criteria for those rankings. And, yea, the difference between C and B isn't usually small, but still... Anyway, I'm for at least shortening the system to only include C (which would include current "Start" and "stub" classes), B, GA, and FA. Alternately, we could go with Start, Good Article, and Featured Article.
— V = IR (Talk • Contribs) 20:14, 19 May 2011 (UTC)
Other than FA and GA, both of which have a visible icon, I doubt readership is even largely aware of the ranking system. I view the ranks as an internal structure for article development, and a valuable on at that. As examples, I have a personal project to improve articles related to the Calgary Flames that utilizes the page rankings to help me decide which articles I will work on next. A fellow editor has an even more ambitious project, of which I have also made use of to seek out articles in great need of expansion for the Wikicup. Resolute 20:20, 19 May 2011 (UTC)
There's little need to get rid of the ranks below B. Unlike Good, A and Featured, there's no burocracy behind them. A user assesses the article using just his good sense, and another user may update or fix the assess equally silently. So, it's not a project-wide issue. In fact, there are specific projects that removed specific ranks from their own system, following their own needs and contexts. The global removal of specific ranks below B will not reduce any pending workload.
As for the removal of A-Class, it's not what I proposed initially, but I recognize that it can also fix the problems I mentioned. However, it may merit a higher discussion, involving the related wikiprojects Cambalachero (talk) 20:47, 19 May 2011 (UTC)

You have to remember the rating system is project depended. For example wp:MILHIST A-class is just below or equal to FA lvl, while their B-class requires at least one citation per paragraph. Thus I have once seen an A-class lvl from some other project which was only start-class for milhist. The start-C-B-A structure is almost exclusively used because templates and stuff are readily available, but if any project decided to make a D class tomorrow they are free to do so. Yoenit (talk) 22:30, 19 May 2011 (UTC)

In an answer to the original question: no, it wouldn't be better. GA and FA processes as wikiwide are quite enough work. Allowing those wikiprojects who find A-class useful to maintain it (according to criteria which are reasonably well-established, being part of the standard {{Grading scheme}}) does no recognisable harm. Rd232 talk 01:21, 20 May 2011 (UTC)

I've been thinking for a while that it may be a good idea to consolidate many of them, as a couple have mentioned above. We could have the following classes:

Stub → Article → GA → FA (all other classes would obviously remain such as "List", "Disambig", etc.)

However, a couple of the others have a good point for retention, in that the assessments for the current lower classes are as lightweight as one can possibly get, as Cambalachero pointed out above and, if anything, provide constructive pointers for future improvement of articles. –MuZemike 19:11, 20 May 2011 (UTC)

Countries & protection

I've been thinking about this for a while, and it seemed like a good idea. I think we should semi-protect articles on sovereign states (including those 10 that are partially or fully unrecognized, such as Palestine, the Republic of China/Taiwan, and Somaliland), due to vandalism. Who agrees with me? Elium2 (talk) 14:16, 13 May 2011 (UTC)

If an article is being heavily vandalized, it already gets semi-protection; if it doesn't, there's no need. What's so significant about countries that they warrant special treatment? – iridescent 21:23, 13 May 2011 (UTC)
Well, a surprising amount of country pages are not protected, but should be. For example, the page on Afghanistan is not, but I'd think vandalism of the page would be rather likely, what with the war going on there… It just seems like country pages would have a higher risk of vandalism, really. Elium2 (talk) 18:31, 16 May 2011 (UTC)
On a quick skim, I can't see a single vandal edit to Afghanistan in the last month, or among the last 100-odd edits. Where are you getting "heavily vandalised" from? – iridescent 19:45, 19 May 2011 (UTC)
Pages are not protected because of the "risk" of vandalism, but whenever there's actual vandalism going on. Consider that high-visible pages are likely to be edited by vandals, but also by new users with good intentions. Cambalachero (talk) 14:22, 21 May 2011 (UTC)

Possibly wikipedia enhancements

“With its broad expansion and growing credibility in the past few years, Wikipedia has become far more widely used and demanded among users. Given its increased popularity, it is likely that Wikipedia will continue to grow and improve its features to maintain its relevance in cyberspace. Possibilities for increased user interaction: -skins or templates for the page that allow users to customize the look of the site to their own preferences and interests -applications- some wikis have already begun to adopt applications such as spreadsheets, polls, or online chat, which might be valuable ideas for Wikipedia to make use of -collaborative software- places for users to communicate with each other on the site such as bulletin boards, online chats, or forums, might allow user feedback and dialogue to improve the quality of information and increase the democratization of knowledge [1] — Preceding unsigned comment added by Megann491 (talk • contribs)

Skins already exist, though you must be logged in to use a non-default one; making skin creation/sharing easier could be interesting. Wikipedia "forums" already exist (this page is one of them); the upcoming-but-continually-delayed WP:LiquidThreads is intended to make them more user-friendly; the WP:Article Feedback Tool is being pursued to gather feedback from readers. I believe integrating currently-jury-rigged processes/features (e.g. references, problem tags, Good/Featured Article Nomination/Review) as proper plugins would be a promising way to improve Wikipedia from an efficiency/user-friendliness standpoint; it's time to better integrate Wikipedia into MediaWiki. --Cybercobra (talk) 11:48, 21 May 2011 (UTC)

I still run into articles where the "External links" section is not the last section, per the MoS. It would seem that a bot could automate checking to make sure that a second level "External links" section always follows any second level "References", "Notes", "Further reading" or "See also" sections. Regards, RJH (talk) 16:57, 18 May 2011 (UTC)

This belongs at Wikipedia:Bot requests. Yoenit (talk) 19:36, 18 May 2011 (UTC)
Ta. RJH (talk)
While ideally articles would follow that order, it is hardly important enough to have a bot go through articles changing it. Combined with other, necessary changes, perhaps, but not on its own. Fram (talk) 10:03, 19 May 2011 (UTC)
Although some wikipedians invest a great deal of effort in making layout (and naming) consistent between articles, I doubt that most of it would be noticed by the average reader. Time could be better spent on improving actual content, rather than lining up the lower section headings in one particular order. bobrayner (talk) 14:07, 19 May 2011 (UTC)
Which is, I believe, the classic reason to have a bot do something like this: The bot can rearrange stuff, and editors can get back to work on content.
I wonder whether it would be possible to move ==See also== ahead of ==References== or ==Notes== (where such sections use a typical name). WhatamIdoing (talk) 14:48, 19 May 2011 (UTC)
I likewise find this a pain to do manually and agree it should be possible to automate. Detection of the end of the last section could be tricky though, but I think there are sufficient heuristics to apply. --Cybercobra (talk) 22:25, 19 May 2011 (UTC)
I fully agree that focusing on the content would better in terms of improving Wikipedia, than would spending so much time on the structural details. However, I don't think my question/suggestion is out of line with some of the other trivial minutiae that get handled regularly by bots. :-) Regards, RJH (talk) 18:58, 20 May 2011 (UTC)
Personally, I'd completely support a change to WP:LAYOUT (and the WP:MOS, by extension) which would change the guidance on the footer structure of articles into a more formal "do it this way" sort of thing. I think that such guidance is good for the encyclopedia, because I think that presenting generally the same structure to readers makes articles easier to access. There seems to be quite a bit of fear though, that people will use such guidance to forcibly change certain articles which use slightly different structures (for what are probably good reasons).
— V = IR (Talk • Contribs) 19:33, 20 May 2011 (UTC)
I have some regex code that can be used to move sections around but when using it you will occassionally find that there are articles that don't fit the standard setup. For example, Some have multiple External links sections, some call it something else, some have an external links sections but then its just templates and categories, etc. Although some can be done as a bot I recommend extreme care because after doing a lot of these I have found a bot would likely cause many errors. If you want the regex code just let me know. --Kumioko (talk) 02:06, 23 May 2011 (UTC)

Additional Section in Ratings Box

Hello; I was wondering re the Page ratings boxes which currently have these four sections:

  • Trustworthy
  • Complete
  • Objective
  • Well-written

Whether it might not be helpful also to have one for Further Reading: 'Do you feel that this page provides useful suggestions for additional research', or something similar; as for any encyclopaedia this place isn't the final word; the better print ones, e.g. Grove Dictionary of Music and Musicians have a lot of references to books and articles; also, if these ratings boxes are aimed at least in part at encouraging editors to concentrate on these key factors, then references should be up there with these other points (not just a subdivision of 'Complete'). Thanks, Maculosae tegmine lyncis (talk) 16:07, 22 May 2011 (UTC)

You should put that suggestion at mw:Talk:Article feedback/Public Policy Pilot/Workgroup. /ƒETCHCOMMS/ 19:19, 22 May 2011 (UTC)

Suggestion for a new sister project for Wikipedia

I am not really sure is quite the right place to propose this, but there has been something which has been on my mind over this year (2010). If you go to Wikipedia: What Wikipedia is not, you will be informed that Wikipedia is not a "how-to" manual. Well, that is as maybe, but how about starting a sister-project to enable such things? We have a Wikimedia Incubator to propose Wikipedias in new languages - go to List of Wikipedias and you will see examples of Wikipedias in various languages which have been proposed successfully here (I believe a Lakota Wikipedia has been under discussion here, but I do not think that anything came of it). I wonder whether we could start a Wikimedia Incubator to propose new projects other than Wikipedias, which be brand new ideas to Wikis? Perhaps the Wikimedia Foundation would have to be informed.

My personal suggestion for a related Wiki "how to" project would be a Wiki Recipe book. I am sure that many people have used the net for recipes, and the concept of a Wiki recipe book to me, sounds quite intriguing. So, shall we see to some sister-projects that really are "how-to" manuals? I know that there are several sister-projects to Wikipedia, such as Wikiquotes, Wikinews, Wikiversity, Wiktionary and Wikispecies, but none of them seem to be how-to manuals. ACEOREVIVED (talk) 20:44, 12 June 2010 (UTC)

Would the Wiki Cookbook be what you're after? – iridescent 20:51, 12 June 2010 (UTC)

Thank you for that, yes, it seems as if it is there. Having gone to Wikipedia: What Wikipedia is not after typing that suggestion, I see that there is where it says that Wikipedia is not a "how-to" manual, it does mention Wikibooks. Many thanks for the information, it is appreciated. ACEOREVIVED (talk) 21:27, 12 June 2010 (UTC)

It might be a good idea to start something like Wikihow but they seem to do a good job over there so it might not be needed.Doc James (talk · contribs · email) 21:49, 12 June 2010 (UTC)

Convert ANI to transclusion system

I'm not too familiar with this, but, I am proposing that ANI threads be moved to subpages and then get transcluded onto the main ANI page, as happens with RFA and SPI. That way, people can watch only the threads pertinent to them if need be. My watchlist would be much less crowded with irrelevant ANI posts if this were done.Jasper Deng (talk) 19:19, 22 May 2011 (UTC)

I believe this was proposed very recently and rejected, can't remember where or by whom. It's not really a good idea, though I understand where you're coming from. Transclusions make it harder to keep track; it may clean up your watchlist but it's harder to see what's going on at a glance. If the ANI scroll is too much for your watchlist, I suggest you do what I did: take it off your watchlist :) → ROUX ₪ 19:30, 22 May 2011 (UTC)
Please explain. I can't take it off my watchlist as I am watching a few threads in particular.Jasper Deng (talk) 19:32, 22 May 2011 (UTC)
I mean that ANI is very high-traffic and of general interest to everyone, so transcluding everything makes it harder to see when updates happen. It also would make it very hard to see when particular topics end, etc, without individually watchlisting every page you have even a vague interest in. → ROUX ₪ 19:53, 22 May 2011 (UTC)
Yes, you can take it off your watchlist. Threads on ANI typically have a very short lifespan. Whatever you're interested in at the moment will likely be gone in two or three days. I'm sure you can remember to check ANI manually for two or three days. WhatamIdoing (talk) 00:09, 23 May 2011 (UTC)
One, waaaaay too many threads for subpaging, so way too much work. We already subpage overly long threads, anyway. Two, I don't even use my watchlist for AN/I—way too many changes to go through, so just skimming the actual page is faster. /ƒETCHCOMMS/ 00:32, 23 May 2011 (UTC)
On the other hand, it might be possible to subpage by the date that the thread started, like WP:FEEDBACK does. Then you'd only have 24 hours' reports to look through. WhatamIdoing (talk) 20:35, 26 May 2011 (UTC)

Using Pending Changes to help unprotect currently-protected articles

Now that the Pending Changes trial is winding down a little bit, I'll heat things back up again with my proposal on how to implement Pending Changes in a more constructive fashion, as opposed to simply turning it on and letting everyone go hog-wild with it.

My proposal would be to implement Pending Changes as a means to mitigate existing article protection. Let me elaborate on how this would work with a brief example:

  1. An article has been semi-protected for a long period of time for one reason or another, usually vandalism.
  2. Change protection level from semi-protection to Level 1 Pending Changes as a means to gauge whether or not the semi-protection should be lifted.
  3. If there is relatively little or no disruption/vandalism on the article, then all protection can be lifted from the article, allowing anybody to edit. If the disruption/vandalism continues, then the article remains on semi-protection.

What we could do is run this through all semi-protected articles which have been protected for the longest time in batches and see whether or not they still warrant semi-protection. This would be a much more constructive approach than the more willy-nilly approach during the trial, and it has the likely potential benefits in that new users and IPs will be allowed to edit more articles again. –MuZemike 02:11, 23 May 2011 (UTC)

I think this is a good idea. But I think discussing it first on Wikipedia talk:Pending changes/Request for Comment February 2011 is best. -- Eraserhead1 <talk> 21:31, 23 May 2011 (UTC)
I think this is a good idea, and I'd like to see automated reports (monthly?) on how often PC changes are reverted in given articles. IMO a page that gets many bad edits should generally be returned to semi-protection (to reduce the load on other editors); a page that gets proportionally few bad edits could be returned to normal editing. Pages that get few-but-often-bad edits could be kept in the PC system as a reasonable use of our resources. WhatamIdoing (talk) 20:46, 26 May 2011 (UTC)

Proposal for Template:Convert to convert inches to centimetres rather than millimetres by default

See Template talk:Convert#Default target unit for inch conversions. ― A. di M.​plé​dréachtaí 20:10, 23 May 2011 (UTC)

Annoying mouseover text

Hi. When I navigate to the search box at the top right of the page, the text "Search Wikipedia [alt f]" pops up. As I start typing, this typically partially obscures the top of the dropdown list, which typically contains items that I might want to click on (if I could see them properly). Eventually the "Search Wikipedia" text times out and disappears, but only long after it's become annoying. I suggest that this text is dismissed as soon as you start typing. 86.179.0.162 (talk) 20:22, 26 May 2011 (UTC)

For me, it disappears if the mouse isn't over the search box, so you can just move your mouse away. Is this something you can do, or not? It might depend on browser, I'm not sure. Grandiose (me, talk, contribs) 20:28, 26 May 2011 (UTC)
Yes, that works. However, it doesn't really eliminate the annoyance because it involves another step that interrupts typing. Typically, I might type some characters and wonder if the article I want is at the top of the list, obscured by the pop-up text. To check, I would have to move my hand away from the keyboard to move the mouse. Then, when I find the item I want is not there, I have to move back to the keyboard to type some more. It seems very minor, but it annoys me every time and would be nice to fix I think. 86.179.0.162 (talk) 21:34, 26 May 2011 (UTC)
What browser are you using? With Firefox the popup text shows up just below the field, so it doesn't obscure. ▫ JohnnyMrNinja 23:12, 26 May 2011 (UTC)
I am using IE8. The pop-up text appears just below the entry field, as you say, but that's exactly the problem because just below the entry field is the drop-down list. Are you saying your drop-down list is not below the entry field? 86.179.0.162 (talk) 01:03, 27 May 2011 (UTC)

Disambiguation for discussion proposal

I know that there are sections of Wikipedia with titles such as "Articles for discussion" or "Redirects for discussion" - so shall we go the whole hog and have an entry "Disambiguation for discussion"? I know this might sound silly, but it is only a suggestion. ACEOREVIVED (talk) 21:22, 26 May 2011 (UTC)

It's been proposed a few times before. The answer has always been to keep it as part of Miscellany for Deletion (WP:MFD). I think that MfD is a sensible solution, to be honest. Disambiguations are really not a big issue when it comes to deletions, and there are many other random things that also are not big issues and only come up occasionally, so having MfD is ideal. Sven Manguard Wha? 21:42, 26 May 2011 (UTC)
Hm. I've always seen them at AfD... --Cybercobra (talk) 22:39, 26 May 2011 (UTC)
See also the failed Wikipedia:Disambiguations for discussion proposal. Rd232 talk 21:51, 26 May 2011 (UTC)

Number of accounts to be restricted

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
This proposal is a sledgehammer to crack a nut. The issue which prompted the proposal is Humor accounts; any attempt to restrict those should focus on them. Rd232 talk 09:52, 28 May 2011 (UTC)

This is a proposal to limit the number of alternate accounts that a user may have to three. We all know that having a single alternate account is clearly within policy and usually done to have an account for when editing from a public area wifi. However, I do not see the need for users to have more accounts than this, as it is not beneficial to the encyclopedia and serves no viable purpose. I can understand that there are some circumstances that might require a third account to be made, so I propose three to be the upper limit.

Note: This number is not to count past accounts that are no longer in use and have been abandoned, accounts that have been compromised, or bot accounts that don't count as being directly used for editing since they are a program. This is only to count for current accounts that are in use. There will also possibly be major exceptions in the future that may need to be accounted for, but these would be far and few between and this is just meant to discuss general policy without taking into account extenuating circumstances.

Disclosure: As it will probably be brought up by certain users almost immediately after submitting this edit, I am making this proposal in response to this edit made by User:Bishzilla, which is the alternate account of User:Bishonen. Might I note that this alternate account Bishzilla has its own alternate account User:Bishapod, which in turn has its own alternate account User:Baby Stupid. I attempted to revert this edit, but was promptly stopped by Alison and Short Brigade Harvester Boris, for no apparent reason, other than "Lighten up". I don't have an issue with someone having alternate accounts (within 3) for humor, but humor is never a reason to employ IAR and edit archived discussions. SilverserenC 00:41, 9 May 2011 (UTC)

  • Can you explain to me what purpose more than 2 alternate accounts serves? Having more than that seems as if they can only be used for disruption, because why else would they exist? SilverserenC 01:04, 9 May 2011 (UTC)
  • Can you please explain to me how it would be a bad thing if a user had 5,000 accounts, so long as they never did anything bad with them? And two is easy - one bot, one public account, one huggle account, one AWB account, etc. Ajraddatz (Talk) 01:06, 9 May 2011 (UTC)
  • I just don't see a compelling need for this restriction. What problem would it solve? 28bytes (talk) 01:10, 9 May 2011 (UTC)
  • I didn't think about bots, that's been added to the note, as they shouldn't count. And are there specific software reasons that would make a user unable to have a single account that uses Huggle and AWB? If so, I would think that would fall under acceptable extenuating circumstances, as both accounts would have a specific purpose. SilverserenC 01:13, 9 May 2011 (UTC)
  • The main issue is that such accounts are often used for disruption and, as in the disclosed case above, actions that are disruptive and break policy are defended by other users because it is "humorous", which should not be a reason for breaking rules. We're here to build an encyclopedia and, while humor is accepted at times, it should not be used as a guise to actually cause disruption. If an alternate account does not have a specific defined use, then it shouldn't be allowed. SilverserenC 01:21, 9 May 2011 (UTC)
  • We're here to build an encyclopedia and, while humor is accepted at times, it should not be used as a guise an excuse to actually cause disruption by overreacting to it. Hans Adler 09:00, 9 May 2011 (UTC)
  • Support if.... 1. Current good faith editors in good standing with more than 3 disclosed accounts are grandfathered in. 2. Good faith editors in good standing may create more than 3 accounts if they have a good reason, perhaps by notifying arbcom as the participants of WP:NEWT did. 3. If a good faith editor in good standing creates a 4th account out of ignorance of the rule, the 4th account may be blocked but subject to an unblock if he can demonstrate that he has a good reason for it. 4. Approved bots don't count. --Ron Ritzman (talk) 01:20, 9 May 2011 (UTC)
  • 1) Presumably, such users would have specific reasons for having more accounts, so of course they would be grandfathered in. But if specifically asked about an account after this point, they should be able to explain the purpose for the account existing.
2) Yes, of course. Having an actual reason for having more accounts would be perfectly acceptable.
3) Yeah, that makes sense. If they don't know about the rule, of course they shouldn't get in trouble for it.
4) Already have that added to the note section, so yes. SilverserenC 01:25, 9 May 2011 (UTC)
...Or, we could not enact all of these new rules and save Wikipedia from increasing levels of bureaucracy. My point is this; since all disruptive accounts are blocked, how does it hurt to have many of them? If anything, it shows that users are subject to WP:EDITCOUNTITIS. Why are we trying to fix a system which isn't broken? Ajraddatz (Talk) 01:30, 9 May 2011 (UTC)
  • Oppose. I don't see why this restriction is necessary, and the people hurt by the rule would be the ones who currently edit constructively, not the ones who edit disruptively. There's no magic way to tell whether accounts are operated by the same person. Why spend unnecessary time checking out legitimate users' accounts? If people are abusing multiple accounts, there's an underlying disruption issue, so they can be blocked under the current rules. There's no need for an arbitrary cap on accounts per person. —C.Fred (talk) 01:32, 9 May 2011 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Subproposal: All accounts should be stated and linked to on the userpage of all accounts

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
This proposal is already covered by Wikipedia:Sock_puppetry#Alternative_account_notification, with the key caveat "Except when doing so would defeat the purpose of having a legitimate alternative account, editors using alternative accounts should provide links between the accounts"." Thus the proposal amounts to a proposal to remove Privacy from the Wikipedia:Sock_puppetry#Legitimate_uses section of WP:SOCK, since requiring onwiki documentation of links in these cases defeats the purpose. This was clearly not the proposer's intention: the issue concerns the last point of Legitimate Uses of socks, Humor accounts. Such accounts are already, by the letter of policy, subject to appropriate notification. The issue prompting this concerned the application of that to a specific case, and this proposal is not a solution to that issue. Rd232 talk 09:48, 28 May 2011 (UTC)

This is a subproposal that would have all accounts of a user stated and linked to explicitly somewhere on the user pages of all the accounts. That way, if any user comes into contact with one of the accounts, they will know right away what other accounts the user has, so there is no confusion. Not listing all accounts could be seen as a type of subterfuge. I would also say that creating a singular link to another alternate account and then a singular link to another one from there back up to the main one is also not helpful, so all accounts should be linked on every account.

Note: Separate accounts created for privacy concerns don't count and would not have to be disclosed in the main set of accounts. SilverserenC 01:13, 9 May 2011 (UTC)

To be clear, WP:Multiple Accounts currently says that editors can have undisclosed alternate accounts if (for example) they have privacy concerns. Your proposal would essentially eliminate the "privacy" section of that policy. To quote Microsoft Windows, "Are you sure you want to do this?" 28bytes (talk) 01:21, 9 May 2011 (UTC)
Good point, clarified with a note. SilverserenC 01:22, 9 May 2011 (UTC)

Comment: Wikipedia:Sock_puppetry#Alternative_account_notification essentially covers all this already. It could possibly be firmed up slightly, but the main thing is a need to actually apply the policy, with blocks if necessary. Rd232 talk 01:26, 9 May 2011 (UTC)

Well, the main reason I made this subproposal is because of Bishonen's alternate accounts, which all have singular links back upward, since they are alternate accounts of the alternate accounts. So you have to follow a string of links to get to the main account of Bishonen, which is entirely unhelpful. SilverserenC 01:29, 9 May 2011 (UTC)
  • Isn't this required already? If they're not linked, ArbCom should know (privacy etc.) or they should never edit the same subjects or interact or be otherwise disruptive. As for Bish, I don't see that happening all over the place—issues with a single user shouldn't be dealt with by imposing site-wide rules. /ƒETCHCOMMS/ 02:30, 9 May 2011 (UTC)
  • I've seen it occurring in other places as well, I just use Bishonen as an example because it is the one that is, imo, the most blatant example of such. SilverserenC 02:37, 9 May 2011 (UTC)
  • Creating a rule that you cannot possibly enforce is a Very Bad Idea. Think about it from the practical end of things: You want editors to disclose accounts. Some proportion of editors do not want to do this. (Far more editors simply won't know the details of the rules.) So how can we make them do what they don't want to do? Well, I can think of only two options:
    1. We can authorize the checkusers to go on massive and doomed fishing expeditions—which will fail, since "User at home", "User at work", "User on a smartphone" and "User at a public computer" don't overlap, but "User" and "User's neighbor who also uses the same WiFi network" does. (See 'checkuser is not magic pixie dust'.)
    2. Alternatively, we somehow find editors with the psychic skills to magically identify non-disclosed accounts, and convince them that this is far more important than, say, solving crimes or finding lost puppies.
      Neither of these are either realistic or proportionate solutions to the trivial irritation of having to click through several user pages. In fact, I suspect that we have spent more time discussing the rule than any of us will spend clicking on such a series of links this entire calendar year. WhatamIdoing (talk) 03:01, 9 May 2011 (UTC)
Re (2) above: we already have too many of those. Some believe that filing SPIs with 30% success rate is the hallmark of a good sleuth. Tijfo098 (talk) 06:27, 11 May 2011 (UTC)
  • Oppose, extra rule that is hard to enforce (and it isn't helpful to do so unless the accounts also break other rules). —Кузьма討論 06:32, 9 May 2011 (UTC)
  • Oppose; done it before, bad idea. Barong 08:21, 9 May 2011 (UTC)
  • Oppose I don't appreciate people bringing up irrelevant proposals to stop some humour they don't like. If the comment about eating dogs had been by someone with a single account would the OP be trying to do something else? This is irrelevant. Only reason I can see for this is if 'Enduring Encyclopaedia' succeeds and we keep the number of new editors up then inevitably user names will have to get longer and longer without bound and this proposal might slow the rate of growth. Dmcq (talk) 08:58, 9 May 2011 (UTC)
  • Oppose with moral support - If this could be enforced without having Checkusers working so hard, I'd be more willing to support. --Σ ☭★ 22:10, 21 May 2011 (UTC)
  • Oppose. Editors should be able to edit with their real name for subjects where the real name would be of interest to other editors, and an anonymous name for areas that are apt to attract abuse (reverting vandalism, for instance). There should be no requirement to explain such an arrangement to anyone. Jc3s5h (talk) 23:45, 21 May 2011 (UTC)
  • Oppose: anonymity and privacy should be valued. There may be good privacy reasons for someone to want to keep account A separate from account B, such as one account that is known to coworkers and another account that is private. I like Jc3s5h's example. And as others have said, enforcement would be difficult. GreenPine (talk) 08:09, 28 May 2011 (UTC)
  • Oppose adding bureaucracy here seems likely to cause more problems than its worth. It would provide even more justification for over-zealous blocking of new users who are unaware of this policy. -- Eraserhead1 <talk> 09:08, 28 May 2011 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

WP:CP clerks

Hi. Those of you who've seen me around know that I've been hanging around in the copyright cleanup department for a long time. I am one of the few administrators who regularly works at WP:CP. I've been doing it for years and am admittedly suffering some burnout, as well as time constraints that have diminished my participation there (and are likely to be diminishing it more in weeks to come). It hasn't mattered so much lately, though, because we have a stellar non-admin volunteer who has been streamlining that work so that mop up has been a relative breeze. What used to take me hours out of every day is now taking hours out of every couple of days. This is significant, because I have not had much success in recruiting consistent admin assistance there from others (in spite of advertising for the position at AN).

I would like to create non-admin clerks for the CP board in the model of the clerks working WP:SPA and WP:CCI. While admins are needed to perform some tasks at WP:CP, they are not required for many of them, and even in those cases where admins must push the buttons clerks can still perform many of the tasks up to that point. I don't think it's a good idea to simply open up some of the more delicate jobs at CP to anyone (although there are some jobs there that anyone can do), since we have seen in WP:CCIs for instance where contributors who themselves have a history of copyright problems or an understanding of copyright out of step with our policies have created more problems than they've solved. But certainly those who have demonstrated facility with the work and who are willing to do it should be not only permitted but encouraged to help out. We need them!

Clerks can evaluate the validity of complaints (helping determine if content is PD or compatibly licensed), identify when content was entered, ensure that those who entered the content have been properly advised of policies, and in some cases directly address articles tagged with {{copyvio}}. Sometimes contributors use this tag when an article could simply have been reverted (recently, I saw the tag applied to an article with a long history where the copyvio had been entered only three edits before); sometimes they use it when issues are easily repaired. Clerks can flag the articles for revision deletion if necessary by the admin who closes the day.

I say with all confidence that this would be a tremendous benefit to Wikipedia. I really hope that the proposal is uncontroversial. At this point, I think that two or three clerks should be sufficient. I think I'd be lucky to find two or three clerks (the work is pretty tedious), but I'm optimistic. :) --Moonriddengirl (talk) 13:28, 22 May 2011 (UTC)

I would support the idea of CP clerks as Moonriddengirl has explained it would help the progress of what is an important back office task. I feel that if the process was clerk driven it would also gain more support from admins who can easily deal with the situation with confidence that the case has been assessed by others with some copyright experience. MilborneOne (talk) 13:52, 22 May 2011 (UTC)
Looks like a good idea to me. Peridon (talk) 14:04, 22 May 2011 (UTC)
Makes sense, and if Moonriddengirl thinks it a good idea to improve copyright cleanup, that's good enough for me. Rd232 talk 14:13, 22 May 2011 (UTC)
Certainly in support of the proposal, not least because I trust Moonriddengirl to understand what would be the best. Also, I'd be interested in helping out (whether or not this goes through), is there a way I can find out more about how it works? Grandiose (me, talk, contribs) 14:17, 22 May 2011 (UTC)
I like the idea, great idea and I trust MRG's word. mauchoeagle (c) 15:44, 22 May 2011 (UTC)
  • Ooh, MilborneOne, that's something I hadn't even considered! That would be fantastic. :) Grandiose, probably the best way to get an idea is to see what User:NortyNort has already been doing. Take a look at Wikipedia:Copyright problems/2011 May 12 for instance. There are four levels of concern we address at CP: (1) final review of articles marked by bot at WP:SCV (generally, revision deletion; deletion if permission was indicated but not supplied; deletion or revision if content was a copyvio but not G12able and the week has passed without remedy); (2) review of articles flagged {{copyvio}} (basically the same approach as SCV final review, although in these cases are more complex as there may be clean versions in history or "reverse infringements" are possible); (3) articles flagged {{copypaste}} (which may or may not be blatant infringements); and (4) articles tagged {{close paraphrase}}, which may be blatant infringements, may require rewriting or may be perfectly fine. Non-admins can already address levels 3 and 4. Clerks can do much with 1 and 2: they can annotate that no action has been taken and the article needs to be deleted; they can clean or stub the content; they can flag it for revision deletion. We would modifify the {{CPC}} system to allow for clerk closure of listings with annotations when admin follow-up is needed, such as revision deletion. Clerks would also need to be able to get in touch with an admin if blocks are needed and would need to know when to follow up at WP:CCI. It would not be necessary for an admin to review clerk closures, although I imagine that with any new clerk on the job a period of mentorship could be valuable. When NortyNort first started helping, of course I double-checked until I was sure I didn't need to. :) Among the more important tasks, particularly with articles flagged {{copyvio}}, is ensuring that clerks know how to recognize backwards copying. A small but significant portion of articles flagged for {{copyvio}} actually originated on Wikipedia; we don't want to remove content that is rightfully ours. If we establish a clerk system, we can easily create a guideline modeled on Wikipedia:Copyright problems/Advice for admins specifically for clerks. May I add that one of the great benefits of a clerk system here is that we would be training people who may choose to become copyright admins in the future. We need those. I've seen a handful of really good ones come through the project in the past three years or so, but as is the nature of a project like this they don't always maintain the level of participation. People do come and go. --Moonriddengirl (talk) 16:38, 22 May 2011 (UTC)
  • I'm not really into clerks for any wiki-process, but there are two advantages to them: one, having the same designated people on a particular job means every participant—admin or not—is more familiar with all the other participants. And two, the training/mentoring aspect is very valuable, especially with long-term benefits to future participants, the clerk him-/herself, and the CP project. I therefore think that clerking is appropriate for a complex area like CP and support this proposal. Also, because MRG is like super-awesome and a copyright nerd, I trust her judgment in what would be best for the project :). /ƒETCHCOMMS/ 19:16, 22 May 2011 (UTC)
  • Support - I think this is an excellent suggestion and wholeheartedly support it. While I would not suggest making copyright expertise a requirement for a CP clerk, I wonder if there's value in having anyone who does have copyright knowledge, and wants to clerk, and doesn't mind giving up a bit of their anonoymity, make their credentials known to OTRS. Such a person might be considered to be a "chief clerk" and act as a resource for the admins working CP problems. But even if this idea is not workable, the basic clerk idea is good. Beyond My Ken (talk) 19:34, 22 May 2011 (UTC)
  • Comment  I don't understand the tradeoffs enough to take a position, but if MRG recommends it, it must be good.  Two questions, what is the process to cancel the clerks if MRG decides it is not working out?  If MRG quits, who would decide that the process is or is not working?  Unscintillating (talk) 21:09, 22 May 2011 (UTC)
  • I'm always happy to discuss it more thoroughly. :) I appreciate the vote of confidence, but many brains are better than one. I had never even considered the advantage raised by MilborneOne, and there are undoubtedly challenges I'll not have considered, either. I think the biggest risk of clerks "not working out" would simply be lack of participation, honestly. That's a problem that plagues copyright cleanup at all levels. If for some reason the whole process takes a belly flop, it seems to me that what village pump (proposals) gives, village pump proposals can take away. I don't plan to quit the work altogether, even though my time has diminished (I do believe strongly in its importance), but there's always the possibility that I'll get hit by a bus or be swept off on a wild adventure into a land sans internet. Since admins still have to close out the days as well as use their tools where those tools are required, there should still be some inkling of whether or not the process is working. As much of what passes through CP is already free for anybody to work on ({{copypaste}} and {{close paraphrasing}} list there merely to make sure that blatant issues aren't too passively tagged and ignored forever), the biggest shift in "authority" I propose here is in allowing select non-admins to interact with the {{copyvio}} tag without requiring consistent admin overview. The selection process may require some thought. There are a number of people whose work I've seen at CP who I would trust with the role, but obviously there needs to be some consistent way to vet candidates. The model at Wikipedia:Sockpuppet_investigations/SPI/Clerks would not work for a board where there are only a handful of clerks. Perhaps clerks could be chosen from among those who have volunteered consistent time at WP:SCV and demonstrated a sound understanding of Wikipedia's approach to copyright concerns there. --Moonriddengirl (talk) 21:41, 22 May 2011 (UTC)
  • LOL, well that works. :D There are a couple of admins who are very active in text-based copyright work besides me. We've sort of just handled WP:CCI clerking very informally, with a brief discussion at the talk page of WP:CCI. Unless there turns out to be way more clamoring for CP clerking than I would expect, we could probably do the same thing for CP clerks, at WT:CP. --Moonriddengirl (talk) 22:56, 22 May 2011 (UTC)
  • I support the establishment of clerks at WP:CP. The workspace is often backlogged and it would be a great help to the very few admins who work there. The work can get quite complex. Some possible copyvios I have dealt with can take up to a half-hour or more to investigate. I haven't learned everything but have learned a lot so far. The clerk job also gives great on-the-job training for potential admins as much of the tools come into play along with content knowledge as well. Clerks can evolve into admins and help regenerate help in the space in the event that admins are "swept off". I think Moonriddengirl and other admins in copyvio areas are 'clutch' to Wikipedia. Editors, although possibly reluctant, would be more apt to work in the space if "help" was more structured. Potential clerks can be mentored by specific editors and can even start in WP:SCV where issues can be a little less complicated. If the community approves of such position, I would like to offer myself as the inaugural clerk.--NortyNort (Holla) 04:22, 23 May 2011 (UTC)
  • Support Currently anybody working at wp:CP needs to be an admin, experienced in copyright and willing to work in the area. The number of editors who meet all three criteria can unfortunately be counted on one hand. Opening up the board to non-admins would significantly increase the pool of eligible editors. (disclaimer: I am not active enough now, but I might apply for this position when I get more free time in a few months, so I have a COI here). Yoenit (talk) 13:27, 23 May 2011 (UTC)
  • Support. There is a chronic shortage of copyvio specialists and this may help suck in a few interested editors. (I may throw my hat into the ring, but there are too many things competing for my free time at the moment.) MER-C 05:22, 24 May 2011 (UTC)
  • Support. Looks like a good idea, although it may require a screening process. Crisco 1492 (talk) 06:27, 24 May 2011 (UTC)
  • I hate to sound out of touch here (or something like that), but... what exactly are we "supporting" or "opposing" (not that there's any actual opposition here, so far) here? I don't see any actual proposal here, just a description of some new label to apply to some folks. Am I mistaken here? Is there a proposal to add a new user group in this, somewhere?
    — V = IR (Talk • Contribs) 08:07, 24 May 2011 (UTC)
    • No separate userright, but something comparable to wp:BAG membership. The instructions at wp:CP say only admins can resolve entries. Unofficially non-admins can help out, but an administrator has to recheck everything they do. The idea behind granting clerk status is that competent users are recognized as such and are allowed resolve entries on their own. Yoenit (talk) 09:06, 24 May 2011 (UTC)
      Just to play a little "devil's advocate" here, why not require these clerks to be admins? Adminship isn't supposed to be a big deal, right? More importantly, if these users are so "trusted", then why aren't they admins? (I think that's a crock personally, but it seems to be a persuasive argument against most proposals like this). Also, I have a partially related question. What's up with the need for permission to do this that's being sought here? If there's no need for a bureaucrat to create a new user right or anything like that, then I don't see why we're debating what appears to be an inner-process issue.
      — V = IR (Talk • Contribs) 09:18, 24 May 2011 (UTC)
      • I did not say trusted, I said competent. All editors with a history free of copyright problems are "trusted" to clean up copyright violations. However, copyright cleanup is complex and there are dozens of pitfalls for inexperienced editors. To mark issues on wp:CP as resolved without further review we therefore need users who have demonstrated competency in copyright issues. The situation is currently restricted to admins, presumably because they are "trusted" not to stick their fingers in something if they are not competent in the area (and of course deletion is sometimes involved). As for discussing it here, is there any reason we should not? Yoenit (talk) 09:59, 24 May 2011 (UTC)
        If nobody needs to do anything to make this happen, then why not just do it? What input is being sought here, exactly? (If I were to allow myself to be cynical for a minute, I could conclude that this is just a round about way of getting some back patting in...) Again though, why not simply rely on admins? You may not have said "trusted", but others have, and your use of "competent" in place of "trusted" seemingly amounts to the same thing. If these users are competent enough to mark issues on WP:CP as resolved without needing further review, then why aren't they competent enough to have the bit?
        — V = IR (Talk • Contribs) 10:10, 24 May 2011 (UTC)
        Being competent enough to have the bit, is not the same as having the bit or even wanting the bit. I assume you are familiar enough with the problems surrounding RFA that I don't have to elaborate. The current system of relying on admins has resulted in MoonRiddenGirl handling the board practically on her own for years, clearly that is not working. Yoenit (talk) 10:52, 24 May 2011 (UTC)
        What is being sought here, as Yoenit says, is community support to permit non-admins who have been vetted at a certain task to take on a role that has always been confined to admins: closing individual CP listings. Why we can't simply rely on admins is because there aren't enough knowledgeable admins who are willing to do the work; I've advertised, including here and here. You might remember the second one; you were the only person to respond at the board. You kind of implied there that non-admins might be good help. People don't need tools to do many of the tasks called on. They do, however, need some understanding of copyright. As for why this is here, I tend not to change long-established processes without making sure that the community is good with it. --Moonriddengirl (talk) 11:55, 24 May 2011 (UTC)
        Was trying to add this comment yesterday but there was a Wikimedia technical error. Clerking can be a good way to gain trust from admins and the knowledge needed to eventually proficient admin in the process if wanted. I assume as well that if an admin with little experience in the copyright areas wanted to investigate reports w/o closing them, that would be acceptable as well. CP can be intimidating at first and the process may be intricate at times but it gets easier with experience. The problem continues that there are too few admins working in an important area. A clerk position can encourage non-admin editors to help, learn and eventually replenish and augment a copyvio SME admin group.--NortyNort (Holla) 08:30, 25 May 2011 (UTC)
  • Support if the clerks become trusted to do a good job it will meant that an admin that comes along to delete does not have to check so much. However there would have to be some defined group with an assessment to see how their work is. Graeme Bartlett (talk) 08:48, 24 May 2011 (UTC)
  • That sounds like a good idea, although defining a group in copyright work is always a challenge. Unlike checkusers, there isn't really a category of copyright admins or anything like that; just whoever is around and feels up to the job. :) I can see if I can get together a group of volunteers from admins who I've seen doing the work who would sign up for periodic review, if you think that would be good? --Moonriddengirl (talk) 11:55, 24 May 2011 (UTC)

Specifics of implementation

  • I have drafted Wikipedia:Copyright problems/Clerks based on the feedback received; Any thoughts or feedback much appreciated. It seems like there's broad support for the idea, and the conversation has generated some good ideas for implementation. :) Unless consensus swings against it, then, what I propose to do is implement that process. I'll alter Wikipedia:Copyright problems, which now says, "After the seven day listing period, an administrator will review the listing and take what further action may be necessary" to read "After a five to seven day listing period, an administrator or CP clerk will review the listing and take what further action may be necessary" (on specific directions for administrators, I'll note that articles flagged for deletion by the process should not be deleted before the seven day window, which allows for those occasions when permission is verified.) I'll make sure that the body is consistent with that, and I'll update {{copyviocore}} so that the "Do not restore or edit the blanked content on this page until an administrator or an OTRS agent has resolved this issue" allows for CP clerks. I do not have a group of identified admins to do the assessment yet, but can solicit volunteers if the idea overall meets approval. I also have not drafted Wikipedia:Copyright problems/Advice for clerks. It may be better to add a subsection to Wikipedia:Copyright problems/Advice for admins. Meanwhile, I have to go to work! --Moonriddengirl (talk) 13:20, 25 May 2011 (UTC)
I think it looks good; short, easy to read and understand while being structured well. Advice for clerks would be much similar to Advice for admins with the exception of "Handling copyright violations", "Closing the investigation" and "Images" (for the most part). More instructions could be added of course such as handling a report along with different templates, etc. I would not mind helping with this page. I think the clerk position can gain traction and SCV is a good place to try and recruit/assess new clerks.--NortyNort (Holla) 11:39, 26 May 2011 (UTC)

Redrafted header

Clerks seem to have broad support. :) Great. Thank you all for feedback. We should be able to implement them within the next few days. (The advice for clerks section has not yet been completed, but should be broadly similar to that for admins, sans tools.)

While I do not know if it will achieve consensus, I've redrafted the CP header generally. For years now, I've been hearing complaints about how difficult it is to follow, and this seems like a good opportunity to try to make it clear. (Also, we have Wikipedia:Copy-paste and Wikipedia:Plagiarism now; neither of those existed last time that header was overhauled. Some of that information can be removed, with links to those.) I've requested feedback on the revision at WT:CP and, of course, welcome one and all. It's not intended to change any practices at all aside from clerking--only to more accurately describe them, particularly with a mind to helping people who create articles on Wikipedia. To save extra clicking, the proposed redo is at Wikipedia:Copyright problems/Header redo, the original at Wikipedia:Copyright problems/Header. :) --Moonriddengirl (talk) 00:03, 29 May 2011 (UTC)

Proposal: Remove bot flag from inactive bots

Any bot that has not made a single edit within the past two years or, in the case of bots with sysop permissions, logged a single action within the past two years are subject to immediate stripping of their flag.

Pro: Throughout most of the MediaWiki software regarding any form of feeds, such as Special:RecentChanges and Special:Watchlist, edits under the bot flag are automatically hidden from view. Compromised bot accounts, with perhaps some malicious code accidentally inserted into their system, would most likely be able to surreptitiously damage several Wikipedia articles en masse without any administrators aware, since the bots have been inactive and the administrators would have ceased to watchlist their retired operators after a certain amount of time. Without the bot flag, any bots that could possibly be compromised would have their edits visually seen in RecentChanges, and sysops monitoring the page can more easily spot the pattern, block on sight and revert any potential damage dealt to articles the bot had edited. If bot operators choose to restart their bot, they can easily do it via the Wikipedia:Bots/Requests for approval process again.

Contra: Nothing that I'm aware of.

Special Main Page for newcomers

How about making 2 new main pages. 1 for IPs and 1 other for newcomers. I think that it would be useful to help out newcomers and IPs. ~~EBE123~~ talkContribs 19:45, 26 May 2011 (UTC)

Define newcomer. New user? IP visiting for the first time? And how are we supposed to direct them to these pages? Ajraddatz (Talk) 23:37, 26 May 2011 (UTC)
**scratches head** Logan Talk Contributions 23:39, 26 May 2011 (UTC)
An newcomer that its the first time. IPs all the time. I do not know how to get an IP but for newcomers, after that they registered, it gets them to that page. ~~EBE123~~ talkContribs 12:44, 28 May 2011 (UTC)
What do you see the point of this being? (That is, how would the two main pages differ and why?) Bear in mind that under the definition you give above, well over 99% of readers would be treated as "newcomers" (Wikipedia has ≈3,600 regular and ≈38,000 occasional editors, and the main page gets around 5 million hits per day), and that most regular editors rarely if ever see the main page. – iridescent 13:54, 28 May 2011 (UTC)
We have a main page? O_o But, yeah, ditto above. What this is essentially proposing is a new main page for registered accounts. So what would be different in it? —  HELLKNOWZ  ▎TALK 08:53, 29 May 2011 (UTC)

Conversational page to provide essential concepts, terminology for new users

I have drafted a page for new users to help them understand the concepts in a conversational tone, what items that would be included in a Wikipedia page, and with the intention to help them ease in to some of the technical areas. The pages are meant to reflect the strategy to make the WP community more inviting and welcoming.

The existing documentation is really great if one already understands how Wikipedia works and it's terminology. If someone is trying to learn a concept, getting bounced to links that provide a lot of technical information can be a bit confusing. I have posted the question on Welcome committee talk page, have not received a reply and am not sure if this is the better place to discuss this topic.

My request here is to ask if someone could take a look at the link for draft to determine if it's something that would be useful. Please bear in mind it's a work in progress, but hopefully there's enough there to evaluate it's potential usefulness.--Thanks so much!!!--CaroleHenson (talk) 18:43, 28 May 2011 (UTC)

Is the idea to provide a link to a document like this on the new user's talk page as part of the welcome or simply to include it as part of all the other Wikipedia: articles (where it might be hard to find)? It's probably just as important to decide how the document should be listed and communicated as seeing that it really contains the essential information for newbies in a clear and concise way. The idea appeals to me but it may be difficult to implement. Any ideas? - Ipigott (talk) 07:25, 29 May 2011 (UTC)

Suggested verbiage for responding to questions about deleted articles

I have also drafted suggested verbiage for responding to questions about deleted articles - to help people understand why the information might have been deleted and not offend the few who with a softer touch could become good community members - or at least not offend them so much that it leaves a poor impression of Wikipedia as a whole. Does this draft of verbiage for Standard text for inquiries about deleted accounts seem as if it would be useful?--CaroleHenson (talk) 18:42, 28 May 2011 (UTC)

There's some overlap with this page. Some of the Help Desk templates might be useful on user talk pages too. -- John of Reading (talk) 07:35, 29 May 2011 (UTC)
Yes, I see your point. The page, though, was intended to be used by people responding to questions about why the page was deleted. The most salient part being the suggested verbiage. I'm more than a little surprised at some of the communication that I've run across about deleted articles - which can sometimes be rude and offensive. Does that help clarify it a bit? Thanks!--CaroleHenson (talk) 07:50, 29 May 2011 (UTC)

Adding Dead url parameter for citations

Hi! Your comments would be appreciated at Wikipedia:Requests for comment/Dead url parameter for citations. —  HELLKNOWZ  ▎TALK 08:37, 29 May 2011 (UTC)

Sorry! We could not process your edit due to loss of session data

If I'm at a library, I naturally won't click where it says to stay signed in, but if I'm using a library database and adding a lot to an article from various sources, this can happen. Fortunately, I successfully copied and pasted before logging in again, but some people might not know they might lose what they typed if they do.

Either there should be a warning about that, or do what Fastmail does. They assure you that you won't lose anything, but you do have to sign in again. I frequently use emails as a notepad and don't think to periodically save them as drafts. One email service used to warn me I was about to be signed out; this might also be a possibility.Vchimpanzee · talk · contributions · 21:40, 25 May 2011 (UTC)

What's wrong with the back button? At least with Firefox it takes you back to the page with the form in precisely the state in which you submitted it, and I would expect it's the same with other modern browsers. So you can copy/paste after the problem has occurred. Hans Adler 21:51, 25 May 2011 (UTC)
This could be part of the message, if it's not already. But it has been my experience lately that if I do anything unusual, I lose what I was working on.Vchimpanzee · talk · contributions · 22:13, 25 May 2011 (UTC)
I have three minutes left at this library. The other one had so few people it wasn't limiting time. But their Internet went out and it's time for me to go home anyway.Vchimpanzee · talk · contributions · 22:16, 25 May 2011 (UTC)
I believe in the latest version of IE, for some reason the back button won't work in the way described (although it used to in older versions).--Kotniski (talk) 06:03, 26 May 2011 (UTC)
I do have IE9 at home, but at some point I reported having problems going back when I previewed, which is why if there's any chance I will follow a link or something after previewing, I'll just save so I won't lose everything. It's the same idea here.Vchimpanzee · talk · contributions · 15:53, 26 May 2011 (UTC)
The back button will also not work if one uses WP:WIKIED and will reset to pre-edited text. On the other hand, F5 to re-submit usually works. —  HELLKNOWZ  ▎TALK 16:46, 26 May 2011 (UTC)
Is any of the information here in the message someone gets if signed out while editing?Vchimpanzee · talk · contributions · 17:29, 26 May 2011 (UTC)
In Firefox, I just click Save again - done! --????
I've never had an issue with this, you sign in and you can then submit your edits. -- Eraserhead1 <talk> 11:29, 28 May 2011 (UTC)

How nice for you. But I don't intend to take any chances. And I don't imagine it works for everyone.Vchimpanzee · talk · contributions · 15:22, 30 May 2011 (UTC)

Regarding the requirement to create new pages

Sorry if this is not the correct page to ask this, but actually eswiki have now a discussion about the requirement of be registered to create new pages, i proposed that in eswiki due to some problems that I see in new pages, but I would like to know what are the reasons to need be registered in this wikipedia, perhaps are the same reasons, and can you tell me if this requirement help to resolve that problems? --Jorge 2701 (talk) 18:59, 28 May 2011 (UTC)

Enwiki requires registration to make a new articles since 2005, when it was enforced in the response to the Seigenthaler controversy. We are currently considering requiring wp:autoconfirmed before users can create articles (see this discussion). I have no idea what the problems with new pages for eswiki are, so I don't know if ours are similar. Yoenit (talk) 19:15, 28 May 2011 (UTC)
Yes, the decision was mostly made to protect wikipedia from lawsuits by living people. Can anyone find the discussion, or was that an executive decision by the board? Choyoołʼįįhí:Seb az86556 > haneʼ 19:18, 28 May 2011 (UTC)
According to the article I linked above it was a board decision. Yoenit (talk) 19:35, 28 May 2011 (UTC)
Thanks for replying, the problem in eswiki is that most of the pages created by IP users are removed, anyway how this discussion end? Is a lot of text and and I'm not so good reading in english =S, I just read the intro --Jorge 2701 (talk) 21:54, 28 May 2011 (UTC)
What was said there is that two thirds of the people that commented at that thread were in support of making autoconfirmed a requirement for creating articles, however a sizable number of people there demanded a trial be done first. As far as I can tell, no one has moved to set up the trial yet. Sven Manguard Wha? 00:20, 29 May 2011 (UTC)
Well, now we have User:Kudpung/RfC for trial (draft), if you'd like to look that over. The Blade of the Northern Lights (話して下さい) 08:23, 29 May 2011 (UTC)
Moved to User:Rd232/RfC for trial (draft phase). Rd232 talk 20:02, 30 May 2011 (UTC)

Media request page

Can we set up something similar to WP:BOTREQ, but for free media? I think a lot of times, users want to include an image (or other media) in an article, but may not have the necessary skills or software for that purpose. These users could request the creation of media for a specific article at that new desk. Someone with image editing software, audio editing software or video editing software could act on behalf of that request and create media. This media should then licensed under an appropriate license by the creator for uploading at Commons. I don't know if there were enough people willing to create such media or even if there were enough requests, but if there were, then that new desk would be a good place to centralize such requests.

Since our goal is to create a free encyclopedia, this would be beneficial for and in line with the overall mission of Wikipedia.

This could be run as a trial first inorder to evaluate, how the reception of this concept would be.

Just an idea from me. Toshio Yamaguchi (talk) 12:03, 27 May 2011 (UTC)

Are you aware of Wikipedia:Requested pictures? Yoenit (talk) 12:26, 27 May 2011 (UTC)
Thanks for the wikilink. However I think that's not exactly the answer to my request
  • WP:FFU is for those who whish to submit files, thus would be for those answering at the new page I am suggesting, not for those requesting there
  • WP:GL only deals with content that has already been uploaded
  • Wikipedia:Requested pictures is only a help page
  • {{reqphoto}} only categorizes requests
Therefore I think there is no page yet like the one I am proposing. And I think the page I propose would be useful, since it would follow the format used by WP:BOTREQ (which is more of a desk, like help desk or the reference desks). I welcome all critical comments on this proposal. Toshio Yamaguchi (talk) 12:55, 27 May 2011 (UTC)
Commons is the repository for free media, so shouldn't this idea be suggested there? We don't want free media on Wikipedia as someone has to manually move it to Commons so it can be used by the other projects. – ukexpat (talk) 16:58, 27 May 2011 (UTC)
"Wikipedia:Requested pictures is only a help page" - no, it isn't, look at all the subpage lists. It is just not commonly useful. Rmhermen (talk) 14:26, 28 May 2011 (UTC)
Commons already has similar pages: commons:Commons:Picture requests and commons:Commons:Audio and video requests. MKFI (talk) 11:35, 31 May 2011 (UTC)

appearance of scientific names in lead of species articles listed at their common names

I've created Wikipedia_talk:WikiProject_Biology#Consensus_how_scientific_names_are_displayed_in_the_lead_of_species_articles_listed_under_common_names to get an idea of whether we should streamline. Casliber (talk · contribs) 01:20, 3 June 2011 (UTC)

Good Article on Hold Template

Many articles are nominated as Good Articles and put on hold by reviewers. Reviewers leave a message on the talk page with a link to this list. However, many editors will not check the talk page and not know that the article is on hold. I wish to add this template to all articles which have been put on hold so that the message is on articles and talk pages.

The template is in my user space and is not yet in use. I wish to see if anyone would agree with this template being put into use. Oddbodz (talk) 08:46, 31 May 2011 (UTC)

What exactly does "on hold" mean here? I suggest that the words "on hold" should link to an explanation. -- John of Reading (talk) 08:51, 31 May 2011 (UTC)
I don't think this is a good idea. We don't want to clutter the article page with unnecessary stuff. There is not actually a problem, so a template drawing attention may not be needed. What you are trying to achieve is help from editors, but instead the 95% of readers will have their experience degraded. Graeme Bartlett (talk) 09:08, 31 May 2011 (UTC)
There really are not that many GANs on hold: Category:Good_article_nominees_currently_on_hold. WO:GAN#On_hold is placed while the nominator addresses the issues. Why do the readers (tag on article) need to be notified of this? Editors would only be notified (tag on talk) if they have the article watchlisted in the first place, but then they would have already known about the GAN. I think this is redundant to the category and the article tag is of interest to only a few editors. —  HELLKNOWZ  ▎TALK 09:34, 31 May 2011 (UTC)
I think editnotice would be more appropriate since it would not clutter up the article but it would still be seen by anyone trying to edit the article.MorganKevinJ(talk) 19:31, 31 May 2011 (UTC)
I support idea of an editnotice. Graeme Bartlett (talk) 23:39, 31 May 2011 (UTC)
  • Oppose, Nearly every article has at least one information box. It is good if there are some articles that don't have any! Normally the user only wants to read the article and doesn't know how to edit - and won't change if there is a new box informing the user. Normally the reader doesn't know what this information is about. mabdul 08:49, 4 June 2011 (UTC)

I noticed Wikipedia:Please use fullurl and, even though I think it may be outdated (as is mentioned on the talk page), it shows how fullurl can make really simple, clean diff and search url code. What if WP were to provide a fullurl code between to article versions on a diff page, or at the top of a search page? Surely it is better than bare URLs? Below is an example from that page. ▫ JohnnyMrNinja 11:21, 3 June 2011 (UTC)

[{{fullurl:{{FULLPAGENAME}}|action=edit}}]
Links to edit this page: [3]
Cf. User:TFOWR/easyDiff2.js. Ucucha 12:01, 3 June 2011 (UTC)

Increasing Wikipedia security

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
This discussion is superseded by the new RFC at Wikipedia:Village pump (proposals)/Account security. If necessary please take any points made here across to the RFC. Rd232 talk 16:52, 5 June 2011 (UTC)

Renewed activity notification

The primary aim of the admin-suspension proposal above is to improve security (though there are clearly secondary considerations about admins staying in touch as well). Are there any additional measures we can take to improve security for all accounts? I have a suggestion (the recent email notification system suggests this should be feasible). We could automatically email editors who return after 3 months' inactivity with a brief "welcome back" email - and include in the email something in the direction of "if you didn't edit recently, your account might have been hijacked; in this case please login and check your contributions and if you have any concerns, change your password". This behaviour would be the default, but it would be controlled by a Preferences setting, to change the inactivity time period, or to turn it off completely. The advantage of this is that once implemented (in software; in theory it could be done by bot in the interim), it just works, without anybody needing to do anything. Thoughts? PS To be clear, I support the above proposal on de/re-sysopping; this would be additional, and based on the logic that the best person to detect account hijacking is the person whose account it is. Rd232 talk 15:04, 1 June 2011 (UTC)

Facebook sends an email when a user returns after being away for a period of a month or more saying "Welcome back!" This lets the editor know that their account is being used, not directly warning them, but it would warn them if their account was hijacked. Facebook also sends emails when the wrong password is entered, saying "We see that you are having trouble accessing your account." These would both be good ideas for WP. ▫ JohnnyMrNinja 19:23, 1 June 2011 (UTC)
Supplementary thought: if it doesn't already, removing or changing a verified email address ought to send a notification to the old address. Rd232 talk 15:08, 1 June 2011 (UTC)
Asking people to check their contribs seems like asking a lot. Most people who wind up getting that notification might not even know what a contribution is. It might be simpler (though less liberal) to follow a more standard security model such as requiring re-verification after a certain period of inactivity in order to log in again. Equazcion (talk) 15:25, 1 Jun 2011 (UTC)
? They'd get a link in the email to Special:Contributions. Should be clear enough. Rd232 talk 15:39, 1 June 2011 (UTC)
Not a bad idea, but it probably ought to be handled as a separate proposal and not a subsection of the sysop-flag suspension proposal. 28bytes (talk) 15:45, 1 June 2011 (UTC)
Alright, I've split it off. Rd232 talk 16:15, 1 June 2011 (UTC)
...and FT2 has reverted you. (Hopefully accidentally and not as an attempt to derail the main proposal now that's it's finally getting considerable support.) 28bytes (talk) 19:14, 1 June 2011 (UTC)
Can't see this - if I've reverted anyone else's edit please do fix it :) FT2 (Talk | email) 19:40, 1 June 2011 (UTC)
I've resplit the related but distinct proposals. Rd232 talk 20:00, 1 June 2011 (UTC)

If we want to improve security, is there a way we can require MediaWiki not to accept passwords shorter than, say seven characters, and they must include at least one numeral and alphabetical character, too? /ƒETCHCOMMS/ 19:09, 1 June 2011 (UTC)

Yes, libraries such as cracklib which I mentioned above can do this (and a php interface for MediaWiki would probably be trivial), but as I also said, doing this wouldn't be popular with users because as much as we'd like to deny it, many users really like to use weak passwords :) --Tothwolf (talk) 20:05, 1 June 2011 (UTC)
Given that many other websites have similar systems set in place, and anyone arguing against password security probably needs a serious reality check, I think getting consensus for it won't be extremely difficult. Then again ... even Sarah Palin's password reset thing was tricked (why would you ever use your dog's real name or whatever it was?). I'm just glad MediaWiki doesn't have security questions, like "What was your mother's maiden name?" /ƒETCHCOMMS/ 21:24, 1 June 2011 (UTC)
In response to that incident, Yahoo did at least improve their password recovery system. --Tothwolf (talk) 01:55, 2 June 2011 (UTC)
@Fetchcomms, so password1 meets those requirements. That's not a wildly secure password. -- Eraserhead1 <talk> 23:10, 1 June 2011 (UTC)
Now that's a red herring... A password such as "password1" would not be allowed by cracklib. --Tothwolf (talk) 01:52, 2 June 2011 (UTC)
Even if it isn't required, why not use cracklib (or something like it) to inform users of their password strength? It looks like the license is compatible with WM, we could install it and try it out. It could be set to offer a real-time password strength test, or a warning similar to the no-edit-summary warning. I think requiring all users to use strong passwords might have too many variables to get consensus easily, but testing out a warning system shouldn't have much opposition. If it integrates well, we could move from there. ▫ JohnnyMrNinja 08:51, 2 June 2011 (UTC)
There's not too much point in requiring complex passwords for all accounts so long as we allow users to log in via non-encrypted connections. My guess is the computational cost of requiring https for everyone would be high. We're working through some of these issues at work, fwiw. My suggestions would be:
-Admin accounts be required to use https and complex passwords
-Normal accounts have a length requirement and cracklib check. I have seen web systems that use a red-yellow-green bar that provides visual feedback on password strength. We can likely get significant improvements in passwords just by showing users a visual indicator of their password strength.
-Provide email notification of renewed activity after 90 days of inactivity for accounts with more than X edits (I'd say 1000), idea being that light editors may have long periods of inactivity on a regular basis.
FWIW, --Nuujinn (talk) 10:23, 2 June 2011 (UTC)
Good ideas. Incidentally I use HTTPS Everywhere addon for Firefox to force use of the secure WP servers. I don't know if the same can potentially be done in software or with a Gadget (for admins On by default), but at least encouraging admins to use HTTPS would help (in combination with a decent password). Rd232 talk 14:03, 2 June 2011 (UTC)
I agree with Rd232, these are all good ideas. Requiring admins to have stronger passwords than new users is especially smart. We don't want to annoy new users by forcing them to come up with complex passwords when they're first registering, but we don't want admins to rely on weak "new user passwords" either. 28bytes (talk) 15:26, 2 June 2011 (UTC)
Security issues could be noted at Wikipedia:New admin school, which is very easy; plus in theory, as a one off following this discussion, every admin could be notified by bot (talkpage at least, maybe email too) to check their password strength. But I'm wondering too if we couldn't have the software email everyone when they get to 1000 edits (say), as in "well done! thanks! BTW, how secure is your password, etc - maybe consider checking against strong/medium/weak indicator here..." (presuming we get one of those, as we should). Rd232 talk 16:27, 2 June 2011 (UTC)
I've moved subsection "Admin account verification and admin know-how" before this section, as it only deals with admins. Anyway, I support sending a ‘welcome back’ email to users who resume editing after 90 days of inactivity (but I'd add an option in the preferences to disable it), I support warning users about insecure passwords but oppose disallowing them from using such passwords if they still want to (except for admins and possibly reviewers, rollbackers etc.), and I'm neutral wrt requiring admins to use the secure server. ― A. di M.​plé​dréachtaí 16:38, 2 June 2011 (UTC)
See this Signpost article where a researcher from the University of Cambridge commented about several password security aspects of Wikipedia. Since then, two of his "low-hanging fruit" suggestions to improve security have been coded into MediaWiki (password complexity checker: rev:70520, encrypt password transmission: rev:75585), but are not activated yet on Wikimedia sites (as far as I am aware). On the upside, Ryan Lane and other Foundation staff are currently working on a major overhaul of HTTPS access to Wikimedia sites (earlier announcement, preliminary test at [4]), which should resolve various issues with the secure server.
Regards, HaeB (talk) 02:17, 3 June 2011 (UTC)
If we are going to make https: more common then the all the components of the page loaded must alsop be https: At the moment there are several javascripts and images loaded with http: even when you logon with the secure protocol. These are a weakness because they leak out the referrer and cookie information. I attempted to disable some, but there were to many parts and cannot easily disable some javascripts such as the geolocator, and ad banner stuff. Graeme Bartlett (talk) 05:38, 4 June 2011 (UTC)

How weak exactly peoples' passwords are

Well, Lulz Security today announced that they hacked into multiple unprotected Sony databases and accessed passwords/addresses/names/emails/etc. of one million users. They released a sample of those, so let's see how weak peoples' passwords are: [6], [7], [8]. For heavens' sake, the issue here is not old admin accounts. It is old admin accounts with weak passwords. Desysopping only "solves" half the issue. We must have MediaWiki require stronger passwords (i.e., a certain length, including both numerals and letters, cannot include the word "password" or something—some idiots are still using that in the above links, FFS). Does anyone else think that such a mechanism must be implemented? /ƒETCHCOMMS/ 23:08, 2 June 2011 (UTC)

hand up. Should be... but how? Will there be a post upon login that says "Your old password has been rejected, please pick a new one"? There are currently 14 million accounts... just saying. Choyoołʼįįhí:Seb az86556 > haneʼ 03:04, 3 June 2011 (UTC)
It can be rolled-out, starting with admins/user right groups, moved on to new accounts... Then, yeah, ask them to change their password. After the Sony hacks, I don't think people would be surprised. ▫ JohnnyMrNinja 03:14, 3 June 2011 (UTC)
You should read up on Wikipedia:User account security and bugzilla:16435. It's important to note that some developers have actively called for users to use weaker, easier to remember passwords, as the value of most Wikipedia accounts is next to nothing. --MZMcBride (talk) 16:09, 3 June 2011 (UTC)
I have to agree, if a user who only makes a small number of edits wants to set their password to something pretty basic does it really matter? Making them have a more secure password is likely to discourage them from editing. Enforcing a stricter password policy on people with rollback or admin rights seems reasonable.-- Eraserhead1 <talk> 09:04, 4 June 2011 (UTC)
I read a paper a couple of years ago about enforced strong passwords having the obvious effect of people being unable to remember them, so they write them down, often in the dumbest places, like on a Post-it note on the side of their monitor. OK, that's not a problem that will be exposed by dramas of the kind experienced by Sony above, nor a big issue for Wikipedia, but obviously still not ideal. HiLo48 (talk) 09:13, 4 June 2011 (UTC)
"the issue here is not old admin accounts. It is old admin accounts with weak passwords. Desysopping only "solves" half the issue." I would add that this issue applies to all accounts, regardless of which permission bits the account holds. As Mr.Z-man pointed out above, removing the admin bit actually fixes nothing and only promotes a false sense of "security". --Tothwolf (talk) 18:41, 4 June 2011 (UTC)
Forcing users who only wish to make a small number of edits to have strong passwords might well discourage them completely, certainly I would be discouraged if the password requirements were very strict, and as HiLo48 points out then people might well write them down or do other things like that. Forcing some level of password security on admins, or on those with rollback rights would probably be a good idea in supplement to this proposal. -- Eraserhead1 <talk> 11:03, 5 June 2011 (UTC)

New RfC

I've started a new RfC with the advice of Rd232 (talk · contribs) about account security on the English Wikipedia. Discussion is welcome about adding new security features to Wikipedia's registration process (and dealing with existing accounts). The RfC is located at Wikipedia:Village pump (proposals)/Account security. I urge everyone who has participated here to comment, because it seems that this is a potentially serious issue, and many users are in favor of reducing security risks per the above desysopping thread. /ƒETCHCOMMS/ 03:35, 3 June 2011 (UTC)

Quick question - does WP require email validation to start an account? If not, I would at least recommend requiring email validation for Admins (maybe for user rights). Even if email contact for other users is disabled, we could validate a method of contact, so that they are sure to get those warning emails. ▫ JohnnyMrNinja 05:06, 3 June 2011 (UTC)
It is optional but highly recommended. MER-C 09:22, 3 June 2011 (UTC)
Ok, thanks. I think that I'll mention it at the RfC. ▫ JohnnyMrNinja 09:26, 3 June 2011 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Default edit summaries

Per a consensus discussion here to implement default edit summaries in the form of dropdown boxes Rd232 and I have been working on a script to do this. The script now seems pretty complete and I would appreciate some more testers making use of it. :)

My question is; what is the next step? Can this be added directly to common.js? or is this better as a gadget (and enabled by default)? We have approval for the idea, I just need approval on the technical aspects. (FWIW I prefer the gadget option because this allows people to disable it). --Errant (chat!) 09:04, 3 June 2011 (UTC)

Hi. I loaded the script, but when I choose "Reply" - my edit summary is " - Replay", is there a need for the hyphen or space? The Helpful One 10:52, 3 June 2011 (UTC)
Nope, I can remove that. The script is adopted from another Wiki so has some holdovers from there. Just about any tweak is possible at this stage :) --Errant (chat!) 19:37, 3 June 2011 (UTC)

See also, User_talk:NuclearWarfare#Make prompting for a missing edit summary the default  Chzz  ►  09:22, 4 June 2011 (UTC)

You may want to look at some hacking in my monobook.js that makes a half-hearted stab at replacing the section summary E.G. /* Default edit summaries */ if you have started a new section. Rich Farmbrough, 18:57, 5 June 2011 (UTC).

Preceding Unsigned Comment

It just occurred to me that there isn't really any good reason to have the sinebot add a small-text template instead of just substing in the user's signature, which I'm sure is possible. Of course we would still encourage people to sign their comments, but the small-text message seems to serve no purpose other than singling out newbies and providing negative reinforcement to get people to sign their comments. It's really quite ridiculous, jarring to look at, a strain to the eyes, and WP:BITEingly disruptive. Does anybody know why this was done in the first place? ☻☻☻Sithman VIII !!☻☻☻ 09:31, 6 June 2011 (UTC)

No bot could (easily) substitute in your actual signature, but it could guess at your signature (by assuming the default). On the other hand, the bot sometimes gets it wrong. This, I think, is the justification for making it obvious that they didn't add that signature. Whether it needs to be quite so obvious, I'm not sure. - Jarry1250 [Weasel? Discuss.] 09:39, 6 June 2011 (UTC)
How is it bitingly disruptive to try to get someone to sign their comments? I think it's completely appropriate to make it obvious. The biggest danger to me is having a bot that impersonates an editor, by putting in a person's signature and not making it obvious that the person didn't add it themselves. I don't think we should ever have a bot that makes edits that appear to have come from another editor no matter what the reason. -- Atama頭 17:32, 6 June 2011 (UTC)
Bot sometimes mistakenly sign comments when people re-add comments by others (i.e. [9]), which is why it (quite properly) uses the "unsigned" template. –xenotalk 18:11, 6 June 2011 (UTC)

Formal proposal to put Featured Lists on the main page from 13 June:

A proposal (and poll) is currently in place on Talk:Main Page#Formal proposal to put Featured Lists on the main page from 13 June to have Today's featured list appear on the Main Page each Monday. The proposal will run until 23:59 UTC on Saturday, June 11. — Edokter (talk) — 11:33, 6 June 2011 (UTC)

Connecting Wikipedia to Spoken-Web

Hi all,I developed a new site to help and serve the blind or visually impaired community by making the web more accessible to them.

[2]http://www.spoken-web.com Using this site, a person who is blind or who has a visual impairment can hear the full range of any wikipedia article content, provided in a logical, clear, and understandable manner.

I thinking about better ways to connect between Wikipedia articles to spoken-web site. such as a link from any wiki page direct to the spoken version of the article

Benefits:

  1. Up-to-date - The spoken version is been generated on-the-fly, so it always be the most updated one
  2. Faster - The text-to-speech engine is on the client computer
  3. Economical - spoken versions for all 2.8 million articles would not take any space

--Eyalshalom (talk) 15:56, 6 June 2011 (UTC)

Disadvantages:

  1. For the meanwhile (money issues) the site available only in English, and the technology requiered IE browsers and Windows Operation System
  2. Text to speech engines often sound quite... unnatural when they synthesize speech (but there is a solution for this too)

--Eyalshalom (talk) 15:57, 6 June 2011 (UTC)

About

[3]Spoken-Web is a web portal, managing a wide range of online data-intensive content like news updates, weather, travel and business articles for computer users who are blind or visually impaired. The site provides a simple, easy-to-use interface for navigating between the different sections and articles Using the keyboard to navigate, a person who is blind or who has a visual impairment can hear the full range of an article content provided in a logical, clear, and understandable manner.
Spoken-web is non-profit organization. --Eyalshalom (talk) 15:54, 6 June 2011 (UTC)


  • Spoken Web was founded at 2006 and had wiki ref since 2008.IBM started World Wide Telecom Web project at 2008 and they changed the wiki page (you can see it in the history of the page).

but this is not the point here--Eyalshalom (talk) 18:55, 6 June 2011 (UTC)

All rated articles by quality and importance
Quality Importance
Top High Mid Low ??? Total
FA 1,577 2,503 2,415 1,960 181 8,636
FL 181 688 768 701 101 2,439
A 370 681 788 584 91 2,514
GA 3,246 7,381 14,816 19,703 1,761 46,907
B 16,993 32,960 54,650 69,722 23,459 197,784
C 16,992 54,337 136,027 312,788 92,422 612,566
Start 18,536 92,520 417,162 1,631,565 413,829 2,573,612
Stub 4,282 31,462 278,033 2,808,556 763,021 3,885,354
List 4,888 17,232 54,096 195,491 69,499 341,206
Assessed 67,065 239,764 958,755 5,041,070 1,364,364 7,671,018
Unassessed 122 480 1,238 17,031 407,138 426,009
Total 67,187 240,244 959,993 5,058,101 1,771,502 8,097,027
About this table
The current assessment system.
This proposal would add a new row in the table, "FM" (Featured Media).
Alternatively, several new rows could be added, e.g. "FP" (Featured Pictures)
and "FSV" (Featured Sounds and Videos).
No change to the underlying assessment processes WP:FP etc. is involved.

I would like to suggest creating a new class for featured media. This new class would be for Featured Sounds, pictures, videos (currently listed under featured sounds) and potentially topics. I believe that Wikipedia now has enough featured media that a category and class would be beneficial but since these content types have relatively few items individually I do not think we need separate categories for each. Currently some of these are tagged as File, however this would give us a better understanding of what media is currently featured.

I have already spoken to CBM who programs the bot that updates the assessment tables and he indicated that it could be done.

A few notes about the idea.

  1. Will help us identify the featured media so we can start identifying other media that could be promotable to featured status.
  2. Will allow projects to see if one of these is deleted, recommended for deletion or demotion, etc. via the Article alert bot
  3. Will help promote the use of our featured media
  4. There are currently about 364 featured sounds/videos.
  5. there are about 2747 featured pictures --Kumioko (talk) 02:13, 23 May 2011 (UTC)
I don't understand. What's a new "class" supposed to be? A new namespace? Cambalachero (talk) 02:25, 23 May 2011 (UTC)
Sorry I should have been more clear. A new class for article assessments. Currently we have A, B, C, GA, FA, FL, List, Start, Stub, File, Template, Category, and a couple of others. So basically we can identify a featured article and a featured list but not featured media (pictures, sounds, etc.) that only way to know its featured is to click on it. --Kumioko (talk) 02:32, 23 May 2011 (UTC)
  • Support, merging the current featured sounds, pictures, etc. into a new large-scope class, similar to FA, is an excellent idea. —[d'oh] 03:23, 23 May 2011 (UTC)
  • Sounds good. I wonder though if we shouldn't plan ahead a bit and make Featured Pictures a separate class. Otherwise, in 5 years' time we might have to split the category. AFAIK categories with no content don't appear in the assessment summary box, so most of the time, with so few multimedia, this wouldn't mean an extra category, since most projects would only have Featured Pictures. Rd232 talk 04:15, 23 May 2011 (UTC)
I suppose thats true. There is a lot of content out there that could be featured the problem is we don't have a very active promotion system for non pictures. The videos and sounds never seemed to get going so thats why we only have a few. --Kumioko (talk) 13:27, 23 May 2011 (UTC)
Actually, featured sounds seem to be growing in number lately. --Another Believer (Talk) 03:54, 24 May 2011 (UTC)
Thats great, I admit I don't actively watch those pages but I suspect if we created a class that might help to increase visibility of this type of content. --Kumioko (talk) 16:03, 24 May 2011 (UTC)
Well, I'd rather have one Featured Media category than not be able to decide and end up not doing anything... Rd232 talk 17:11, 24 May 2011 (UTC)
Since the assessment classes are 'owned' by the WP:1.0 team, their input would be useful here. WhatamIdoing (talk) 20:48, 26 May 2011 (UTC)
It's rather easy to do, and I don't see how it could harm WikiProjects (aside from the up-front assessment work, but even that wouldn't be too hard). The main question I have is how we would handle images on Commons—if they get deleted there, we can't pick that up in the local deletion log. Titoxd(?!? - cool stuff) 21:09, 26 May 2011 (UTC)
There is User:CommonsNotificationBot. Rd232 talk 01:39, 27 May 2011 (UTC)
Thats a good point on Commons. I don't know what the best approach would be for associating commons files with a WikiProject myself. I had added the WikiProject US banner to several images that were commons images and other users came along and deleted the WikiProject banner so I stopped adding it to Commons related files. --Kumioko (talk) 01:11, 27 May 2011 (UTC)
The simplest would be to create the equivalent talkpage on Wikipedia and tag that. Rd232 talk 01:52, 27 May 2011 (UTC)
I misunderstood the proposal, therefore this answer is off topic. Sven Manguard Wha? 17:23, 27 May 2011 (UTC)
The following discussion has been closed. Please do not modify it.
  • Oppose FP/FS merge This would be a mess. Featured Sounds has clearly defined and high standards. Featured Sounds has poorly defined and admittedly iffy standards. Videos are accepted into Featured Sounds on the primarily on grounds of their audio quality, however often enough the video quality is sacrificed to improve the audio, leaving something acceptable for a Featured Sound but not so much for a Featured Media. The two areas, FP and FS, would not merge well together, I don't think. Sven Manguard Wha? 22:02, 26 May 2011 (UTC)
  • Strongest Possible Oppose for including FT as part of any of this! It's hard for me to comment on this component of the proposal without being rude or condescending. FT has nothing to do with media. If you want to merge off FT, which is something I don't see any reason for, merge it with a Featured Books process to create a "Featured Collections" entity. Do not, however, merge it with media. If merging FP and FS does go through, it should only be for the top items in the file namespace, period. Sven Manguard Wha? 22:02, 26 May 2011 (UTC)
I think the proposal is getting confused a little so let me clarify the intent a little. The purpose of this proposal is NOT to merge FP, FS or even FT's. What it does is add a "Class" for featured media to the WikiProject assessment tables. Currently we have Featured Article and Featured list but nothing for pictures, video, sounds or topics. All we can do is lump them under File. I would be ok with creating separate classes for each however I just don't think we have enough content built up in those yet to warrant seperate classes for each one. --Kumioko (talk) 01:11, 27 May 2011 (UTC)
Yep. I've added an assessment table - a picture's worth a thousand words. Rd232 talk 01:42, 27 May 2011 (UTC)
Thank you that did help to explain things. --Kumioko (talk) 13:17, 27 May 2011 (UTC)
Thats fine, that was always sort of a maybe anyway. --Kumioko (talk) 16:45, 27 May 2011 (UTC)

I updated several more files relating to adding the new class but Template:Cat class is protected and I cannot change it. I think this is whats causing it to not work properly. --Kumioko (talk) 02:42, 7 June 2011 (UTC) I think were gonna need to update Template:Class mask also. --Kumioko (talk) 02:56, 7 June 2011 (UTC)

That shouldn't be the problem. The banner template for WikiProject United States is not populating the Featured Media category for the project, so the bot is not picking it up. However, {{Cat class}} is a display template, which does not affect how the categories are populated, and {{Class mask}} was edited here already. Titoxd(?!? - cool stuff) 03:15, 7 June 2011 (UTC)

All I get is NA class if I put in fm or File class if I put in Featured Media. Is anything different supposed to appear? Is there an example of a successfully parsed fm class file? Since this is a featured class shouldn't it be standard for all projects? --Guerillero | My Talk 06:29, 7 June 2011 (UTC)

If you are using WPBannerMeta, you need to modify your WikiProject's banner in order to accept FM-Class as a valid option (see example). You can request assistance at Template talk:WPBannerMeta and one of the friendly people there may do it for you. As for FM being a standard class, I think so as well (or at least included in the extended assessment scale), so you can voice your opinion about that at WPBannerMeta talk too. Titoxd(?!? - cool stuff) 21:15, 7 June 2011 (UTC)
WikiProject US is working now. I'm not sure if someone else modified something to make it work or if the servers just needed to catch up but the bot is picking them up now. --Kumioko (talk) 23:15, 7 June 2011 (UTC)

Interesting concept. I like the idea of keeping track of project files although not sure how to automate this with Commons content. For Wikipedia:WikiProject Turtles, I actually just made a little manual montage of all the featured pictures on the topic (from WP or from Commons). So, I think it's something that I can see Projects wanting to track or liking to put up on their sites to intrigue visitors, motivate file work, etc. See here: Wikipedia:WikiProject Turtles/Turtles Featured Pictures.TCO (talk) 03:02, 8 June 2011 (UTC)

Aren't most featured media files stored on Commons? The existing system (and its associated bot) doesn't index files that not directly on the English Wikipedia. It'd be a little weird to have groups of en.wiki volunteers imposing our internal assessment scheme on Commons. WhatamIdoing (talk) 00:47, 10 June 2011 (UTC)
I don't think that matters. AFAIK every image file has a local talk page, even if the file is on Commons. Rd232 talk 01:04, 10 June 2011 (UTC)
I think your both correct. --Kumioko (talk) 01:49, 10 June 2011 (UTC)

Uw-3rr, ANEW, and WP:Don't template the regulars

I've noticed that the line "diff of 3rr warning" in each ANEW report encourages templating of experienced or semi-experienced editors. Thus I am proposing that a template for experienced users be made for the purposes of 3RR warnings.Jasper Deng (talk) 22:37, 27 May 2011 (UTC)

WP:DTTR is a mindbogglingly stupid page. Regulars should be templated; it's newbies who should be handled more carefully. I see absolutely no reason why experienced editors in an editwar--as in, people who should know better--should be treated nicer than people who may or may not know the rules. → ROUX ₪ 22:41, 27 May 2011 (UTC)
I dunno; you're assuming that the individual, personalized message left is kinder and more pleasant than the template. I have the impression that the opposite is frequently true, especially for people who are dealing with basic vandals on the WP:Recent changes patrol. There's a limit to how many times most of us can say craft friendly notices that amount to, "Please stop adding 'I LOVE CHEESEBURGERS!!!!' to articles" before we lose our tempers.
I think the point behind DTTR is that templating an experienced person is unnecessary, and likely to offend the recipient by failing to acknowledge his 'status' as a part of the community. Besides, someone like you and I doesn't need a link to the usual explanatory pages for the typical warnings; we're not going to wonder what "Knock off the edit warring already" or "Quit spamming your blog into articles" means. WhatamIdoing (talk) 23:27, 27 May 2011 (UTC)
Agree with ROUX: DO template the regulars. Choyoołʼįįhí:Seb az86556 > haneʼ 23:59, 27 May 2011 (UTC)
That's exactly the point though; there shouldn't be status like that. People who know better should be held to a higher standard; the inverse of this means we should be taking the time to not template newbies (blatant vandals excluded; they know exactly what they're doing and should be treated accordingly), whereas regular editors deserve to be told "I can't be bothered to write out something by hand for you, because you should know better already. → ROUX ₪ 00:06, 28 May 2011 (UTC)
I find DTTR valuable for this notion: "A personal message tends to work better in these situations. If you have a question, why not ask the experienced user your question? You may begin a dialogue that will prove much more effective than a template." With an experienced editor it's much, much more likely they've either made a mistake or that I'm missing the reason behind their actions. A question is more helpful in this case than a template. --NeilN talk to me 00:08, 28 May 2011 (UTC)
Agreed with Roux. I don't follow DTTR at all. Mind you, that's because I work in files and I have to inform people when their files are up for deletion. Still though, as I resize non-free files, I get non-free orphaned image templates regularly enough. Experianced editors should be expected to notice the template, take appropriate action, and dispose of the template when it is no longer needed. It's what I do, and I really don't get what all the whining about template messages is about. Sven Manguard Wha? 01:07, 28 May 2011 (UTC)
I do not follow it either and User:Roux made a good point, but people want me to follow it, like User:Orangemarlin that yelled at me after. ~~EBE123~~ talkContribs 13:25, 28 May 2011 (UTC)
@NeilN: Personal messages are fine too, but when you have to deliver dozens upon dozens of messages in a reasonable period of time, templates are efficient, civil, and for the most part unambiguous ways of doing that. Sven Manguard Wha? 01:12, 28 May 2011 (UTC)
While you do get complaints for doing so I find templating users 3rr warnings to be useful as it gives them all the dispute resolution information in one easy to see space.
Though as you do get complaints for using the template on regulars possibly a workable compromise would be to add another template with similar information, but without the warning symbol and stuff. -- Eraserhead1 <talk> 13:28, 28 May 2011 (UTC)
Could add a |regular=yes parameter to adapt the template message appropriately. At the end of the day "DTTR" is primarily about not insulting oldtimers by acting as if they're newbies, not about not using standard messages. Rd232 talk 13:49, 28 May 2011 (UTC)
Good idea. Then all we need to do is get it up and running in Twinkle, but that shouldn't be too hard. -- Eraserhead1 <talk> 17:26, 28 May 2011 (UTC)
It would require extensive editing of the uw warning templates, but, I feel it'll make the project run more efficiently. User:AzaToth, developer of Twinkle, has been notified.Jasper Deng (talk) 19:15, 28 May 2011 (UTC)
Frankly solving the problem for the 3rr template would solve 90% of the possible issues with templating the regulars. Usually the others aren't particularly useful with regulars anyway. -- Eraserhead1 <talk> 19:33, 28 May 2011 (UTC)
Well then maybe we shouldn't complicate all the templates, especially as it's probably best to start from scratch for regulars, rather than build from the newbie version. How about something in the direction of {{Uw-3rr-resolve}}? Rd232 talk 22:07, 28 May 2011 (UTC)
That'll be nice - except, we don't want to sound too nagging.Jasper Deng (talk) 03:22, 30 May 2011 (UTC)

You will not 'solve' DTTR by changing the wording of a template. The reason that you should not template regulars is that templates are designed for clear cases. For example, {{uw-ew}} is great - but only if edit warring is obvious. Regulars know the rules, and they are not going to be doing anything they believe violates the rules of the project. Templates say "You are violating rule X, stop." - some as bluntly, others more politely. Experienced users are extremely likely to have a reason they believe their action is justified. Applying a template in such a case is going to come across as very rude. Write a personal note. Obviously this problem wouldn't a apply for things like not including sources in images, in that case a template would be fine for any user. Prodego talk 05:20, 31 May 2011 (UTC)

How about something like {{Uw-3rr-resolve}}? Rd232 talk 09:54, 31 May 2011 (UTC)
I'm not going to write a personal note for edit warring that contains the appropriate dispute resolution links, which the user may not know. Even for clear edit warring you get shit for using the standard template. -- Eraserhead1 <talk> 06:37, 31 May 2011 (UTC)
Why not leave a personalized message asking that they cease edit warring, followed by the template, followed by a report to 3rr. If they are really a regular, and don't have a history of tendentious editing, why not AGF instead of rushing to meat the threshold to report them? Monty845 18:29, 31 May 2011 (UTC)
Personally I wouldn't bother giving them a message until the 3rd revert, at which point its a bit of a stretch to assume good faith - and giving them a link with all the resources is useful for them - we all get angry from time to time and over-revert. -- Eraserhead1 <talk> 20:35, 31 May 2011 (UTC)
There's a reason why TW does not provide uw-3rr1, uw-3rr2, uw-3rr3, and uw-3rr4.Jasper Deng (talk) 04:13, 1 June 2011 (UTC)
I never mind being templated if the template applies. I'd rather get a template than no notification at all. One reason why I like templates is that they're neutral, they help avoid the appearance of canvassing and could be less offensive than a personal note that might rub someone the wrong way. I try to follow DTTR when I can remember to, but not because I believe in it, but rather because "we're supposed to". I do often use a personal note when a template is available, but it's because I want to convey something in a way other than the template, or want my message to be more personable. But I do the same with newbies and regulars alike and don't discriminate. -- Atama頭 17:46, 6 June 2011 (UTC)
The way I see it, it all depends on which template. Obviously the "if you're new here and didn't know it" forms of templates are patronizing when used on an editor with a few hundred edits. On the other hand I think the emotionally-neutral tone and clear progression (you could be blocked, you will be blocked, do it again and you're getting blocked) are of great value in dispute resolution. HominidMachinae (talk) 20:09, 9 June 2011 (UTC)

Proposal for a "timeline" layout

First, apologies if this is wildly against policy/misformatted -- not a regular ;) I've noticed a lot of sections have a lot of one sentence paragraphs that go "On [date] thing X happened." one after another. I think adding a CSS style to support a timeline would be easy, and such articles could really benefit from the new formatting (I can't speak as to the wikimarkup side of things). Here's an example of this kind of page: Auction Rate Security#2008 auction failures — Preceding unsigned comment added by Felipeochoa0918 (talk • contribs)

  • Personally, I find "On date X, Y happened" entries to be nothing more than lazy writing. Unless a section is specifically intended to be a timeline, the proper solution is to turn these entries into proper paragraphs. Resolute 16:24, 5 June 2011 (UTC)

There was a discussion a while back about some kind of graphic network tool that would make nicer/easier Ahanentafeln (sp?), taxonomies, etc etc. Might be worth digging for that. Rich Farmbrough, 19:00, 5 June 2011 (UTC).

Some articles in quieter backwaters tend to build up a timeline peacemeal, because an editor will see some news on the subject in a source, and add a few words covering just that news, then a few months later another similar edit is made, over and over again - so the article gradually accumulates a chronological sequence of awkward bullet-points even when it's a subject which would be better off with a single, carefully-written paragraph. I'm wary of encouraging the development of such timelines when a better solution would often be to invest slightly more effort in writing a single block of prose. bobrayner (talk) 23:25, 5 June 2011 (UTC)

For the relevant essay, see WP:Proseline. —Mike Allen 01:39, 6 June 2011 (UTC)

Are you referring to something like this currently used on the Commandant of the Marine Corps article?:
James F. AmosJames T. ConwayMichael HageeJames L. JonesCharles C. KrulakCarl Epting Mundy, Jr.Alfred M. Gray, Jr.Paul X. KelleyRobert H. BarrowLouis H. Wilson Jr.Robert E. Cushman, Jr.Leonard F. Chapman Jr.Wallace M. GreeneDavid M. ShoupRandolph M. PateLemuel C. Shepherd Jr.Clifton B. CatesAlexander VandegriftThomas HolcombJohn H. Russell, Jr.Ben Hebard FullerWendell Cushing NevilleJohn A. LejeuneGeorge BarnettWilliam P. BiddleGeorge F. ElliottCharles HeywoodCharles Grymes McCawleyJacob ZeilinJohn Harris (USMC)Anthony GaleArchibald HendersonFranklin WhartonWilliam Ward Burrows ISamuel Nicholas


Its not the simpest thing to use I admit but it does work.--Kumioko (talk) 16:47, 6 June 2011 (UTC)

There's a very useful timeline, that unfortunately suffers from formatting problems (as well as using whole years rather than specific dates) at Timeline of Presidents of the United States. Before joining Wikipedia, I'd independently constructed something similar on MS Excel (to show how many former and future U.S. Presidents coincided with any president's term), but I haven't figured out if there's a good solution for this page. —— Shakescene (talk) 21:30, 6 June 2011 (UTC)


Often, the string of dates is a blow-by-blow description of events written while it was breaking news. Dramatically shortening such things often results in more encyclopedic descriptions.
WP:Graphs contains information on making timelines. WhatamIdoing (talk) 01:33, 10 June 2011 (UTC)

More discreet banners

Hi, I would like to suggest that the banners that appear at the top of so many articles ("needs additional citations", "neutrality is disputed", etc. etc.) are made smaller (while still being noticeable). The ones we have now are better than a few years ago, but they are still big, blocky and ugly, and give the impression that most of Wikipedia is in a perpetually broken state. 86.181.172.159 (talk) 03:08, 6 June 2011 (UTC).

That's because most of Wikipedia is in a perpetually broken state. They are big and ugly for a reason; readers (the people these articles are written for) must be made aware when there are problems with articles, particularly when those problems have to do with reliability and sourcing. Their large ugliness is a feature, not a bug. → ROUX ₪ 03:29, 6 June 2011 (UTC)
Yea, god forbid we attribute one iota of intelligence to our readers. Gotta watch out for there best interests and well-being, don't you know? Can't have people reading things that we don't like, after all.
— V = IR (Talk • Contribs) 03:39, 6 June 2011 (UTC)
IN addition to this I would like to suggest that we calrify the rules of using some of these templates to say they are not needed on stubs. If an article is a stub there is almost no reason to put a Cleanup, expand, wikify or several others on the article. These are self evident by the class of the article. Some such as Ref needed, ref improve or the BLP tags would and should still be allowed though IMO. --Kumioko (talk) 16:42, 6 June 2011 (UTC)
You can already use {{multiple issues}} to merge these banners together. I agree that they should be smaller, at least for me as they are just a nuisance when I'm trying to read an article, so I shrink them with this script. Gary King (talk · scripts) 20:04, 6 June 2011 (UTC)
You know Gary thats an excellent point. Rather than trying to choose a one size fits all scenario why don't we see about adding that script as a preference Gadget that allows people to decide for themselves if they want the banners smaller. Some may and some may not and either way is fine but we should be allowing the users to decide how they want to see them. --Kumioko (talk) 20:15, 6 June 2011 (UTC)
Certainly at least the POV template should be big. -- Eraserhead1 <talk> 20:16, 6 June 2011 (UTC)
Clean up templates do not exist to "warn the reader" about anything. Our readers are smart enough to look over an article and notice that it doesn't name any reliable sources, or that the formatting is awful, or any number of other things that we template for. Templates exist so that people (including readers that we'd like to turn into new editors) will solve the problems.
IMO we need to write a guideline that explains the purpose of templates and addresses their abuse, rather than repeating the basic instructions (like "not a badge of shame" and "may be removed by any editor") on individual template's doc pages. WhatamIdoing (talk) 01:38, 10 June 2011 (UTC)
You'll probably like this banner I saw the other day: Voyager640 (talk) 08:16, 7 June 2011 (UTC)
I love that banner, and I'll be sure to use it on every page I read that doesn't meet Featured Article standards. Regarding my script that I mentioned above called Smaller Templates, all it does is it removes the icon from from these templates, then shrinks the text down to about 75%, and removes the "descriptive" text so only the bold text remains (and it unbolds it), so that you can still read and understand the template fine, but it takes up much less space. Gary King (talk · scripts) 18:33, 7 June 2011 (UTC)
I find that banner offensive. People who volunteer their time to this project do not have an obligation to fix every problem they see and often the problems that can be tagged by a person, cannot be fixed by that same person for many reasons. That's for "passive taggers" but more importantly, the people who do most of the "drive-by tagging" are the dedicated new pages and other patrollers, who do a critical, mostly thankless task, and to say that they could remediate the problems in the articles they tag rather than do the tagging is so unrealistic that there's little to say on the matter.--Fuhghettaboutit (talk) 23:59, 8 June 2011 (UTC)
Your criticism cuts both ways, though. People who create new articles are not obligated to create featured articles right out of the gate. Plastering our articles with all sorts of warnings in the readers faces makes all of us who contribute here look silly, at best. All other maintenance issues are dealt with on the talk page, and for good reason. Readers aren't stupid, and our behaving as though we can't trust them to realize that our content comes with caveats that have been well covered over the previous 10 years is rather insulting to them and to authors and editors. Nobody who is interested in actually improving articles is suggesting that maintenance categories, and the work at clearing the backlogs, should be stopped; the reason that this is a perennial point of discussion is that contributors don't want their contributions besmirched with warning tags, is all. You're asking for consideration, but failing to acknowledge how you're not giving consideration to others yourself.
— V = IR (Talk • Contribs) 00:35, 9 June 2011 (UTC)
Let's separate out the template above from what you're saying. Say I agreed with you on all fours. I would still find that template offensive for the same reasons I just gave. That template doesn't make your points, it just attacks with a massive brush the entire cadre of editors who tag any article with any maintenance template whatsoever. Putting that aside, I always find the idea that any reader would be insulted by seeing these templates silly, as if they were directed against them specifically; that's what insults people, not notices on articles they land on that on their face are directed at no person in particular. Meanwhile, you're demonstrably wrong that there aren't large numbers of people who actually aren't aware of the "caveats". We often see users at the help desk here, for example, and in other places all over the net, who have no idea and actually assume our articles consist of vetted content, written by a central authority of experts. But you're right that large numbers of people also do know the general caveats, and it's a far larger percentage than those who don't. But this is a side issue, because the caveats about our content are unspecific and do not make the targeted tags any less important or invalid. People hear that Wikipedia content can be added by anyone and that its unreliable and statements in that vein, but that does not translate to knowing specifics, like that some articles have cited sources and some do not; that articles with lots of inline citations are almost always much more reliable than the reverse of that coin; that if all the sources in an article are primary sources the article is probably POV, and on and on. Articles which are unreferenced, poorly referenced, non-neutral, etc. should not be relied on; people coming to these articles should be told in no uncertain terms—not on the talk page—but right up front, that the article has certain specific problems. Taking the general caveats to the specific to inform the public's reading is only one function. Another is to hope that action is actually taken by someone who cares about the subject; the templates are a guide for suggesting the action that is actually needed, and it won't act to inform but a few if hidden on the talk page. Neutral, balanced, comprehensive, well sourced articles containing no original research need no tags. Until they are well on the path to that stage, flagging problems they actually have is not "besmirching" them.--Fuhghettaboutit (talk) 04:50, 9 June 2011 (UTC)

I assume that none of these comments are directed at me in particular, but just in case, my last comment above was meant to be sarcastic (the first sentence). Gary King (talk · scripts) 19:55, 9 June 2011 (UTC)

Show blocked users gadget

Russian Wikipedia has a Gadget to show blocked users, which I've been using for a while.

add

importScriptURI('http://ru.wikipedia.org/w/index.php?title=MediaWiki:Gadget-markblocked.js&action=raw&ctype=text/javascript');

to Special:Mypage/Skin.js.

Proposal: import the Gadget, and add it to Preferences as an actual Gadget. Rd232 talk 16:52, 6 June 2011 (UTC)

That would be really handy, I usually look at an editor's contributions to see if they're blocked. Seeing it right away would be great. -- Atama頭 17:33, 6 June 2011 (UTC)
How about using User:Gary King/userinfo.js instead (I forked the script from User:PleaseStand/userinfo.js; the original author has been busy and therefore unable to implement bug fixes, updates, etc.), which shows more than just blocked info, but also the user's groups, number of edits, last edited time, etc. The documentation is here. Gary King (talk · scripts) 19:09, 6 June 2011 (UTC)
That's good, but it only displays block status when on the user or user talk page. The Russian markblocked script puts a line through a username wherever it appears, if the user is blocked. Rd232 talk 19:23, 6 June 2011 (UTC)
Ah, didn't realize that. Y'know, a number of scripts with similar features can probably be combined so that we have fewer gadgets. Gary King (talk · scripts) 19:31, 6 June 2011 (UTC)
I'm sure that's the case, and that would probably be helpful both in general and in this case (though how the extra complexity of scripts vs fewer scripts would affect maintainability I'm not sure). On a related note, others may be interested in the conversation at MediaWiki_talk:Gadgets-definition#Gadget_tab_structure about restructuring the Gadget tab to be more user friendly. Rd232 talk 19:34, 6 June 2011 (UTC)
The scripts don't even have to interact with each other if we don't want them to. They can just be "packaged" together; it's somewhat similar to using importScript once for Twinkle rather than half a dozen times for each of its components (although in that case, each script is dependent on others). Gary King (talk · scripts) 20:00, 6 June 2011 (UTC)
For what its worth I am going to suggest to the AWB developers to line out blocked users as well if AWB is being used to add comments to talk pages. --Kumioko (talk) 20:28, 6 June 2011 (UTC)
"line out"? "strike out" or "line through" - pick one :P ... Yes, could be useful addition to AWB. Rd232 talk 21:31, 6 June 2011 (UTC)
I oppose that (the AWB thing) as strongly as possible. AWB has no way of sensing when a comment was added; are you seriously suggesting that because a user happens to have accidentally crossed the 3RR line and earned a 24 hour block, you want to strike through every comment that user has ever made? If I see anyone refactoring talk comments in this way, I'll have no hesitation at all in blocking for disruption. – iridescent 21:55, 7 June 2011 (UTC)
Irridescent I'm going to assume AGF that you did not just imply that if "the AWB thing" is put into effect by consensus of the Community that you will go around blocking individuals who do it? And as an administrator your "threat" can be seen as trying to intimidate, threaten, and unduly influence future discussion and implementation. Your personal views against this proposal are one thing, your threats of blocking individuals is a little overbearing. A clarification of your opinion and perhaps striking through your threats of blocking may be something you might want to consider as a good faith move right now.Camelbinky (talk) 22:23, 7 June 2011 (UTC)
I understood Kumioko to be talking about indicating to AWB users when an editor is blocked, by marking up the text shown to the AWB user (i.e. an equivalent of the JS script). Saving strike-through into Wikipedia is obviously undesirable. Rd232 talk 22:40, 7 June 2011 (UTC)
The script is listed at WP:JS, which links to User:NuclearWarfare/Mark-blocked script.js, which links to the Russian one. However I did find that calling up the Russian one did slow page loads down (I could see FF was waiting for ru.wikipedia), so I copied the whole thing to User:Ronhjones/strikeblocked.js and then called that from my monobook.js with an importScript('User:Ronhjones/strikeblocked.js'); - which has improved the page loads.  Ronhjones  (Talk) 22:29, 7 June 2011 (UTC)
Cool, thanks. Now how about making this a gadget - or perhaps bundling it with an existing gadget, as Gary King suggested above? Rd232 talk 10:24, 9 June 2011 (UTC)
  1. ^ http://wiki.wetpaint.com/page/Wiki+Future
  2. ^ http://www.spoken-web.com. Retrieved 6 June 2011. {{cite web}}: Missing or empty |title= (help)
  3. ^ http://www.spoken-web.com/index.cgi?p=about. Retrieved 6 June 2011. {{cite web}}: Missing or empty |title= (help)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_73&oldid=1143735794"
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy