Wikipedia

Wikipedia:Village pump (idea lab)/Archive 13

< Wikipedia:Village pump (idea lab)
Village pump (idea lab) archive  

This page contains discussions that have been archived from Village pump (idea lab). 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: 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

Update graph technology on page history external tools

 
"External tools" - number 8 in this screenshot

The "external tools" page view statistics link currently points to User:Henrik's excellent daily editcount visualiser (http://stats.grok.se). But there is a newer tool available - User:Mr.Z-man's outstanding tool on toolserver (http://toolserver.org/~alexz/pop/graph.php) which shows trends back 5 years.

I'd like to make a proposal to either swap the link, or to add Mr Z-man's tool alongside.

Any thoughts on this before I move it to the proposal board?

Oncenawhile (talk) 22:00, 2 March 2014 (UTC)

The links are made by MediaWiki:Histlegend. A swap was opposed at Wikipedia:Village pump (technical)/Archive 123#Replace old stats.grok.se with wikiviewstats. There was some support for listing both. PrimeHunter (talk) 22:25, 2 March 2014 (UTC)
Wasn't the proposed swap about some third tool, though? I recall people saying that it wasn't useful because it only showed data for the last 30 days, not the last five years. WhatamIdoing (talk) 01:08, 3 March 2014 (UTC)
Right, that was a third tool at http://tools.wmflabs.org/wikiviewstats. The Toolserver tool only has monthly totals and currently ends with December 2013 (default is November 2013 for some reason). Considering the uncertainty at Wikipedia:Toolserver and meta:Future of Toolserver, it may be problematic to add a link. Is it known whether the tool is expected to get a new home before or when the Toolserver closes? Once people get used to a link, they can quickly become annoyed if it disappears. PrimeHunter (talk) 02:38, 3 March 2014 (UTC)
Migration to Labs is in progress, but will probably be another few weeks for this tool, so it's a bit premature to add the link now. Data collection is moved to Labs (which is why December is the most recent data), but there's still some work to do for the web interface. I should also point out that since it only tracked articles that were part of projects that were signed up, early months are rather incomplete. July 2009 (the first month) has data for only 550,000 articles. More recent months are almost complete (December 2013 has 3.4 million) and as of this January it is tracking all articles. Mr.Z-man 04:05, 3 March 2014 (UTC)

Idea for new article namespace: "workspace"

I have an idea for a new namespace. It would be called "workspace." the purpose of this namespace would be to provide documents which would permit people to work on collaborative efforts where they could link to wikipedia articles, and compile information, without being subject to constraints of writing an actual article, but would serve as a collaborative resource for writing regular articles.

so for example, we could have a namespace article called civil rights. this would be a way to provide an overview of the topical area of civil rights, for the purpose of collecting articles and information which would enable a group of people to collaboratively discuss and brainstorm where new articles are needed, and where information can be elaborated upon.

further down is a sample of some possible text from possible articles. note that the purpose for this is to be a category for drafts of documents to be approached in a collaborative manner.

please note that the reason that we have use for such articles, in my opinion, is that one ironic aspect of wikipedia is that we are the world's greatest collaborative website already. yet ironically we do not have any pages here where folks can collaboratively collect their ideas and possible texts to create documents in progress. we do have project pages where folks can discuss their efforts, and of course articles where folks write articles together.

but we do not have any pages which exist solely to be a place to encompass a collaborative effort where people can put their ideas together in "rough draft" form. this new namespace would address that, and provide a dynamic new energizing space for such efforts.

so a workspace for political topics could be a place to collect ideas on new topics to be covered by new entries. a workspace on current events could be a place to collect ideas on new late-braking events to be covered. a workspace on technology could be a place to collect ideas on new innovations to be covered.

my main idea here is that if a new field of invention or a new political issue takes shape, the workspace would be a place where numerous interested editors could go to see the current shape of common effort on that topical area, and to add their own ideas and input.

below are some examples.

on a topical area, blending history and current affairs,such as civil rights:

first pioneers of civil rights were people like John Lewis, Medger Evers, Martin Luther King, Junior.

current civil rights efforts hinge on issues like fair pay for women, amnesty for immigrants, including the 2014 amnesty issue

on an area of current events, combining new entries with updated information on existing entries

the 2014 unrest in Ukraine has centered mainly on controversy over EU membership for Ukraine president Yavuchenko has given up power and left the capital.

for changing scientific areas of interest.

renewable energy sources have multiplied in recent years. developments in scotland wave energy plants have revolutionised the search for tidal energy. the new death valley solar plant constitutes a vital new step in building solar power plants.

yes, some of these article links are active, and some are not. that is the point. creating these collaborative entries would be a way for groups of editors to identify which way they wish to go on a particular topic or set of items.

well, what do you think? I think this could be beneficial. it would help to promote new editing activity here and heightened participatory efforts. please feel free to let me know what you think. I appreciate and welcome any feedback, comments, input, etc on this idea. thanks! --Sm8900 (talk) 02:22, 27 February 2014 (UTC)

Surely we have this already, in the form of the Draft: namespace? --Redrose64 (talk) 10:04, 27 February 2014 (UTC)
hm, I hear ya, but I thought that namespace is only for people's individual drafts. I don't think it is a collaborative gathering place designed specifically for whole groups of people to apply themselves to developing a particular topic. that has been my impression. do you know whether anyone does do so, in that namespace? by the way, thanks for your reply on this.
to use that namespace in the manner described in my idea, we would need some links, categories, or other resources specifically designed to facilitate group involvement, and actively designed to point groups of editors towards specific articles or pages for them to help out with. thanks. --Sm8900 (talk) 11:48, 27 February 2014 (UTC)
hm, well, I can try to think of some ways to use that namespace for this. thanks. --Sm8900 (talk) 12:22, 27 February 2014 (UTC)
  • This is exactly why I opposed using the term "Draft" for naming this new namespace. "Draft" is just too narrow in scope and I believe this will become a perennial proposal as such. I was thinking that "Concept" was a more appropriate name for the namespace because it will be where ideas and draft would be developed in a collaborative manner reducing the human impulse to think that just because a person put an idea or started a draft, it wouldn't belong to them. Once I have the backend work done with my idea for a re-write of the article creation wizard and a plethora of other improvements and design preparations (because this stuff doesn't care what the namespace is called), I may propose renaming "Draft:" to "Concept:" at that point and it would be a relatively simple thing to do. — {{U|Technical 13}} (t • e • c) 13:25, 27 February 2014 (UTC)
hey, I see some value to that idea. that's good. i think we do want to promote active collaboration here. your idea might be one good way to do that. the whole point for me is that this is wikipedia, probably one of the greatest sites on the Web for collaborative participation; and yet, ironically, we do not have any web area which is devoted mainly to article collaboration for its own sake. --Sm8900 (talk) 17:51, 27 February 2014 (UTC)
I have plenty of drafts in the "Draft" namespace, and was never under the impression that these were for "people's individual drafts". If an editor wants drafts that no one else is expected to edit, put them in user space. I think we should just make it clear that "Draft" space is a collaborative space, and anyone can edit anything there, just as if it was an article in mainspace. bd2412 T 15:38, 7 March 2014 (UTC)

Section editing reflinks idea

I was just editing a section of an article, and was thinking of how much of a pain in the arse it is to temporarily add a {{Reflist}} to the bottom of the page, preview, then remove the fake section. I then thought about all of the "oppsies" that could happen as a result of it and started wondering to myself if there was a better way. I then noticed that the page I was editing had a "semi-" protection notice, and started thinking to myself, "wait, in edit mode all pages have an edit notice, why not put a fake "references" section there? Then people wouldn't have to mess around with adding a fake reflist to the section potentially forgetting to remove it and causing a minor disruption on the page until the next person that knew how to fix it caught it?" So, I decided to head over to Template:Editnotices/Namespace/Main to add this global pseudo-{{Reflist}} section and found the page is fully protected. This is why I am here, I wish to know if adding this is something that others think may be considered controversial and as such I should gain consensus on WP:VPR before submitting and edit notice, or if this idea is golden and I can just submit my request. Thank you — {{U|Technical 13}} (t • e • c) 13:48, 1 March 2014 (UTC)

I doubt an edit notice could display references from the page but if it could then it would be impractical when you edit the whole page. See Wikipedia:Footnotes#Previewing edits for an alternative. PrimeHunter (talk) 14:31, 1 March 2014 (UTC)
  • PH, You can insert a {{reflist}} into the edited section temporarily and remove it before saving; you will still not be able to see named references which were defined in other sections. from Wikipedia:Footnotes#Previewing edits is exactly what I want to avoid and why I am inquiring about this idea here. I will run some test (create an edit notice for my sandbox and see if it loads the references) to see if they display (I suspect they will). As to your suggestion that it would be impractical when editing a whole page with hundreds of link, what if the reflist was in a collapsible section? — {{U|Technical 13}} (t • e • c) 15:48, 1 March 2014 (UTC)
My test showed that since it technically renders above the references, it doesn't work as an editnotice, so I asked myself what is on the page below the references and came up with MediaWiki:Edittools. It could be added at the bottom of that page turning:
<!--
Everything up to here gets automatically replaced with the JavaScript edit tools for users with JavaScript enabled.
-->
</div>
into
<!--
Everything up to here gets automatically replaced with the JavaScript edit tools for users with JavaScript enabled.
-->
<table class="navbox collapsible collapsed" style="text-align: left; border: 0px; margin-top: 0.2em;">
  <tr>
    <th style="background-color: #f2dfce;">References section</th>
  </tr>
  <tr>
    <td style="border: solid 1px silver; padding: 8px; background-color: white;">
      <references/>
    </td>
  </tr>
</table>
</div>
Which should give a collapsed section at the bottom of every edit window that will allow an editor to view the references for the section they are editing. — {{U|Technical 13}} (t • e • c) 16:06, 1 March 2014 (UTC)
Your above example would get replaced if the CharInsert gadget is enabled; you need to place it outside the div. That said, it's a bit of a hack to abuse edittools for this. It would make more sense to use the area below that also lists the categories and templates used. Ideally, this should be implemented in the Cite extension. — Edokter (talk) — 16:33, 1 March 2014 (UTC)
  • Edokter, perhaps that delimiting comment should be moved down then? I'll look into what it would take to add it to the extension and ping who might be needed to make such a change. I agree that would probably be the "best" option, and depending on how long it would take, this "hack" may be a temporary stopgap. — {{U|Technical 13}} (t • e • c) 16:47, 1 March 2014 (UTC)
That won't actually work anyway. The edit page interface isn't part of the preview. If you're that desperate, have you looked at User:Anomie/ajaxpreview.js? Anomie⚔ 00:20, 2 March 2014 (UTC)
  • Anomie, I'm not certain if it is just your script or not but I get:
console log
19:59:49.112 "MWDeprecationWarning: Use of "addOnloadHook" property is deprecated. Use jQuery instead" load.php:148
19:59:49.112 Stack trace from load.php, function mw</<.log</log.warn, line 148. load.php:148
19:59:49.146 "MWDeprecationWarning: Use of "addOnloadHook" property is deprecated. Use jQuery instead" load.php:148
19:59:49.147 Stack trace from load.php, function mw</<.log</log.warn, line 148. load.php:148
19:59:49.155 "MWDeprecationWarning: Use of "addOnloadHook" property is deprecated. Use jQuery instead" load.php:148
19:59:49.155 Stack trace from load.php, function mw</<.log</log.warn, line 148. load.php:148
19:59:49.254 "MWDeprecationWarning: Use of "addOnloadHook" property is deprecated. Use jQuery instead" load.php:148
19:59:49.254 Stack trace from load.php, function mw</<.log</log.warn, line 148. load.php:148
19:59:49.305 "MWDeprecationWarning: Use of "addOnloadHook" property is deprecated. Use jQuery instead" load.php:148
19:59:49.305 Stack trace from load.php, function mw</<.log</log.warn, line 148.
— {{U|Technical 13}} (t • e • c) 01:07, 2 March 2014 (UTC)
I don't see any of that here. Probably some other gadget or script you have enabled. Anomie⚔ 12:21, 2 March 2014 (UTC)
  • Not quite sure why I've been pinged about this discussion. I've never actually had this problem - I just, you know, wait until I hit save ;p. Ironholds (talk) 17:22, 1 March 2014 (UTC)
T7984 - Edit preview doesn't let you preview cite.php footnotes. Italic text
References using groups will not show with this method. This includes {{refn}} and variants which use {{notelist}} to show the reference list. You can add the reference list markup for the more common goups with no issues. --  Gadget850 talk 18:33, 7 March 2014 (UTC)

2d/3d mechanic

Hello,

I've proposed to create an article about 2d/3d mechanic. I've many times seen this expression without understanding what it is. I've proposed one example of game using that.

If someone want to write an article about this thematic, it will be very interesting :) — Preceding unsigned comment added by Rempaf (talk • contribs) 21:10, 9 March 2014 (UTC)

Go over to WP:AFC and propose this there. They may be able to help.Serialjoepsycho (talk) 00:43, 11 March 2014 (UTC)

New Idea - Improve Article Indexing

When a user searches for a WikiPedia article, they are hampered by a too-literal search engine. One example: there is an article head "Digital Equipment Corp. vs. Intel" (redirected to "DEC Alpha"). To be successful in finding this reference, the user MUST enter "Digital Equipment Corp." - with a period, and without using "DEC", "Digital Equipment Corporation", or other possible variants. This search engine is far too literal for today's users, who are accustomed to flexible, sometimes error-correcting search engines from Google and many other websites. It's time to bring this index/search program into the 21st century. — Preceding unsigned comment added by Oleh77 (talk • contribs) 13:18, 10 March 2014 (UTC)

I cannot reproduce your example. A search on Digital Equipment Corp vs Intel with no periods gives the redirect to DEC Alpha as first search result for me. DEC Alpha never says "vs" or "versus" so "DEC" and "vs" don't occur on the same page. Considering this, I don't think it's too bad that our search engine shows the redirect at Digital Equipment Corp. vs. Intel on the first page of results for DEC vs Intel. Anyway, our search engine is actually about to be changed. See mw:Search. The new CirrusSearch can be enabled at Special:Preferences#mw-prefsection-betafeatures. I don't know whether it performs differently in this case. PrimeHunter (talk) 13:56, 10 March 2014 (UTC)

Block review process page suggestion

Thread retitled from "Block review".

Why is there no process for asking for a review of a block to determine if the blocking admin acted in accordance with community consensus? GabeMc (talk|contribs) 19:22, 12 March 2014 (UTC)

I dunno; is there a need for a specialized process over just starting a thread at AN like usual? Writ Keeper ⚇♔ 19:28, 12 March 2014 (UTC)
Most editors cannot take an admin to AN without risking a boomerang block or ban. GabeMc (talk|contribs) 19:30, 12 March 2014 (UTC)
Do you think a specialized process would change that? Writ Keeper ⚇♔ 19:32, 12 March 2014 (UTC)
  • Most editors cannot take an admin to AN without risking a boomerang block or ban.[citation needed] — {{U|Technical 13}} (t • e • c) 19:48, 12 March 2014 (UTC)
  • A blocked user can't start a thread on AN to request a review of their block. It would have to be done by a proxy edit request, although, any admin that blocks someone and there is a chance it was controversial or the {{Unblock}} request suggests that it was ZOMG ADMINABUSE by a ROGUE ADMIN of the SUPREME CABAL!!! should open a review of the block themselves on AN to confirm that it was appropriate (which is fairly often done if you ever watch the llama boards (don't do it, it is not worth it)) — {{U|Technical 13}} (t • e • c) 19:48, 12 March 2014 (UTC)
  • The unblock request does not entitle the blocked editor to an audience within the block period or with an uninvolved admin, so its pretty useless, IMO. Anyway, this is less about unblocking and more about the review of a block to confirm its appropriateness. GabeMc (talk|contribs) 19:53, 12 March 2014 (UTC)
  • Huh? Say what? That is exactly what the unblock request does, it draws attention by those llama lovers that want to see who was blocked and why so that they can start a thread on AN or AN/I complaining that JoeAdmin is misusing the admin tools. Apparently you don't watch those boards very much (I don't watch them when I've not been dragged there, which seems to happen quite often because I'm not very good at communicating what I mean, I'm fairly stubborn in keeping true to my beliefs (which doesn't mean I won't admit when I'm wrong), and I ask too many questions (yes, there is such a thing as too much of a good thing)). — {{U|Technical 13}} (t • e • c) 20:06, 12 March 2014 (UTC)
  • Well, I should have said that the unblock request does not guarantee that the blocked editor will be granted an audience with an uninvolved admin during the block period. GabeMc (talk|contribs) 20:10, 12 March 2014 (UTC)
  • Again, I'm going to have to say: [citation needed]. Using my block as an example, I count at least seven different admins involved there. You'll notice that just about every single {{Unblock}} request was answered by a different admin (not to mention the other half dozen or so regular editors who were curious to watch the whole thing). This seems to be following the WP:BLOCK#Unblocking policy which starts, Unblocking or shortening of a block is most common when a blocked user appeals a block. An uninvolved administrator acting independently reviews the circumstances of the block, the editor's prior conduct, and other relevant evidence, along with any additional information provided by the user and others, to determine if the unblock request should be accepted. That section also seems to go into what to do if you feel that you need a specialized block review process: a block may still be appealed by submitting a request to the Unblock Ticket Request System. (I made it red because it's probably not a good idea to be forced to go that route.) — {{U|Technical 13}} (t • e • c) 20:43, 12 March 2014 (UTC)
Yes, as long as the editor requesting the review is not in jeopardy of being blocked or banned for doing so, which is always a possibility at AN. We review deletion closures, why not review blocks so that the community can give input regarding the implementation of guidelines that allow for blocks. GabeMc (talk|contribs) 19:35, 12 March 2014 (UTC)
I mean, I guess those who are inclined to do so will just see this as The Voice Of The Admin Cabal speaking, but people generally don't get blocked because they made an AN thread; they get blocked because they behaved poorly, and their AN thread drew attention to their behavior. A specialized block review is going to draw exactly the same sort of attention to one's actions, so boomerangs are going to happen in the same way. I mean, if you're saying that whoever reports a block for review gets actual immunity from reaction for anything they may have done wrong, well, that's just plain silly; one could do whatever one wanted and be immune from any consequences whatsoever as long as they have a block review thread open. Immunity for the reporter is horribly abusable, and without it, it's no different from AN. Writ Keeper ⚇♔ 19:42, 12 March 2014 (UTC)
That's not at all what I'm saying. When you bring someone to AN for any reason, you may be blocked or banned for unrelated reasons. Proper due process should never subject the filing party to WP:BOOMERANG, which is always a possibility at AN. When we want to dispute a file deletion we don't bring the closer to AN, do we? There needs to be a venue to ask for a block review that does not put the filing party in jeopardy from everyone who has a bone to pick with them. GabeMc (talk|contribs) 19:45, 12 March 2014 (UTC)
But the point is that they, like every other editor, are always in that jeopardy, whether they've started an AN thread or not. They are not suddenly vulnerable to a block because they started an AN thread; they were always vulnerable to a block. Creating an AN thread just drew attention to themselves, so that an admin noticed their misbehavior (or decided they had a boone to pick, or whatever). I don't see how a specialized block review noticeboard would be different in that respect. Writ Keeper ⚇♔ 19:55, 12 March 2014 (UTC)
"Always" in jeopardy? Even when not breaking any guidelines or policies? GabeMc (talk|contribs) 19:59, 12 March 2014 (UTC)
If they're not breaking any guidelines or policies, they're not in any danger of a boomerang, either. Writ Keeper ⚇♔ 20:00, 12 March 2014 (UTC)
If you really think that AN works that way then I'll just agree to disagree with you. The very act of taking someone to AN puts an editor at more risk of sanctions then not taking someone there. Do you really dispute that AN is a placed where things regularly snowball out of control? What harm would a block review noticeboard cause, except to corrupt admins who are more interested in maintaining their control over the project then improving the editing environment? GabeMc (talk|contribs) 20:04, 12 March 2014 (UTC)
Of course things spiral out of control at AN. (I think the degree to which it spirals out of control is usually overstated, but that's not the point.) My question remains: why do you think a block review board would be any different? Whether the real reason one is blocked after posting to AN is valid or not, the ostensible reason is never "they posted to AN". The ostensible reason is always "they broke a guideline or policy of some kind", and we can only make rules about the ostensible reasons. It's not like there's a rule somewhere that says "you can block them if they posted to AN". There's no kind of new vulnerability in the rules that one acquires when one posts to AN. So, unless you're advocating for some kind of special protection, essentially the immunity to which I alluded earlier and which is trivially exploitable and gameable, the block review noticeboard is no different from AN. It might not do any harm per se, other than as an increase in pointless bureaucracy, but it won't help at all. To put it another way: if corrupt admins are the problem, why would they respect a block review board when they don't respect AN? Writ Keeper ⚇♔ 20:14, 12 March 2014 (UTC)
1) Editor A blocks editor B. 2) Editor B then asks to be unblocked, but only editor A responds by denying the request. 3) The block expires, but editor B feels like it was a bad block. What is editor B to do now other than taking editor A to AN or dropping the matter altogether? GabeMc (talk|contribs) 20:19, 12 March 2014 (UTC)
If Admin A blocks Editor B and Editor B asks to be unblocked, Admin A should never decline the unblock request. The only action Admin A should take on a block they placed is an unblock. GB fan 20:31, 12 March 2014 (UTC)
GB fan, I'm sure you are technically correct that an admin should not formally decline the unblock, but all they need to do is ignore the request until after the block expires, which accomplishes the same end in that the unblock was not granted even if not officially declined. GabeMc (talk|contribs) 22:11, 12 March 2014 (UTC)
Hmm, not really; a declined unblock request will take the user out of Category:Requests for unblock, where any admin might take a look and handle an unblock request; an ignored unblock request will remain in the category, visible to other admins. Writ Keeper ⚇♔ 23:56, 12 March 2014 (UTC)

(edit conflict) Those are indeed the two options. (In passing, as GB fan said, an admin cannot decline an unblock request for a block they've placed, and that is something we should enforce more strictly.) What I still don't see is: how is taking editor A to "BRB" any better than taking editor A to AN? I mean, are you envisioning that, at the creation of the BRB, all the corrupt admins say, "well, they created a BRB, it's a fair cop, I guess I'll play by the rules now"? Again: if the problem is corrupt admins who are not playing by the rules and who are delivering unfair boomerangs, the solution is not "make a new board", since the corrupt admins will just follow their corrupt standard operating procedure and continue not playing by the rules and delivering unfair boomerangs at the new board. If you're just saying "no boomerangs at the new board", well, unless there's explicit immunity, which again is a bad idea because it is easily gamed/exploited, that doesn't really mean anything, since boomerangs aren't actually a feature of the old board; it's just what happens when people either misbehave or "misbehave" (depending on how cynical you are about admins) and then draw admin attention to themselves. Since there's nothing at the old board that gives admins a new power to block a given editor, what's to stop them from doing the same at the new board? Writ Keeper ⚇♔ 20:35, 12 March 2014 (UTC)

A BRB would keep all admins more honest not because they would be required to participate in the review, which they wouldn't, but because the community as a whole would be reviewing their actions, and the only thing a corrupt admin likes less than more power is looking bad to the community. RE: "what's to stop them from doing the same at the new board", what's to stop you from blocking me now? Unrelated issues are often brought into the fold an AN. E.g., "this editor is always rude to me". The BRB would look at only the block, not all unrelated behaviors like at AN. The BRB would only ask if the block was justified based on guideline and policy. Its one thing to allow unilateral blocking, but without any due process this is not a mature system. GabeMc (talk|contribs) 20:45, 12 March 2014 (UTC)
Look at it this way, in most civilized countries when a police officer brandishes their firearm and shoots a suspect, that shooting is reviewed by a board who is not out to boomerang the victim of the shooting. It only decides if the shooting was justified based on the specific facts of that incident, not the entire known criminal history of the suspect, which is often the case at AN. When a police officer shoots a suspect it matters not if that suspect had been arrested several times before. The validity of the shooting is not affected by the victims previous arrests, as is the case at AN. GabeMc (talk|contribs) 20:59, 12 March 2014 (UTC)
I don't know. More noticeboards means fewer people watching each one, and therefore a higher likelihood that the ones who are watching have some sort of special interest in it. WhatamIdoing (talk) 20:54, 12 March 2014 (UTC)
I'm not sure what you mean. This would add a needed set in our due process, of which there is currently little to speak of. A blocked editors should have a recourse other than AN. GabeMc (talk|contribs) 20:59, 12 March 2014 (UTC)
Nothing is to stop me from blocking you now (except that, y'know, I'm not a corrupt admin and know of no reason to block you). And that's my point: since there is nothing to stop me from blocking you regardless of whether you have posted to AN or a hypothetical BRB, there's no "boomerang-avoiding" benefit to be gained from splitting off block reviews into their own board. If there is cause to block (whether it's legitimate or not), blocks will happen, and if it's a BRB thread that brought that cause to an admin's attention, then that block will be just as much a boomerang block from BRB as it would've been from AN. So there's no real significant benefit vs. AN in that respect, whereas (if one is concerned about corrupt admins) the creation of a new noticeboard gives said corrupt admins one more way to shut down a discussion prematurely (because "this is the wrong noticeboard!"). Increase of bureaucracy with no counterbalancing benefit is bad. Don't get me wrong: block reviews in general are a great idea, and I think we should do them more. But I don't see how creating a new noticeboard dedicated to them is helpful. Writ Keeper ⚇♔ 21:04, 12 March 2014 (UTC)
It could be as simple as adding a Block review page to the User conduct section of WP:AN, but IMO it should be stressed that the filing party is not putting themselves on the chopping block by exercising this right. Its bad enough to have unilateral blocking privs, but when that power has no check or balance it invites corruption. Also, if an admin's blocks were routinely labeled as "bad", that fact could be used at an RFC/ADMIN, but as it is now, its all hearsay and opinion to accuse an admin of regularly making bad blocks. If editors had BRB discussions to point to it would empower the non-admins with an ability to hold admins accountable for their blocks. GabeMc (talk|contribs) 21:16, 12 March 2014 (UTC)
I agree completely about holding admins accountable (though again, a thread with the same conclusion on AN could be used the same way), but the thing is that you can't tell the filing party that they're not putting their head on the chopping block, because like it or not, they are, and I don't see how creating a BRB changes that. I mean, again, we can say that there are no boomerangs at BRB, but because boomerangs are simply blocks for cause that someone noticed because of a noticeboard posting, that doesn't actually mean anything. Nothing will have changed. Writ Keeper ⚇♔ 21:21, 12 March 2014 (UTC)
Well, I guess that you are correct about that point, but I still think that having a dedicated page will reduce the likelihood that someone will accuse the filing party of breaching protocol, as can happen at AN. If the board is intended only to review blocks then I don't really see how the filing of a review request could be seen as forum shopping or pointy behavior. GabeMc (talk|contribs) 21:29, 12 March 2014 (UTC)
Again... There already is an alternative to AN or AN/I... It's called the arbitration committee, of which a complaint can be (and is preferred IIRC) file via email, which reduces the likelihood of a boomerang block. — {{U|Technical 13}} (t • e • c) 21:52, 12 March 2014 (UTC)
Arbcom will not hear cases on short blocks, which make-up the bulk of all blocks. GabeMc (talk|contribs) 21:54, 12 March 2014 (UTC)

A system where bans can be questioned I wouldn't be opposed to. Where a user or someone on their behalf can question a short term ban and that it can be questioned up until a certain amount of time after the ban ends. Like a week or so after the ban ends. I'd stick it with arbcom.Serialjoepsycho (talk) 06:39, 13 March 2014 (UTC)

There is a difference between a ban and a block. Bans and long blocks can already be appealed to ArbCom via the Ban appeal subcommittee. ArbCom is supposed to be a last resort for things that can't be resolved by the community. I wouldn't be totally opposed to a trial of block review page, but I think the cases where a user wants to appeal a block on behalf of someone else are going to be rather infrequent. Mr.Z-man 14:48, 13 March 2014 (UTC)
Well, we wouldn't require that the filer be someone other than the blocked user, the review request could be filed by the blocked user, which would put nearly every block up for community review. The peer pressure of having your blocks judged by the community would increase the frequency of warnings and decrease the frequency of blocks, especially borderline ones. GabeMc (talk|contribs) 18:22, 13 March 2014 (UTC)
In situations where the user is still blocked and cannot edit any Wikipages other than their user page, the review could be addressed at their user page and transcluded to AN. GabeMc (talk|contribs) 18:28, 13 March 2014 (UTC)
I've been following this and still don't see why having a new, barely watched noticeboard, would be better than a post to WP:AN. –xenotalk 18:41, 13 March 2014 (UTC)
I reluctantly agree, so the working idea here is to add a Block/Ban review page to the User conduct section of WP:AN so that there is a dedicated forum for these reviews, but not an stand-alone board. GabeMc (talk|contribs) 18:47, 13 March 2014 (UTC)
I'm afraid I don't follow. You mean that little box on the right? –xenotalk 18:58, 13 March 2014 (UTC)
AN is devided into sub-pages, including Abuse, Article sanctions, Conflict of interest, Contributor copyright, Edit warring & 3RR, Editor restrictions, Editor review etcetera. All this proposal aims to do is add a Block/ban review sub-page to join the others. GabeMc (talk|contribs) 19:44, 13 March 2014 (UTC)
That'll just be a new, poorly watched, noticeboard that's a subpage of AN. –xenotalk 22:05, 13 March 2014 (UTC)
(edit conflict)If this were set up to allow users to appeal their own blocks, then I would probably oppose it. Users already have the {{unblock}} template and WP:UTRS, as well as BASC for longer blocks. If this were set up to replace {{unblock}}, then maybe, but having 3 separate places to make the same appeal is excessive and just asking for forum shopping. The number of cases of people abusing {{unblock}} with frivolous requests (continually asserting they did nothing wrong even after review from multiple uninvolved admins) is far greater than the number of blocks actually overturned. If the few legitimate requests just get lost in a sea of BS and wiki-lawyering, then no one is going to pay any attention to it. Mr.Z-man 19:02, 13 March 2014 (UTC)
This wouldn't necessarily replace the unblock request. What I'm trying to explain here is that admins can block anyone that they want for good reason or no reason, but other than taking an admin to AN and risking a boomerang block or ban, or appealing to ArbCom, which won't hear appeals on short blocks, there is no due process that determines if a block was justified. If editor A was blocked by editor B, and the block wasn't overturned but let to expire, this would be a place where editor A can request a community review of editor B's block. If editor B makes a habit of handing-out bad blocks then this would provide a permanent record of the community's assessment of said blocks. ArbCom won't hear appeals on short blocks, so as long as an admin gives mostly 24-hour blocks their actions are beyond the purview of ArbCom and thus without due process. Apparently, some editors already ask for blocks to be reviewed at AN, so this isn't that different except that we would create a dedicated sub-page at AN that deals only with ban and/or block reviews. This is less about getting a block overturned then it is about establishing checks-and-balances for blocking admins. When a police officer uses their weapon, that use is subject to an automatic review. This is similar, except I don't imagine it should be automatic, since most blocks are clearly justified. GabeMc (talk|contribs) 19:44, 13 March 2014 (UTC)
My point is that if it doesn't replace something else, this would mean that we have as many as 4 processes/forums dedicated to basically the same purpose. How many other processes have more than 1? Saying that blocks under 24 hours have no due process is false, as there are at least 2 means of appeal other than BASC. You may not intend it to be about getting blocks overturned, but that's what people are going to use it for if it exists. Besides, other than indef blocks where we decide to give the user a second chance, improper blocks are basically the only reason a block is overturned, so complaining about a block being improper and asking for it to be overturned are basically the same thing. Mr.Z-man 21:45, 13 March 2014 (UTC)
Okay, what if I get blocked and use the unblock request, but it is not responded to by anyone except the blocking admin who does not overturn the block? Is that due process, IYO? Because due process requires that people other than the blocking admin review the block and as it is now, the only due process is ArbCom, which won't hear 99% of all blocks. So no, there are not processes available to an editor who would like the community to review their block. If an admin knew that every block they issued might end up as a thread at AN:BRB, and that any bad blocks would look bad on their record, then they would be much more likely to warn users versus issuing trigger-finger blocks. GabeMc (talk|contribs) 21:52, 13 March 2014 (UTC)
Then you make another unblock request, or contact UTRS. Like I said, there are at least 2 means of appeal already other than ArbCom. Mr.Z-man 01:31, 14 March 2014 (UTC)

WP:ADMINABUSE also suggests Wikipedia:RFC/U as an option. There is a section Wikipedia:RFC/U#Use_of_administrator_privileges, but that just ends up creating a regular RFC/U. While an RFC/U couldn't impose sanctions, it would draw comments from other users that might have similar experiences an admin was being accused of. Hopefully the admin would use the comments constructively; if nothing else, the results of RFC/U could be taken to ArbCom if needed.—Bagumba (talk) 21:52, 13 March 2014 (UTC)

Bagumba, an RFC/U is prohibitively complicated and nuanced. A BRB is an exceedingly simple way for every editor to seek constructive feedback on their block. 99% of all editors will not bother with an RFC/U on an admin because its so unlikely to produce results. What's so scary about having to answer to the community when you block one of us? GabeMc (talk|contribs) 22:01, 13 March 2014 (UTC)
Nothing. It's just probably better to do it at WP:AN rather than a subpage thereof. –xenotalk 22:25, 13 March 2014 (UTC)
Assume that this page is formed, and feedback comes back that GabeMc should not have been blocked. What happens next?—Bagumba (talk) 22:07, 13 March 2014 (UTC)
Good question. Nothing except that it starts a record of the blocking admin's reviewed blocks. A good admin might have 15 blocks reviewed with none of them closed as bad, so its not always a bad thing for admins, as long as they choose wisely before hitting the block button. An admin with consistently questionable criteria for issuing blocks might find themselves with the community saying that they do not support their approach. GabeMc (talk|contribs) 22:14, 13 March 2014 (UTC)
You said RFC/U is "prohibitively complicated". Which parts of Wikipedia:Requests for comment/USERNAME, the current template used to start the process, would you want improved?—Bagumba (talk) 22:24, 13 March 2014 (UTC)
Well, I've only ever participated in one RFC/U, which was a complete disaster in terms of correcting the subject's negative behavior. The focus quickly shifted to every indiscretion of the filing parties and to nit-picks over the process and formality and red-tape until the meaning was utterly perverted. RFC/Us are rare for good reason; in practice they do not work. Anyway, a BRB is much different than an RFC/U in that its not really attempting to correct the blocking admins behaviors. Its meant primarily as a forum whereby the community can decide if an editor was appropriately blocked and whether the blocking admin acted in accordance with the broader community consensus. Again, this is a very basic component of any corrective system and that Wikipedia currently does not have it is embarrassing, IMO. Its really not rocket science and its certainly not re-inventing the wheel; its an accepted practice in preventative and corrective systems around the world. GabeMc (talk|contribs) 22:33, 13 March 2014 (UTC)
I assume you are referring to this RfC? Unfortunately, I think the same behavior could happen even if your proposed BRB is formed. Discrediting a proposer and generalizing motives is a timeless tactic, Wikipedia or not.—Bagumba (talk) 22:53, 13 March 2014 (UTC)
That's true, but I don't see much potential for boomerangs with a request as simple as: "I was blocked and I'm not convinced it was justified based on the community's working consensus regarding the relevant guideline/s. Will you please review the incident and determine if the block was appropriate?" That's the inherent flaw in an RFC/U; it attempts to do far too much when all you really need most of the time is a succinct and explicit affirmation that a problem exists. GabeMc (talk|contribs) 22:59, 13 March 2014 (UTC)
So why can't this same discussion happen at AN? GB fan 23:16, 13 March 2014 (UTC)
Well, that's what I'm arguing for, but as a distinct sub page in User conduct with: Abuse, Article sanctions, Conflict of interest, Contributor copyright, Edit warring & 3RR, Editor restrictions, and Editor review. What I'm suggesting is an AN sub page called Block and ban review, or similar. GabeMc (talk|contribs) 23:21, 13 March 2014 (UTC)
A new subpage is going to be very poorly watched, and most likely those watching it will have some particular angle. AN is watched by over 3800. –xenotalk 23:23, 13 March 2014 (UTC)
I understand what you are arguing for, but there is a specific page, WP:AN. Why can't the discussion about a block happen at the main WP:AN page? GB fan 23:28, 13 March 2014 (UTC)
I think you are both underestimating the intimidation factor that most editors would feel about posting what could be seen as a severe critique of an admin on the general AN board as if you were reporting editor abuse. Noticeboards ect. currently lists more than 50 subpages, but not even one of them pertains to the oversight of any of the significantly impactful admin duties. Zero. There are subpages for: Abuse (long-term cases) · Article sanctions · Conflict of interest · Contributor copyright · Edit warring & 3RR · Editor restrictions · Editor review · New pages patrollers · Paid editing · Sockpuppets · Usernames · Vandalism, but none of these imply that its an appropriate place to ask for a review of a block or ban. GabeMc (talk|contribs) 23:35, 13 March 2014 (UTC)
That's because it belongs at WP:AN; see Wikipedia:Administrators' noticeboard/Header: Issues appropriate for this page could include: General announcements, discussion of administration methods, ban proposals, block reviews, and backlog notices.. I'm sorry but I don't see how the intimidation factor would be reduced if it were shuffled off to a poorly watched subpage (and it could probably be argued that it would actually increase because people could just think "well admins on this board are just going to circle the wagons"). –xenotalk 23:47, 13 March 2014 (UTC)
Maybe you're right, but you are assuming a lot, IMO. I would never dream of taking an admin to AN/user abuse over a basic block, but if there was a dedicated block review page I absolutely would file a report there. The question here is not which of us is right, its which of our opinions is most commonly held by the broader editing community. The question of whether it would in practice work can only be answered by a trial, and not by skeptical conjecture. What risk of substantive loss is there in temporarily establishing a block review subpage pending further review of its efficacy? The potential for loss is almost zero, so why not give it a chance to work? I think the concern that it would be poorly watched is based on a false assumption, because I think it would be one of the most popular subpages of AN. I mean, how hard is it to put a page on your watch-list anyway? GabeMc (talk|contribs) 00:24, 14 March 2014 (UTC)
Based on this thread, how commonly held is your opinion that this requires a separate page? –xenotalk 00:29, 14 March 2014 (UTC)
I'm not sure anyone has ever suggested this before, so I have absolutely no idea, but I suppose you could take the number of blocks issued per month and assume a figure from there. The best test of that would be hits, which you cannot quantify unless its actually attempted. GabeMc (talk|contribs) 00:33, 14 March 2014 (UTC)
Have any of the editors commenting here been blocked? GabeMc (talk|contribs) 00:37, 14 March 2014 (UTC)
That would represent a rather substantial selection bias. –xenotalk 00:40, 14 March 2014 (UTC)

This was suggested once here: Wikipedia:Administrators' noticeboard/Archive225#Block review noticeboard?. –xenotalk 00:54, 14 March 2014 (UTC)

Wikimedia genealogy project

Plans for a Wikimedia genealogy project are currently underway. Any comments, concerns or questions are much appreciated. Thank you. --Another Believer (Talk) 21:51, 14 March 2014 (UTC)

The issue of permanent stubs

I've been working on a number of articles related to the late Byzantine world where, after reasonable research, I've had to face the fact that there is just not that much information on the topic. (By reasonable, I mean the standard authorities -- i.e. books -- searches in JSTOR & other periodical databases, as well as Google queries.) While most of these articles are biographies, I have encountered this problem in the past with other topics such as towns & villages, battles, etc.

An example of what I'm talking about can be seen with John I of Trebizond: all that is known about him is that he reigned 3 or 6 years, & was trampled to death playing polo. (Or a game like it.) Other examples include Anna Philanthropene, Andronikos III of Trebizond, Caterina Gattilusio, & Palamede Gattilusio. And there are more possible topics I could have written on, but I dislike creating stubs which I know will never be expanded beyond a stub size -- for example, battles about which practically all one can say is X defeated Y -- just because Wikipedia "needs" an article on the subject.

While I know there is an eventual solution to this problem -- be imaginative in how to present the topic, merge the article, or (in some exceptional cases) delete it -- I'd like to propose an interim step here: a way to mark a stub as containing all the information on this specific topic that a reasonable effort to research. In other words, an established Wikipedian thinks this stub probably contains everything on the topic. After a certain point, a dilligent researcher gets a feel for just how much information is actually out there, & can accurately sense when specific subjects have been covered completely. And there are times when there just isn't all that much information on notable subjects to provide more than a few hundred words of useful content. (I'm assuming here that no one wants to pad out articles with unnecessary verbage & tangential details just because of length.)

Tagging these "permanent stubs" as such would at least alert other contributors to the issue with the subject. Who then could suggest a new manner of presentation (thus overcoming systemic bias), or a new line of research. (For example, not all reliable sources are in English, & this tag might poke Wikipedians on other language projects to look for sources in their own languages, which could then be used in the English Wikipedia.) Or simply make the argument for merging related articles that much shorter & effective. -- llywrch (talk) 19:00, 19 February 2014 (UTC)

I think that User:Biosthmors will be interested in this idea.
If the article is truly complete, then it shouldn't be tagged as a stub, no matter how short it is. WP:Stub gives this definition: "A stub is an article containing only one or a few sentences of text that, although providing some useful information, is too short to provide encyclopedic coverage of a subject, and that is capable of expansion." If it provides proper encyclopedic coverage or it is not possible to expand it, then the article is not a stub.
This sensible proposal is unfortunately going to run up against the problem of things that some people believe are "inherently" notable. I gave a (real) example in a discussion on schools a while ago. Given a school that was in existence for about two years, about a hundred years ago, and all that is known about it (really) is the years, the approximate location (a temporary village), why it closed (the temporary village was abandoned when work at the site dried up), and the type of school (that is, whether or not it was a high school), should we have an article on it? Several people enthusiastically declared that if it was a high school, then it absolutely qualified for its own article, even if you literally could not write more than three sentences about it. I think this position is absurd (did you notice that neither the name of the school nor the name of the temporary village appeared in the list of things that are known?!), but if we had such an article, it really would be impossible to say anything more than what I've described here. I definitely wouldn't want anyone to think that it was a stub, which implies that it's in need of expansion. WhatamIdoing (talk) 19:22, 19 February 2014 (UTC)
FWIW, I remember some years ago taking part in a WikiProject Biography A-Class review of an article about a British cricket player included in the hall of fame and elsewhere and still highly regarded despite having an article of little more than a paragraph in length. I now know of several other historical figures of pretty much unquestionable historic significance and importance who, sometimes as the result of destruction of documents, sometimes other reasons, have little if anything about them available today. Given the sheer number of such people (and I assume other topics) which are included in significant encyclopedic and other sources regularly, if never to any real length. I could argue, and kind of have elsewhere, that in such cases it might be more reasonable to have such articles available in wikisource or elsewhere, if we could improve the position in which such articles appear through search engines. Until then, if that ever happens or even should happen, I think there may well be a lot of existing and potential articles that will never be reasonably improved beyond apparent stub level, and it would be useful if we could find some way to clearly identify them. John Carter (talk) 23:08, 21 February 2014 (UTC)
Hi, User:Llywrch. This is an excellent topic now that Wikipedia is in its mature stage. I concur with User:WhatamIdoing. Although pages like WP:Stub don't make it clear enough (and even imply the opposite), an essential properties of "stubness" is that there is room for much expansion. If the article basically covers everything that is known about the subject, it's merely a short article, and should not be considered a stub. I would fully back removal of the stub template in those situations where an editor deems an article "rather complete" in their informed judgment. A quick note on the article's talk page explaining the removal would be a good idea though. Jason Quinn (talk) 16:35, 2 March 2014 (UTC)

Some folks have offered positive comments about this idea, & no one has spoken against it. So what should we do now? Ask for a change to {{asbox}} to add this parameter? Hack together a template to add this to Talk pages & see what happens? -- llywrch (talk) 06:30, 3 March 2014 (UTC)

Thanks User:Llywrch for starting this conversation. I am a new Wikipedian from Malawi (Africa) and I am having trouble finding enough reference material on some notable Malawians mainly because there’s a thin collection of written works on them (online, elsewhere). Like User:Jason Quinn, I would fully back removal of the stub template in special situations. Michaelphoya (talk) 04:42, 18 March 2014 (UTC)
Hi, User:Michaelphoya. I would just like to mention a distinction between short articles that should not be stubs because their coverage is complete and articles for which not many references exist. The former may be highly notable with hundreds or thousands of potential sources for each of the few statements in the article whereas the latter's notability may be in question (at least by Wikipedia's standard of it). Jason Quinn (talk) 15:30, 18 March 2014 (UTC)
Hi, Jason Quinn. Thanks for the clarification. Much appreciated. Michaelphoya (talk) 18:21, 18 March 2014 (UTC)

New Idea - Holiday Update

I think it would be a great idea to display every holiday that takes place around the world, on the home page of Wikipedia. This will allow Wiki users to be more knowledgeable about the world.

Thanks, 

trummell  — Preceding unsigned comment added by Trummell (talk • contribs) 02:48, 10 March 2014 (UTC)
Well, under "On this day" on the Main page we generally list the day's holidays, so long as the articles are in decent shape. Chris857 (talk) 03:12, 10 March 2014 (UTC)
It sounds like you want a script that will take the "Holidays and observances" section of the article about today's date and display that on the Main Page. If you can program in Lua, you can create a Lua-based template that can do the job. Getting it on the Main Page will require some discussion. davidwr/(talk)/(contribs) 22:10, 19 March 2014 (UTC)

Limit binding authority

A current onging RFC is being used bind a topic title and the discussion of it until 31 August 2015. I personally think that the authority to bind anything should be very limited. Specifically to ARBCOM or thru the consensus of the community. Admins have a variety of blocks and bans to deal with disruptive editors. If it is necessary to give this binding authority to RFC or others systems it should wholly limited, to a week or a month, and only used when there is a need to descalate a situation. If there is any actual need to bind anything the dispute should work its way thru dispute resolution until it reaches arbcom and they can make that decision. There should also be some system of oversight such as a system proposed in WP:BCD. I'm seeking help on how this should be suggested.Serialjoepsycho (talk) 19:41, 10 March 2014 (UTC)

Wouldn't an RFC represent consensus of the community? –xenotalk 19:44, 10 March 2014 (UTC)
A segment of it. Not that of the greater community.Serialjoepsycho (talk) 19:49, 10 March 2014 (UTC)
A small segment of it generally.Serialjoepsycho (talk) 21:09, 10 March 2014 (UTC)
This is an example of community consensus building. An arbitrary decision that effectively pushes a policy onto the entire community done by a minority of users does not represent a community consensus.Serialjoepsycho (talk) 02:39, 11 March 2014 (UTC)
I'm sorry, this just looks like you don't like the way the wind is blowing at that RFC so you're looking for a broad policy change to nullify the impending result. Properly advertised RFCs closed by uninvolved parties are typically taken as consensus. –xenotalk 03:39, 11 March 2014 (UTC)
I don't like the way the winds blowing. However not because of soccer, kickball, football, or what ever name. I could care less about the sport. The consensus should be respected. Their consensus that it should be called soccer or kickball. Their content based consensus. Their content based consensus shouldn't be able to be reversed with out a discussion that clearly reverses it. However there policy based consensus should not be respected. Policy that discussion should be closed for about a year. That shouldn't be. Not there or anywhere else. If someone is disruptive and disregards the consensus without discussion the admins have the tools to handle that. If there is a need to bind a discussion they can work thru all of the dispute resolution required and work all of the way up to ARBCOM and ARBCOM can. A RFC/U has more oversight and generally only effect one person. I could careless about a trivial naming dispute. Where is the limit? Can I get 4 people to agree with me in an RFC and lock in a change and shutdown discussion for a year? Or does it require 10, 30, 50, or will 100 be enough? While I don't feel it is necessary to have this ability, if it's found necessary it should be limited in scope. A week or a month. That doesn't preclude renewal. If necessary they can renew if for another month and ect. If that was the case I would alsdo limit the number of renewals. After a predetermined number it automatically goes to arbcom. Or something like that. Or give RFC this power but create a sytem of oversight and appeal.Serialjoepsycho (talk) 06:38, 11 March 2014 (UTC)
Consensus can change. In typical parliamentary-procedure situations where issues that have already been discussed and "voted on" cannot be brought back to the floor, there are usually two exceptions: Someone who was on the "winning" side of the vote can "move to re-consider," and anyone with standing can "move to suspend the rules for the purpose of revisiting the previous decision." "Motions to re-consider" are usually workable in small groups, such as a city council or corporate board of directors. They are not workable in a larger community like Wikipedia. A motion to suspend the rules typically requires a super-majority to support. To turn this into Wikipedia-speak, if this motion passes, any attempt to discuss the issue before August 31, 2015 will require a super-majority of support or even the attempt to discuss it may be considered disruptive, which can lead to sanctions. davidwr/(talk)/(contribs) 22:06, 19 March 2014 (UTC)
This is not a Parliment. Interesting, A minority can force it's will on the majority but to reverse it that would require a response from the majority. Thanks anyway. I'm done pursuing this.Serialjoepsycho (talk) 02:20, 21 March 2014 (UTC)

Deleting unused things

I think we should delete our old pages and archives that will never, ever be used anymore. I mean, who will need to keep a talk post from five years ago over grammar? And old archives in AfC, those needn't be kept forever. Ditto with old deletion remnants and ancient records from old versions of articles. We need to create more space in Wikipedia for usable content. — Preceding unsigned comment added by JDgeek1729 (talk • contribs) 03:33, 15 March 2014 (UTC)

You don't need to worry about WP:PERFORMANCE. You should assume that Wikipedia's disk space is essentially infinite; you will never be able to fill it, even if you do nothing except post new comments or edit articles all day long, every day, for the rest of your life.
Also, as a technical matter, "deleting" pages doesn't reduce the amount of disk space used. It's more like putting a file in your computer's trashcan, and then never (ever!) emptying the trash can. Any page that's deleted by an admin can be read or undeleted by any admin at any time. WhatamIdoing (talk) 05:28, 15 March 2014 (UTC)
The only benefit I can see is to reduce organizational clutter, including the clutter in the "search Wikipedia" function if truly useless pages that are not marked "noindex" are kept. As others pointed out though, neither disk space nor performance will be improved by deleting such pages. However, I am against your proposal on the grounds that what is useless to you may be useful to me, and you might never know what I consider useful and because some of the things you suggest deleting, such as old versions of articles, typically need to be kept for copyright-attribution reasons. The way to have things deleted is through the AFD/MFD/FFD/CFD/TFD/"XFD" process. You may and in many cases should batch-nominate related items in a single deletion discussion. davidwr/(talk)/(contribs) 21:52, 19 March 2014 (UTC)

New type of block: "all edits require approval"

Problem:

Some school- and public-library IP addresses (such as User talk:65.115.61.236) have to be blocked for abuse by immature editors, forcing more responsible editors who want to edit from those computers to create an account whether they want to or not.

The need:

Make it easy for anyone to edit from these computers without requiring them to log in, but without allowing disruptive edits from these computers to be visible by default.

Proposed solution:

IP addresses with a history of not understanding Wikipedia's rules but who are not clearly editing in bad faith can have their accounts marked "all edits require approval" instead of being blocked entirely.

If a page that was not otherwise protected by any level of pending-change protection is edited by an editor whose account or IP address has an "all edits require approval" "block" on it, the edit is not visible. "Held edits" would function just like not-yet-approved pending changes, except that any account or IP address without an active block (either a regular block or an "all edits require approval" "block") can approve the edit, and editors who are not subject to an "all edits require approval" "block" would have their edits automatically approved.

For pages protected by pending changes or pages which the editor cannot edit (e.g. fully-protected pages and, for non-logged-in and non-autoconfirmed editors, semi-protected pages) this system would be irrelevant.

Other uses:

This system can be applied to immature logged-in editors who repeatedly edit disruptively but not in bad faith, as an alternative to a block or ban.

Request for the community:

I'm looking for high-level technical and other feedback and alternative solutions before sending this to Wikipedia:Village pump (proposals) for consensus and, if approved, to Bugzilla for implementation. davidwr/(talk)/(contribs) 21:46, 19 March 2014 (UTC)

This seems like either (a) a ton of technical work to re-implement pending changes on a per-user rather than per-page basis or (b) dependent on, well, having pending changes everywhere. I'm not convinced the benefit would be equal to the amount of effort required. Ironholds (talk) 18:10, 20 March 2014 (UTC)
One technical way to implement this would be to have a lower-level "pending changes level 0" everywhere, in which all editors, registered or not, were approvers, EXCEPT those IP addresses (and possibly registered editors) whose accounts were downgraded to "all edits require approval" instead of being blocked outright. Technically, this would be relatively easy. Unfortunately, the term "pending changes" is an emotionally charged one on Wikipedia and the use of the term would be distracting to what, I hope, would be a straightforward way of reducing the number of blocks placed on IP addresses and the small number of good-faith-but-immature/perpetually-clueless editors (typically those with a maturity level below that of your average 14-year-old). davidwr/(talk)/(contribs) 18:46, 20 March 2014 (UTC)
Ironholds (and everyone else) - do you have an alternative solution to the problem that meets the "need" stated above? davidwr/(talk)/(contribs) 18:48, 20 March 2014 (UTC)
Encourage those helpful users to make an account. It's that simple. -- Ypnypn (talk) 19:47, 20 March 2014 (UTC)
  • This seems like a no (or very low) net positive for the project. It would be a lot of work (I'd see it requiring months if not years worth of RfCs to hash out all of the implementation details to a point where enough of the community would agree to it) for the occasional IP editor to not have to either create an account, request an edit be made on their behalf from the IP talk page, or wait to make the edit them-self from another location with an unblocked IP. — {{U|Technical 13}} (t • e • c) 20:00, 20 March 2014 (UTC)
    I agree. Not only would it be a lot of work to implement it, but simply using it creates more work (reviewing and then approving/reverting edits), all so we can possibly get a few good edits in between the numerous bad ones that we know we'd get. We should always be considering ways to help more people edit, but this would be taking that to an extreme in terms of cost/benefit. Mr.Z-man 21:52, 20 March 2014 (UTC)
  • Putting aside the technical questions raised above, I don't believe your solution fits your need. I really don't think black holing all of someone's contributions for what would be a random period of time makes editing easier for someone editing from these locations and who has not registered an account. I suspect it would lead to a lot of frustration for the editor. Resolute 22:06, 20 March 2014 (UTC)

Person articles should have birth/death years in the title

Suggest: Person articles should have birth and death years in the title if they are known. Reason: List of persons, such as authors, do not allow filtering or sorting. Consider the difficulty in getting a list of authors that died in 1940 from the list of authors page and the list of persons that died in 1940. — Preceding unsigned comment added by 99.18.175.187 (talk) 07:40, 8 March 2014 (UTC)

We shouldn't put it in the title unless it's directly needed (although I can't think of any examples offhand), otherwise it just screws with a lot of wikilinks, templates, etc. I don't have the technical know-how to write a script to do what you're thinking of, but I wouldn't think it'd be that hard to crawl the infoboxes and filter that way. Supernerd11 :D Firemind ^_^ Pokedex 23:38, 10 March 2014 (UTC)
Or get the info from Wikidata... --Izno (talk) 02:42, 11 March 2014 (UTC)
  • I know what this IP wants, but I'm unclear on their reason. Can you provide a use case where this would be useful? — {{U|Technical 13}} (t • e • c) 23:59, 10 March 2014 (UTC)
  • WP:Category intersection has been requested for years. WhatamIdoing (talk) 21:00, 11 March 2014 (UTC)
    • I know I'm preaching to the choir here, but the day that category intersections become a built-in part of Wikipedia, not an external tool (and especially not one with output as hardcore-looking as the one Obi-Wan links to below!) will be the day of a major evolutionary step for this project. Our category system is essentially still the same technology that Stan Silver invented for WikiWikiWeb in 1996. We need to move forward. — Scott • talk 18:57, 25 March 2014 (UTC)
  • Very simply, including a person in a category or page of lists (e.g., persons born in 1922) only lists the person's name as a link in the category page. This precludes any sort of simple filtering or searching. Constructing a birth-death index of authors by country is most useful in determining which of their works are in the public domain given country specific laws. — Preceding unsigned comment added by 99.187.85.197 (talk) 06:56, 24 March 2014 (UTC)
Just use category intersection. like this: "American writers" + "1922 births" or American poets + 1940 deaths --Obi-Wan Kenobi (talk) 19:02, 25 March 2014 (UTC)

New RfC about VisualEditor

I started drafting a new Request for Comments about whether to re-enable VisualEditor for anonymous users. While the previous proposal was clearly against this, in the past 7+ months there has been significant improvement to the feature, so the community may be willing to change its mind. What do you think? Is it too soon? -- Ypnypn (talk) 17:46, 11 March 2014 (UTC)

Anonymous users kind of makes up two classes. On the one hand you can be Anon and be a rather experienced editor. On the other hand you should be anon and be rather new. I wouldn't want to present this to someone who's rather new. I wouldn't be bothered if they had the ability to opt-in however. If they discovered VE and they wanted to try it out. I'm not sure what mean by present in question 2. Serialjoepsycho (talk) 19:28, 11 March 2014 (UTC)
You're right, the wording was unclear. I clarified the question. -- Ypnypn (talk) 19:36, 11 March 2014 (UTC)
This trivial but maybe you could add something in the background section or elsewhere. It seems to me not that you want VE to be right there as click option that can be turned over and anon can then use it. It seems to me wht you are saying is that if Anon's run accross info on this and they want to try it there should be some way that they can. Pick you own poison and all of that. Your not exactly advocating that anons use this but instead advocating that anon's should be able to use this if they find out about it and would like to try it.Serialjoepsycho (talk) 19:43, 11 March 2014 (UTC)
That's a good point. I added an option for enabling it for anons, but hiding it. -- Ypnypn (talk) 20:07, 11 March 2014 (UTC)
Too soon I think. But how about asking if development of VE should be ceased with the money spent re-appropriated elsewhere. Jason Quinn (talk) 02:43, 19 March 2014 (UTC)
Money already spent can't be re-appropriated elsewhere; although a time machine might help ;) Seriously, VE is already used on hundreds of other wikis, so completely getting rid of it is not an option. -- Ypnypn (talk) 03:39, 19 March 2014 (UTC)
Probably best to give it a year at least. The problem is no such if the software sucks or not but that the more active parts of the community have zero interest in cleaning up after it at this point.©Geni (talk) 17:37, 22 March 2014 (UTC)

Download links

Add please:

  • in articles about software -> on the very top place navigation/link connecting straight to downloading page on Hippo files or others

Change:

  • navigation -> when you click "Down" arrow you land under (seldom used) table instead near some interesting links like: External links:-)

Thanks for doing...

Wojtek:-) — Preceding unsigned comment added by Ronin12 (talk • contribs) 13:51, 22 March 2014 (UTC)

Download entire work should be available.

Suggest: Multipart works of fiction or non-fiction should be available as a single download. Reason: Larger works such as Robert E. Howard's "The Hour of the Dragon" have each of the 23 chapters as an individual web page. This requires a reader to download 23 different web pages for offline reading on an e-reader. Can there be a link on the page to download entire work as html or epub? This helps for works not available in epub or single html web pages and also not available on Gutenberg like sites. — Preceding unsigned comment added by 99.187.85.197 (talk) 07:02, 24 March 2014 (UTC)

Something like this? Which is linked to from the bottom of the The Hour of the Dragon article? Mr.Z-man 15:57, 24 March 2014 (UTC)

Geoblocked/region blocked websites

In my opinion geoblocked/region blocked websites have no business being linked to from wikipedia, especially as references. They are a barrier to use of wikipedia and I'd love to see them banned. I don't know well enough how wikipedia works to develop this into a policy idea on it's own, or even if it's technically feasible. — Preceding unsigned comment added by 115.188.135.11 (talk) 18:11, 25 March 2014 (UTC)

  • Against such a broad block, but in favor of scrutinizing these and replacing them with more suitable links if such links are available. I assume you mean web sites or portions of sites that block INCOMING traffic from certain countries or certain ISPs, such as some of the video-hosting at the BBC that is blocked if the web site detects you are trying to access it from outside England. I would be in favor of an unwritten practice of treating such sites as if they were either paywalled or they were offline resources like a book. Both paywalled sites and offline sites are explicitly allowed as references and both are allowed in "external links" and/or "for further reading" sections of articles, and for good reason. davidwr/(talk)/(contribs) 18:22, 25 March 2014 (UTC)
This sounds like the same basic idea as websites between paywalls: Using other ones are preferred, but these are acceptable (assuming they're good sources). Supernerd11 :D Firemind ^_^ Pokedex 18:28, 25 March 2014 (UTC)
There is of course a limit to this. At a certain point, it may become appropriate to challenge references which at in Military Libraries on North Korean Army Bases due to the inability for a willing editor with time and money to check the information.Naraht (talk) 18:49, 25 March 2014 (UTC)
Yes, websites that block incoming connections to their pages is what I'm talking about. I see geoblocking as distinctly different to access of paywalled or physical content as it is possible, if not immediately, for anyone to access those. However geoblocked content can be either impossible for some to reach by any means, and/or illegal to access from either or both the hosting and visiting countries perspective because the act of circumventing the geoblocking itself may be illegal. This creates a barrier to access that is impossible to overcome, rather than merely an inconvenience.115.188.135.11 (talk) 18:59, 25 March 2014 (UTC)
Some paywalls are in practice accessible only to small groups. In particular, paywalls associated with universities may only be accessible to students, employees, etc. If paying five-figure tuition is the price of getting access isn't something available to "just anyone." davidwr/(talk)/(contribs) 19:41, 25 March 2014 (UTC)
Discouraging use would be fine, but a total prohibition would be counter-productive. It's better for something to be referenced to a source that's difficult to verify than to be left completely unreferenced. Besides paywalls, you could also make similar arguments for websites in foreign languages and books/periodicals not available online. Getting someone to check a website that's only available in 1 country is probably going to be easier than getting a copy of a local newspaper from 1985 or a book that's been out of print since 1950. But proposing to ban references to things not available online would just be ridiculous. In this case, they are available online, just not to everyone. Mr.Z-man 19:49, 25 March 2014 (UTC)
The assertion that it is impossible or illegal to access geoblocked sites is wrong. It's merely difficult and expensive. You access it the same way you access physical materials in a library: you physically travel to the place where the material is accessible.
More relevantly, if you want to double check that a listed source really does support the material, then ask another editor to take a look. There are editors from all over the place, and what's blocked for you will be accessible to others. WhatamIdoing (talk) 21:02, 25 March 2014 (UTC)

Will my idea work?

I have an idea called PrePress and EasyDefine.

PrePress

Pie

PrePress. You might feel annoyed sometimes when you have to press a link to find out something. Never fear, PrePress is here. When you hover over a link it will give a summary of what the page says!!!

EasyDefine

supercalifragilisticexpialidocious

Is wikipedia to complicated for you. Does the simple english encyclopedia not have enough information? Never fear, EasyDefine is here. Just hover over a link with the distinctive dots on it and hover over and voila! The defination is there!

NOTE: Text formatting doesn't work. Also I would like to make a template for PrePress(I am well aware that EasyPostf has its own template already)

Please give me feedback. ZSpeed (talk) 21:50, 11 March 2014 (UTC)

Go to Special:Preferences#mw-prefsection-gadgets and click the item under ==Browsing== that says, "Navigation popups, article previews and editing functions popup when hovering over links". I think that will do most of what you want. WhatamIdoing (talk) 21:58, 11 March 2014 (UTC)
I think there are a number of browser addons like your prepress. There are also dictionary addons.Serialjoepsycho (talk) 01:13, 12 March 2014 (UTC)
I use a Firefox plugin called CoolPreviews that has functionality similar to what I think you want PrePress to do. Also Wikipedia already has something similar to EasyDefine for abbr ({{Abbr|abbreviation|definition}}). I find both CoolPreviews and the abbreviation template invaluable, but I don't think we want to clutter up MediaWiki or Wikipedia with custom interface elements that may potentially throw off some users, especially since those customizations are already covered by plugins and existing facilities. Not bad ideas, but I think the needs are already met. — Frεcklεfσσt | Talk 13:40, 12 March 2014 (UTC)
@ZSpeed: Re: PrePress - Check out the new Hovercards feature, now available in your Special:Preferences#mw-prefsection-betafeatures. :) –Quiddity (talk) 01:18, 27 March 2014 (UTC)

Suggestion: Wikipedia Two

Please forgive me if this is an inappropriate question, but has anyone considered adding a "Wikipedia Two" to the Wiki family of editing efforts? I was looking for information on the Dodd-Frank bill and opened the page at:

http://en.wikipedia.org/wiki/Dodd%E2%80%93Frank_Wall_Street_Reform_and_Consumer_Protection_Act.

Was distressed to see, "This article may be too technical for most readers to understand. Please help improve this article to make it understandable to non-experts, without removing the technical details." This seems to be a plea for "dumbing down". Sometimes, professional vocabulary is needed to give full information on a complex subject. The vocabulary, itself, may be what the reader is looking for in the process of self-education. The populist flavor of the Wiki-verse is one of its most important features, but couldn't there be a place for technical documentation as well? — Preceding unsigned comment added by 50.135.79.178 (talk) 20:41, 22 March 2014 (UTC)

Hello, I think that splitting efforts would hurt the project. Articles on technical issues could have an introductory section. --NaBUru38 (talk) 13:05, 25 March 2014 (UTC)
Another possibility is to have the "This article may be too technical" automatically generate a request to create the equivalent article in simple.wikipedia.org.Naraht (talk) 18:51, 25 March 2014 (UTC)
This reminds me of the discrimination between Micropædia and Macropæadia in Encyclopædia Britannica. We could use Simple English for the basic definition of a term or on a subject and English Wikipedia for in-depth information.--93.192.3.203 (talk) 00:32, 28 March 2014 (UTC)
Right. We've already split enough, with Wiktionary providing just definitions and Simple English Wikipedia providing dumbed down versions. Some realignment might be in order but the main reason we can't get much use out of these already existing small auxiliary wikis is that few people have made the effort to make them effective. Jim.henderson (talk) 00:40, 28 March 2014 (UTC)

WP:NPOV and WP:UNDUE in Crimea-related articles

There is currently a lot of edit warring going on with articles that have something to do with the status of Crimea. People putting in the Russian claim, reverting it with the Ukrainian claim, trying to make the discussion more neutral, getting reverted claiming NPOV and UNDUE issues. You probably get the idea?

I'm wondering how this solution could be solved in a way that adheres best to Wikipedia policies. From what I've seen, there are three main "camps" in the edits:

  1. Those that say Wikipedia should reflect the de facto reality: It's part of Russia in actual practice, even if not widely recognised as such.
  2. Those that say Wikipedia should reflect the views of the wider international community: It's a part of Ukraine de jure, and most countries recognise it as such, despite the real situation on the ground and despite the claim by Russia and the (so far minor) international recognition of that claim.
  3. Those that say Wikipedia should not choose between these alternatives, but present both points of view equally.

My main concern with 1 and 2 is that it doesn't reflect that a dispute exist. It's "taking sides" which is against WP:NPOV. But the argument against 3 has been made that it violates WP:UNDUE, because the Ukrainian claim has wider international recognition. A "compromise" I've seen in a few articles is to state the Ukrainian claim first, and the Russian one after it in parentheses, so something like "... is a city in Crimea, Ukraine (disputed/claimed/whatever by Russia)". It seems like a decent solution but it doesn't sit right with me, because it still amounts to Wikipedia taking a stance on which claim is more valid, which we shouldn't be doing.

I feel that in some way, the issue is about which Wikipedia policy takes precedence over which. Should we give more weight to UNDUE concerns, and follow the wider international community, or should we go with wider NPOV concerns and treat both sides as equal partners in the dispute? CodeCat (talk) 20:21, 21 March 2014 (UTC)

  • We must hold to NPOV. Both claims must be presented. No side can be taken. We can state that most of the international community considers the annexation illegal, and we can also state that Russia considers it legal by virtue of various precedents and documents. But we cannot minimise either side in the dispute. We can merely state what has happened, and allow the reader to interpret that as they will. RGloucester — ☎ 20:33, 21 March 2014 (UTC)
  • Indeed, both claims must be presented equally. The fact that the whole world (minus Russia) recognizes the Ukrainian claim and the fact that Russia is actually controlling the territory while the Ukrainian official presence there is minimal to non-existent have very comparable weights, as far as neutral coverage is concerned. The actual control is of paramount importance in the issue and including information about it in no way, shape, or form violates UNDUE.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); March 21, 2014; 20:46 (UTC)
    • (in reply to both) What I'm also wondering about is how to handle this practically with any Crimea-related topic. For example, how do we formulate this with every town and village that has an article? We probably don't want to waste too many words on describing the dispute in every single article, as it's probably not relevant in the majority of cases. So how do we phrase it concisely in articles such as Kerch (which, as of right now, has the "compromise" approach I mentioned, stating Russia's claim in parentheses)? CodeCat (talk) 20:53, 21 March 2014 (UTC)
      • I've seen "Ukraine (de jure), Russia (de facto)" added to such articles' infoboxes, and I personally was changing the lede to say that such and such place is located "in the Autonomous Republic of Crimea, Ukraine (claimed by Russia as the Republic of Crimea)". I don't see what else we can do in articles about populated places. Administrative divisions should definitely continue to represent the Ukrainian status (with a similar note, perhaps), because Russia is all likeliness is going to re-incorporate the administrative/municipal divisions in accordance with its own laws. When that happens, it would become possible to create separate articles for such Russian divisions (see a conversation I had earlier today at Talk:Krasnohvardiiske Raion about this exact problem). This will allow us to separate the Russian/Ukrainian entities the same way the Republic of Crimea and Autonomous Republic of Crimea are currently separate. I'm open to suggestions, of course, and things are changing so rapidly that we may need to think up a different solution entirely.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); March 21, 2014; 21:00 (UTC)
I'd advocate for just saying: "in Crimea". Add the qualification that the territory is disputed, but that Russia has de facto control. What did we do for South Ossetia and Abkhazia? RGloucester — ☎ 21:07, 21 March 2014 (UTC)
There have been several discussions about the fate of the Crimea article, but from what I've seen, the consensus is moving towards having three articles: Crimean Peninsula, Autonomous Republic of Crimea (Ukraine's entity), and Republic of Crimea (Russian entity), with Crimea (disambiguation) being moved to "Crimea". If that's indeed the outcome, your solution will not work. There's also a matter of infoboxes, which typically contain division and country information (and which are the first target for extreme POV edits). Now, I personally have no problem with solving this by removing the infoboxes altogether until the region stabilizes (in fact, I proposed exactly this a while ago at Talk:Sevastopol#Status change), but I'm afraid others may not share my enthusiasm for such a drastic solution!—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); March 21, 2014; 22:23 (UTC)
I have been part of those discussions, and that is not what is being proposed. What is being proposed is to have the present Crimea article moved to Autonomous Republic of Crimea, and then move Crimean Peninsula to Crimea to serve as a general article. My proposed to solution is not to mention politics at all, but merely present a link to the general Crimea article, which presumably can explain the political situation. RGloucester — ☎ 14:25, 22 March 2014 (UTC)
  • This is taken from the article for Tskhinvali, and I think it serves as a good template:

"is the capital of South Ossetia, a disputed region which has been recognised as an independent Republic by Russia and another four UN members. South Ossetia is a de facto independent state that controls its claimed territory, in part with the support of Russian troops. Despite this, it is recognised by all other UN members as part of Georgia." RGloucester — ☎ 21:09, 21 March 2014 (UTC)

    • I think that's a bit too long to have to copy-paste into every single article about something in Crimea. I do like what Ezhiki mentioned though: "Ukraine (de jure), Russia (de facto)". It's short, concise, and gets the point across, hopefully. CodeCat (talk) 21:11, 21 March 2014 (UTC)
The ideal situation is not to even mention the state entity. Merely mention "Crimea". Once we have a general Crimea article up and running after the requested move is finished, the link to "Crimea" will presumably explain the dispute, making it needless to go into depth on the pages of minor towns and villages. RGloucester — ☎ 21:24, 21 March 2014 (UTC)
  • We need to present content in an NPOV way. I agree with Ezhiki and RGloucester's arguments. Everyone agrees that Crimea is a peninsula on the northern coast of the Black Sea, but beyond that -- both Ukraine has a claim, rooted in Ukrainian and international law, and Russia has a claim, rooted in Russian law and the concrete fact of the Russian occupation. I would lean toward presenting the Ukrainian claim first in most cases, such as for populated places in Crimea, but I think presenting the Russian claim in passing, parenthetically, or buried in a separate paragraph lower on the page is inappropriately assigning undue weight. -Kudzu1 (talk) 23:48, 21 March 2014 (UTC)
  • It was my understanding that we generally went by the views of the wider international community, and that that's the reason, or at least a large part of the reason we call the Palestinian territories occupied rather then disputed. Emmette Hernandez Coleman (talk) 23:34, 27 March 2014 (UTC)
  • I agree with Emmette Hernandez Coleman and furthermore, I don't think alternative 1 or 2 doesn't reflect that a dispute exists. For example, saying that Yalta is in Crimea, Ukraine but occupied by Russia after the conflict would reflect it. --IRISZOOM (talk) 01:16, 29 March 2014 (UTC)
  • I am in agreement with RGloucester and Kudzu1. This NPOV sensitivity applies not only to Crimea-related articles, but also to nearly all biography articles on past and present people from disputed areas (including Scottish and Welsh), and I have not yet found a Wiki policy, past discussion or arbitration covering this issue. In my view, root of the problem is the act of categorizing place/people/things requiring a point of view from which to make the determination on how to call them. May I invite all of you to this nationality side of discussion at Wikipedia talk:WikiProject Biography#Nationality of people from disputed territory/country/colony/region ? Yiba (talk | contribs) 13:15, 31 March 2014 (UTC)

technical articles: accessibility to general reader

I'm currently editing a technical article Genetic resistance to malaria. It has a maintenance tag placed by me, {{technical}}. I think it's a fair assessment of a significant problem. The problem occurs at multiple levels: vocabulary, particular concepts (like 'reducing chemical reations' and 'protein polymorphisms') as well as implied specific background knowledge (Darwinian selection, cellular biology, hematology, etc).

The issue is accessibility to the general reader. Who's a 'general reader'? I received my first set of (printed) encyclopedias when I was 7, and we donated them to a school when I was in my mid-teens. I think the paradigm somewhat limited when applied to wikipedia. I think many more adults read wikipedia. The average American adult has a highschool education, no more, and only a weak background in technical subjects. 'Genetic resistance to malaria' is not accessible as it stands to such a reader. I have a post-grad college education and substantial reading knowledge of the subject (now), and major portions of it are not understandable to me, still. As it stands it is accessible only to those who devote their lives to biological or medical careers. That is, those who would be capable of writing the article, or their peers.

My objective is to rewrite the article to make it accessible to the general reader. In the vernacular, that means 'dumbing it down', starting at the bottom: vocabulary. I've collected a lexicon of words I either don't know, or are at the fringe of my vocabulary Talk:Genetic resistance to malaria#lexicon with regard to technical maintenance tag, from the text of the article. Among a few other erudite editors I tried them on, each knew only a handful of them, so I think the list is representative of a real difficulty. While some of the words in the article should be replaced with vernacular, others cannot readily be replaced without awkward circumlocutions, and loss of specificity. I propose for this issue, to construct a glossary (there are about 100 words), which would be a kind of appendix (trailing section) to the article. I've not heretofore seen this in wikipedia, though it is common in books, and occasional in long magazine articles. Other alternatives are not wholly satisfactory: wikilinking terms to other articles even more dense than this one doesn't help; cross-linking to wictionary means having to load a new page (many including me, are on dialup modems), then reload the original page to get back; if either page has graphics, it can cost many minutes per link and there may be multiple links per sentence I need to look up. For most words, a concise definition relevant to the topic of the article, is all that's needed. For example, a general definition of "reducing (chemical reaction)" is hardly relevant to what it means in the context of cytoplasm, when the reaction is maintained not by a chemical, but by an enzyme. That definition is very specific. What I don't want to happen, is to spend days or a couple of weeks to construct a technical glossary, and have another editor summarily delete it as off-topic, or excessively detailed, or some such.

But more than that is needed. The general background necessary to understand this article is substantial. It can be made reasonably accessible if some of that background, like what 'genetic resistance to disease' means, the general structure of hemoglobin, and basics of cellular structure and function, were explained in the article. Maybe these could be sidebars of a few paragraphs. Yes, they drift into the topics of other articles (even more dense than this one - that's why I don't refer to them). Even in professional papers, there's often a background section, for those who aren't up on the field, or sidebars to give a basic description of concepts used in the article (like the lifecycle of malaria, for example).

I once found a medical wiki, where all the technical terms, when moused over, gave a one sentence definition in a pop-up highlighted box, with a [more] link - when clicked, the link popped up a larger box with a few paragraphs of detailed explanation, like a subsection of the article itself. That article was very pleasant to read, and eminently accessible to the nontechnical reader, solely because of that. I propose that as an alternative to the appendix-style glossary and sidebar boxes.

What do other editors do, or do we do anything?Sbalfour (talk) 21:22, 30 March 2014 (UTC)

You might be interested in Wikipedia:Tools/Navigation_popups.©Geni (talk) 23:22, 30 March 2014 (UTC)
Sbalfour, mostly we complain that good writing is difficult. You might want to look over WP:Making technical articles accessible. WP:MEDMOS might provide a tiny bit of help. But my most important suggestion is that you drop by WT:WikiProject Medicine and say hello, because we're all interested in these subjects, and we like meeting people like you. WhatamIdoing (talk) 19:01, 31 March 2014 (UTC)

Accounts claimed as former accounts with lost passwords

I recently came across a user who claims to be the owner of three previous accounts, all of which have irretrievably lost passwords. In this particular case there is no reason to suspect that the accounts are not owned by the same person. Assuming that is true, those three accounts will be just sitting around forever just waiting to be hacked. Does it make sense to block those accounts indefinitely (with user notice)? The only risk I can think of is user impersonation but I don't think that would be too common. Potentially a new item to Wikipedia:Blocking_policy#Protection could be added to green light blocking of clear cut cases of "dead accounts" at admin discretion. A template could give instructions for lifting the block or for account usurpation. Jason Quinn (talk) 04:14, 31 March 2014 (UTC)

Don't see a particular need to do this, to be honest. There are countless ' dead accounts' not being used, lost password or otherwise. –xenotalk 10:51, 31 March 2014 (UTC)
If the password is truly "lost" and not "compromised" then the only risk would be if Wikipedia allows (or in the future, ever allows) password resets via email or some other non-risky method. Password resets by email are somewhat risky as email accounts can themselves be compromised. I recommend putting a note on the supposed-editor's talk page explaining the possible risk and letting her know that she can request that these accounts be blocked as "possibly compromised." If she used a WP:Committed identity she may be able to get a new password set and sent to her. davidwr/(talk)/(contribs) 18:09, 31 March 2014 (UTC)
But absent a committed identity or some other confirmable method, how would we confirm that the user is actually the old user? Some troll could have old accounts blocked this way. –xenotalk 18:13, 31 March 2014 (UTC)
Good point. Perhaps if there was some intelligent review similar to the "WP:DUCK"-analysis that goes on in an WP:SPI, that could be useful. Absent a checkuser check (which would be stale unless the PW was forgotten very recently, and I doubt a checkuser would be allowed to get involved), it would require that both the "old" and "new" accounts have a long enough history for the analysis to be reliable enough to use. There are some things that can be compared, such as email addresses and possibly watch-lists, that an admin could use to tie two accounts together. davidwr/(talk)/(contribs) 20:29, 31 March 2014 (UTC)
I'm slightly puzzled as to why anyone would go to the trouble of hacking into a 'dead account' when we haven't (yet) run out of new ones. Even if they did, the account would easily be blocked if it misbehaved - as would be likely if used by someone who hacks into accounts. Any account that is disused long enough for the password to be forgotten will probably not have made many edits anyway. More of a problem, to my mind, is the person who wants their user page deleted after many years of inaction, but they can't remember the password. In most cases, there's no desperate need for the page to go, but when a real name is used and/or identifying info is present, what can we do? Peridon (talk) 10:35, 2 April 2014 (UTC)

Research Idea: Investigating the impact of offline meetups on participation and productivity in Wikipedia

I'm putting forward an IEG Project Proposal to investigate how the interaction of Wikipedia members at offline meetup events such as Hackatons or Wikimania may have an effect on the productivity of those members and their participation in Wikipedia. You can read the project proposal here and I'd appreciate the input of community members who have visited these events before. Do you think there is a specific area of these meetups that would better reveal how participation is impacted? How do you define participation in Wikipedia? Any comments would be welcome! OSUBrit (talk) 21:05, 31 March 2014 (UTC)

Shortcuts during editing

Here is something that gets on everyone's nerves, when you go to ANI and you click the edit button, only to have to scroll down and up looking for that exact spot. Is there any way to make Wikipedia so you could select a section of a page (Like a discussion on ANI) while editing? It would make Wikipedia run a lot faster.

Thanks,

Happy Attack Dog (you rang?) 02:04, 2 April 2014 (UTC)

I agree that it's hard to find things in ANI. That notification that 'there is a discussion at ANI' (or at An for that matter - same problem...) is very annoying. Especially when you're looking into something after the archiving has taken place, and you have to search three pages to find the discussion you wanted. Peridon (talk) 10:22, 2 April 2014 (UTC)

Toggle references off in edit session

When editing articles, it is sometimes difficult to read the body text due to many and long (often longer than the text they refer to) inline references. What would be useful is a way to toggle on and off (or at least change text colour to a light grey) the content between <ref> and </ref> tags. This would make it much easier to spot and correct typos, spelling errors and poorly formed sentence structure during an edit session.

As an example, see this short paragraph from a recent article - Malaysia Airlines Flight 370 with the displayed body text in bold:

A joint search and rescue effort, later reported as the largest in history,<ref>{{cite web|last=Neuman|first=Scott|title=Search For Flight MH370 Reportedly Largest in History|url=http://www.npr.org/blogs/thetwo-way/2014/03/17/290890377/search-for-flight-mh370-reportedly-largest-in-history|publisher=The Two-way|accessdate=19 March 2014}}</ref> was initiated in the Gulf of Thailand and the South China Sea.<ref>{{cite web|url=http://www.bbc.com/news/world-asia-26541057 |title=Malaysia Airlines MH370: Last communication revealed |publisher=BBC |date=12 March 2014|accessdate=13 March 2014}}</ref><ref name=20140310cbcnews/> The search area was later extended to include the Strait of Malacca, Andaman Sea, and the Indian Ocean.<ref name=20140310indie/><ref name=Reuters>{{cite web|last=Grudgings|first=Stuart|title=Malaysia Airlines plane crashes in South China Sea with 239 people aboard: report|url=http://www.reuters.com/article/2014/03/08/us-malaysiaairlines-flight-idUSBREA2701720140308|accessdate=8 March 2014}}</ref><ref name="id">{{cite web|url=http://www.nst.com.my/latest/font-color-red-missing-mh370-font-indonesia-helps-in-search-for-airliner-1.504168|title=MISSING MH370: Indonesia helps in search for airliner|work=[[New Straits Times]]|date=9 March 2014|accessdate=9 March 2014|author=Tasnim Lokman}}</ref> On 15 March, investigators believed that the aircraft had first headed west back across the Malay Peninsula, then continued on a northern or southern track for approximately seven hours.<ref name="thestar18"/>

Is this, or something similar, feasible? Regards Lynbarn (talk) 15:24, 4 April 2014 (UTC)

I have no idea, Lynbarn, but I can offer some workarounds. First, do you have syntax highlighting turned on in your Preferences? While it doesn't color a ref in a single color, it does group some items together and it might help. In fact, you may want to contact the maintainers of the syntax highlighting feature and ask them to put refs in a single color.
Next, all refs can be named and moved to the bottom of an article. I won't give the syntax here, but I've done that in some articles I work on and it's made the raw wikitext incredibly easier to read. Just my $.02... — Frεcklεfσσt | Talk 15:51, 4 April 2014 (UTC)
Two more options for you, Lynbarn:
  • WP:VisualEditor hides (almost) all the wikitext. To enable it, go to Special:Preferences#mw-prefsection-betafeatures and tick the box. See WP:VisualEditor/User guide—most of it's easy to figure out, but some of it's very different (like using Control+k to make links, rather than typing [[ ]]).
  • WP:WikEd does snytax highlighting (and a lot more). Go to Special:Preferences#mw-prefsection-gadgets → Editing → WikEd. I used it for a while a few years ago and then gave up on it, but some people really like it. Whatamidoing (WMF) (talk) 17:18, 4 April 2014 (UTC)

Company page guideline

We have a guideline for medical articles focused on sourcing and a policy for BLPs focused on respecting their reputation. I'm wondering if we should also have one for articles about organizations, focused on WP:NOT (not advertising, a forum, etc.).

For example, often a marketing rep adds a huge Awards section and editors disagree on whether it should be deleted. Like the other documents that provide guidance for a sub-set of articles, the guideline for articles about organizations wouldn't introduce new rules, but would offer advice on how NPOV, V, etc. should be interpreted in various circumstances that are common on that subset of articles.

I got a draft started at User:CorporateM/Extant Organizations for discussion. I previously discussed this at User:Jimbo's Talk page and it seemed like it had at least some support. However since I have a COI with quite a few company pages, I won't do anything bold with it. If it is in fact a good idea, ideally someone else may take an interest in spearheading it forward. (or if it's a bad idea, let it flop) CorporateM (Talk) 21:08, 6 April 2014 (UTC)

IEG proposal on the category system in the English Wikipedia

I have submitted a proposal for an Individual Engagement Grant for the first phase of a project looking at the category systems in Wikimedia wikis. In this first phase I will research the nature of the English Wikipedia's category system, as the first step in designing ways to optimize category systems throughout WMF wikis. In later phases, I plan to

  • Research how readers and editors utilize the category system in the English Wikipedia.
  • Investigate the category systems in other language Wikipedias and in other WMF projects.
  • Explore the value and feasibility of using Wikidata as the basis for the category system across WMF wikis. If deemed appropriate by the community, work with the community to develop and implement this.
  • Utilize user-centered design methodologies to prototype various enhancements to the category system to improve the user experience. If deemed appropriate by the community, work with the community to develop and implement such enhancements.

If you would like to endorse this proposal, you can do so here. I would also appreciate any other feedback, pro or con, which can be posted here. Thanks! Libcub (talk) 05:48, 7 April 2014 (UTC)

Wikimania 2014 London: Promoting livestream using banners

Hello!

I'm leading the team organising Wikimania this year. As an outreach initiative, I am organising a track of presentations by notable speakers; so far I've confirmed Lawrence Lessig, Clay Shirky, Danny O'Brien (Director of EFF), Elizabeth Marincola (CEO of PLOS) to name a few, as well as Jimmy and Sue of course. All of their talks will be on aspects of Wiki*edia, how it functions, its role in education, the role of open licensing, wiki*edia and open access, wikidata, etc.

I'd like to promote the livestream of these talks via banners on en-wp during the conference itself. Does the community have any objection to this? Ignore for now the technical demands on the streaming servers - this is just about whether there are any problems in principle with promoting Wikimania livestreams using banners.

EdSaperia (talk) 15:31, 14 March 2014 (UTC)

Hi! I'd put a banner with a message like "The Wikimania 2014 conference has begun. Watch the presentations live." I prefer a more neutral message, rather than promote specific speakers or activities. --NaBUru38 (talk) 16:31, 17 March 2014 (UTC)
Yes, this is exactly what I plan to do, something like "Watch live presentations at Wikimedia's annual conference." EdSaperia (talk) 15:35, 23 March 2014 (UTC)
Yes the problem is that it uses banners. Using un screen real estate on something that 99% of our readers don't care about is a bad idea. Really rather than asking "Can I use banners for X?" you should be asking "can I do X without banners?".©Geni (talk) 08:22, 23 March 2014 (UTC)
Well, Wikimania is customarily promoted via banners anyway. This would just extend that to livestreams of keynote talks, which should be interesting to a lot more people than an invitation to buy tickets to an event, and I think is a great opportunity to get new people interested in the projects. EdSaperia (talk) 15:35, 23 March 2014 (UTC)
I think there is no need to add the to the banners. What streaming tech are you planning to use seeing that Commons:Commons:Requests for comment/MP4 Video came down pretty anti MP4?©Geni (talk) 13:49, 31 March 2014 (UTC)
As written in the opening post, this question is specifically about the banners, not any technical requirements. FWIW I quite like the idea, I think it would engage readers in aspects of Wikimedia that they don't otherwise hear about and could even bring in new editors depending on the talk's content. Sam Walton (talk) 12:10, 11 April 2014 (UTC)

Links

  • Would be great if there was a button to share wikipedia pages to Twitter, Facebook, Google+ (the usual) in the same way that news website articles. - SA 07:41, 11 April 2014 (UTC) — Preceding unsigned comment added by 79.97.163.125 (talk)
See Wikipedia:Perennial proposals#Share pages on Facebook, Twitter etc.
  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. PrimeHunter (talk) 12:44, 11 April 2014 (UTC)

Watchlist management

I know there are already a lot of things to click on on the watchlist page but I'd like to see one more. Can we add a button or star that removes the associated article from your watchlist? I struggle to keep my watchlist to a reasonable size and sometimes I just want to blast stuff off my watchlist without having to visit the page (or one of the watchlist editing pages). ~KvnG 19:14, 29 March 2014 (UTC)

Try mw:Snippets/Unwatch from watchlist or one of the wp:userscripts built for this purpose. –xenotalk 19:25, 29 March 2014 (UTC)
I'm not sure I understand this query. If you're not on the watched page itself (in which case, just 'unwatch'), how can you have a button that associates with a particular page? I could do with clearing some of MY watchlist, but where are 2000 odd buttons going to be put? Peridon (talk) 10:40, 2 April 2014 (UTC)
@KvnG: You could try user:js/watchlist. -- Toshio Yamaguchi 11:08, 13 April 2014 (UTC)

Font Pages

What if all the pages about fonts were actually written in the font they are talking about! Is it a good idea? ZSpeed (talk) 14:36, 12 April 2014 (UTC)

I am waiting for this to be applied to the Wingdings article. -- Toshio Yamaguchi 23:17, 12 April 2014 (UTC)
<serious>I don't think it is a good idea. Wikipedia is an encyclopedia and the content should in my opinion be presented in a uniform way, as using different fonts for such articles might be distracting.</serious> -- Toshio Yamaguchi 23:26, 12 April 2014 (UTC)
Early versions of our article Gadsby (novel) were written without using the letter 'e'. Consensus was that this was not a good idea.-gadfium 23:54, 12 April 2014 (UTC)
It's a bad idea. {{Infobox typeface}} has parameters to display images with the font. That's a good idea. PrimeHunter (talk) 00:03, 13 April 2014 (UTC)

About new user group

Invited UserーーーThe member who pays 240 dollars a year or more as a registrant of donation to the wiki foundation, mailman and (directly associated site). --shiroikabe 08:17, 11 April 2014 (UTC) — Preceding unsigned comment added by Shiroikabe (talk • contribs)

Why? What rights would such a user receive as a result of their donation, and why would these rights not be suitable for a non-donator? Sam Walton (talk) 12:19, 11 April 2014 (UTC)
@Shiroikabe: Thank you for your donation and your support of open-source projects. However, I don't feel such discrimination is a good idea, since everyone is invited to Wikipedia, in fact. Also, GNU Mailman is not related to "associated with" the foundation in any way, and Wikipedia is only using it to deliver various emails, if that's what you mean by "mailman". Zhaofeng Li [talk... contribs...] 07:42, 13 April 2014 (UTC)

I think the measures that I suggested about User which did the donation that is suitable for User which there is me with a regular member of mailinglist, and paid suitable money, the Wiki foundation to take measures.--shiroikabe 22:52, 14 April 2014 (UTC) — Preceding unsigned comment added by Shiroikabe (talk • contribs) --Shitoikabe (talk) 00:57, 15 April 2014 (UTC)

Allow original research in articles protected by level 2 pending changes protection

Sometimes people discover new things in math that would speed up math research if they're added to a Wikipedia article. The original reason for not allowing original research was probably because people sometimes make mistakes and write a false or unprovable statements when they do original research, such as the highlight red text here and solving for a physical quantity x in our universe as follows: sin(x) = 1/2 ⇒ x = sin-1(1/2) ⇒ x = π/6 when it turns out that x = 5π/6, but an untrue statement is so much less likely to be written by doing original research when the article is protected by level 2 pending changes protection. In fact, some article should even become level 2 pending change protected so that people can discover and write new things without risking adding a false statement to the article, speeding up research. For example, if Exponentation had that protection, I would feel free to add in a very useful piece of information such as 'The property (bm)n = bm⋅n doesn't hold for complex numbers. For instance, ((-1)3)1/2 = (-1)1/2 = i ≠ -i = (-1)3/2 = (-1)3⋅1/2.' Maybe Wikisource could make a change of adding an entry for each Wikipedia article with level 2 pending change protection to carefully research which statements that people want to add in are true and which ones aren't. Blackbombchu (talk) 17:01, 15 April 2014 (UTC)

I think you misunderstand why original research isn't allowed. The things you've written above should be in their articles regardless of the protection on them if reliable sources have written the information. There's no room for writing your own ideas, your own derivations, etc. since Wikipedia fundamentally reports what reliable sources have said so that we keep focused on notable topics and know for near certain that the information we're writing is true - saying 'Yeah this is my own research but it's right, honest' just isn't good enough. Sam Walton (talk) 19:03, 15 April 2014 (UTC)
Wikipedia:No original research is a stricter policy than Wikipedia:Verifiability. I was only trying to argue for exceptions to the Wikipedia:No original research policy, not argue for exceptions to the Wikipedia:Verifiability policy which arguing Yeah this is my own research but it's right, honest would be doing. Blackbombchu (talk) 19:34, 15 April 2014 (UTC)
The problem is that verifiability and original research are linked by being directly opposite to each other. "The phrase "original research" (OR) is used on Wikipedia to refer to material—such as facts, allegations, and ideas—for which no reliable, published sources exist" - "verifiability means that people reading and editing the encyclopedia can check that the information comes from a reliable source." These are directly incompatible concepts. Sam Walton (talk) 20:00, 15 April 2014 (UTC)
Why are those two incompatible? On the contrary, I'd even go as far as saying they are actually in a sense the same. NOR requires that material added to an article is directly attributable to a reliable source. Verifiability means essentially the same. -- Toshio Yamaguchi 21:19, 15 April 2014 (UTC)
I believe that Sam Walton meant that original research itself is incompatible with the verifiability policy, not that NOR is incompatible with it. Novusuna talk 21:39, 15 April 2014 (UTC)
Yeah that's what I meant :) Sam Walton (talk) 22:40, 15 April 2014 (UTC)
I do want thank OP for posting here, rather than Proposals. Thanks.--S Philbrick(Talk) 21:49, 15 April 2014 (UTC)

Cross-entity community portal

I believe it would very much be in everyone's best interests if we could somehow create a "community" portal for all the WF entities, which could appear maybe just below the existing project-specific community portal of each of the sister projects. It could indicate current drives, collaborations, etc., on them, among maybe other things. I think such would increase SOE of the sister projects, increase the chances of inter-project collaboration, and with luck decrease the number of unencyclopedic articles here while also maybe help increase their quality there. One possible early effort might be to get as many of the best PD sources around at Commons and/or Wikisource, for easier access to them. How would I go about trying to get such a portal on the English wikipedia, and are there any other things it could/should do? John Carter (talk) 18:20, 3 April 2014 (UTC)

Do you know Meta? --NaBUru38 (talk) 16:28, 17 April 2014 (UTC)
Yes,but how many people check it regularly? Something on the WF's busiest site would probably get much more attention, particularly from newer editors. John Carter (talk) 00:30, 19 April 2014 (UTC)

Collaborative editing even before the start of an article (gathering refs for notability)

Often articles are removed because they have not established notability. Most of the time this is very good and 95% of articles removed for this reason will never be notable. That however leaves the 5% that will be. I think it would be useful if the collaborative editing process on an article could be started even before the article itself and by that I mean if there would be a way to submit valid references related to a matter that yet hasn't got an article on Wikipedia. I guess to not make this an amazing spamfest the proposed refs would have to be accepted and verified by admins or something like that. If there was such a review admins could even rate the "goodness" of the ref(s) and when a threshold of ref goodness was reached a stub would automagically get created, proposed or something. How's that for a crazy idea? Palosirkka (talk) 16:26, 17 April 2014 (UTC)

It's a nice thought, but the closest I can think of that'd be feasible is to make a user subpage and invite other editors to contribute. As for the automatic part, someone might be able to write a script for it, but not sure how good that'll fly what with blacklisted urls and the previously mentioned spamarama. Let me know if you can get something like this set up, I'll be happy to help! Supernerd11 :D Firemind ^_^ Pokedex 00:43, 19 April 2014 (UTC)
Just a note that we already have WP:Requested articles where posters are asked to provide sources along with the entries. Zhaofeng Li [talk... contribs...] 13:46, 25 April 2014 (UTC)
I've started a few pages in Category:WikiProject lists of encyclopedic articles showing articles and subarticles in a few reference sources. Such lists will obviously never be current,but they can be at least a starting point for some potential articles. John Carter (talk) 14:13, 25 April 2014 (UTC)
Hello! There's drafts, perhaps that will work. Good luck! --NaBUru38 (talk) 01:46, 29 April 2014 (UTC)

Curiosumé - open protocol using Wikipedia entries as ontology for personal data matching

Any suggestions about who or where to share this information are appreciated.

Curiosumé article (draft)

This explains an open Internet protocol that utilizes Wikipedia entries as an ontology for personal data matching.

Prototype software is being developed, providing the features described in this article.

Feedback and involvement from Wikipedia and Mediawiki would be helpful at this point in further developing the ideas described here.

Excerpt:

An open protocol extending the conventional résumé / CV as a means for describing one’s interests, skills, abilities, and intent with respect to semantic web resources and other metadata (such as spatiotemporal location).

The word is a portmanteau of the words curiosity (representing desired skills, which can be learned) and résumé (representing acquired skills, which can be taught).

Resources defined by Wikipedia cover most conceivable topics and offer multilingual translations. Hierarchical categorization and heterarchical associations (wikilinks) between topics allows for partial relevancy comparisons.

Sseehh (talk) 17:00, 25 April 2014 (UTC)

I couldn't understand that article, and I'm fairly technologically adept. I see that it was rejected as an article (which I agree with). IIWY, I would move it to Draft:Curiosumé, where it can stay indefinitely. You can let it stay there and wait and see if the idea catches on. If it does, you can enhance it with better references and move it to article space. — Frεcklεfσσt | Talk 18:29, 25 April 2014 (UTC)

simple pop-up when hovering the mouse over hyperlinks

hello,

currently: when we hover/move the mouse over any blue words (hyperlink:when clicked will direct user to another page in wikipedia) a pop up text will appear containing the title of the directed page.

suggestion: include some more brief info in the pop up box. for example, when im on this page (http://en.wikipedia.org/wiki/Mood_congruence), and then hover my mouse to the word 'psychiatry' for a few sec, a pop up will appear with containing the word 'Psychiatry'. It would be better if the pop up can include also a brief info taken from the targeted page. In this case i suggest the pop up also show info such as this:

PsychiatryItalic text Psychiatry is the medical specialty devoted to the study, diagnosis, treatment, and prevention of mental disorders, among which are affective, behavioural, cognitive and perceptual abnormalities.


Regards, Tom Bishop — Preceding unsigned comment added by 202.170.48.13 (talk) 14:12, 11 April 2014 (UTC)

You get your wish. Register an account, click on the Beta link on the top of every page, and select Hovercards (More information here). Please tell the developers what you think! Zhaofeng Li [talk... contribs...] 07:26, 13 April 2014 (UTC)
There's also a gadget if you register: Go to Preferences ==> Gadgets tab ==> Browsing section ==> Navigation popups. I live by that here! Supernerd11 :D Firemind ^_^ Pokedex 17:09, 17 April 2014 (UTC)
Popups conflicts with hovercards I am sad to say. Dustin (talk) 13:59, 20 April 2014 (UTC)
Yea, it's an either/or thing, forgot to mention that. I personally prefer the navigation popups over the hovercards because of the other stuff that it gives you, like a way to access the history right from the link. Supernerd11 :D Firemind ^_^ Pokedex 16:00, 20 April 2014 (UTC)
Eventually, we want to bring in the functional actions from the gadget into hovercards. Could you please add your comments here - https://www.mediawiki.org/w/index.php?title=Talk:Beta_Features/Hovercards&workflow=rt4khfuq1svh8sx3. Tom Bishop — Preceding unsigned , hope you are using the hovercards beta feature. Thank you very much. Vibhabamba (talk) 20:26, 23 April 2014 (UTC)

Are we talking about the little boxed popup that happens when we hover on a cite index? It seems somebody thought it would be nice to put a little arrow at the bottom of that, located over the cite index being har\\overed. Problem: The little arrow gets disconnected on an incoherent basis depending on the order selection of the cite indices. Check this picture:

  •  
    Shows indicator arrow separated from cite-index hover box

You can see the little arrow far to the left on the page margin. I'm using Iron 27 in W7HPx64SP1. Gordon | Talk, 07:04, 4 May 2014 (UTC)

Vertical navigation templates turned into horizontal navigation templates

Multiple vertical navigation templates on the same article ruins the layout and readability of the articles. Even when there is just one vertical navigation template it conflicts with lead images, infoboxes and more. On the other hand horizontal navigation templates are unobtrusive and non-disruptive, especially the collapsible ones. How can we change the vertical templates into horizontal templates?

Given the number of such templates and the number of articles that are carrying them it may require bots and stuff to clean this up. But, waiting longer to fix this clear and evident problem will only aggravate the situation. Aditya(talk • contribs) 17:49, 4 May 2014 (UTC)

  • Maybe first we should propose just changing the navbox templates and only if it is accepted, discuss how to achieve that. — Petr Matas 00:42, 5 May 2014 (UTC)

Monitor pages

Please glance at this COI discussion [[1]]. I'd love for there to be an independent (not editing in the category) monitoring body. Isn't a day go by I don't read text that grossly misrepresents the reference. Often in profitable ways. Sometimes the text goes 180 degrees back and forth!32cllou (talk) 06:23, 5 May 2014 (UTC)

Would you be willing to spend all of your time on Wikipedia verifying sources in a category that doesn't interest you enough to have edited in it? If you, despite being fully aware of the difficulty, are not doing this, then I have no hope that dozens of other editors would be willing to give up the areas that interest them to independently review the areas that interest you. WhatamIdoing (talk) 17:42, 5 May 2014 (UTC)
Thank you for replying. You express my difficultly. I frequently edit wiki because I read something that isn't true (want to do good for others). Fixed usually, I don't want to spend time maintaining. Often corrupted again. Seems like software could do most of the work. Within Wiki, I already very frequently see the problems created by having too few editors participating. I've gotten a meeting with a Foundation staff member.32cllou (talk) 19:40, 5 May 2014 (UTC)
If you're interested in increasing the number of editors, then Halfak's research indicates that automation is the opposite of what you want. Everyone already knows (and the data proves we're right) that being reverted drives away new editors (some older ones, too). Being warned for "vandalism" or other perceived infractions drives them away even more reliably. This is fine if you're driving away an obvious vandal. It's a disaster when you're driving away someone who could be turned into a good editor.
So what's changed between when I started and now? WP:Twinkle (2007) and WP:Huggle (2008) have made it easier to revert and dump canned warnings on the new editors' talk pages every time the new person makes a mistake. And guess what? Vandalism has stayed the same as ever, but four times as many warnings are being issued, and the retention rate for potentially desirable new editors has declined with the rise of the automated warnings. I suggest that you look into that research if you want to make progress on this. WhatamIdoing (talk) 22:33, 5 May 2014 (UTC)

Allow some double redirects

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.

The proposal is transcluded from a separate page, where it is being developed. Feel free to refine it or suggest improvements on its talk page. — Petr Matas 18:27, 2 May 2014 (UTC)

It seems that the proposal is mature. You can vote at proposals. Petr Matas 11:11, 7 May 2014 (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.

How to encourage newish editors to make small edits

The Superspreader mess is discouraging, partly because I can see it happening again. (For those not familiar with the problem, the issue in a nutshell - a student as part of a class assignment, made a large change to an article, which was reverted, and acrimony ensued. More at ANI and related pages)

The professor involved wrote a blog entry about it.

One of the positive take-aways - the student had worked up the potential edit in a sandbox, then did one large edit rather than a series of small edits. It is plausible that had the student started by making incremental edits, the result would have been very different (Another take-away is important, it would have helped had the class been registered. That might well be the more important best practice, but I do not have thoughts on how to make that happen more often, and this discussion is about the other issue.)

I wanted to start a conversation about whether there would be value in requiring smaller edits in certain situations.

If we accept that there are advantages to making edits in smaller increments in some situations, I can think of two ways of making this happen.

The first is to add such advice to the advice we generally give to edits. I won't check, because I bet it is there, but I have two problems with this suggestion. The first is that we have a massive amount of advice we give to editor, and adding this is like;y to be missed. (Doesn't mean it shouldn't be added if it isn't there, maybe someone will see it, I just don't want to pretend this is likely to have much effect). The second is that the problem is most acute with newish editors. Our experienced editors may have need to do a large edit, for a variety of reasons, but they are expected to know when a large single edit makes sense and when it does not. A brand-new editor is struggling with all kinds of new things, from markup to a dizzying array of alphabet soup rules, and there's no way I can justify this as one of the most important things on the list.

So I'm musing about whether there is a technical solution.

What if we imposed a limitation - any editor with fewer than n edits (400?) could not make a single edit which added (or removed?) more than n bytes (1000?). If they try, they get a message indicating that best practice for new editors is to make edits in smaller increment.

(Before responding, remember that this is the idea lab, not Proposals. An acceptable response to a proposal is "No" The idea lab, in contrast, is a place to develop proposals, so I would prefer answers like - "it would be better to...")--S Philbrick(Talk) 18:02, 6 May 2014 (UTC)

I don't know how you would do this, but I wonder if making multiple small edits would be a good goal for new editors anyway. When I was new-ish, someone complained at me for making "too many" small edits instead of one large one on a page.
What some (lazy?) reviewers really want is not "please make small changes", but "don't change too many parts of the article in one day" (and perhaps "never, ever rearrange pages"). It's okay to take one sentence and turn it into six paragraphs. It's easy to read the diff when one sentence is replaced by six paragraphs. It's difficult to read the diff when nothing lines up with the old version. Multiple small edits turn into the same nightmare of a diff in the end. Few of us remember to just read the new version of the article and see if it's okay, rather than trying to compare changes to individual lines. WhatamIdoing (talk) 20:13, 6 May 2014 (UTC)
I'm glad that this question is being raised. One of the other places it's being discussed is at WT:MED#Super-spreader student problem, where it's worth taking a look. In my mind, it's pretty difficult to generalize about what new editors, generally, should do in this regard. Some new editors make gnomish edits, and others write whole paragraphs or sections, and I think that either way can be welcome.
In this particular incident, the newish editor was also a student editor, on a student assignment, and that's significant. Student edits follow certain patterns that are distinct to student projects, and not like edits generally. There is typically an assignment, and it typically focuses on one page for the student. Thus, students very often create large amounts of content in a sandbox or draft space, and then suddenly move it into mainspace, where other editors see it for the first time. That's what happened here. WP:ASSIGN tries to give instructors and students some advice about how that can misfire. I think it would be very nice if some brainstorming here could lead to better ways to guide student editors, but I do see this issue as pertaining to students, specifically. --Tryptofish (talk) 21:37, 6 May 2014 (UTC)
I think Tryptofish's points relay the concept that these expectations for students are unrealistic. The idea of editors under an arbitrary edit count (which will be all of them) are limited in increments of so many kilobytes is simply unworkable. The super-spreader problem (in my opinion) was that the article's primary author didn't assume good faith and rather than be patient with the student, dug-in in opposition. This problem doesn't need a solution. We have guidelines, policies, and essays on all this stuff and none of it influenced that trainwreck. Chris Troutman (talk) 00:13, 7 May 2014 (UTC)

Edit count

Can we somehow provide a feature which automaically updates edit count of a user when it is previewed ? Zince34' 11:44, 2 May 2014 (UTC)

I'm a little confused about the "previewed" part. Is your goal just to have an easy way to find your own current edit count? If so, then that's easily done: Click here and read the fifth line in the first section, "Number of edits". There's a link to this page at the top of every single page if you're logged in.
If you want to get instant edit counts for other people, then there are several options, and perhaps you'll tell me what kind of a system you're looking for. WhatamIdoing (talk) 21:27, 2 May 2014 (UTC)
@WhatamIdoing: Well, I was talking about was not to show the user what the edit count is, but you know, in some templates they need the edit count, and the user has to update it manually. Zince34' 05:09, 7 May 2014 (UTC)
Ah, you want {{Service award progress}} to be auto-updating. It's possible that it could be re-written using the sort of approach seen in this user script. You'd need to find someone who knows a lot more about that sort of stuff than I do, though. WhatamIdoing (talk) 05:35, 7 May 2014 (UTC)
Exactly right. But, I think it can be used on a variety of templates, rather than just service award progress. Zince34' 10:38, 7 May 2014 (UTC)
It would require developers to add a magic word we don't currently have, and the count would only be updated when the page displaying or using the count is rerendered for some reason like an edit or purge. There may be performance issues with such a magic word so I'm not sure the developers would like it. PrimeHunter (talk) 10:53, 7 May 2014 (UTC)
Might need an alteration in the Mediawiki framework. It should work how an article shows up in a filepage as soon as the file is linked to it. Zince34' 11:08, 9 May 2014 (UTC)

Creation of a sort of "target protection" for redirects

There are some redirects on Wikipedia which have been fully protected due to target changing vandalism, among other things. One example is the redirect at Miami, Florida; I tried to add a categorization template, but I found the page to be fully protected. This is rather frustrating and unfair; only sysops can make edits to the categories on that page now. I don't know if it is even possible (at the moment) to only protect the part of the redirect where the target is given (on Miami, Florida, it would be the "#REDIRECT Miami" part) , but if it is, I think that it would be a useful addition. Does anyone have any ideas about this? I am the kind of person who would like to modify redirect categorization templates en masse, and I don't want to have to make requests to sysops about every fully protected redirect I come by. Dustin (talk) 14:15, 20 April 2014 (UTC)

Dustin, I'm afraid not. Protection applies to an entire article, there's no technical way to protect only part of it. — The Hand That Feeds You:Bite 16:55, 25 April 2014 (UTC)
Wikipedia:Requests for adminship/Dustin V. S. ? FYI I've lowered the protection on that redirect. How many more have you encountered? –xenotalk 17:11, 25 April 2014 (UTC)
I've encountered several others, but a few of them include San Diego, California, Boston, Massachussetts, and North Atlantic Treaty Organization; they all appear to have been protected for very similar reasons to Miami, Florida's protection. I will address this further later; I do not have much time. Dustin (talk) 01:12, 28 April 2014 (UTC)
Why can't there just be a type of uncommon "redirect protection," similar to template protection? If there were, then Admins wouldn't feel inclined to fully protect redirects any longer. There could be certain users with the ability to edit redirects with "redirect protection," and my problem would be greatly lessened, if not entirely. If this type of page protection existed, I would make a request for the right almost immediately. This is just an idea though; I don't really understand how everything would work out. (ask if clarification is needed) Dustin (talk) 02:47, 29 April 2014 (UTC)
Hello? Is anyone going to reply before a bot just archives this section? Dustin (talk) 02:13, 5 May 2014 (UTC)
I think that your proposal for the new redirect editor user right is quite clear and ready to be brought to proposals. — Petr Matas 05:10, 5 May 2014 (UTC)
I am very late in saying this, but I have done so. Dustin (talk) 23:02, 12 May 2014 (UTC)

Put each proposal to a separate subpage

Currently, many Village pump proposals are discussed on a single page, which makes watching of individual proposals difficult and their history is a mess. I suggest that a separate page is created for each proposal, which will allow users to choose, which proposals they want to watch. Current presentation of all active proposals on a single page can be preserved by transcluding them to that page. Petr Matas 17:57, 8 May 2014 (UTC)

As I understand it, the WMF is going to implement Flow for all talk pages at some time in the future. When that happens, each editor will be able to watchlist individual sections of talk pages, as an alternative to watching the entire page. --Tryptofish (talk) 20:47, 8 May 2014 (UTC)
Exactly so. And the Product Manager wants to bump this to the top of the priority list, so the feature should be in-development soon. There are many items in the mw:watchlist wishlist that are seeing increased interest or activity recently, and I hope (and will be pushing) for Flow to help and work alongside that. Quiddity (WMF) (talk) 23:26, 15 May 2014 (UTC)
I proposed something like that in the past (I can't find the proposal in the archives at the moment) and I still think this would be extremely useful. -- Toshio Yamaguchi 20:54, 8 May 2014 (UTC)

Watch also all redirects to a page

For each page on the watch list, I would like to be able to choose whether all redirects to it should be watched too, without having to add them to the watch list. I would be notified about any new redirects to the page and they would become watched automatically. Petr Matas 03:44, 9 May 2014 (UTC)

I like this idea. Chris857 (talk) 23:00, 9 May 2014 (UTC)
I'm not against the idea, but what purpose would this serve? Sam Walton (talk) 23:03, 9 May 2014 (UTC)
Imagine that you watch Aaron Basketeer. Later, a redirect to it, Aaron basketeer, is created. After some time, the new redirect is changed to an article with nonsenses. Without the proposed feature, you will not be able to catch this change, while readers searching for "aaron basketeer" will end up on the bad article. Petr Matas 23:20, 9 May 2014 (UTC)
+1, good idea. –Quiddity (talk) 23:27, 15 May 2014 (UTC)

Filed as a new proposal. Please vote. Petr Matas 01:27, 16 May 2014 (UTC)

Backup images of alphabet charts

One of the many nice things about Wikipedia is its collection of articles on different writing systems. Most articles of this sort include one or more tables that summarize and display the writing system. Since many of the world writing’s systems are represented in Unicode, it is standard practice to use Unicode characters in those tables, whenever they exist. The problem is that many of our readers do not have Unicode fonts that include all defined glyphs, and so often see a bunch of squares in the tables instead of the characters they are looking for. Such articles typically include a warning that this may happen, but that does not help the casual reader who is not prepared to hunt down and install a font with the characters needed just to satisfy their curiosity.

I would like to propose a fairly simple remedy to this problem: establish the practice of including a small link at the bottom of each such table that takes the reader to a screen shot of the table in question, taken with the needed font. The link might be the just letters PNG or perhaps a suitable icon. These tables are likely by now to be pretty stable, but if some maintenance is required, the screen shot can be rerun and uploaded as a replacement image. As a temporary measure, a notice of the change could be placed in the image's file descriptor. Since the editors who maintain these articles presumably have the needed fonts, they would not require anything more than a screen capture utility and an image editor to crop the screen shot. Such programs are widely available for most operating systems. Some guidance on desired resolution and a suitable category on Commons, just for screen shots of Wikipedia writing system tables, would be simple enough to create. No new WikiMedia development activity would be needed. Comments?--agr (talk) 23:37, 12 May 2014 (UTC)

There is information at Wikipedia:Screenshots of Wikipedia about how to do this. Whatamidoing (WMF) (talk) 23:51, 12 May 2014 (UTC)
Thanks for the link. I have moved this discussion to Wikipedia talk:WikiProject Writing systems where it might get more attention.--agr (talk) 15:15, 16 May 2014 (UTC)

Article - Satpal Maharaj

I went thru the article Satpal Maharaj & found that article written is defamatory.

Name Bal bhagwan is not on any government of india Site also this is not a title which given by any government body/organization this name should not be the part of this Artcle. Reference mentioned is also not reliable source.

Again Issue of DLM - There is no such bifurcation of function, No authenticated report found on the site or in Judicial order,

Mentioning of two person who left service and sale of land is also not correct, No official record on the same also this should not be the part of biographical content.

Corruption charges section also giving wrong details. Charges found is incorrect please refer www.hindustantimes.com/indias-news/dehradun

Award & Various work not mentioned at all, which shows that volunteer who is maintaining this data writing the content with malafied intention — Preceding unsigned comment added by 203.90.118.146 (talk) 10:39, 19 May 2014 (UTC)

Or it could mean that the volunteer didn't have all of that information, or didn't finish yet. WP:There is no deadline. You could WP:Be bold and try to add missing information yourself. Just be sure to write in your own words, without copying and pasting any sentences from any other website. WhatamIdoing (talk) 23:18, 19 May 2014 (UTC)

Inline citations

I see no way at all to determine whether an inline citation opens up a hovering box that links to the reference like in Fermat number by how you type the reference into the edit box so making an article work that way is probably an administrative action by somebody with high level web design knowledge. I think the Wikipedia source code should change to make all articles work that way, even ones that are created after that change gets made. Blackbombchu (talk) 16:14, 23 May 2014 (UTC)

This is Preferences → Gadgets → (D) Reference Tooltips: hover over inline citations to see reference information without moving away from the article text (does not work if "Navigation popups" is enabled above)
It's not a characteristic of the reference; it works with anything enclosed by <ref>...</ref> if the matching entry in the {{reflist}} is off-screen. If the matching entry in the {{reflist}} is on-screen, the popup doesn't appear, instead the ref entry gets a thick dark blue border for as long as the mouse pointer is over the [1] marker. --Redrose64 (talk) 16:36, 23 May 2014 (UTC)
When I created Masters of Survival, I didn't see that article having that feature, either because not all articles had that feature at that time or because it's so short that all its references are already on screen. I assumed it was because that article was so unwell known that no one added that feature to it. Blackbombchu (talk) 16:52, 23 May 2014 (UTC)
It's not controlled on a per-article basis, but per-user. If you enable that gadget in your prefs, it's effective on all pages - provided that they use the <ref>...</ref> method (or one of its variants, like {{sfn}}) for referencing. If the article uses another method - such as parenthetical referencing (like Actuary) or the obsolete deprecated Footnote3 ({{ref}}/{{note}}) system - the gadget won't work on those refs. --Redrose64 (talk) 17:35, 23 May 2014 (UTC) amended Redrose64 (talk) 19:05, 23 May 2014 (UTC)
{{ref}}/{{note}} is called Footnote3 and is deprecated, not obsolete. --  Gadget850 talk 18:01, 23 May 2014 (UTC)

social integration info box

In Wikipedia and others are almost always external links. A lot of these links go to Facebook, twitter, Google+, etc.

I was thinking, is it possible to make a section in the info box where can be linked to the social pages of people, companies, projects, etc?

Svenvdvlist (talk) 12:21, 24 May 2014 (UTC)

I don't think that would be a great idea; it seems as though the only benefit to doing so would be to advertise those people/companies. Sam Walton (talk) 12:35, 24 May 2014 (UTC)
Most of those pages need to have most of those links removed, per WP:External links (especially the WP:ELMINOFFICIAL section). WhatamIdoing (talk) 22:31, 27 May 2014 (UTC)

A forum for Wikipedians

I think that Wikipedians need another way to talk, somewhere off-wiki where discussions can be kept together and categorised. Unlike IRC where they are not retrievable from a log, a forum is surely the best idea. WikiProjects can have their own subforums. There can be an off topic section for Wikipedians wanting to chat about non-wiki business. As it would not be open to the public and members would be required to login with their WP username, it's a space for the people who are experienced on the wiki to talk just generally rather than on a specific talk page. Why has nobody started this yet? Well, I did, and put it at http://wikipedia.forums.com/ . I'm not saying this would ever be Foundation endorsed, but surely a forum could become the new IRC and is surely more suitable for an encyclopedia as there is a record of past discussion. What does everyone think of the idea? (Please sign up, and advertise.) Rcsprinter123 (gimme a message) @ 08:55, 22 May 2014 (UTC)

I'm not sure how I feel about this, but of course you'll have to get the Foundation's endorsement and cooperation to have people sign in with their Wikipedia usernames & passwords. — Frεcklεfσσt | Talk 16:00, 22 May 2014 (UTC)
Rcsprinter123: That is a good idea. So good that it already exists, and you are talking on it. It is called the Village Pump, and it is already categorized. It is not off-wiki, but why should it be? (I think that IRC discussions should be logged and searchable, since they are public chats after all, by the way - quite odd they aren't apparently).--cyclopiaspeak! 18:42, 22 May 2014 (UTC)
How does the Village Pump come even close to what is being proposed here? -- Toshio Yamaguchi 11:19, 23 May 2014 (UTC)
@Rcsprinter123: How would this forum be different from either the Wikipediocracy forum or the Wikipedia Review forum? APerson (talk!) 00:36, 24 May 2014 (UTC)
Technically, no difference, but it isn't for criticising and complaining, it's for collaboration and friendliness. Rcsprinter123 (articulate) @ 05:57, 24 May 2014 (UTC)
If off-Wiki, why propose here? Start it, and announce. Or participate in Wikipedia's page at Facebook. [2] or Google Plus [3] Jim.henderson (talk) 21:42, 25 May 2014 (UTC)
How about /r/Wikipedians? Blake (Talk·Edits) 16:02, 28 May 2014 (UTC)
  • To Jim Henderson - there those of us who wouldn't go near Google Plus or Facebook (except when checking copyvios...) and who only visit forums when there's a chance of getting an answer to a problem. To RCS - "it's for collaboration and friendliness" - I like seeing optimism. Peridon (talk) 22:23, 28 May 2014 (UTC)
  • There's also a LiveJournal group. And there are of course oodles of things on meta that involve using Liquid Threads, Flow, or some other horror. However, I for one value the fact that logging is forbidden on freenode IRC - and the availability of cloaks. Sorry, I won't be using the new forum. Yngvadottir (talk) 18:54, 29 May 2014 (UTC)

Bold Edit Button.

In the same way that there is a tick box for a minor edit, would there be an advantage to having a button for a bold or controversial edit? I have made a number of very bold edits to articles after failing to attract any discussion to the relevant talk page. I am of the opinion that many editors ignore changes to talk pages and thus miss out on such discussions but a big 'bold edit' warning on their watchlist might attract their attention.--Ykraps (talk) 12:21, 29 May 2014 (UTC)

In essence, a bold edit would be something you believe is wrong some editors may not agree with, but you are going to do it anyways because you think it improves the quality of Wikipedia. I think there would be obvious pros and cons, but if you feel a change is worth discussion, do both! Make sure the section header accurately describes the situation. While people may not religiously check talkpages, if they are "watching" an article, they are automatically watching the talkpage, in which it would generally take a good section title to let them know something relevant to their interests is being discussed. Blake (Talk·Edits) 14:43, 29 May 2014 (UTC)
I don't think we need this and, in fact, think it would be a Bad Thing. Already, my watchlist tells me if there is a big edit by bolding the number of bytes changed in the edit. As Blake said, if you're watching an article, you're already watching the Talk page automatically, so if someone discusses a change and you don't bother to talk about it, it's your own darn fault. And if you make a Bold edit, you can say so in your edit summary. In short, I think this functionality is already served by existing features. — Frεcklεfσσt | Talk 15:09, 29 May 2014 (UTC)
Using the work "BOLD" in big capital letters in the edit summary would have the same effect. --LukeSurl t c 15:13, 29 May 2014 (UTC)

A bold edit isn't necessarily a big edit (Frecklefoot). Changing the respective fleet strengths here [4] for example has zero effect on the number of bytes but is controversial because it contradicts a version that has been accepted since the articles creation (albeit unreferenced). I don't accept that a bold edit is something that is wrong (Blake). In the given example the initial figures were unreferenced and I had two sources which gave the figures I eventually inserted. I still think however that this was bold and deserved to be brought to the attention of a wider audience who might have additional sources. You will also note I raised the issue on the talk page without success. I agree that perhaps adding "BOLD" to my edit summary might work though (thank you, LukeSurl)--Ykraps (talk) 15:45, 29 May 2014 (UTC)

I agree, a bold edit isn't necessarily "I am going to remove/add a chunk of this page", it is just controversial to some extent. Blake (Talk·Edits) 16:03, 29 May 2014 (UTC)
I think edit summaries could handle this. Some people do, on occasion, summarize with things like "Boldly changing X". Or use related terminology. I've left edit summaries of "complete rewrite" and similar, which implies a bold action. Resolute 16:19, 29 May 2014 (UTC)
Typing in "Making bold edit" takes up space, meaning that the max edit summary length will be restricted more. That's not very much space, but it's enough to have an irritating, bad effect. Also, unless it's a very difficult addition to make, I don't see any good reason against it. Better more than less, right? I mean, not everyone uses the "minor edit" button, but we still have it. I would support such an addition. Dustin (talk) 17:24, 29 May 2014 (UTC)
I agree with Frecklefoot, above. One can tell from the number of bytes how much was changed in terms of quantity. Also, if an editor is interested in a topic, he or she will have both the article and the article's Talk page on his/her watch list. A number of editors are keeping an eye on most articles. At least one of them will deal appropriately with edits which need undoing, modifying, or discussing. Finally, what is bold to one editor may not be bold to another editor. CorinneSD (talk) 19:39, 29 May 2014 (UTC)
But if an editor were to mark his/her edit with the proposed "bold button," then that would show that the editor was using WP:BOLD as justification for making the edit; other editors' opinions on whether or not said edit is "bold" do not matter in this situation because the "bold" label would only be indicating that the editor actually making the edit was using WP:BOLD as reasoning for the edit. Dustin (talk) 19:58, 29 May 2014 (UTC)
That editors use the number of bytes as an indication of the importance of an edit is perhaps part of the problem. Changing dates, casualty figures, fleet sizes etc produce little or no difference to the number of bytes but can make a massive difference to the article. Changing the GVA of a local economy from $10,000,000 to $100,000,000 for example will show up as +1 byte.--Ykraps (talk) 22:35, 29 May 2014 (UTC)
And, in fact, if you remove 10,000 bytes of text and replace it with a completely different 10,000 bytes, it'll show up as no important change at all by that criterion! -- Boing! said Zebedee (talk) 11:40, 30 May 2014 (UTC)
Quite.--Ykraps (talk) 13:15, 30 May 2014 (UTC)
Okay, I admit I combined the definition of BOLD and BIG. Certainly, changing one digit can be considered a Bold edit and show zero change for the number of bytes. But I still hold that a BOLD EDIT button is unnecessary. It's also likely to confuse editors. — Frεcklεfσσt | Talk 18:26, 30 May 2014 (UTC)
Why couldn't it be like the minor edit button where you use it or you don't? Not all editors understand the exact meaning behind the minor edit button already. Is it minor as in I didn't change much or is it minor as in an insignificant edit? All of this stuff applies. Dustin (talk) 18:34, 30 May 2014 (UTC)
It was my intention that it should function exactly like the minor edit button, which as you say, is so often misused. A minor edit is one that doesn't alter the content's meaning in any way, such as a typo or spelling correction (see Help:Minor edit); it is saying, "This is an edit you don't need to review". The bold edit button is saying, "You really ought to check this out". Perhaps a better name for it would be a major edit button.--Ykraps (talk) 23:56, 30 May 2014 (UTC)

Contributions tab

I think it would be super-helpful if there was a "user contributions" tab at the top of a user page, along with the "user talk" tab. Currently, if one wants to see a user's contributions, they must click the "history" tab, then look to see where they edited their user or talk pages last (which might not have been very recently), and then click on the link next to their username. I propose a simple tab next to the "talk" tab for easy access to a user's contribs. — Confession0791 talk 10:23, 30 May 2014 (UTC)

There is already a "User contributions" link under "Tools" in the left pane when you are in userspace. There is no need for a tab. PrimeHunter (talk) 10:29, 30 May 2014 (UTC)
Most people don't know that. I certainly didn't. — Confession0791 talk 15:13, 30 May 2014 (UTC)
Confession0791,
You mean you don't hand-edit the URLs directly?  
If you'd like to see something cooler, then follow the instructions at User:PleaseStand/userinfo. That will display some information directly on the user's page, and it adds a link to their contributions under the words about how many minutes/hours/days it's been since the user's last edit. WhatamIdoing (talk) 15:25, 30 May 2014 (UTC)

Pre-RfA opinion page


Asked and answered. Remember this is the idea lab (not an 'active proposal') so further discussion in the 'support/oppose' format is not necessary (further developing of the idea would be fine). –xenotalk 14:28, 29 May 2014 (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.

There are probably many good editors who would like to run for adminship and would probably succeed, but fearing failure, dare not try.

So, I thought that maybe an "opinion page" which focuses on readiness to become an admin might be a good idea. I am thinking of something optional like Wikipedia:Editor review but specifically for editors to ask for feedback about their RfA chances, what may be lacking, etc. to get an indication of what the outcome might be.

Has this been suggested before? Something tells me this is a bad idea, but I can't figure out why. Many thanks for any thoughts on the matter. Anna Frodesiak (talk) 05:03, 23 May 2014 (UTC)

Found my way to this from your talk page - I think it's a great idea :) I've been interested in possibly running in the future myself, and have had to turn to individuals for their opinions and suggestions. A board specifically for this would be nice. My only worry would be a lack of volunteers to give feedback in a timely manner (seeing the backlong over at editor review), but hopefully it would be able to stand up, especially if it's more established members of the community seeking suggestions. ~SuperHamster Talk Contribs 22:54, 27 May 2014 (UTC)
Sure, I support this proposal per SuperHamster. Jim Carter (talk) 05:55, 28 May 2014 (UTC)
  • Support. I think that's a very good idea. I know that we have Wikipedia:Editor review, but that's for general editing as opposed to a review that looks specifically at admin qualities. I know that having a way to review pre-admin would also encourage people to be a little nicer or more loose when looking at potential faults, as sometimes people can be somewhat strict because RfA does make an adminship decision. Tokyogirl79 (｡◕‿◕｡) 06:53, 28 May 2014 (UTC)

As I stated before, I'd support a system set up identical to how the typical editor review is set up, but I'm going to throw this idea out there: how about a sort of "mock trial"? Perhaps this is what Anna was going for the whole time, but as opposed to the normal editor review that asks for comments or relatively in-depth reviews, I'm imaging a system where editors could state whether they would support or oppose the candidate at that particular point in time, and provide feedback in a way that is more constructive and less harsh than what is generally given at RfA. This would of course require active participation by multiple editors, but having a sort of !vote system might draw more reviews and give a better insight at a candidate's potential chances than otherwise. ~SuperHamster Talk Contribs 07:00, 28 May 2014 (UTC)

  • Support. To this day I will never understand how obtaining adminship became such an onerous task. I never went through RFA (yes I'm that freaking old) and I'm pretty sure I never would have bothered had it existed. So I heartily endorse anything which makes achieving the lofty status of "janitor" easier. I'd really like to see some structure aimed at keeping it a positive experience though. Manning (talk) 07:05, 28 May 2014 (UTC)
  • Support. Sure, why not? --Ixfd64 (talk) 07:09, 28 May 2014 (UTC)
  • Being an admin needs skill and intelligence. There needs to be some sort of checking of candidates for adminship. How many active admins does this Wikipedia have, and how many are needed? Anthony Appleyard (talk) 07:11, 28 May 2014 (UTC)
    Of the 1409 admins 599 are considered to be active, defined as having made 30 or more edits in the last two months.[5] As to how many admins are needed, as the number of active editors declines I suppose that inevitably the number of admins required to police them will also decline proportionally. Eric Corbett 12:30, 28 May 2014 (UTC)
  • Unfortunately, Eric is probably right. What I see is that we need more admins who can participate in the closure of the more serious discussions, like RfCs. There's no quantifiable requirement that I can think of that determines whether someone is made of the right material for that job. It requires brains and diplomacy, and, as far as I'm concerned, a pretty serious background in article writing and development. All the other areas, meh, as Writ Keeper might say--the occasional backlog at RFPP etc. isn't the biggest deal. We need admins who are seasoned editors who can close the things that keep festering--and then we need editors who, after a difficult close of an AfD or an RfC, don't immediately start complaining. That's my one penny, but I got a bag full. (Hey Eric, nice to see you again.) Drmies (talk) 14:30, 28 May 2014 (UTC)
  • Admins arn't needed to close discussions. Any respected user who isn't involved and has more then 1000 edits should be able to close any discussion that doesn't require the tools to implement. Admins arn't special. Just because someone isn't trusted with the block or protect tool doesn't mean they arn't capable or trusted enough to close a discussion.--v/r - TP 16:59, 28 May 2014 (UTC)
  • Oh, well, that's me put in my place then. Drmies (talk) 20:44, 28 May 2014 (UTC)
  • SupportThe RFA inquisition is the only reason I've not applied yet. I get the impression that editors who have anything other than a milquetoast contrubutions log tend to be grilled about every dispute or conflict they had ever been involved in. Something like this would be good - as long as it isn't used as a way to uncover "dirty laundry" to use against the candidates when they do later submit to RFA. Roger (Dodger67) (talk) 07:35, 28 May 2014 (UTC)
  • I'm not sure this solves anything. Really, I'm not sure there is a solution. When I ran for adminship, in 2007, my involvement in controversial areas (inclusion criteria, mainly, at that time) was generally seen as a positive, even by those who may not have agreed with everything I had to say. Anymore, it seems that a prospective admin's best bet is to keep their head down. I want to change that mindset and get across that a good admin candidate should get involved in tough areas, make some mistakes, and learn from them. I'm almost inherently suspicious of a candidate who can't cite an experience where they've truly screwed up and learned something from it. Seraphimblade Talk to me 08:02, 28 May 2014 (UTC)
  • Comment: I'm pretty sure we used to have admin coaching. And editor review was often used as RfA preparation. Admin coaching is now marked as historical because there weren't enough people doing it to make it viable. Editor review has a backlog and there aren't enough users stepping up to perform the review. Before I was an admin, I put myself forward for editor review and got no responses at all. The flipside to this is there is probably lots of informal "admin coaching"/RfA-focussed admin coaching going on, but it's off-wiki. The thing that scares people from going to RfA—that it's going to bomb and there'll be a big drama storm, and the trainwreck will sit there on a project-space page forever... well, that's the same thing that's going to stop the people who need editor review/admin coaching/whatever we want to call it this week from going for a review on-wiki. Informal reviews by email or IRC or whatever don't have that issue precisely because they aren't public. I don't know how you fix it. It may not be fixable. —Tom Morris (talk) 08:04, 28 May 2014 (UTC)
  • Sounds like a good idea. Something akin to peer review before featured article candidates.--Father Goose (talk) 08:06, 28 May 2014 (UTC)
  • Great Idea, but might get a huge backlog. Hg andVenus 08:22, 28 May 2014 (UTC)
  • Support We need to get more good Admins and RfA can be scary. Like Seraphimblade, my candidacy was partially due to my involvement in controversial areas (basically areas rife with nationalistic editing) and that was seen as a good thing, but it isn't like that now. If we do something like this we need to be careful about the title - I'm not sure 'review' should be in it. Dougweller (talk) 08:23, 28 May 2014 (UTC)
  • Support, purely because I'd love to be an admin and am scared.--Launchballer 08:49, 28 May 2014 (UTC)
  • Support This seems an idea worth trying. I know a few excellent editors who have decided to not apply for the admin tools due to the often horrible atmosphere at WP:RFA (though I think that things have improved there over the last 12 months or so). A forum where people can test the waters might be helpful in encouraging more applicants for the tools. Nick-D (talk) 08:54, 28 May 2014 (UTC)
  • Weak Support. There is also a small voice in my head telling me this is a bad idea and it's because RFA should not be the way it is, at all, and this would just further give the current gauntlet of hell process that candidates have to go through legitimacy, and possibly make it even worse. I don't know when we got rid of "adminship is not a big deal", I remember that was more or less the way when I went for RfA in 2008 (with a tally of 34/0/0 and no extra questions, which is simply unthinkable nowadays). Any way of helping people become admins is good, so I can support an idea such as this as long as going through it never becomes a requirement for passing RfA, be it de jure or de facto. - filelakeshoe (t / c) 09:00, 28 May 2014 (UTC)
  • Oppose per Tom Morris, projects like this fail because of a general lack of participants. Furthermore, we have a pile of guidance on the RfA process. Any editor incapable of navigating that information has no business in the admin role. Many of the quickfail/SNOW RfAs include users that didn't bother adhering to that guidance. Finally, I don't want to see a "practice run" review board to play bad cop for those experienced editors who have been mollycoddling aspirants when brutal honesty would suffice. Chris Troutman (talk) 09:07, 28 May 2014 (UTC)
  • Comment While the RfA experience is generally rather daunting, I think that if potential admins are able to keep a cool head then why not simply seek to submit their candidature when they feel ready? If such a request results in a snow close or other unsuccessful outcome then acknowledge concerns, move on and re-submit in the future. As has been stated previously by others, a major problem can be the behavio(u)r of !voting participants. If candidates can deal with comments appropriately, then an unsuccessful RfA should not necessarily be held against them in the future. It appears that more janitors are needed, and there's no shortage of editors who would be well suited to helping out. Both editor review and admin coaching have AIUI been criticised in the past for grooming candidates; therefore it could be more meaningful to "Jump in the Fire" and test the community's views. Having said that, I do think that it'd be helpful to gain consensus on certain pre-requisites which come up time and time again: this could avoid potential embarrassment. -- Trevj (talk · contribs) 09:15, 28 May 2014 (UTC)
  • Comment – well since admins only are being polled to comment here, I guess content builders who are not admins have nothing of value to say. However, the way the admin system is currently structured is so compromised that it is hard to see why self respecting editors would want to be admins. We don't need easier RfA's so more admins can dash about making bigger messes. We need to restructure the admin system in such a way that good editors have pride in the system and want to be part of it. --Epipelagic (talk) 09:16, 28 May 2014 (UTC)
    An interesting observation demonstrating one of the problems here, which is that admins have to vote to change the power structure they're the bedrock of, and that will obviously never happen, as we've seen so many times before. Eric Corbett 12:49, 28 May 2014 (UTC)
  • Sounds like a bad idea to me. There is already nothing stopping a potential admin candidate from seeking editor review and explicitly asking for comments on adminship viability. There is no reason to think that a special process would be any better supported that the poor support we get now for editor review. It just adds to the bureaucracy and has the danger of becoming de rigueur ("so why didn't the candidate submit him/herself to review before coming here and wasting out time...") SpinningSpark 09:41, 28 May 2014 (UTC)
  • Question Actually I am such an editor, anyway, I have these questions. Is there any guarantee that if an editor gets "assurance" in such "opinion poll" , he will succeed in the RFA too? "Editor review" is not one of the most successful initiatives. Tito☸Dutta 09:52, 28 May 2014 (UTC)
  • I do not think this needs to be discussed at the Village Pump. Just boldly set up such a system and watch it fail like Editor Review and Admin Coaching did. Trying to ask a seasoned Wikipedian for a nomination is IMHO much more useful than setting up a new page for this. Also, what Tom Morris said. —Kusma (t·c) 09:53, 28 May 2014 (UTC)
  • Oppose per Spinningspark. RFA is already too fraught and complex a process, and even if this well-intentioned idea works any better than editor review, it will just have the undesirable effect of expanding the labyrinth. --BrownHairedGirl (talk) • (contribs) 09:57, 28 May 2014 (UTC)
  • Oppose per BHG. Jehochman Talk 10:02, 28 May 2014 (UTC)
  • Support although I would prefer a revived (and revised) admin coaching system instead. --Lenticel (talk) 10:43, 28 May 2014 (UTC)
  • For some reason I thought that editor review was dead and historical, but now I see people are still listing themselves. This venue could certainly be used for the pre-qualification check purpose already. The RFA process can be stressful, but having a pre-test will not alter that. Either people drop out early from RFA, or they stick out the week and endure the stress. The worst will be for those that are close to successful, lasting the whole week but fail. They will have faced opposition. A pre-test may find the quick fails but perhaps not the near successes. So I would suggest that we just keep editor review but encourage more to respond. Graeme Bartlett (talk) 11:06, 28 May 2014 (UTC)
  • Oppose The idea is a good one, but we've seen other similar efforts fade away numerous times in the past. I can guarantee that there are RfA's that would fail simply because the candidate used this proposed process to prepare. Hiberniantears (talk) 11:41, 28 May 2014 (UTC)
  • Qualified Support The timing is interesting, as I was mulling writing a post at the RfA talk page explaining why I have largely stopped !voting in RfA (with some exceptions). In short, I think the process is horribly inefficient. Imagine a proposal for a new way to write articles - identify a possible topic, then ask 100 editors to each write up their version of an article, without talking to each other. Some will write the whole article, some will write parts, but there will be no coordination of who does what. Then, cobble together an article from the 100 submissions. It might not even be half-bad, that's not the point, the point is that it is an enormous waste of valuable resources to write an article that way. If I made such a proposal, it would be laughed out of here, as it should be. Yet I just described how we approach an RfA. We can do better. Maybe the pre-RfA process would be a good place to experiment. --S Philbrick(Talk) 11:47, 28 May 2014 (UTC)
  • Oppose I don't think it's the fear of failure that's stopping folks but having to deal with all the negativity. A Pre-RfA won't stop that; it'll just change the location. Rklawton (talk) 12:06, 28 May 2014 (UTC)
  • Neutral It sounds like it will just be another bump in the road when we should have as few bumps as possible. Then again, it might be worth a try. We don't have anything to lose. I won't personally change my opinion of an editor who went through this step. The editors caught up in these pre-RfA experiments should be treated the same as every other candidate come the actual nomination. Gizza (t)(c) 12:18, 28 May 2014 (UTC)
  • (Weak) Oppose. It's a typical "good faith idea", but I see the same problem as others above: it's just adding another layer of complexity, and one more step to add drama. --Stephan Schulz (talk) 12:22, 28 May 2014 (UTC)
  • Support, if the process is constructive. --Ancheta Wis   (talk | contribs) 12:35, 28 May 2014 (UTC)
    There's a copper-bottomed guarantee that it won't be any more constructive than the present RfA. Eric Corbett 12:42, 28 May 2014 (UTC)
  • Oppose. Tom Morris and Rklawton put it well, this would simply give an alternate locus for the venomous RfA, with candidates being opposed either for having gone through the pre-RfA or not having gone through it at their RfA trial by fire. The only practical solution is one that's been suggested many times and knocked down many times; unbundle the user rights, and don't allow admins to accrete ever more rights to themselves. Eric Corbett 12:42, 28 May 2014 (UTC)
  • Not convinced we need a formal area for this kind of thing; why can't editors just informally ask a current Admin for their opinion on the Admin's UTP? It Is Me Here t / c 13:17, 28 May 2014 (UTC)
  • Support. I've been a bit 'out of the loop' lately, so I don't know how RfA has changed in the last year or two, but I can't see why such an idea shouldn't be implemented. If it's a failure, it can be shut down later on, and I can't really see any negative outcomes as a result. I don't think it should be a necessary part of the RfA process, however. It should be strictly voluntary, like Peer Review. If the idea is to make it mandatory, I would oppose. In short, I don't think it's needed, but it can't hurt and may be helpful to some.-RHM22 (talk) 13:19, 28 May 2014 (UTC)
  • Oppose Adding another gantlet != great idea. Heck, why not have a "pre-editor opinion page" where we can gauge how good a person will be as an editor, and essentially squash those who are "not ready for the keyboard"? And this added gantlet will not reduce the toxins wafting around so many RfAs in any case. Sorry. Collect (talk) 13:23, 28 May 2014 (UTC)
  • I support making RFA easier and less stressful, but I don't think this is the solution. --Kbdank71 13:25, 28 May 2014 (UTC)
  • Sceptical support It's been a long time since I had to jump through the necessary hoops to become an admin, and I haven't kept track of the minute details of how the process has changed. One thing that does slightly worry me, that hasn't much changed, is that this might simply turn out to be yet another "badge" which an editor will add to their collection to be held up as some kind of "proof" that they are worthy…and which will be wielded as a weapon against those who might have some reasonable objection ("But I've done the course, I must be qualified"). on the other hand, if it results in better-prepared new admins, how can that be such a bad thing? —Phil | Talk 13:26, 28 May 2014 (UTC)
  • Something tells me this won't be a positive thing. I endorse the motivation for this, but I expect that this would become just one more hoop for prospective sysops to jump through (to the cheers and jeers of numerous onlookers) -- adding to the onerousness of the RFA process, rather than improving things. --Orlady (talk) 13:30, 28 May 2014 (UTC)
  • Weak Oppose—I don't want to ruin anyone's party so my opposition is really tentative, but aside from the aforementioned backlog problem, it seems to me like this proposal would just strengthen what is already broken in RfA—the extreme scrutinization that users have to undergo in the process. Adding a new review process (even if optional) will just create another step in this scrutinization. Eventually I am afraid that it might become "mandatory", i.e. it will be optional, but many RfA !voters will oppose because tacitly they don't trust a candidate who didn't go through the review process first. —Ynhockey (Talk) 13:35, 28 May 2014 (UTC)
  • Oppose per Chris troutman. We should focus on improving (and quite possibly simplifying/shortening/merging) Wikipedia:Guide to requests for adminship, Wikipedia:Miniguide to requests for adminship, Wikipedia:Advice for RfA candidates, Wikipedia:Administrators#Expectations of adminship, Wikipedia:WikiProject on Adminship/Goals of the adminship process#Discernment and possibly others. Indeed, while making this list I realized there is likely too much information out there that might overwhelm an inexperienced user. So our problem isn't lack of guidance, it's overabundance of it. I'd strongly support an initiative to consolidate all those pages in one or two guidelines at most, and then having these widely accessible as links from the relevant pages and navigation templates. --Waldir talk 13:38, 28 May 2014 (UTC)
    • Oppose because I completely agree with Waldir. I'm another one from an era where people asked to be nom'ed, other admins said yea, or nay and cited a meaningful reason, and that was that. I was stunned after some time away from the process at how onerous the process has become, not just for the nominee but for those who are trying to approve the person. All that reading and evaluating! I just stopped looking, as a result. I have been out of the loop for quite a while, so I'm not sure whether there was some mass abuse of adminship that caused the community to come up with the process, but really I think that more admins is better and the process should be much, much easier. Elf | Talk 16:28, 28 May 2014 (UTC)
  • Oppose, as the adminship process is complicated enough; I believe we need to simplify what we have already in place. --Merovingian (T, C, L) 13:40, 28 May 2014 (UTC)
  • Oppose - The way I see it is this - If you want to be an admin - Ask!, If not - Don't!, No one should be worried/scared of the RFA ... Anyway it's a nice idea but imho it's just kind of pointless. →Davey2010→→Talk to me!→ 13:42, 28 May 2014 (UTC)
  • Oppose - Basically for all intents and purpose, WP:Editor review is pre-RFA review. We didn't explicitly call it that, but a lot of people used it for that and I think at one point there was an instructional page that recommended it. 2 of the 3 standard ER questions are basically the same as 2 of the standard RFA questions. But it has basically been dead for years. In fact, it was supposed to be marked historical a month ago, but has been kept on life support again after yet another eleventh-hour proposal to revive it that, not surprisingly, petered out after a few days. Creating a nearly-identical process with a different name isn't going to fix it. Mr.Z-man 14:07, 28 May 2014 (UTC)
  • Oppose – I have some fear that this would just become what RFA already is... It just seems like that's exactly going to happen again. Mitch32(Any fool can make a rule, And any fool will mind it.) 14:09, 28 May 2014 (UTC)
  • Weak Oppose - While I do understand the "fear of failure leading to not acting at all" behavior, I agree with the various posters above that (1) there are already a host of advice and options out there and (2) this process seems likely to just add to the pile and get few-to-no responses. I wouldn't hate the idea of taking the mishmash of pages which Waldir identified into one, unified RFA/adminship advice page. Were that done, there could perhaps be a request for input/advice/comments/etc section on the talk page (or something along those lines). As it is, however, it seems like just another re-hash of what is already out there (and a re-hash not likely to yield much participation anyways). Staxringold talkcontribs 14:15, 28 May 2014 (UTC)
  • Oppose - either it will be as painful as RfA or it will fail to warn of what will be painful at RfA. It would be another layer of bureaucracy. The toxicity at RfA is caused by people, not process, and this won't solve it. --Stfg (talk) 14:53, 28 May 2014 (UTC)
  • Oppose - likely to generate more heat than light in ways noted in many opinions above. --Versageek 15:06, 28 May 2014 (UTC)
  • I'm mostly with BHG on this one. I don't think this is likely to be successful, any more than editor review was. I wouldn't go so far as to say I'm opposed, however. We could give it a try. --BDD (talk) 15:08, 28 May 2014 (UTC)
  • Weak Oppose Either it will be ignored, or be another troublemaker magnet. We need to be discouraging toxic behavior at RFA - if more RFA candidate haters were banned, you'd see more volunteers to be admins. Stan (talk) 15:20, 28 May 2014 (UTC)
  • Oppose - I think if experienced editors that have read through RFAADVICE, looked at the RFA standards and status quo, and not opted for an assessment from another editor they trust, then I can't see them as opting to undergo a public assessment that fundamentally won't be any different than an actual RFA in terms of stress. The reason being is that a negative assessment on this step will surely affect any future RFAs (unless a significant amount of time has passed) thus making it equally as stressful and open to the same public pile on that one may experience at RFA. Mkdwtalk 15:25, 28 May 2014 (UTC)
  • Support - it probably wiil be more helpful than harmful. Bearian (talk) 15:28, 28 May 2014 (UTC)
  • Interesting idea, but I don't think softening the RfA process is the way to go here. Eagles 24/7 (C) 15:33, 28 May 2014 (UTC)
  • Oppose - unless the process of being an Admin is made less disruptive. See WP:Admin abuse. The RfA process, although demeaning, is less so then what you go through after you become an Admin. — Arthur Rubin (talk) 16:28, 28 May 2014 (UTC)
  • Hesitant support - I like the idea, but very seriously wonder whether it might not be basically a way to attack potential candidates earlier. Maybe, and this is just a maybe, instuting a system which would point out specific areas of onoing discussion, maybe like at RfC, where individuals who are considering becoming admins can comment and then receive feedback on their comments might work. After some possibly predesignated period of time making such comments, or maybe immediately, they could start receiving responses on their input and whether others think the candidates' input was useful, in accord with policy and guidelines, etc. etc. etc. It might work, but it might also drive potentially useful admins away if a group of enemies gang up on them. John Carter (talk) 16:31, 28 May 2014 (UTC)
  • Oppose, but with thanks to Anna for raising the suggestion. The barrier to admin is scarily high, but I don't think the best solution is to give would-be admins a leg-up that evades the real structural problems. In my view, what we need is twofold...
    1) We need a Community-led admin recall process. If people feel it's not a "now and forever" decision and that they have a right to recall an admin in the future if they lose confidence in them (as exists in all reputable democratic systems), they'll surely be prepared to be less strict in their RFA criteria.
    2) We also need as much unbundling of rights as possible - for example, there was absolutely nothing "admin" about the right to edit templates, and it was absurd to allow technically incompetent admins the right while technically competent non-admins were denied it.
    In short, the focus should not be on attracting new candidates to a broken admin culture - fix the culture, and they will come.-- Boing! said Zebedee (talk) 16:33, 28 May 2014 (UTC)
    Just a few more thoughts having read everyone else's words more carefully, and I think the problem here is that we're aiming at the wrong target. The admin bar is too high, but that's for good reason. 'Ordinary' editors here have far too many experiences of admins-for-life bullying them and abusing their positions, and generally acting like the authoritarian dicks that too many of them are. And because that's the power positions we're placing admins in, with no realistic second chance should we change our minds when we find out what they're really like, our new candidates are going to be subjected to intense critique - and trying to soften that won't change anything. So rather than trying to make it easier for candidates to achieve dictator status, we should instead be removing the potential for dictator status by making them directly answerable to the Community. Remember "No big deal"? We should try to get back to that -- Boing! said Zebedee (talk) 20:14, 28 May 2014 (UTC)
  • Oppose with due respect to Anna for raising it. Why add another potential layer of complexity to something that many people already consider a tortuous process? What weight will this have? What if the results conflict with RfA !voting? Perhaps most importantly, why do we need another "forum" for discussion while the real tasks of building an encyclopedia and mopping up the inevitable detritus resulting therefrom get sidelined?  Philg88 ♦talk 16:50, 28 May 2014 (UTC)
  • Support (kind of) – it sounds like a good idea, especially considering that we need more admins and that many people have never run for adminship again after a failed RfA, but what about the people who don't want to have a pre-RfA? And if this is implemented, shouldn't there also be reconfirmation RfAs, too, to balance this out? Epicgenius (talk) 17:32, 28 May 2014 (UTC)
  • Support, it would be a good idea. People would get good feedback about their chances of becoming an admin without actually having to go through all the harshness of an actual RfA process. This pre-RfA opinion page would have a much looser format than the actual RfA process, allowing the admin candidate to state their question and other editors to reply in a free format. And it would leave the candidate the option open not to actually pursue adminship at this exact time, but at an indeterminate point in the future. JIP | Talk 18:23, 28 May 2014 (UTC)
  • Oppose par user:Rklawton and similar. It just moves the inevitable "shoot out" to a different page. I agree a week of RfA can be a bit daunting, especially if there is some rush of opposition following a comment that just one person started! But being an active admin also carries a daily dose of flak - you delete a few pages and you just know there will be the bright orange banner when you log on the next day, with someone complaining bitterly that their pride and joy has gone (I have one now...). Admins need a thick skin, if they cannot stand 7 days of questioning at RfA, then they should think again about being an admin. I think a better idea would be a list of admins willing to give a review of an editor if requested - that would just be a one to one chat and would help potential admins to see if they are covering the correct ground.  Ronhjones  (Talk) 18:27, 28 May 2014 (UTC)
  • 'Comment - This wouldn't be a bad idea. Maybe, and this is just a maybe, the pre-pre-RfA might be having an editor take part in some admin-related discussions for a month or two, providing links to those discussions in which they were involved, and asking for opinions on how they did and what they could do better. Something like a user conduct RfC, maybe, but preferably not quite identical. John Carter (talk) 18:45, 28 May 2014 (UTC)
  • Oppose - This would only add complexity to an already too complex process. Carrite (talk) 18:41, 28 May 2014 (UTC)
    • Comment: AFAICS, this would not actually be part of the process, as no one would be obligated to go through this pre-RfA commentary before making an actual RfA. And successfully going through this pre-RfA commentary would not be an obligation to ever actually undergo an RfA. JIP | Talk 18:47, 28 May 2014 (UTC)
  • Try it this might become a helpful tool to people considering running for adminship which helps people avoid the worst of the process, or it might become a harmful extension of RfA. Both seem plausible to me and the only way we're going to find out is to do some kind of trial run. One thing I would strongly recommend is that this does not become a de facto required part of the RfA process. In particular any opposes on the grounds that the candidate didn't go through this process should be discounted. Hut 8.5 19:45, 28 May 2014 (UTC)
  • Oppose Is a pre-RfA review going to be any better than an RfA in terms of participant behaviour? Is it an open review, or a request to particular people to do a review? I can see it becoming a part of the system, whatever the intentions behind it. Someone who 'fails' a review is not going to feel any better about it than if they failed an RfA. I presume the opposes Hut 8.5 refers to would be RfA opposes for an unreviewed candidate, rather than the gentleman near the top who seems to be saying he was adminned without an RfA. (Just like people used to pay their half a crown and get a driving licence...) I can see a lot of opposes being on the ground of non-review - which might be a change from the contents creation theme... No, just like the SATS test in UK schools, which was intended to measure the success of the teaching, but turned into a parent-driven 'pass your SATS' thing which was of no use to man or beast, and least of all to the kids, this will become a 'must have'. Part of the RfA thing is the pressure. Why have two sessions of it? As an admin, you will get called names (some of which may by chance be true...), you will be pressured by people with five edits and a legal right to have equitable treatment with other companies based in Upper Slobodia (or so they think), you will be called nazi and fascist (maybe even by the same person on different days, and you will be dragged to AN/I over something that turns out to have been great politeness on your part and ignorance by the dragger. I went into RfA (having been picked on out by a respected admin, and knowing that if it went pear-shaped I could always carry on tagging things instead of actually getting to delete them. I'd be doing less typing here - explaining to people why their article has been deleted without actually using the words 'spam' and 'crap'. Peridon (talk) 20:33, 28 May 2014 (UTC)
PS Don't bother calling me a cynical pessimist - I know I'm one. Better to get pleasant surprises when things actually go better than expected than constant disappointments when they don't...Peridon (talk) 20:35, 28 May 2014 (UTC)
  • On balance, oppose. The community is divided as to whether we need more administrators. That's partly because there are so few recourses when an admin is overly autocratic. Hence as others have said, there are good reasons members of the community scrutinize admin candidates so closely. I used to think we had too many admins, part of a distressing devolution towards seeing admins as more valued editors rather than janitors - however, the project is not only very large, it's increasingly bureaucratic. There are all sorts of corners where admin tools are required, and different editors have different ideas about which ones need to be kept un-backlogged. Absent a de-bureaucratisation of the whole shebang - which I doubt is possible - we do have a shortage of active admins. More importantly, especially in a volunteer project, we need to keep the admin corps from ossifying; we need new people to become admins both because they deserve just as much consideration for the position as old timers did back when they ran, to make up for the inevitable turnover (especially in a volunteer project), and to avoid cliquishness. And RfA can be bruising. However, this does not strike me as a good solution for a number of reasons. One is that in a project of this size - and a volunteer one, where we all have other demands on our time - most RfA participants don't just comb through a candidate's editing history, but rely quite a bit on the candidate's deportment in the RfA itself to get an idea of their suitability. In fact I think that's quite appropriate: being an admin involves making a lot of decisions and reacting to others, and the group interview that is RfA can throw useful light on how the person will deal with the job. There are already a number of ways to consult with others and prepare before taking the plunge, on- and off-wiki - such as contacting one of the editors listed as willing to nominate - and availing oneself of such opportunities is also part of demonstrating readiness. Which brings me to - I understand the reason WP:Admin coaching is no longer active is that candidates who had gone through it were being voted down. This would be open to the same distressing abuse. Let's leave it to the candidate and those they consult (which includes the duty of nominators to examine the candidate's record and help them deal with potential weak points, already set out in the guidance for RfAs) and then see how they run. I don't think this would be a net benefit, well intentioned though it is. Yngvadottir (talk) 21:09, 28 May 2014 (UTC)
  • Hell Yes That's my positive and encouraging mode. For something like this you and others interested should just open the page and see what happens. Someone may MfD it or not. Someone may use it or not. It may thrive or not. It may fail or not. But anything anyone wants to do to set up a minor process they think will help themselves, help others, and help the Pedia, go for it and work on it and see what good things may come -- it can always be sent to the history bin, whether its history is long or short. Why not try a place with open discussions about -- so and so wants to be an admin -- what would that mean for them or others, etc. (your proposed project in general holds little interest to me personally but I say to you godspeed and may you enjoy your work on it). Alanscottwalker (talk) 22:21, 28 May 2014 (UTC) I should add all this 'something else is wrong and that other thing should be fixed (which no one can agree on and isn't even trying to fix)' is what's useless, perhaps these discussions on the proposed board will generate breakthroughs in whatever inertia is being complained about this time. Alanscottwalker (talk) 22:56, 28 May 2014 (UTC)
  • Oppose Adminship should be easier to get, not harder. It's because it is so precious that people make it so hard to get, and likewise hard to lose. This just adds another layer of bureaucracy, making the process more labyrinthine than it is. Instead, we should focus on lowering the bar for experienced users to get the mop. --Jayron32 22:35, 28 May 2014 (UTC)
  • Comment - As one going through an RfA right now, I would like to comment that generally, I sought advice from experienced editors (both administrators and non-administrators) whom I trusted, and when there was a consensus among them that I was ready, I kept editing for another few months to convince myself I was ready, and then I ran. Just my two cents; not sure exactly how this process would work, but in theory, it might not be the worst thing in the world, although getting feedback from users whom a prospective candidate trusts is likely a better idea. Just my thoughts for what they're worth. Go Phightins! 00:38, 29 May 2014 (UTC)
  • Support per Hut 8.5 that there is no harm in giving it a try. If it fails or fades out, well, at least it was attempted and can sit quiet for another year or two until someone comes up with a brilliant idea to try it again. On an unrelated note, it is amazing how many admins' signatures here violate that now policy SIGAPP and contain the deprecated <font />. If any of you would like some assistance in bringing your signature into the 21-st century, I'd be happy to help you with the technical coding aspects of it on my talk page. Good day.. — {{U|Technical 13}} (e • t • c) 01:10, 29 May 2014 (UTC)
  • Oppose, Editor Review died because there were no people willing to review, and we are already having difficulties finding voters at RFA properly analyzing the whole contribution of the candidate, so that I think it would just add additional burden on the community without much of a benefit.--Ymblanter (talk) 02:45, 29 May 2014 (UTC)
  • I don't think this is the solution - we have existing pages such as Editor Review that can be used, and spreading interested editors over yet more and more pages is the last thing this project needs. My money is on admin review process being unsatisfactory. Cas Liber (talk · contribs) 04:50, 29 May 2014 (UTC)
  • Oppose If someone wants to find out what they should focus on before approaching RfA, they can just use Editor Review (that's what I did and it worked just fine for me). No point in creating yet another process for people to go thru, and I definitely don't think it should be a formal step. EVula // talk // ☯ // 05:09, 29 May 2014 (UTC)
  • Oppose The absolutely last thing the Wikipedia needs now is more procedure. The project is already paralyzed by nit-picking reviews processes that are doing nothing but scaring away editors (you have seen the participation graphs, right?), and I really can't imagine any scenario where adding another review would improve that. Maury Markowitz (talk) 12:32, 29 May 2014 (UTC)
  • Oppose, I agree 100% with Maury Markowitz: "The absolutely last thing the Wikipedia needs now is more procedure." If WP:NOTNOW candidates are a problem, that's easily solved by establishing some baseline requirements to run for RFA. No candidate with (say) less than 2500 edits and/or a recent block has any realistic chance of passing, so why do we make-believe that they do by letting them run? Establishing some sort of workable minimum criteria would go a long way for a lot less trouble. Andrew Lenahan - Starblind 14:21, 29 May 2014 (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.

Suggestion Colour vs. Black and White

I'd like to suggest that Wikipedia favour colour photographs over black and white photos as information-wise colour photographs serve the purpose better. For example: Noam Chomsky. 117.199.10.200 (talk) 10:51, 29 May 2014 (UTC)Tea

  • While broadly true, there may be cases where a good-quality black-and-white image is preferable to a fuzzy low-quality colour alternative. These things are adequately handled on case-by-case basis and a new policy or guideline is not necessary. --LukeSurl t c 12:33, 29 May 2014 (UTC)
I'm not sure I agree. Are you saying that, for example, a highly detailed black and white map should be replaced with a less detailed colour one?--Ykraps (talk) 12:34, 29 May 2014 (UTC)
I'm saying that Wikipedia should favour colour photographs over black and white photos, i.e., a black and white photo should be replaced with a clear colour photograph, and that a clear colour photograph should be the final aim(regardless of artistic touch). I agree that in instances where a clear black and white photo is the only version available (vs. poor quality colour versions) the black and white photo is the only option. But in such instances, if a clear colour photo is available or obtainable, it must be replaced with a clear colour photograph. In short, I am suggesting that Wikipedia favour colour photographs over black and white photos (not regardless of quality; but subject to type). 117.199.10.200 (talk) 14:28, 29 May 2014 (UTC)Tea
In cases where more than one free image is available the better image should be used. Various factors should be considered, colour would be one of these factors. I don't believe there's any place on Wikipedia where editors believe a photo is good just because it is in black and white. In essence, your idea is already in effect due to WP:COMMONSENSE. I would be against any additional guideline or policy as it could over-emphasize colour over other measures of image quality/utility and also for general WP:Avoid instruction creep reasons. --LukeSurl t c 14:58, 29 May 2014 (UTC)
This is not the way Wikipedia works. We use whatever material is available. If a free-to-use color photo is available and an editor feels like uploading it, it will be used. If only a black and white one is available, and someone feels like uploading it, that's the one we'll use. This is all volunteer, so we only use what people contribute. I'm not sure how this policy would work. It's unlikely that an editor would replace an identical color photo with a b&w one unless the color one was artificially colorized or of poorer quality. Are we supposed to reject uploads of b&w photos if we already have color ones? — Frεcklεfσσt | Talk 14:58, 29 May 2014 (UTC)
Wikipedia doesn't archive all verified quality photo's regardless of quality? It should though, maybe as a side branch.

"Are we supposed to reject uploads of b&w photos if we already have color ones?" 1. We are supposed to choose the best of the two 2. if both are of the same quality, we choose the one in colour. 3. If the b&w one is better we choose it, but try to find a better colour version to replace it with. 117.199.10.200 (talk) 16:50, 29 May 2014 (UTC)Tea

I still don't support this idea. Right now, the only reason we reject images is if they're infringing on a copyright. We want more content, not less. Just because an image exists in Commons doesn't mean it has to be used. Right now, space isn't at a premium for Wikipedia, so I don't see this as an issue. Forbidding someone to upload a file just because we already have a color version is a bad idea, and I fear would just deter people from trying to contribute in the future. — Frεcklεfσσt | Talk 17:15, 29 May 2014 (UTC)
  • There are far too many possible variables to insist on a rigid policy - image quality, resolution, relevance, recentness, etc. It's all down to context, and the best image for each need can only be decided on a case-by-case basis, as it is now. -- Boing! said Zebedee (talk) 17:33, 29 May 2014 (UTC)
  • such a condition would be crazy instruction/guideline/policy/bureaucracy creep B&W can be an effective way to illustrate a subject. In high contrast situations, or where the background colouring is detracting are reasons why a photographer chooses to use it. Additional benefits are the file sizes are smaller making uploading quicker/cheaper for the person providing the image. Images are used as an enhancement in an article editors will choose what is best for the subject what shows the features that suit the specific features, but unless colour is specifically necessary as in the plants flower has orange inflorescence lets leave the editors to make their own choices. Gnangarra 11:04, 30 May 2014 (UTC)
  • Comment The OP said 'photographs'. That means photographs, not maps, drawings or charts. I thought that we already preferred colour to b/w where available. Pics of Victorian bewhiskered gentleman and severe looking ladies with hair in buns aren't normally found in full colour (sepia maybe, or hand tinted b/w which can be ghastly...). Indeed, up to the sixties, b/w was an everyday norm. Now, it's only the 'artistic' type of photographer who takes b/w for effect - and their stuff is copyright and probably unusable here anyway. Mostly, it's stuff from the late fifties, the sixties and early seventies where you get a choice. Before is b/w, after is colour. Colour can always be viewed or printed in greyscale (= b/w). B/w can't be viewed in colour. It's content that matters, and overall quality - which rules out a lot of the early colour pics which are crap. Peridon (talk) 19:17, 1 June 2014 (UTC)

Disability Access Issues with Wikipedia

Hello!

Is it possible to change the background colour for all the Wikipedia articles I view? I have three eye disabilities (lucky me!) that make reading a fine font against a harsh white background increasingly difficult and now lose the ability to focus after only a few hours. Two of the disabilities are recent - within the last three years - and now threaten to blind me if aggravated (damage caused by Type 1 diabetes and diabetic neuropathies).

I have always used a cream tone for anything I can change, such as Windows / MS Office (something like RGB 244, 241, 221) even before the diabetes and this works perfectly fine.

I am sure there are many other people all over the world who find the combination of the harsh white background and fine font difficult to read but do not know how to voice their problem and they are being denied access to an amazing and unrivalled source of free and generally unbiased information. A simple change, particularly of the background colour, is an easy remedy.

Your advice and assistance gratefully received.

Kurt Adam — Preceding unsigned comment added by Kurt Adam 69 (talk • contribs) 05:50, 1 June 2014 (UTC)

@Kurt Adam 69: You can do much of this by adding some CSS to Special:MyPage/common.css. To make most of the background change to  this colour , use 
div#content { background-color: rgb(244, 241, 221) !important; }
This won't affect most boxes, such as infoboxes, tables, the Table of Contents, etc. which are normally a slightly darker background. If you want those altering too, say which ones, also what colour you would like the backgrounds to be; I also need to know which skin you have set at Preferences → Appearance, since that affects the kind of code that is needed.
BTW this is the sort of thing that we often handle at WP:VPT. --Redrose64 (talk) 10:29, 1 June 2014 (UTC)

@Redrose64 Hello! Thank you for your immediate response! :D

I am using the default appearance and do not have a clue how to change the coding as you suggested! :) My website-making experience came and went rather rapidly back in 1996 and became a writer of prose as opposed to code ;)

I would like to adjust Wikipedia as I use it to research a rather mammoth undertaking and switch from looking for iddy-biddy traces of, say, a stone temple on a mountainside or a mudbrick town in the desert on Google Earth, to checking information on Wikipedia and whatever other sources are on the net. I read stacks for hours every day!!!

I am long-sighted since birth and now have Type 1 diabetes and a bucketful of neuropathic damage to go with it. Most activities make my eyes tired but otherwise ok, whereas a few hours on Wikipedia reading about Prestor John and Himalayan Tower Houses just burns my eyes out now and I have to go look at the real 3D world for a while longer than I ever did before and it has become rather alarming as diabetes tends to trash the things it touches.

I am surprised, given the founding ideals and ambitions of Wikipedia, that it has no way to adjust its rather dull and harsh appearance to make it more user-friendly for the visually disabled such as me - and there are MILLIONS of us just with my 3 conditions!!! This isn't just a personal matter - I think it would be smart for Wikipedia to have a frontpage click option; it certainly has plenty of experts freely contributing their expertise on all manner of topics, so it could be done properly I am guessing, but even the simple colour change would help a bundle. I'd like to get on the case and see how far I can run with it.

Thanks again! Kurt Adam (talk) 05:05, 2 June 2014 (UTC)

@Kurt Adam This type of issue is in the purview of WP:WikiProject Accessibility. They should be able to help design a custom skin for your needs. Roger (Dodger67) (talk) 05:56, 2 June 2014 (UTC)
@Kurt Adam 69: I've created User:Kurt Adam 69/common.css with the line of code that I described above. You should now find that most Wikipedia pages that you visit have a straw-coloured background. Not all parts of every page will change, because their colours will need different code to set them. If you say which other areas you would like to be changed I can do those as well; they need not have the same background colour as the main part of the page. --Redrose64 (talk) 11:17, 2 June 2014 (UTC)

@Redrose 64 - Excellent - thank you very much. :) I am very impressed at how quickly a solution has been found. I use Wikipedia and Google Earth all day nearly every day and Google Earth changed how the screen focuses when you move the track wheel from the centre of the screen to the position of the mouse cursor about 4 years back I guess. It has made it impossible to use for longer than a brief session, and impossible to find things without the correct GPS as the world literally keeps moving when you just want it to stay still!!! :D Fortunately I had an old copy on a laptop and I run that in a different file location so the pesky updates don't do their nasty work. I have tried writing to them to say, but they have no proper ear to the ground. No matter that I could be one of their best testers; I know what makes it crash, where the glitches are, I've seen all over the planet, trying to find stuff in deepest Iran and darkest Peru!!! But hey, they are a mega-corporation so as long as the money rolls in, who cares, right? ;) Now it is time to figure out how to edit articles for Wikipedia. The standards I think for English articles is very good now on the whole. I'm the kid that sat in the library reading the Encyclopedia Britannica, so this is Heaven for me! Going blind because of it would really suck, so thanks again for putting that day off for a while longer yet. :D — Preceding unsigned comment added by Kurt Adam 69 (talk • contribs) 01:20, 4 June 2014 (UTC)

noticeboard for anonymous complaints, particularly for cases of fear of retaliation

A lot of us who have been around here for some time will know of cases where individual editors seem to, for whatever reason, fear some degree of reprisals if they should ever do anything to offend certain other editors. Some of us may even have been victimized by such editors. And many of us are long-term editors with registered accounts. IP editors or people with newly established accounts may well be even more fearful of such reprisals, or perhaps harassing complaints to noticeboards, or whatever, particularly if, as newer editors, they may not be as well aware of the efforts some are willing to go to to retain editors.

I think it might be useful, maybe, to have some sort of noticeboard or similar structure in place, and, with any luck, linked to in one or more welcome templates and other help pages, where individuals who are either newer editors or ones who feel some degree of threat of retaliation could post an anonymous tip, similar to those received at anonymous tip lines at many police departments. It would I think be possible to create a page with, perhaps, a preloaded structured method indicating, perhaps, an article name and either a blank for a policy or guidelines name which they believe may be a reasonable concern at that page, and/or perhaps a drop-down menu of the most standard complaints. It might, maybe, be possible for the editing history of that page to be in some way be either harder to access, like maybe by checkuser only, or something like that. Maybe. It might also be a good idea if checking the record of contributions could only be done through a formal request, or, perhaps, by arbitrators, as part of an ongoing case. Granted, it would probably be impossible for others to verify that arbs or checkusers might be checking it for only such reasons, but I think we can reasonably assume that it is extremely unlikely arbitrators who have to wade through the mountains of evidence presented in most cases will want to spend their little time independent of arbitration duties fishing for evidence against others, but I think that is probably a safe bet they won't. And, of course, if other arbs or checkusers were to see evidence that one might have done so, that could be the basis for action against the person doing the fishing.

It might also be a good idea if such a page is created to have the box at the top of the page indicated that it is pretty much intended solely for comments which could perhaps inspire vengeful response, and that other noticeboards would probably be a better place to file comments otherwise.

Yes, I know that it is almost certainly the case that the majority of such messages would be themselves of a questionable nature. If there should be reason to believe that an anon poster there is themselves using it as the basis for harassment, then the checkuser or otherwise qualified editor could check to see if there was clear evidence of such. Anyway, I was wondering what anyone else here might think. John Carter (talk) 19:18, 25 May 2014 (UTC)

This post is simply TL;DR for me, is it anything like Wikipedia:Village_pump_(proposals)/Archive_85#A_noticeboard_about_rude.2C_abusive.2C_or_policy-abusing_admins, Wikipedia:Village_pump_(idea_lab)/Archive_13#Block_review_process_page_suggestion, or any of the other proposals for such a new noticeboard (everyone has a slightly different name for it, but it seems like a perennial proposal to me). — {{U|Technical 13}} (t • e • c) 21:27, 25 May 2014 (UTC)
If someone doesn't want to publicly report a possible problem (for any reason), then e-mail (to a friend, an admin, the arbs) is a possibility. WhatamIdoing (talk) 22:34, 27 May 2014 (UTC)
Such a noticeboard would be problematic in practice for several reasons. If someone resorts to using an IP or a sock account to file a complaint about a specific action, then many reports would be either a report would have to be so vague as to be worthless or detailed enough that it wouldn't be too hard to identify involved parties. Notwithstanding that, such a forum would be used at least as often as a means to evade scrutiny as often as it would for fear of reprisal. An accused party could be denied the opportunity to defend themselves. (Not to mention that Jimbo's talk page already fulfills this role for all intents and purposes, and it doesn't work well.) An OTRS-like email queue might work a little better, but probably not by much since you would require an interested advocate to both speak on-wiki on behalf of the person making the report and whom could assess the probability of a WP:BOOMERANG-esque report. Resolute 22:51, 27 May 2014 (UTC)
I'm not ready to throw it out completely, although I concede it is hard to imagine that it won't attack nonsense and gaming and worse. However, this is the idea lab, where (in theory) we try to identify whether there is some redeeming element to the idea, and see if it can be improved. I think the core issue is valid - some editors have identified concerns, yet are unwilling to bring them up with their names attached. How can we facilitate the reporting without creating obvious problems?--S Philbrick(Talk) 23:08, 27 May 2014 (UTC)
FWIW, in the event the above was too long, the essence of the proposal is to basically just indicate the page in question and maybe a generic concern, either from a drop down menu or with a blank for a relevant policy or guideline, possibly (if it is to be a page) with the edit history available only through checkuser or similar, in the event it somehow gets used abusively. If it were a page, it would probably be best if it indicated at the top of the page that it is basically intended as a last resort, and that other non-anonymous noticeboards should be used first, unless the threat of retribution is immanent. Yeah, a list of editors who could be contacted directly through e-mail, preferably with at least one each for each of the main subdivisions of the Dewey decimal or similar would be a reasonable alternative as well. Some familiarity with the broad topic would be useful, as someone familiar with Evolutionary biology might not be the best choice for a problem at the Omaha Storm Chasers page. But, presumably, any possible respondents to a noticeboard type set-up would be aware of the possibility of retribution or abuse, and might be on the watch for any conduct along those lines. John Carter (talk) 23:30, 27 May 2014 (UTC)
It wasn't too long. The readers attention span was too short.--Anne F. Figy (talk) 11:04, 29 May 2014 (UTC)
It is tricky. The current system tends to tell unhappy people to go off and talk about stuff, until they break an obscure rule and get blocked, get angry and have talk page access removed. (I exaggerate, but only a bit.) Often an AN/I post is an expression of frustration, and should be treated as such, with an attempt to move the problem forward, rather than searching for "boomerangs" and block reasons for either or both parties. Again this is cultural. I'm not sure an additional noticeboard would solve things, nor an additional mailing list, but I'm open to being convinced. All the best: Rich Farmbrough, 23:06, 5 June 2014 (UTC).
I'm wondering if the answer to this is an off-wiki forum. All the best: Rich Farmbrough, 23:11, 5 June 2014 (UTC).

Notification of deletion discussions

It seems to me that when a category is nominated for deletion, a message box should appear on the categorized articles saying that a category on that page is being considered for deletion; just as it is done when templates are nominated. It only makes sense that the editors familiar with the articles categorized should be aware of the discussion, and potential deletion. Anne F. Figy (talk) 11:24, 28 May 2014 (UTC)

Deletion discussions are for editors not readers, so I don't think we should be defacing articles and bothering readers with this sort of thing. (The same logic applies to template deletions.) If there was an effective way of notifying appropriate editors about deletion discussions then that might be worth pursuing. Article alerts seems to work quite well in notifying relevant WikiProjects. — Martin (MSGJ · talk) 11:33, 28 May 2014 (UTC)
There isn't really a clear distinction; many "readers" make occasional edits. But I believe that there's a way to display text only to logged-in users (or only to admins), if keeping it away from the thousands of logged-out editors and many more thousands of non-editing readers were really important. WhatamIdoing (talk) 05:21, 29 May 2014 (UTC)
I think there is a way, but no clear will. Right now swaths of categorization and human effort are being deleted wholesale, by parties of two and three who declare consensus; to the point that Wikipedia:Categories, lists, and navigation templates is barely recognizable from the reckless misapplication of Wikipedia:Overcategorization. From a fallacious mentality, underpinned by the premise that "editors are not capable of maintaining article content" and therefore deletions occur so there will not be the ability to mis-categorized an article.
If a reasonable category is created, and subsequently added to 150 featured articles; and not reverted by one (which implies tacit approval)—that category can be nominated and later deleted by two or three, each with many CfD's under their belt—while none of the article maintainers would even know, or notice a week later when they're just gone. If they did know, it is counterintuitive to imagine that 2 or 3 or 4 of those editors might not show up to defend a categories usefulness and place the deletion perversion in check. To say a message box defaces an article is hyperbole and a poor excuse to allow that it be undermined instead.--Anne F. Figy (talk) 07:17, 29 May 2014 (UTC)
It's worth looking at the proposed methods of widening CfD participation the other editors are suggesting here. All the best: Rich Farmbrough, 00:38, 6 June 2014 (UTC).
Templates display a notification when they're under threat of deletion ({{Template for discussion}}: ‹The template Example is being considered for deletion.› ); they're just as much "for editors" as categories are. It would make a lot of sense for the same thing to happen for categories. — Scott • talk 15:14, 6 June 2014 (UTC)
  • Support. I noticed this a few days ago and I was surprised that the template warning didn't have a corresponding category warning.--cyclopiaspeak! 15:30, 6 June 2014 (UTC)
  • Oppose unless somebody can describe just how this would work. If you take a template to WP:TFD, you add a {{subst:tfd}} to the template, and the {{Template for discussion/dated}} which that adds is visible on any page (article or otherwise) which transcludes the template (unless you enclose it in <noinclude>...</noinclude>). If you take a category to WP:CFD, you add a {{subst:cfd}} to the cat page, and this adds a {{Cfd full}} to the cat page. So far, this is parallel to templates; but category pages are not transcluded, so the {{Cfd full}} will not be visible on the articles that are members of that cat. --Redrose64 (talk) 16:38, 6 June 2014 (UTC)
  • Oppose. Per Martin above. The average reader wants to view content, not be distracted by details meant for behind the scenes maintenance and clean up. Joining the relevant Wikiproject and watching the Article Alert notifications is the simplest and least cumbersome way for individual editors to monitor CFDs.  Philg88 ♦talk 18:21, 6 June 2014 (UTC)

Modal Dialogue Box Before Submitting Without Login

Hi all, it's my first time by the Village Pump, so please excuse my ignorance if I'm doing anything wrong. I keep forgetting to log in before making edits. There are some good suggestions here: Wikipedia:Village_pump_(proposals)/Archive_50#Warn_me_if_I.27m_not_logged_in. But for reasons that may be obvious to some here, I don't want to reveal my IP anywhere. In these situations, someone could easily make this mistake on their first edit, and their IP is now available for the world to see. I believe a modal confirmation has been discussed in the past, but I'm interested in the reasoning behind not implementing this feature. For the user who is not logged in but would like to be, it can be a big deal. For a user that actually wants to edit without logging in, it's just one more click among many, along with a lot of keystrokes in most cases for the actual edit. What am I missing here? ,Wil (talk) 00:48, 4 June 2014 (UTC)

Hi Wil. Interestingly, my team is actually working on a closely related problem right now. We just wrapped up an A/B test where we tried asking unregistered editors to sign up before or after they completed edits. You can learn more about this via the design documentation and I just did a presentation about the preliminary results at our Metrics and activities meeting today (my slides and a YouTube recording are available). TL;DR: we're probably going to implement a version where (once per user) we invite people to register before they even get to the editing screen, though we may have followup A/B tests. The other alternative we haven't tested yet but have prototyped on iOS and Android is prompting people to login/signup at the point of save. Overall, we'd really like to reduce clutter and interrupts at the point someone is actually making an edit, so we're trying to focus on testing options around that activity. Compare this to the current static warning message, which interrupts people mid-edit. CC: Risker who has also discussed this recently with me and others. Steven Walling (WMF) • talk 22:26, 5 June 2014 (UTC)
"Just one more click" is what you are missing. If the system is implemented with good session handling, so that it doesn't keep asking, then it is probably a good thing. Otherwise it's a royal pain (as Steven says, we just had this, it was most irritating). All the best: Rich Farmbrough, 00:46, 6 June 2014 (UTC).
Wil, whether they admit it or not, a lot of Wikipedians just use a different skin than the default Vector skin so that they have a visual reminder that they're not logged in. Some people have personalized skins, but you can go to preferences and select one of the others; Monobook is the most popular. Incidentally, for holders of Wikipedia accounts, you can contact the oversight team to remove your IP address from public view; unfortunately, first-time unregistered editors who don't see the current warning and suddenly find their IP address hanging out on the world are denied that privilege. Risker (talk) 00:55, 6 June 2014 (UTC)
I think this IP exposure requirement causes too much trouble. Aren't a lot of innocent editors required to expose their IP's now?PencilPapers (talk) 15:02, 6 June 2014 (UTC)

URL Shortener update - better idea

The topic of Wikipedia and other Wiki sites using an URL shortening service has come up several times here. The proposal has been something along the lines of wi.ki, wiki.to, wikipedia.co, and so on. My understanding was that one of the concerns with this was the cost of maintaining the other domains, and I think I might have a solution I wanted to float here.

Obviously other sites are built on a MediaWiki platform from the Wikimedia Foundation, and so they could conceivably benefit from the URL shortener as well. The idea is that Wikimedia/MediaWiki would own the domain, but the costs would be subsidized by other wikis who use the shortener. Only those who use this, for a small fee (maybe a few dollars a month or year depending), would have access to it. All of the Wikimedia projects would be using it too, but again the costs are paid by those using Wikis who want to use this as well. Again, I'm not saying people who use MediaWiki, but those who wish to utilize a shortener would pay a very small part of the percentage of the costs it takes to maintain it. 4jonah (talk) 23:41, 2 June 2014 (UTC)

As a general note, there's an unofficial shortener for the English Wikipedia at enwp.org. For example: http://enwp.org/Example . — Scott • talk 15:08, 6 June 2014 (UTC)
Yes, I'm aware of that but for something like http://enwp.org/Taumatawhakatangihangakoauauotamateapokaiwhenuakitanatahu, it wouldn't be as useful as say, wiki.it/Wr9q41sR — Preceding unsigned comment added by 75.110.90.85 (talk) 03:55, 7 June 2014 (UTC)
When I hover over a link, I like to know where it's taking me before I click it. wiki.it/Wr9q41sR could be anything: the only clue there is that it's a wiki (of some sort: not all Wikis are Wikipedia) and that it's based in Italy. Other than that, I have no idea, so wouldn't click it. --Redrose64 (talk) 09:15, 7 June 2014 (UTC)
URL shorteners have plenty of problems. It'd be best if we didn't encourage them. —Tom Morris (talk) 12:48, 12 June 2014 (UTC)

Basics suggestions

Some pages are too technical to be understood. Like those that deal with mathematical theories, politics, law or such. How about a basics suggestion box, based on the articles, that will fully enable you to understand the article in question? (at least to let you know what you require or should look for;what you should read first; to build on.) It shouldn't rely on books for obvious reasons. 117.199.15.181 (talk) 16:38, 18 June 2014 (UTC)BY-SA

The lead for all articles should be digestible by all readers. If they aren't, they are lacking. But some articles are written by experts in the subjects and it's hard for them to understand what they consider fundamental is incomprehensible to others. Also, some topics are so advanced that it's nearly impossible to explain them to laymen in simple terms.
I don't know if a "basics" box is feasible because how could it account for every user; every user has their own level of understanding of any given topic, so how would it know what the user needs guidance on?
IIWY, I would just post on the Talk page of the articles you found unapproachable and ask for a more basic lead. I have, and the principle author(s) generally come back and ask "What don't you understand?", I tell them, then they post a revision and see if I understand that. It goes back and forth until I, a layman in the subject, can understand it. I can't guarantee it will work in every case, but it's worth a shot. If you don't get an answer on the Talk page (give it a day or two), most articles belong to a WikiProject or two, and you can raise the issue there. YMMV. — Frεcklεfσσt | Talk 17:15, 18 June 2014 (UTC)
Actually I found out that there is already a hierarchy at the bottom illustrating some of the basics you need in order to understand the article you're on. Could this be incorporated into "The Wikipedia Adventure"?(So people know about this? At the mention of the words linking to articles would be a good idea.) 117.199.15.181 (talk) 17:49, 18 June 2014 (UTC)BY-SA

Reveal anchor links for headers in articles to increase usability

I propose to reveal anchor links for headers in articles to increase usability.

This idea has been inspired by what GitHub has done when rendering Markdown files in repositories. For instance, in jQuery’s repository, hovering over any headers reveal an ‘anchor’ or a ‘chain’ to its left, whereupon if the user clicks on it, a fragment identifier is appended to the URL. Any existing fragment identifier in the URL may be replaced by a new one.

This allows the user to share articles directing to a specific section or sub-section. One way users can generate the URL with a fragment identifier is by clicking on the links in the article’s table of contents. However, scrolling up to the TOC is an anti-pattern for web usability, especially if an article is long.

Thus, I’m proposing Wikipedia (or MediaWiki) to implement header anchor links much in the same manner that GitHub has done. This would increase Wikipedia’s usability in sharing articles.

As far as I know, I’m unaware if this idea has been proposed/suggested. — Preceding unsigned comment added by Dashed (talk • contribs) 02:43, 19 June 2014 (UTC)

Korea Artists

Hello all,

This is my first time proposing and idea on Wikipedia, and I have no idea if this is the right place/way to do so. Please go easy on me if not ;)

I have been a resident of Korea for the past 8 years and am now fluent in Korean. I have noticed a distinct lack of English information on some fantastic modern Korean artists and would like to start a project to add them to Wikipedia. But along with that also comes a lack of English language sources, so I am wondering what the procedure is for verification in this case.

Please get in touch if you have any tips or would like to be involved.

Marie — Preceding unsigned comment added by Marie.frenette (talk • contribs) 02:23, 19 June 2014 (UTC)

Hi Marie Korean artists isn't a relevant topic for this page. May I suggest that you post a message at the WP:Wikiproject Korea talk page? Best,  Philg88 ♦talk 08:56, 19 June 2014 (UTC)
Welcome, Marie.frenette! Please WP:Be bold in creating or improving articles about WP:Notable Korean artists. It does not matter if all of the sources are in Korean. Our official policy is WP:NONENG: Sources do not have to be in English. If you can find English-language sources, then that is great; if you can't, then please use the best non-English sources you can find. WhatamIdoing (talk) 18:11, 20 June 2014 (UTC)

New way to contribute money!

How about introducing a new way to contribute? How about an option where you can contribute by viewing ads of your choice but only on a page meant for that purpose? (an article free page) The advantage is if you can't contribute real cash it could be possible to bring in small revenue without it being invasive. Another problem may be the bandwidth it would consume. (I don't mean there should be an ad-on-every-page option for those users who opt in for it - that would defeat the point[the point being that the contribution is required to achieve the aim of free education]) It's likely to be more attractive. Ads you choose when you want to see them and what you want to see. You could select 'household' and 'stationary'. However it would be a bad idea to incorporate it to go to a wiki page on 'stationary' as this might offer incentive for brands to unfairly edit the article to include their names or inadvertently promote brands(like in 'hardtack'). PencilPapers (talk) 14:47, 6 June 2014 (UTC)

I understand your idea, but would this cause an increase in server load? That's what I'm wondering. Dustin (talk) 14:54, 6 June 2014 (UTC)
Where is the need of more money? The Wikimedia Foundation have enough money. 78.35.225.154 (talk) 01:34, 18 June 2014 (UTC)
?? Any non-profit enterprise is always in need of money. But as for the proposal, I can't see anyone going out of their way to visit an ad page. Besides, wouldn't this still violate the rationale for not having ads in the first place? That editors might feel inclined to "gently handle" advertisers? — Frεcklεfσσt | Talk 12:34, 18 June 2014 (UTC)
The WMF stops its annual fundraiser when it has met its target, so in a very real sense it does have enough money. This idea avoids some of the pitfalls of advertising in article space, a separate page for ads would avoid both the scenario of company x advertising on the page about itself with material that we would reject in an article due to POV phrasing or primary sourcing, and the reverse scenario of Company Y advertising on the page about its competitor company X. However the link to the page on ads would itself be clutter, unless it was done by replacing the current donate link in the sidebar with support which would be just one letter longer and could lead to a page that gave people the option of supporting by giving money, watching ads, taking photographs or doing some edits. But the risk of that would be that some of the people who currently give money would switch to supporting by watching ads, and the value of getting a few hundred thousand people to look at an ad on the internet is much less than getting a few thousand people to give ten dollars each. So perversely it could get us less money, and of course any reopening of the debate about advertising, even if some of the normal objections are overcome, risks tearing the community apart. I still don't see any advantage in reopening the advertising debate until such a time as our current method of fundraising stops working. ϢereSpielChequers 11:17, 24 June 2014 (UTC)

Article links to indicate quality of linked article

This discussion led me to think about a particular bugbear of mine: "tiny stubs" that amount to no more than one or two sentences (example). I find redlinks a really useful way to identify where we have topic gaps. I find these tiny stubs problematic as they cause me to miss the fact that significant work is still required on the topic (i.e. the real article, rather than just a short description, often no better than something you might see at a disambiguation page).

Extending the logic of colouring, I'd like to see the class of a linked article by the colouring of the internal link, perhaps based upon the colours and functionality used in the User:Pyrospirit/metadata gadget. Would this be possible or would it simply be too much of a drag on the server for the benefit? Would it be possible to assess the size of the article's prose, and not just its byte-size? Also, I see that under the "Preferences-->Appearance-->Advanced option" there is a stub threshold limit (though I've only just found that now while looking for the origin of the text coming from the metadata gadget, so that could perhaps be better advertised). SFB 19:26, 23 June 2014 (UTC)

The "metadata gadget" is "Display an assessment of an article's quality in its page header (documentation)", comprising MediaWiki:Gadget-metadata, MediaWiki:Gadget-metadata.js, MediaWiki:Gadget-metadata.css --Redrose64 (talk) 19:59, 23 June 2014 (UTC)
I think he's looking for having that information available on links to that page instead of having to navigate to them to find out their assessment. So a link to the stub article Pinnacle Peak (Washington) would show up as Pinnacle Peak (Washington), while good article Mount Rainier would be Mount Rainier, or something like that. VanIsaacWScont 21:20, 23 June 2014 (UTC)
@Sillyfolkboy:s idea is worthy of future study, imo.--Tomwsulcer (talk) 22:23, 23 June 2014 (UTC)
Hi, Sillyfolkboy! You could also check Wikiprojects, where there are tables of articles by assesment and importance. There you could find Stub articles by topic. Good luck! --NaBUru38 (talk) 01:46, 24 June 2014 (UTC)
@Vanisaac: Thanks for demonstrating the idea. It's interesting that we have the choice of coloured font vs. coloured background. It might be a worth doing a mock-up to show the difference/benefits. @NaBUru38: my idea is to bring this information out of tables and talk pages and into the context of real content – with the stub threshold tool, for example, I can see instantly on the main page that motorsports is a very small article. I think expanding the variety of what we can show this way could change editors' perspectives on the red/blue link binary (which can often be crudely interpreted as "done/not done"). SFB 06:37, 24 June 2014 (UTC)
The background vs text color for the demonstration was actually practical: I don't know, off the top of my head, how to set link color in CSS, but I could see in Redrose's sig how to set the background. So background it was. VanIsaacWScont 07:21, 24 June 2014 (UTC)
In my sig I set both background and text colour for the same part of the link, using <span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span> which shows as Red; for the background, it doesn't matter whether the link is inside the <span>...</span> or vice versa, but to set the text colour, it only works if the <span>...</span> element is inside the wikilink: Pinnacle Peak (Washington); Mount Rainier
But since this is going to be a gadget, where Javascript and/or CSS files are used to add and modify styling, it may be easier to forget about employing inline styling and instead use the :link and :visited pseudo-classes. You need to set both of these for each different article assessment class, for example 
a.assess-ga-link:link,
a.assess-ga-link:visited {
  color: #007700;
}
a.assess-stub-link:link,
a.assess-stub-link:visited {
  color: #990011;
}
- if you set only the :link, it'll go back to purple as soon as you click it; if you set only the :visited, it'll be blue until you click it. Setting the :visited to the same as :link avoids the need to set up two different colours for each different article assessment class, but means that the distinction between unvisited and visited links is lost. --Redrose64 (talk) 11:58, 24 June 2014 (UTC)

Portal about Wikipedia

Since there is a WikiProject about Wikipedia, there should be a portal for it. However, Portal:Wikipedia currently redirects to the Main Page. I saw the deletion discussion. The Main Page is a "portal" about Wikipedia's contents, not about Wikipedia. Should we have a Wikipedia portal instead? Wikipedia is quite notable in the Wikipedia community. 175.156.242.240 (talk) 18:24, 25 June 2014 (UTC)

There is no rule that every WikiProject should have a portal, or the other way around. WP:WikiProjects are groups of people, and they can do the same things as any other group of volunteers. WhatamIdoing (talk) 18:41, 25 June 2014 (UTC)
WhatamIdoing: I am proposing to convert the redirect to a portal, and as the redirect is fully protected, there is a need to have consensus whether to unprotect or just delete the redirect for other purposes. 175.156.242.240 (talk) 06:51, 26 June 2014 (UTC)
How about coming up with a draft portal first? You could create it in your sandbox or in the Draft: namespace. Then you'd actually have some content to put in the portal once it's unprotected. — Frεcklεfσσt | Talk 12:48, 26 June 2014 (UTC)

We need a way to pique the interests of bored readers!

Hi everyone. I love reading Wiki pages. I love to soak up information, but currently there is no reliable way to find new and interesting articles daily which I might find interesting. In fact, I find myself coming to this place to read interesting arciles as a result of Reddit.

So why is it we rely on Reddit to tell the world about the interesting articles here? Why can't we have our own page which allows users to submit their own links, perhaps even allow a reddit like discussion on them. This would mean that.. even if I don't really know what I'm looking for, and I'm just bored and looking to learn something interesting, I can navigate to this page, and read through the most popular articles of recent-- submited by users.

Not only would this allow for more casual browsing, but this would get users to sign up, and become more involved with Wikipedia.

I am a web developer, and my company is www.soulcreative.org. I would be happy to contribute to the creation of such a page if it were to gain the support of Wiki staff. Even, though, if they believe that is not necceary, I would simply be happy to see this solution come to life. It's very simple, but it would really help both Wikipedia, and users who enjoy light, casual, educational reading.

Thanks,

Luna Prey — Preceding unsigned comment added by Lunaprey (talk • contribs) 06:01, 22 June 2014 (UTC)

  • The main page has a "Did You Know" section that sort of functions like your idea.AioftheStorm (talk) 06:10, 22 June 2014 (UTC)
  • There is also a 'Random page' button on every page. It's amazing where you can get with that. Peridon (talk) 14:37, 22 June 2014 (UTC)
  • Three thoughts:
    1. Sounds good to me.
    2. Any web developer or other interested people should see mw:How to become a MediaWiki hacker.
    3. This is really a content question, which "the Wiki staff" (meaning the staff of the Wikimedia Foundation) leaves to the community—which includes you! You don't need to convince "staff"; you just need to either WP:Be bold or get support from other people in the community. WhatamIdoing (talk) 19:26, 23 June 2014 (UTC)
I think that portals should be improved and promoted heavily. They would help for the purpose that Lunaprey has described. I've done some of that in the Spanish-language Wikipedia. --NaBUru38 (talk) 01:44, 24 June 2014 (UTC)
I think we've got this pretty much covered at Wikipedia:Unusual articles.©Geni (talk) 18:59, 24 June 2014 (UTC)

Extant Organizations Noticeboard

About one year ago from today, User:Jayen466 gave me a barnstar for creating a COI submission wizard (which to this day is still just in user-space) and said they had - for the longest time - felt a BLPN equivalent for companies should exist ("Extant Organizations Noticeboard"). I've been spending some time at BLPN and I quite enjoy it. Both attack pieces and promo pieces are brought there for broader scrutiny and while I find negative material is often removed even when BLP-compliant sources are easily found that can support similar content, all-in-all editors that participate there are fairly neutral and even-keeled. It doesn't feel like a drama board to me.

Company articles are subject to all the same types of POV pushing as BLPs and an Extant Organizations Noticeboard seems overdue. One could be created in literally an hour. I was wondering if there was a reason nobody has started one yet? CorporateM (Talk) 19:17, 23 June 2014 (UTC)

Be bold. :) If someone doesn't like it, they'll nominate it for deletion, and a discussion will ensue. Andreas JN466 22:54, 24 June 2014 (UTC)
  Done I have created the Noticeboard here and ask that anyone that disagrees with it propose it for deletion so a discussion can ensue. I haven't wired it into the noticeboard grid/category/etc. or anything like that, which I think would require more discussion. CorporateM (Talk) 18:16, 26 June 2014 (UTC)
So it's basically a noticeboard for BLP like issues relating to companies and such? I don't see an issue with that. There should be a clear distinction between it and WP:COIN, however. The latter deals with editor issues, this noticeboard deals with negative articles on companies issues. And issues relating to non-neutral articles that aren't attack articles, but are promotional or something like that belong at WP:NPOVN.
What i'm essentially saying is that what this new noticeboard is for needs to be clearly delineated from the other noticeboards. I see you currently have it set to be about promotional and attack articles. Those are two completely opposite topics. SilverserenC 01:46, 27 June 2014 (UTC)
I think - in my mind - a noticeboard's purpose does not (maybe even should not?) be so strictly defined, per NOTBUREAU. BLPN is defined as a place to bring BLP issues, but people also use it for promotional articles, even when a COI is involved that would be equally relevant at COIN. Most noticeboards also overlap with ANI in that sometimes administrative action may be needed. I would just summarize it as "content discussions" related to company articles, though in some cases I could see conduct issues being brought there too, if they decide not to take it to ANI/COIN/Edit-warring/etc.. I don't have a strong opinion on it though. CorporateM (Talk) 02:07, 27 June 2014 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(idea_lab)/Archive_13&oldid=1180253381"