AutomaticStrikeout (talk | contribs) →An admin of the day: new section |
|||
Line 452: | Line 452: | ||
:::::::I wouldn't describe myself as "optimistic" that RfA's original atmosphere can be restored. But I remain hopeful, mainly because I believe that the alternatives suggested thus far would make matters ''worse''. |
:::::::I wouldn't describe myself as "optimistic" that RfA's original atmosphere can be restored. But I remain hopeful, mainly because I believe that the alternatives suggested thus far would make matters ''worse''. |
||
:::::::At this point, WMF intervention might not be a bad idea. I'm generally one of the last people to advocate such a thing, but when the community fails to come up with a viable solution on its own, something must be done. —[[User:David Levy|David Levy]] 20:19, 12 October 2012 (UTC) |
:::::::At this point, WMF intervention might not be a bad idea. I'm generally one of the last people to advocate such a thing, but when the community fails to come up with a viable solution on its own, something must be done. —[[User:David Levy|David Levy]] 20:19, 12 October 2012 (UTC) |
||
== An admin of the day == |
|||
I am proposing the initiation of a project that identifies one administrator each day to be the admin of the day. It would be very similar to the Wikipedian of the Day, but more focused and would be a reward given to an admin for a specific admin task he or she performed. The project would list openings ten days in advance, and users could nominate an admin for any of those days, although they would only be allowed to nominate an admin once per admin task being recognized (as in, you would only be allowed to nominate an admin one time in recognition of a specific action, but you could nominate him for all ten days for ten different reasons). Self-noms would be prohibited. The admin of the day would be the first admin to receive 5 supports (the admin could not support them-self) for that specific day. Likewise, 5 opposes would cause the nomination to be removed. [[User:AutomaticStrikeout|Automatic]]''[[User talk:AutomaticStrikeout|Strikeout]]'' 21:34, 12 October 2012 (UTC) |
Revision as of 21:34, 12 October 2012
Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
- Table of contents
- First discussion
- End of page
- New post
New ideas and proposals are discussed here. Before submitting:
- Check to see whether your proposal is already described at Perennial proposals.
- Consider developing your proposal on Wikipedia:Village pump (idea lab).
- Proposed software changes that have gained consensus should be filed at Bugzilla.
- Proposed policy changes belong at Wikipedia:Village pump (policy).
- Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
- Proposed new wikis belong at meta:Proposals for new projects.
- Proposed new articles belong at Wikipedia:Requested articles.
Bureaucrat rights' proposal
Proposal: remove/hide signature button when editing articles
This proposal is short and sweet: I propose removing or hiding the signature button ( or ) from the editing toolbar when the page being edited is an article. Per WP:SIGNHERE, "Edits to articles must not be signed, as signatures on Wikipedia are not intended to indicate ownership or authorship of any article."
Adding a signature to an article is a common mistake among new users (my bot spends much of its time removing these from articles), and whenever something's not supposed to be done, it makes sense not to have a button to do it. (If there ever is a reason where an article should be signed, a user could still just type ~~~~ manually in the edit window to do it.) 28bytes (talk) 23:02, 30 September 2012 (UTC)
- Sounds like a good idea, but having a magic word or other setting to enable the button on a per-page basis would be good (such as for project pages like this one).--Jasper Deng (talk) 23:05, 30 September 2012 (UTC)
- Support. There's no reason why an article should be signed. --Rschen7754 23:40, 30 September 2012 (UTC)
- Support - though I don't know of its technical implementation.--Jasper Deng (talk) 23:59, 30 September 2012 (UTC)
- Rather easy: Check if the edited page is in mainspace, then skip, else show the button. mabdul 08:40, 1 October 2012 (UTC)
- Support provided technical implementation won't be complex or take excessive developer time relative to other priorities, and provided this won't create a server load issue (since a different page configuaration would need to come up for some pages tha others). Newyorkbrad (talk) 00:20, 1 October 2012 (UTC)
- Support iff NYB's conditions are fulfilled. --Guerillero | My Talk 01:08, 1 October 2012 (UTC)
- Okay It's alright, but what does it solve? The most it might help with is if new editor goes to sign their contributions. Other than that the only time four tildes have appeared in a row in an article is for vandalism. It might just be easier to put ~~~(~~) on a blacklist specifically for the article namespace. Regards, — Moe ε 02:37, 1 October 2012 (UTC)
- There's no reason to have it there at all in the article namespace - it just adds clutter to the toolbar. -— Isarra ༆ 02:45, 1 October 2012 (UTC)
- Not saying that it doesn't, but the difference between (around) 25 clickable things versus 24 isn't the argument, I think. If the goal is to have lower instances of signatures appearing in the article namespace, then a blacklist on a string of ~ appearing is a better solution. Manually, ~~~~ could still be typed out by editors, making the button not being there pointless. Regards, — Moe ε 05:08, 1 October 2012 (UTC)
- A button is still easier to click by accident than a pile of tildes are to type out, and just blocking the end result won't stop people from doing it in the first place and getting confused. If it is an issue, perhaps doing both would be in order? -— Isarra ༆ 05:22, 1 October 2012 (UTC)
- Possibly. I have no preference whether the button stays or goes personally, I was just addressing the problem it creates being there rather than its existence. Either a blacklist or a notification (similar to the "you are missing an edit summary" save notification) if ~~~[~~] are saved in the article namespace would probably fix it, along with removing the physical button. Regards, — Moe ε 06:11, 1 October 2012 (UTC)
- I believe there are a number of maintenance templates used in article-space which involve timestamps generated through a five-tilde signature, and various deletion-related templates (eg speedy, prod) are often signed by editors. I don't think technically prohibiting the string is the best solution. Andrew Gray (talk) 13:59, 1 October 2012 (UTC)
- Possibly. I have no preference whether the button stays or goes personally, I was just addressing the problem it creates being there rather than its existence. Either a blacklist or a notification (similar to the "you are missing an edit summary" save notification) if ~~~[~~] are saved in the article namespace would probably fix it, along with removing the physical button. Regards, — Moe ε 06:11, 1 October 2012 (UTC)
- A button is still easier to click by accident than a pile of tildes are to type out, and just blocking the end result won't stop people from doing it in the first place and getting confused. If it is an issue, perhaps doing both would be in order? -— Isarra ༆ 05:22, 1 October 2012 (UTC)
- Not saying that it doesn't, but the difference between (around) 25 clickable things versus 24 isn't the argument, I think. If the goal is to have lower instances of signatures appearing in the article namespace, then a blacklist on a string of ~ appearing is a better solution. Manually, ~~~~ could still be typed out by editors, making the button not being there pointless. Regards, — Moe ε 05:08, 1 October 2012 (UTC)
- There's no reason to have it there at all in the article namespace - it just adds clutter to the toolbar. -— Isarra ༆ 02:45, 1 October 2012 (UTC)
- Support emphasizing that this only applies when editing an article. Pine✉ 06:05, 1 October 2012 (UTC)
- Support, but button should be blanked out rather than completely removed, so that the other buttons are in same place, for the sake of editors who use them a lot and whose fingers know exactly where to find them. PamD 06:40, 1 October 2012 (UTC)
- If implemented in JS, this will also avoid the problem of a user trying to select a button before the JS fully loads, and then clicking the wrong button as everything "jumps" to the side. (I keep having this with the top-bar links, as "My sandbox" lags a second or so) Andrew Gray (talk) 14:25, 1 October 2012 (UTC)
- Support, Makes sense. Kudpung กุดผึ้ง (talk) 07:42, 1 October 2012 (UTC)
- Support, really good idea! mabdul 08:40, 1 October 2012 (UTC)
- Support The button could be disabled or grayed out if removing is technically complex. --Anbu121 (talk me) 08:44, 1 October 2012 (UTC)
- Support Computer software usually makes it impossible for users to do things that ought never to happen. On Wikipedia, we make it technically possible to do undesirable things, then when a confused newcomer does them, we revert them and give that user a telling off. This change would be a first step towards remedying that. MartinPoulter (talk) 12:45, 1 October 2012 (UTC)
- This is in Bugzilla (remarkably enough, from 2006). Link added. Andrew Gray (talk) 14:08, 1 October 2012 (UTC)
- Support, I too remove mistaken signatures in articles, from mis-clicks of buttons. This one is not needed for editing articles. Fylbecatulous talk 14:12, 1 October 2012 (UTC)
- Support Makes sense, little to no chance of causing problems, and removes a common nuisance. --Jayron32 14:14, 1 October 2012 (UTC)
- Support assuming it doesn't create technical problems. It's just good UI design.--Curtis Clark (talk) 14:55, 1 October 2012 (UTC)
- Support Yay, you're halving the edits my bot has to do! Why did nobody think of this years ago? Rcsprinter (talk) @ 15:12, 1 October 2012 (UTC)
- Support as this is a no-brainer. AutomaticStrikeout 18:39, 1 October 2012 (UTC)
- Support. Sensible suggestion. Axl ¤ [Talk] 20:12, 1 October 2012 (UTC)
- Support, although to my mind a greater problem than stopping new editors signing articles is the problem of getting them to sign talk page posts... Peridon (talk) 20:59, 1 October 2012 (UTC)
- Support but I'd prefer to do the right thing—change the software so it automatically signs where needed. If it monumentally silly that we ask new users, faced with a mountian of non-obvious rules, to add one more that could be handled by the software. --SPhilbrick(Talk) 22:53, 1 October 2012 (UTC)
- I don't think it would be that easy to automate signing. I mean, we could program so that everything one posts on a talkpage has four tildes added at the end ... but suppose I post something, and it's signed, and then I go back and fix a typo in it. Do I then wind up with a second signature in the middle of a sentence? (And then there are pages, such as RfAs, where most comments need to be signed but there are some mechanical things that don't, and so forth....) Newyorkbrad (talk) 02:02, 2 October 2012 (UTC)
- I grant that it isn't trivial, but I've posted in a lot of forums, and I can't think of another one where I have to sign. Surely if everyone else has figured it out, we can too. To respond to the specific question about typos, in one other discussion site, every post is signed, but if I see I made a typo, I click on edit, as opposed to post, and it doesn't add a new sig. The problem here is that everything is an edit, we don't distinguish between new posts and edits, but one possibility is either that minor edits (which should apply if it is a typo) would not be signed, alternatively, there could be a box to check which indicates not to add a sig. As for RFAs it should be easy enough to identify pages which are not normally signed.--SPhilbrick(Talk) 17:07, 8 October 2012 (UTC)
- Those forums store every post separately; that allows for the post to be linked to the author. MediaWiki does not have that. For all it knows, this discussion is simply a long unnumbered list. Building in something like you proposed is quite a lot of work, that will result in a likely buggy implementation with its own quirks that annoys a lot of people who are, for better or worse, used to the old system, all for relatively little benefit. T. Canens (talk) 16:03, 12 October 2012 (UTC)
- I grant that it isn't trivial, but I've posted in a lot of forums, and I can't think of another one where I have to sign. Surely if everyone else has figured it out, we can too. To respond to the specific question about typos, in one other discussion site, every post is signed, but if I see I made a typo, I click on edit, as opposed to post, and it doesn't add a new sig. The problem here is that everything is an edit, we don't distinguish between new posts and edits, but one possibility is either that minor edits (which should apply if it is a typo) would not be signed, alternatively, there could be a box to check which indicates not to add a sig. As for RFAs it should be easy enough to identify pages which are not normally signed.--SPhilbrick(Talk) 17:07, 8 October 2012 (UTC)
- I don't think it would be that easy to automate signing. I mean, we could program so that everything one posts on a talkpage has four tildes added at the end ... but suppose I post something, and it's signed, and then I go back and fix a typo in it. Do I then wind up with a second signature in the middle of a sentence? (And then there are pages, such as RfAs, where most comments need to be signed but there are some mechanical things that don't, and so forth....) Newyorkbrad (talk) 02:02, 2 October 2012 (UTC)
- Support as straightforward. Would
.ns-0 .wikiEditor-ui a[rel="signature"] {display: none;}
or similar suffice for the WikiEditor UI? That should probably work, but someone should check it over. {{Nihiltres|talk|edits|⚡}} 00:42, 3 October 2012 (UTC) - Support - definitely no reason for the sig button when editing articles, and it just leads to mistakes among newcomers. Eliminating it would help improve Wikipedia. --Jethro B 01:07, 3 October 2012 (UTC)
- Support - A button should only esist if it can be used appropriately in some conceivable circumstance. I see no such circumstance for this button. — Preceding unsigned comment added by Tazerdadog (talk • contribs) 03:53 3 October 2012 (UTC)
- Comment This can easily be done by looking at the ca-addsection element presence. Alternatively though, I have also been thinking if it would not be a good idea to move the sign button to the bottom right of the edit screen when you are at talk pages. At least out of the toolbar. I feel it's not fully in it's right location and the reason for that is probably mostly 'historical'. This point/issue might be something for the team of Oliver Keys. —TheDJ (talk • contribs) 07:42, 4 October 2012 (UTC)
- Support — Makes sense to me. When will we ever have a need to sign our names in article space? Just imagine reading this in an article as someone who's never even set foot in Wikipedia's backroom discussions (i.e. this place):
“ | George Washington was one of the Founding Fathers of the United States, serving as the commander-in-chief of the Continental Army during the American Revolutionary War and later as the new republic's first President. --Lackadaisical Office Temp (talk) 13:13, 13 October 2013 (UTC) | ” |
- No, doesn't make any sense. No scenario where it'd be useful. Yes, this is a discussion about an arbitrary technical update, but like I said, it makes sense to not have that button there. Kurtis (talk) 06:37, 7 October 2012 (UTC)
- Support per "oops you didn't mean to do that, did you?" [1] (and apologies for posting an example for why it is needed - I've probably done the same thing myself...) AndyTheGrump (talk) 06:53, 7 October 2012 (UTC)
- Support --Orange Mike | Talk 00:29, 8 October 2012 (UTC)
- Strong support – There is absolutely no good reason for signing articles – especially ones in the article namespace. If you really, really have to, you can just type
~~~~
. –– Anonymouse321 (talk • contribs) 20:32, 9 October 2012 (UTC) - Support; since there's no valid reason for a signature in articlespace, there's no reason for the button. --R'n'B (call me Russ) 21:31, 9 October 2012 (UTC)
- Support if this is technical possible. Blue Rasberry (talk) 21:53, 9 October 2012 (UTC)
- Support If technically possible. — ΛΧΣ21™ 03:26, 10 October 2012 (UTC)
- Support no need for this in the article namespace. — MrDolomite • Talk 13:41, 10 October 2012 (UTC)
- Support, though with the addition of a magic word to override on certain pages if deemed necessary (however rare that would be). elektrikSHOOS (talk) 15:51, 12 October 2012 (UTC)
Email Notifications (No Re-Arm)
As is, articles can be monitored for changes by adding them to My Watchlist and setting up My Preferences\E-mail options to "E-mail me when a page or file on my watchlist is changed".
Unfortunately, after each notification a user has to log in and visit the watched page to "re-arm" the notification service.
It would be nice if notifications would continue without having to "log-in to re-arm". — Preceding unsigned comment added by 195.241.24.118 (talk) 00:13, 2 October 2012 (UTC)
- On the other hand, consider what would happen when you watch very busy pages, like this one or like WP:ANI. You'd wake up in the morning and have an inbox full of hundreds of change notifications. And then you'd come home from work and have an inbox full of hundreds more change notifications. Take a holiday for a few days, and come back to thousands. I don't think that would work for very many people. Anomie⚔ 20:05, 2 October 2012 (UTC)
- Who would watchlist a page that is constantly updated, generating "thousands" of e-mail notifications a day? What would be the point? Perhaps the concept of "watching" should be refined to give people the explicit choice to "favorite" and/or "subscribe". --rrzzrr (talk) 03:31, 8 October 2012 (UTC)
- Not everyone uses the watchlist the way you do. 2307 have this page watchlisted, 2397 watch Wikipedia:Village pump (technical), 2571 watch Wikipedia:Village pump (policy), 2744 watch User talk:Jimbo Wales, 3559 watch Wikipedia:Administrators' noticeboard, 5614 watch Wikipedia:Administrators' noticeboard/Incidents, 3539 watch Wikipedia:Administrator intervention against vandalism. Especially now that we have the ability to show which revisions have changed since the last visit in the history for watched pages, watchlisting these pages can be very useful. Anomie⚔ 10:47, 8 October 2012 (UTC)
- Here's who: subjects of BLP articles. People keeping an eye on articles about companies. Quite frequently, people want to know immediately when someone changes an article if that change is likely to cause them real-world stress. Unlike the hardcore Wikipedians, admins (etc.), some expert editors are likely to have very short watchlists. If someone is an expert on, say, an obscure 18th century German philosopher, their watchlist might just consist of one or two articles. Email is actually perfect for that kind of use case, even if it would be overkill for those of us with thousands of things on their watchlist. —Tom Morris (talk) 11:52, 12 October 2012 (UTC)
Proposal to create a Wikipedia blackout in the Philippines
Editors are discussing a Wikipedia blackout in the Philippines at Wikipedia talk:Tambayan Philippines#Proposed blackout. Frankly, I disagree with them that local consensus on that page can be used to make that decision, but I better let some people know. Ryan Vesey 05:15, 3 October 2012 (UTC)
- English Wikipedia blacked out for SOPA; why not black out worldwide for this new law that is equally bad in a different country? John Vandenberg (chat) 07:33, 3 October 2012 (UTC)
- This is possible, but not as a result of a discussion on a talk page, I guess.--Ymblanter (talk) 07:35, 3 October 2012 (UTC)
- If there will be a blackout, it will most likely be a localized one, not a global one like the SOPA/PIPA blackout. But if non-Filipinos would like to take up the cause of RA 10175, then they are free to do so. (And Yaroslav, that "talk page" is the Philippine notice board. I don't see why people think that proposals can't go through a country's regional notice board if the issue affects users in the country in question.) --Sky Harbor (talk) 07:50, 3 October 2012 (UTC)
- John, the main difference is that the English Wikipedia has to comply with US law, so SOPA and PIPA could have had an outsized effect on us. The WMF isn't based in the Philippines. WhatamIdoing (talk) 19:36, 3 October 2012 (UTC)
- As I recall, there's a few countries who have tried to say that we're not complying with their laws, and we've responded "we're an American site that hosts our content in different languages. Just because much of that content is maintained by people in your country does not change the fact that we only have to comply with US law." Ian.thomson (talk) 19:41, 3 October 2012 (UTC)
- Based on what I've been hearing from the lawyers who are also riled up about this, the situation currently confounding Filipino Wikipedians is akin to the situation involving the Italian Wikipedia. The law punishes people for what they say on the Internet, regardless of where that data is stored. This is why people here are making such a big deal about how the law could potentially affect our right to freedom of expression: because of the way libel is defined in Philippine law, where it is the substance that is punished and not the intent, there is a very big risk for users to continue with our activities here if we know we're risking 12 years in jail, a one-million peso ($20,000) fine, or both! For example, a BLP violation or a politician wanting to get revenge for Wikipedia "slandering" him can easily sue and possibly win, or in the meantime get the Department of Justice to issue a takedown order to remove the "offending" material without the need for a warrant.
- As I recall, there's a few countries who have tried to say that we're not complying with their laws, and we've responded "we're an American site that hosts our content in different languages. Just because much of that content is maintained by people in your country does not change the fact that we only have to comply with US law." Ian.thomson (talk) 19:41, 3 October 2012 (UTC)
- Just because the Wikimedia Foundation's servers are based in the United States does not change the fact that in many countries, Internet users (Wikipedians included) are governed by both U.S. and local law: U.S. law for content storage, and local law for things that netizens do online. It's the latter's prospects that have scared many Filipino netizens, Wikipedians included. --Sky Harbor (talk) 23:41, 3 October 2012 (UTC)
- This is why Scott MacDonald's approach to WP:NPOV is correct. Nyttend (talk) 12:52, 6 October 2012 (UTC)
- Just because the Wikimedia Foundation's servers are based in the United States does not change the fact that in many countries, Internet users (Wikipedians included) are governed by both U.S. and local law: U.S. law for content storage, and local law for things that netizens do online. It's the latter's prospects that have scared many Filipino netizens, Wikipedians included. --Sky Harbor (talk) 23:41, 3 October 2012 (UTC)
Editor review with RfA/RfB in mind
I'm proposing a new form of editor review that would be a precursor to an RfA or RfB. I know that many times that is effectively the case anyway, but this new type of review would dispense with any uncertainty as to the purpose of the review. The review would be conducted to allow a user to gauge whether or not he has enough support to conduct a full-fledged RfA/RfB. Other editors could comment by saying that they would likely support, oppose or be neutral in a future RfA/RfB. This review would give the user a better idea as to if a week-long RfA/RfB would be worthwhile or if it would just be a waste of time. Also, editors contributing to such a review could provide the editor being reviewed with suggestions on how to better refine their editing skills in preparation for an RfA/RfB. The review would be closed by the editor in question at a time determined by him or her. AutomaticStrikeout 00:55, 5 October 2012 (UTC)
- Support Per nom. --v/r Electric Catfish (talk) 14:09, 5 October 2012 (UTC)
- Comment: so a straw pool with additional comments? mabdul 14:11, 5 October 2012 (UTC)
- Support: That would increase the probability of getting a review. --Anbu121 (talk me) 20:56, 5 October 2012 (UTC)
- I think it would be helpful for an editor who is really seeking a review with adminship in mind if they can officially get a review that pertains to adminship. Also, I think editors would be more willing to simply state if they would support a user than conduct a full-fledged review. AutomaticStrikeout 23:13, 5 October 2012 (UTC)
- Comment - Note that this is a recurring proposal. - jc37 23:20, 5 October 2012 (UTC)
- Comment - Not necessary for threee short reasons: 1. Most candidates don't bother to do an editor review. 2. Most editor reviews are don with adminship in mind anyway. Hardly anyone is interested in becoming an admin these days. Kudpung กุดผึ้ง (talk) 23:42, 5 October 2012 (UTC)
- Question: How is this different than Wikipedia:Editor review? --Jayron32 04:57, 6 October 2012 (UTC)
- All they have to do is make that statement when requesting an editor review. I would suggest no new board. Perhaps this is a softer RFA, but typically there will not be a lot of response unless the candidate actually runs! Graeme Bartlett (talk) 11:13, 7 October 2012 (UTC)
- Oppose if somebody wants to gauge whether he would or would not pass a RfA, he can go thru one and find out. We don't really need an additional process designed as a pre-RfA. And if one wants feedback on their work, strength and weaknesses than there's the already existing, tho weak, editor review process. This is a solution in lack of a problem, and it hardly solves anything. Creating a pre-RfA hardly solves either our problems of lack of active sysops or that some percieve RfA has a too high bar. It has been proved in the past over and over that there's no harm in running for an RfA, multiple admins have been elected after multiple failed runs, and as such there is no reason to create an additional process when two already processes cover it perfectly. Snowolf How can I help? 10:53, 10 October 2012 (UTC)
- Comment We used to have Admin coaching, something I believe Esperanza introduced. I went through it. Here's my admin coaching page when I was preparing for RfA. Admin coaching has now fallen into disuse and is marked as "historical". If people want this, they could revive it. —Tom Morris (talk) 11:57, 12 October 2012 (UTC)
Templates for new city articles
Hi everyone! I'm active in New Page Patrol, and for a while now I've been seeing an increasing trend of new articles about cities and towns. While these are, obviously, a good thing, there's also a problem: these articles look horrendous. So, what I am proposing is a new sort of template - a template that would theoretically work like this:
- the current "create a page" workflow adds a new button to the last page: "create an article about a city or town"
- if clicked, the new article edit window is opened: preloaded with a subst:city (or whatever its name will be) template that includes fields for variables that would belong in an infobox, categories, as well as things like name, nearest town, a "fill in your own other stuff" box, etc -- all common in these new city articles.
When the user clicks Save page, the template is substituted, and voila! A new gorgeous city article. Thoughts? Theopolisme 12:11, 6 October 2012 (UTC)
Support Sounds like a good idea to me. AutomaticStrikeout 02:22, 7 October 2012 (UTC)
- Support for towns/cities only. Per my comment earlier today here, I'd strongly object to broadening the automation to any topic other than those like cities, mountains, sports teams etc where an infobox is always appropriate - if a new editor follows all our instructions to the letter, and then the infobox is removed as inappropriate by someone, it's likely to confuse and annoy the newcomer. Mogism (talk) 14:59, 7 October 2012 (UTC)
English variations
I'm just wondering, has anyone ever proposed some sort of addition to the edit window in articles tagged with english variation templates like {{Use British English}}
? I can see that an old top-icon has been removed, but how would editors know about these templates placed at the top if they're editing only a section, for example? There seems to be no notification to the editor that the article uses a specific variation, as the template itself is invisble in read mode, is a hidden category, and only appears in the hidden categories on the edit page, which are now even more hidden by the new edit window design. So I suppose what I'm suggesting is that for articles tagged with these templates, some sort of edit notice should be in place in the edit window (kind of like the one for BLPs) Brambleclawx 14:44, 7 October 2012 (UTC)
- Excellent idea, particularly if there's some way to automate it. Mogism (talk) 14:47, 7 October 2012 (UTC)
- I think you want an WP:Edit notice. I don't think it can be automatically added by the template, but I believe that we could set up a bot to create one for every page that has the UBE template. You'd need to file a WP:BOTREQ. WhatamIdoing (talk) 23:52, 7 October 2012 (UTC)
Would it be beneficial to seek consensus somewhere other than here first then, before filing a bot request? Brambleclawx 02:18, 8 October 2012 (UTC)
- It would be necessary to seek a strong consensus (i.e. much more than just 1 other person supporting), but whether that is done here or elsewhere probably doesn't matter much. Anomie⚔ 02:24, 8 October 2012 (UTC)
Democratic wikipedia fork
I propose that Wikimedia will initiate a fork of Wikipedia where the rules of editor interaction are democratic. I set up a fork under the name of Creative Democracy to host this proposal until it is picked up. Its charter reads:
Creative Democracy is a democratic Wikipedia fork. Like Wikipedia it accepts anyone to its editor ranks, but, unlike Wikipedia it follows the principle of separation of powers as a federation of categories, guided by noting but Humanism at large.
All other issues are left to decision of the federal legislative body. |
→Yaniv256 wind roads 19:13, 7 October 2012 (UTC)
- You don't need consensus to make this fork. It is very unlikely that Wikimedia will host a fork of one of its own websites, especially since Wikimedia wikis are built on cluocracy; ballot-stuffing via sockpuppetry would easily be a logistical problem.--Jasper Deng (talk) 19:26, 7 October 2012 (UTC)
- The idea behind forking Wikipedia is that given that all of its articles are in the public domain What? No, not true at all. You should probably read Wikipedia:Reusing Wikipedia content. LegoKontribsTalkM 20:09, 7 October 2012 (UTC)
- See fork footer "Content is available under Creative Commons Attribution Share Alike". This is a legitimate fork initiative. If anyone feels this fork is not in compliance with its stated license please let me know why and I'll do my best to correct it. →Yaniv256 wind roads 20:36, 7 October 2012 (UTC)
- While I think your idea is a good one, and I personally wouldn't mind working on a website that actually was set up in a democratic fashion, I don't think your plan has much of a chance of taking out. I generally believe that attempting to work on a fork of Wikipedia is a waste of time for the contributors. It is unlikely to get a similar level of participation or readership. I wouldn't contribute for that reason. Ryan Vesey 20:59, 7 October 2012 (UTC)
- You don't need our permission. Every single contribution to the English Wikipedia comes with a license that allows you to make your own copy whenever you want. WhatamIdoing (talk) 23:53, 7 October 2012 (UTC)
- Barking mad proposal. Wikipedi is a bad system that works quite well. Your proposal sounds like a good system that'll fail pretty much instantly as a result of a) no take-up and b) mass ballot-stuffing & sockpuppetry. I very much doubt yuo've thought the proposal through. I am very confident that it is not going anywhere. --Tagishsimon (talk) 11:44, 12 October 2012 (UTC)
- To the contrary, I think this is an exceptionally good proposal (well, apart from the part seeking to have Wikimedia host it, which is IMHO not gonna happen, and in any case this is not the forum to decide that). Let contributors decide where they want to contribute. That way, the people who actually want to contribute to building an encyclopedia can stay with Wikipedia, and those who want to play a political science simulation game can go with this fork. --R'n'B (call me Russ) 13:50, 12 October 2012 (UTC)
- Comment: So, err, have fun. Be sure to avoid the failures of all the other Wikipedia clones. —Tom Morris (talk) 12:00, 12 October 2012 (UTC)
Proposal for redesign of Help:Contents
A redesign of Wikipedia's main help page has been proposed. Comments are welcome on the talk page. the wub "?!" 11:41, 8 October 2012 (UTC)
a proposal
Dear Mr./Ms.,
I am one the milions users of your outstanding website. perfect job! However, take this as a suggestion. I'd like to know your opinion about what if most of the people in the world could have a page on your pedia page. Basically just those the most important and well known persons have wikipedia page as who they are and what they did. But may be it would be a good idea for less important people, I mean, compare to celebrities, athletes, scholars or the others can be a wikipedia; although, not necessarily that much complete. What I mean is that to design something somehow as a curriculum vitae of normal people. For example if someone wants to apply for a job or university easily their personal information accessible on your website. Is it possible?
I hope I could convey the message what had crossed my mind. I am sure you all are talent enough to elaborate all the ideas perfectly. Thanks in advance!
Sincerely, B.M.Azmoodeh — Preceding unsigned comment added by 193.205.230.58 (talk • contribs) 17:33, 8 October 2012
- This idea, while interesting, cannot be implemented on Wikipedia. It may be appropriate for another website or wiki, but we strive to be a neutral, verifiable encyclopedia. As such, there are things that Wikipedia is not. In particular, Wikipedia is not a social network, a resource for conducting business, or a means of promotion. szyslak (t) 16:47, 8 October 2012 (UTC)
- Aren't you proposing Facebook?--SPhilbrick(Talk) 17:14, 8 October 2012 (UTC)
- Or more specifically, LinkedIn. Apteva (talk) 20:28, 8 October 2012 (UTC)
Prolific IP editors - encouraging them to register
Most IP editors only make a small number of edits to Wikipedia. However there are some that contribute much more to it. Whilst IP editing is generally OK (and note - I am NOT proposing that we prevent it), it can be problematic, particularly when another editor wants to discuss something with an IP user whose IP address changes (e.g. to point out a consistent error they're making or a policy they're not following properly). Yes, you can post on an IP Talk page, but next time the editor logs on they might have a different address and therefore not see the message. Also, where an IP user is enaged in a discussion, it can be difficult to keep track of what they're saying - each time they post to the thread, it may appear as though they're a different person. Where IPs edit once or twice and then disappear, this isn't a problem, but some IP users are quite prolific and should really be encouraged to register so that they can contribute more effectively to Wikipedia.
I therefore propose capping the number of edits that can be made by an IP address in a certain time period, say, a maximum of 20 edits per day. Those users that only do a little bit of editing won't be affected, but the more prolific ones will be more inclined to register. This approach may also help to reduce mass vandalism by some IPs. What do you think? Bazonka (talk) 20:27, 9 October 2012 (UTC)
- So basically you're saying that IP editors can't make mistakes and fix them? ♫ Melodia Chaconne ♫ (talk) 22:20, 9 October 2012 (UTC)
- Er, no. IP editors are likely to be less experienced and less knowledgable of Wikipedia policies than an active registered user. Everyone makes mistakes or does things wrong, especially new editors. If they amend their own errors then fine, but sometimes people need to be nudged in the right direction or shown what to do. It's all part of Wikipedia's collaborative processes. If it is difficult to communicate with a user, then this nudging won't be as effective. Bazonka (talk) 22:26, 9 October 2012 (UTC)
- As one of the many very prolific IPUsers, I strongly object to any restrictions on using IP editing. What I normally did as a work around was to move discussion to the registered users talk page to consolidate it and so that I could find it again. I also move discussions that were started on one user talk page and answered on another (if I am one of the two parties), so that the discussion is in one place and easier to follow. This is an encyclopedia and by nature there are many edits that can most easily be made by someone who is an expert in that subject, and the annoyance of having to make up a username just to be able to make an edit is absurd. And if that person sees 50 or a 100 things to fix in one day so much for the better. While I frequently got encouragements to register, it was a little pointless two years after I already had... Apteva (talk) 23:11, 9 October 2012 (UTC)
- @Apteva, since you already have two(!) registered accounts, I cannot understand why you'd ever want to edit as an IP. This is a form of sockpuppetry, and since you don't get the advantages of a registered user, e.g. a watchlist, then why would you want to do it? Making sure that your conversations are all readable is good, but will all IPs do this? Probably not. Also, if I wanted to start a conversation with you via an IP talk page then I have no way of knowing whether it will actually reach you, unlike if I were to use User Talk:Apteva. Bazonka (talk) 07:23, 10 October 2012 (UTC)
- The answer to "why" is beyond the scope of this conversation. I was simply pointing out that there are many prolific IPUsers and I am one of them. I rarely if ever missed anything that was placed on an IP talk page, as the orange bar shows up just like for everyone else, but had I not moved it to the user talk page following the conversation the next day, from a different IP address would have been difficult. I can think of an Admin who never checked or responded to anything on their talk pages - though after that was pointed out they might have become a former Admin. As to a watchlist, it gets so full as to become useless, so I rarely use it (my recollection is that out of 4,000 edits I have edited about 1,000 different pages). So I have the village pump and maybe two or three other pages on it right now. Apteva (talk) 13:33, 10 October 2012 (UTC)
- I note that you didn't respond to my comment about sockpuppetry. My suggestion about a daily cap of IP use would surely help to reduce this heinous crime. Regards, Bazonka (talk) 16:30, 10 October 2012 (UTC)
- Distinguish "sock-puppetry" from "multiple accounts". Our primary goal in discouraging sock-puppetry is to encourage good behaviour and discourage bad behaviour. As long as Apteva's following our guidelines and policies and generally behaving well, there's no real issue with them having multiple accounts. IAR. {{Nihiltres|talk|edits|⚡}} 17:36, 10 October 2012 (UTC)
- I'm not convinced such a restriction would have an impact on sockpuppetry and it may have unintended consequences. Here is an example of an editor who uses sockpuppetry extensively both via registered accounts and via IPs. The list of IPs used is incomplete because they sometimes use IPs that aren't reported because blocking them would cause collateral damage (e.g. to a university network). An edit restriction could also cause collateral damage. This SPI case archive is a good source of sock data. The indefinitely topic banned and subsequently blocked editor has used sockpuppetry pretty consistently over an extended period, they have confirmed that they will not stop socking, and so the dataset is quite a large and relatively continuous sample of the trail left by a sockpuppeteer. If you look at the contributions by the IPs, and there are 15+ examples, you can see that within any given 24 hour period they make relatively few edits (and in this editor's case they are sometimes made in parallel with registered sock accounts). Relatively few edits within any given 24 hour period by IP socks is fairly typical in my experience and socks can and often do use both registered accounts and IPs. Sean.hoyland - talk 17:53, 10 October 2012 (UTC)
- I note that you didn't respond to my comment about sockpuppetry. My suggestion about a daily cap of IP use would surely help to reduce this heinous crime. Regards, Bazonka (talk) 16:30, 10 October 2012 (UTC)
- The answer to "why" is beyond the scope of this conversation. I was simply pointing out that there are many prolific IPUsers and I am one of them. I rarely if ever missed anything that was placed on an IP talk page, as the orange bar shows up just like for everyone else, but had I not moved it to the user talk page following the conversation the next day, from a different IP address would have been difficult. I can think of an Admin who never checked or responded to anything on their talk pages - though after that was pointed out they might have become a former Admin. As to a watchlist, it gets so full as to become useless, so I rarely use it (my recollection is that out of 4,000 edits I have edited about 1,000 different pages). So I have the village pump and maybe two or three other pages on it right now. Apteva (talk) 13:33, 10 October 2012 (UTC)
- @Apteva, since you already have two(!) registered accounts, I cannot understand why you'd ever want to edit as an IP. This is a form of sockpuppetry, and since you don't get the advantages of a registered user, e.g. a watchlist, then why would you want to do it? Making sure that your conversations are all readable is good, but will all IPs do this? Probably not. Also, if I wanted to start a conversation with you via an IP talk page then I have no way of knowing whether it will actually reach you, unlike if I were to use User Talk:Apteva. Bazonka (talk) 07:23, 10 October 2012 (UTC)
- As one of the many very prolific IPUsers, I strongly object to any restrictions on using IP editing. What I normally did as a work around was to move discussion to the registered users talk page to consolidate it and so that I could find it again. I also move discussions that were started on one user talk page and answered on another (if I am one of the two parties), so that the discussion is in one place and easier to follow. This is an encyclopedia and by nature there are many edits that can most easily be made by someone who is an expert in that subject, and the annoyance of having to make up a username just to be able to make an edit is absurd. And if that person sees 50 or a 100 things to fix in one day so much for the better. While I frequently got encouragements to register, it was a little pointless two years after I already had... Apteva (talk) 23:11, 9 October 2012 (UTC)
- Er, no. IP editors are likely to be less experienced and less knowledgable of Wikipedia policies than an active registered user. Everyone makes mistakes or does things wrong, especially new editors. If they amend their own errors then fine, but sometimes people need to be nudged in the right direction or shown what to do. It's all part of Wikipedia's collaborative processes. If it is difficult to communicate with a user, then this nudging won't be as effective. Bazonka (talk) 22:26, 9 October 2012 (UTC)
- While there are many legitimate reasons for IP editing (and even some for legitimate socking) the fact remains that IP edits are inevitably seen as being potentially problematic. The real question to ask is: Why can't we make it more obvious to good faith IP editors what the chief benefits of registration are? Especially for dynamic IP assignment, it is virtually impossible to sustain a constructive one to one dialog: the talkpages keep changing. LeadSongDog come howl! 18:45, 10 October 2012 (UTC)
- Speaking only for myself, I think that if it was possible to upload images I would never have even thought of becoming an admin some day, and never would have registered. I have found little to no use for the perks of being able to customize thumbs, etc, etc, and if anything when I am editing I want to try to figure out how someone else is going to see the article. I found the AFC process quite sufficient for creating new articles, and so on. I have seen ornery confirmed IP users whom I would have liked to have seen editing as a registered user, but telling someone else what to do is like herding cats. Apteva (talk) 19:38, 10 October 2012 (UTC)
- Oppose. We need to remember that IPs are not the same as IP editors. One IP address can represent a library a company or even an entire country, and there may be many individual people editing via that IP address. So this wouldn't just be 20 good edits only then you're locked, it would be if anyone else has done 20 IP edits via the same IP you then can't do any. We also need to remember that IP editing is not something to be discouraged, sometimes it should even be encouraged. For example I occasionally edit via IP addresses in insecure locations such as airport terminals, we should be discouraging people from logging in when they are on an unsecure free public WiFi, not pressurising them to login. ϢereSpielChequers 20:54, 10 October 2012 (UTC)
- Former prolific IP editor here. I think this proposal would be unnecessary and countereffective. While it is true that communicating with dynamic IPs can pose challenges, they can easily be overcome if the IP editor chooses to do so. It's easier and quicker with an watchlist and a new messages bar, but an IP can check the page history of pages they recently edited and check if they were reverted or if their former talk page turned blue. And if they need to follow up from a different IP, they can resolve any confusion by saying exactly that. Furthermore, prolific IP editors have likely been welcomed several times. Thus their continuing editing as an IP means WP:REG was read and rejected and throttling their edits is more likely to drive them to leave than to register. Kilopi (talk) 04:29, 11 October 2012 (UTC)
- WP:WHY already exists. If an IP user has been here a long time, and feels that they don't need to register an account, we don't need to even know why, much less try to actively coerce, nudge, cajole, or encourage them to do so. If they wanted to, they'd have done so already. If they don't want to, as long as they are productive and useful members of the Wikipedia community, who cares? --Jayron32 04:40, 11 October 2012 (UTC)
- Oppose Prolific IP editors find ways to deal with the issues mentioned, and some have relatively static IPs which makes it easier. Inviting them and encouraging by identifying the benefits to registering is fine, but ultimately it is the editors choice. Monty845 06:33, 12 October 2012 (UTC)
- Comment So, why would people want to be IP editors? Oh, here's a reason. A few months ago, I was at the Apple Store waiting to talk to one of their many blue t-shirted hipster Geniuses. I had about ten or fifteen minutes to wait. I was using a public computer on a public wifi network in a shop where I could be interrupted at any minute and forget to log off. Why would I want to log in with my admin account? I hopped over to Commons and categorised a few images and generally improved the wiki, then carried on with my day. IP editors aren't all newbs, idiots and crazies: some of them are long-time users, admins and the like who, for some practical reason, don't want to log in. —Tom Morris (talk) 12:05, 12 October 2012 (UTC)
Articles for Improvement
I am proposing the approval of this new process called Articles for Improvement. I have been working on this since June and think it is ready to be presented to all the community. This process is intended and designed to support the development and expansion of articles in the need of urgent care from editors. The process is also planned to avoid those articles to be mistakenly nominated for deletion for the mere purpose that it doesn't meet the guidelines but, with help from the community, will be eventually able to. The whole process is already designed, as can be seen in the link above, including how to nominate an article, how the nominations may evolve, among other information. — ΛΧΣ21™ 03:21, 12 October 2012 (UTC)
- Strong support A great idea! Zac (talk) 03:22, 12 October 2012 (UTC)
- Comment It's not clear to me how this improves on the current situation; we have articles nag-tagged, and users either do or do not improve them. Now we can list them on AFI and have a discussion. A discussion about what, exactly? You seem to be describing out many unloved and somewhat borked articles - articles on which several cleanup and maintenance tags has been placed and still, after a grace period of over one month, are still awaiting such improvement where there's little to be said beyond "please wikify / reference / adduce notability / etc". So. Not convinced. --Tagishsimon (talk) 03:45, 12 October 2012 (UTC)
- This is an alternative to AFD. Many articles end up in AFD because of their actual state. This process is intended for any article. users can gather here and improve any article they wish, altough the process is originally designed to apporach articles in a poor state that can be substantially improved in a matter of days. How this improves the current situation? Tagging an article is not enough, if you never visit the article, you'll never know it needs improvement. AFI's goal is to provide a centered gate were many users can discover and work on articles that do need help and that otherwise they will never look at. — ΛΧΣ21™ 03:59, 12 October 2012 (UTC)
- Well, good luck with that. The argument you level against tagging (and fail to level against the categories which tagged articles fall into, and the work groups which mine those categories) applies equally to the proposed page/method. Only time will tell if the community will adopt and use such a process. I tend to doubt it, mainly for the reason that I think we lack editors, not the organisation of the work of those editors. --04:21, 12 October 2012 (UTC)
- Categories is not the same as this. This gives you the possibility to center discussion with all users interested in improving the article. Tags and categories doesn't do that and i've proven that by myself. If AFD works at improving articles, why not designing a process for articles that are not up for deletion but can be substantially improved? Our goal is to build an encyclopedia, and we lack a work center to join as a community and share ideas and teamwork. I know we have Wikiprojects, but they center on some specific groups of articles; this is a global process. I know we have categories, but this lets you comment and interact with other users on a single venue to reach a common goal: achievement. Tagging is not enough if we don't have an organized entity into which discuss how to make such tag dissapear and produce quality content. — ΛΧΣ21™ 04:29, 12 October 2012 (UTC)
- I kinda like this idea. Social processes on Wikipedia should be used to help nudge articles to a better state. WikiProjects is part of that. Strangely, AfD does that too (albeit with the negative cost of holy shit they want to kill my baby!). WP:TAFI is doing that. Imagine, if every day you went on to Wikipedia, there were editors who were actively looking for people to help improve an article. Sort of a bit like WP:ANI but instead of drama, it'd be filled with good faith efforts to improve the 'pedia. I'm up for that. —Tom Morris (talk) 12:08, 12 October 2012 (UTC)
- Support. Sounds very rationale and needed. We have a lot of articles in bad shape and this can help. Good idea! — Tomíca(T2ME) 18:03, 12 October 2012 (UTC)
- Support seems like it would be a net positive--it can always be refined if there are bumps in the road. Mark Arsten (talk) 18:54, 12 October 2012 (UTC)
- Strong support If the process fails, no harm is done. If the process succeeds there is a considerable amount of benefit. Fruitful discussions from the process could be passed on to WP:TAFI to get even wider improvement. Ryan Vesey 18:58, 12 October 2012 (UTC)
There are a large number of institutional stakeholders that would benefit from having what I would call an institutional account, from which editing could be done. Here's an example. I recently spoke with the public relations offices of the Indiana University Maurer School of Law and the Indiana University Robert H. McKinney School of Law, in order to clear up a few lingering disambiguation links from Indiana University School of Law. In the course of each conversation, I suggested to the outreach person to whom I spoke that their office would benefit by having someone with a presence at Wikipedia to insure the accuracy of information about alumni of these institutions. Indeed, I think every university should have a Wikipedian in residence in their outreach office, someone who can facilitate communications and access to university-held information. However, I don't think it makes sense to ask these institutions (or other institutions like libraries and museums) to rely on individuals who take the username with them when they leave the position.
I think that with proper guidelines to insure transparency, we could make very effective use of accounts attached to institutions, wherein the person holding the office of institutional Wikipedian may change from time to time while the role of the account itself remains the same. Obviously, such accounts would be ineligible for admin status (although I could see giving rollback rights to an institution that has demonstrated wisdom in selecting account holders), and users wishing to maintain a personal account while also having access to an institutional account would need to disclose their distinct roles. I believe that such an amendment to our policies would allow institutions with a useful body of knowledge to develop a greater sense of investment in Wikipedia's success. bd2412 T 04:44, 12 October 2012 (UTC)
- Agree. OTRS exists to validate stuff like this. --Tagishsimon (talk) 04:47, 12 October 2012 (UTC)
- Oppose In sui generis cases, it may be OK per WP:IAR, but I would be opposed to changing the existing policy in any way. It's a very short trip down a very slippery slope to get from having a role account used by University Wikipedians in Residence to other more dubious uses, such as having PR offices from companies using such accounts to enforce "official" versions of pages. I don't see having each person who hold such an office having to maintain their own account at Wikipedia to be a significant barrier to having them contribute. Seriously, if a new person takes the job, they can register their own account. It take 10 seconds. --Jayron32 04:51, 12 October 2012 (UTC)
- Oppose: If there is change at the university in employee status, user pages can be updated. I've talked to people inside stakeholder organisations who have done or might be interested in contributing knowledge and donating materials. This issue has never come up as a need. --LauraHale (talk) 05:01, 12 October 2012 (UTC)
- Oppose Too many problems come with shared accounts: Disputes over control, one controller getting a message and then another controller not knowing about it, issues with socking, etc. Also we would need to carefully consider the implications on our licensing scheme. Is a shared account compatible with our licensing structure? Monty845 05:11, 12 October 2012 (UTC)
- Oppose - I believe that people should contribute Wikipedia on a personal and individual basis, for which shared accounts have no uses outside the scope of the current policy.--Jasper Deng (talk) 05:15, 12 October 2012 (UTC)
- Oppose Personalities and memories are unique to an individual and so should the username that we are interacting with. Make up a username like IBM-23846328 if you wish, but make it only for one person. This is a situation, though that may lend itself to the necessity of using an alternative account for other edits, or changing usernames if the individual leaves. Apteva (talk) 05:57, 12 October 2012 (UTC)
- Comment
Kinda surprised no one seems to have mentioned it, but isn't "individuals who take the username with them when they leave the position." a necessary part of the licence you submit to when editing WP?Whoops, I guess someone did. ♫ Melodia Chaconne ♫ (talk) 06:25, 12 October 2012 (UTC) - Oppose I agree with the sentiments expressed by others - potential headaches, with not enough benefits. Like Apteva, I think the goal can be achieved better by other means. I think eight digits is overkill, a starting user name like Indiana SOL_a, followed by Indiana SOL_b, when a new person is appointed, then Indiana SOL_c etc., will keep the edits identifiable.--SPhilbrick(Talk) 14:19, 12 October 2012 (UTC)
- I definitely like the idea of certain institutions having a larger presence (assuming that they behave themselves as per WP:COI), but I'd rather they have clearly-defined individual accounts, which would make it easier to remove them from a specific role once the individual is no longer employed by the institution. (and for the record, my "certain institutions" statement means that we'd happily welcome a group like a museum or a university, but be FAR more wary of a PR firm). EVula // talk // ☯ // 21:25, 12 October 2012 (UTC)
New user right proposal.
I am very well aware of the potential fact that this has been proposed before and am very well the apprehension the community may have towards this proposal, but here goes. The are highly experienced users out there how can be trusted with additional user rights. The rollback right, the reviewer right, the account creator right, the file mover right, and the autopatrolled right given that the editor has demonstrated the necessary trust to handle such requests. There editors out there who can demonstrate when and when it's not appropriate to edit a protected page. There are editors who tend to have to make a lot of edit requests to get their edits to go through. I am therefore proposing the tboverride, editprotected user rights be added as a separate permission for users to obtain through a standard WP:PERM request. The evaluating admin will judge the editor based on how previous edit requests were handled, and the validity of their own edit requests and how many times it gets approved or not, as well as if the trust in the editor is there or not. The edit protected user bit can come in handy as it allows access to blacklists, fully protected pages, and edit notice pages. Access to these pages can allow a user who regularly maintains a template or usually has to have an admin override the title blacklist to the work themselves. The new user right would be called Protected Page Editor. I would like the community to give some input in this.—cyberpower ChatOnline 14:50, 12 October 2012 (UTC)
New user right proposal - Support
- As proposer.—cyberpower ChatOnline 14:53, 12 October 2012 (UTC)
- I'd prefer a combination of only
editprotected/tboverride
, as I think thateditinterface
should stay only to admins, but It's okay. — ΛΧΣ21™ 16:06, 12 October 2012 (UTC) - I agree, we need to modularize these tools so that more people can help. Kumioko (talk) 16:32, 12 October 2012 (UTC)
- Editinterface is not a big deal. The vast majority of interface pages require little or no skill to modify, such as MediaWiki:Blockedtext.--Jasper Deng (talk) 17:07, 12 October 2012 (UTC)
- And the vast majority of deletions carried out each day are easy uncontroversial speedies that do not require much judgment to carry out, but I don't think you'll find support for making deleting pages a freely grantable right. The editinterface right allows a user to immediately wreak havoc across every single page on this wiki with a single edit. Not even vandalizing the most highly transcluded template can do that. T. Canens (talk) 17:19, 12 October 2012 (UTC)
- Surely we don't need admin-level trustworthiness with this? I don't buy that argument when most editinterface edits are completely minor like spelling corrections. Yes, I would support unbundling speedy deletions. This would not be a freely-grantable right (I would otherwise oppose); it should require the trustworthiness associated with the edit filter, which is unbundled and can also cause havoc if misused.--Jasper Deng (talk) 19:24, 12 October 2012 (UTC)
- The "editinterface" permission does require a high level of trust, to which even some administrators have failed to live up. —David Levy 19:47, 12 October 2012 (UTC)
- Surely we don't need admin-level trustworthiness with this? I don't buy that argument when most editinterface edits are completely minor like spelling corrections. Yes, I would support unbundling speedy deletions. This would not be a freely-grantable right (I would otherwise oppose); it should require the trustworthiness associated with the edit filter, which is unbundled and can also cause havoc if misused.--Jasper Deng (talk) 19:24, 12 October 2012 (UTC)
- And the vast majority of deletions carried out each day are easy uncontroversial speedies that do not require much judgment to carry out, but I don't think you'll find support for making deleting pages a freely grantable right. The editinterface right allows a user to immediately wreak havoc across every single page on this wiki with a single edit. Not even vandalizing the most highly transcluded template can do that. T. Canens (talk) 17:19, 12 October 2012 (UTC)
- With the
editinterface
right removed, this is a good idea. I just recently had to go through a multi-step process for a simple page move that garnered absolutely zero discussion during its RM, when I was sure it wouldn't be a problem in the first place. Seems like this would help remove some clutter from a few places and speed up a few processes if used by experienced editors. —Torchiest talkedits 18:32, 12 October 2012 (UTC) - Good idea, will help trusted non-admins contribute more. Mark Arsten (talk) 18:51, 12 October 2012 (UTC)
- Now support -- WOSlinker (talk) 21:14, 12 October 2012 (UTC)
New user right proposal - Oppose
- Not with editinterface rights. -- WOSlinker (talk) 15:16, 12 October 2012 (UTC)
- Would you support if edit interface wasn't in there?—cyberpower ChatLimited Access 15:31, 12 October 2012 (UTC)
- The edit interface has been removed from the package. I can see where you guys are coming from though.—cyberpower ChatLimited Access 17:40, 12 October 2012 (UTC)
- Per WOSlinker. Editinterface is...a bit too much. I can support something with only editprotected and tboverride, if it is made clear that this right is not to be used to edit pages fully protected due to a content dispute. I think that for those pages the edit requests should still be serviced by admins only. T. Canens (talk) 16:16, 12 October 2012 (UTC)
- "is not to be used to edit pages fully protected due to a content dispute." I guess we don't need to make clear that. If a user with this right uses it for content dispute, then any admin can revoke the right, just as rollback or reviewer. — ΛΧΣ21™ 17:31, 12 October 2012 (UTC)
- The edit interface has been removed from the package. I can see where you guys are coming from though.—cyberpower ChatLimited Access 17:40, 12 October 2012 (UTC)
- Editinterface opens too much opportunity for mischief. I would support a package with editprotected and tboverride only. Anomie⚔ 17:26, 12 October 2012 (UTC)
- The edit interface has been removed from the package. I can see where you guys are coming from though.—cyberpower ChatLimited Access 17:40, 12 October 2012 (UTC)
- Oppose (with or without the "editinterface" permission included). As noted in the past, anyone who can be trusted to not abuse the ability to edit protected pages can be trusted with all of the administrative tools. This type of unbundling would worsen the RfA problem by reinforcing the perception that adminship is a "big deal". —David Levy 17:30, 12 October 2012 (UTC)
- That's clearly nonsense. No wonder things go from bad to worse here. Malleus Fatuorum 17:36, 12 October 2012 (UTC)
- Perhaps an explanation of which comment(s) you dispute — and why — would change my mind. Simply labeling my opinions "nonsense" definitely won't (nor will your pointy opposition to the proposal). —David Levy 17:47, 12 October 2012 (UTC)
- I have no intention of trying to change anyone's mind about anything to do with unbundling user rights, as that would clearly be an exercise in futility. My comment specifically addresses your naive belief that anyone who can be trusted to edit protected pages would be trusted to become an administrator. Malleus Fatuorum 18:01, 12 October 2012 (UTC)
- Then you misinterpreted my comment. My point is that the level of trust required should be the same. RfA is broken because segments of the community have begun imposing unreasonable demands (instead of simply granting adminship to trustworthy editors, as was customary not long ago). This type of unbundling would seemingly validate their approach. —David Levy 18:12, 12 October 2012 (UTC)
- Also see my comments below in the discussion. The RFA process is a nightmare that many don't wish to go through. Kumioko (talk) 18:05, 12 October 2012 (UTC)
- Agreed. And this type of unbundling would firmly cement it as such. —David Levy 18:12, 12 October 2012 (UTC)
- I don't mean to get too far off topic here but, everyone including you it seems agrees the RFA process is crap, but yet, you proceed to try and justify its existence by opposing a process that would make it less painful for users to get the tools to do more to help the pedia? I'm sorry for the rather blunt reply but that makes no damn sense. Kumioko (talk) 18:18, 12 October 2012 (UTC)
- My point is that RfA shouldn't be painful (and wasn't in the past). The process itself isn't inherently "crap"; certain segments of the community have lost sight of how it's supposed to operate.
Workarounds such as this one shouldn't be necessary. Editors trustworthy enough to be granted a hypothetical "protected page editor" permission should simply be made administrators. This proposal's implementation would amount to a formal determination to the contrary — a declaration that the onerous demands making RfA "a nightmare" are justified and should continue. —David Levy 18:44, 12 October 2012 (UTC)- Actually, on the contrary, this should make RfA easier by making it less a step-up in permissions.--Jasper Deng (talk) 19:46, 12 October 2012 (UTC)
- In other words, it would promote a culture in which trustworthy editors are expected to "ascend the ranks", gradually taking on additional permissions as prerequisites to adminship. That isn't what I call making things "easier". —David Levy 20:26, 12 October 2012 (UTC)
- Actually, on the contrary, this should make RfA easier by making it less a step-up in permissions.--Jasper Deng (talk) 19:46, 12 October 2012 (UTC)
- My point is that RfA shouldn't be painful (and wasn't in the past). The process itself isn't inherently "crap"; certain segments of the community have lost sight of how it's supposed to operate.
- I don't mean to get too far off topic here but, everyone including you it seems agrees the RFA process is crap, but yet, you proceed to try and justify its existence by opposing a process that would make it less painful for users to get the tools to do more to help the pedia? I'm sorry for the rather blunt reply but that makes no damn sense. Kumioko (talk) 18:18, 12 October 2012 (UTC)
- Agreed. And this type of unbundling would firmly cement it as such. —David Levy 18:12, 12 October 2012 (UTC)
- I have no intention of trying to change anyone's mind about anything to do with unbundling user rights, as that would clearly be an exercise in futility. My comment specifically addresses your naive belief that anyone who can be trusted to edit protected pages would be trusted to become an administrator. Malleus Fatuorum 18:01, 12 October 2012 (UTC)
- Perhaps an explanation of which comment(s) you dispute — and why — would change my mind. Simply labeling my opinions "nonsense" definitely won't (nor will your pointy opposition to the proposal). —David Levy 17:47, 12 October 2012 (UTC)
- That's clearly nonsense. No wonder things go from bad to worse here. Malleus Fatuorum 17:36, 12 October 2012 (UTC)
- Oppose yet another attempt to erode the priestly status of administrators by unbundling any user rights. In fact I'd go so far as to say that only administrators should be trusted to edit Wikipedia at all. Malleus Fatuorum 17:39, 12 October 2012 (UTC)
- it is not an attempt to erode anything. It is an attempt to assist in the technical aspect of Wikipedia. PS, the comment at RfA you made towards me was unacceptable and appreciate you not doing that again.—cyberpower ChatLimited Access 17:44, 12 October 2012 (UTC)
- I have no idea what you're talking about, or why you would feel it appropriate to raise your objection here. Malleus Fatuorum 18:01, 12 October 2012 (UTC)
- I'll discuss on your talk because it'd be inappropriate here as you mentioned.—cyberpower ChatOffline 18:11, 12 October 2012 (UTC)
- I have no idea what you're talking about, or why you would feel it appropriate to raise your objection here. Malleus Fatuorum 18:01, 12 October 2012 (UTC)
- it is not an attempt to erode anything. It is an attempt to assist in the technical aspect of Wikipedia. PS, the comment at RfA you made towards me was unacceptable and appreciate you not doing that again.—cyberpower ChatLimited Access 17:44, 12 October 2012 (UTC)
- Sorry, but anybody trusted to edit the interface should be trusted to pass RfA first. PeterSymonds (talk) 17:46, 12 October 2012 (UTC)
- The edit interface has been removed from the package.—cyberpower ChatLimited Access 17:48, 12 October 2012 (UTC)
- Oppose Let's wait for pending changes. The use of PC will mean that the general level of article protection can drop. Instead of full protection, we will be able to have full-protection with PC, which will speed up approvals of things which would otherwise require {{edit protected}} requests. Same with semi-protection. Let's hold on and wait to see how PC works out. —Tom Morris (talk) 18:15, 12 October 2012 (UTC)
- PC level 2 (full protection to most) has been outlawed via RfC. What about title blacklists?—cyberpower ChatOffline 18:20, 12 October 2012 (UTC)
- Oppose There are far too many people who completely don't understand what is necessary to edit protected pages. While this would hopefully only be given to those who understood the purpose, I think its use is minimal. Ryan Vesey 18:40, 12 October 2012 (UTC)
New user right proposal - Discussion
- I don't see the issue with editinterface, maybe an explanation may help me understand, but i'm towards supporting this idea for editprotected. Also, what does tboverride does? — ΛΧΣ21™ 15:39, 12 October 2012 (UTC)
- It overrides the title blacklist and let's you create pages that are on the blacklist. My bot could use that feature when it maintains the bad image task.—cyberpower ChatLimited Access 15:42, 12 October 2012 (UTC)
- Oh okay. And editinterface? (Excuse me if I'm asking too much) — ΛΧΣ21™ 15:46, 12 October 2012 (UTC)
- Allows editors to edit interface pages such as the watchlist details or the Twinkle gadget.—cyberpower ChatLimited Access 15:49, 12 October 2012 (UTC)
- Oh okay. And editinterface? (Excuse me if I'm asking too much) — ΛΧΣ21™ 15:46, 12 October 2012 (UTC)
- It overrides the title blacklist and let's you create pages that are on the blacklist. My bot could use that feature when it maintains the bad image task.—cyberpower ChatLimited Access 15:42, 12 October 2012 (UTC)
- i have removed the editinterface right from the package.—cyberpower ChatLimited Access 17:45, 12 October 2012 (UTC)
- Thank you Cyber for removing that so that this idea has a chance at success. For those that think that the world will come to an end if Editinterface is allowed though I submit to you that suggestion is mere hogwash. This isn't going to be granted to every Joe, dick and Harry but to users who have displayed good judgement and the necessary knowledge required. I would also add that to say that an editor who should have this access should be able to make it through RFA is also nonsense. Its not just about making it through RFA, the RFA has such a bad reputation that many editors refuse to even go through it. Some who do, sigma recently and even myself have a history of good judgement and the knowledge necessary to get this access but may not be suitable or desire to be a full blown administrator. Personally I think that the "Admin" role be scrapped and users just apply and be granted to the tools they need and use and have shown a pattern of trust and knowledge about rather than a whole toolbox full of stuff so they can edit protected pages and never use anything else. With that said and as much as I support this I doun't this will pass. The admins are in power and they want to keep it that way so they will find a way and justification to scuttle it just as they have done in the past. Kumioko (talk) 18:00, 12 October 2012 (UTC)
- It's true that a few admins will feel that the power if this goes through but there admins out there who feel this to be productive change to Wikipedia to allow non admins to assist in fully protected areas. I am willing to WP:AGF that they will truly choose what is best for the 'pedia. I do understand their concerns and even asked myself why I added that right to the package. I believe that only admins should edit pages that have site wide changes.—cyberpower ChatOffline 18:08, 12 October 2012 (UTC)
- Sorry I still don't agree and here's why. If I can be trusted with editing protected templates like Template:WikiProject Biography thats on a couple million articles then the other should also be no big deal. Let's remember that a change made to one of these is going to be noticed fast and would probably be reverted in seconds followed swiftly by a revocation of that users right to edit protected stuff. Will it happen, sure, but no more often than one of the Admins doing it and another reverting it and slapping them with a trout. Kumioko (talk) 18:14, 12 October 2012 (UTC)
- And there are admins (myself included) who are disgusted by the absurd hoops through which current candidates are expected to jump. Proposals such as this one attempt to address a very real problem, but they do so by sidestepping it (and unintentionally exacerbating it) instead of repairing it.
- If someone can be trusted to not abuse the ability to edit protected pages, he/she can be trusted to not abuse the other administrative tools. That he/she might not need all of the tools is immaterial; he/she can be trusted to simply not use unneeded tools.
- The solution to the RfA problem is to return to the longstanding standards that served Wikipedia well, not to validate the onerous demands that have given the process "such a bad reputation". —David Levy 18:44, 12 October 2012 (UTC)
- For the most part I agree with you however having seen no less than a dozen attempts to correct and revamp the RFA process and even participating in many of the discsussions myself, all to no avail, I realize that to continue to do is unrealistical in coming to any kind of consensus. I said as much so on Jimbo's page earlier this week. This leads me to the very realistic and inevitable solution to not use the RFA process. If this causes the RFA process to be circumvented and abandoned because its too painful and easier to get the tools we need without going through it then that's the cost of doing business. Using my RFA as an example, it was a crushing disappointment and many editors said I couldn't be trusted which I still feel is complete BS. I have never in my 6+ years and 400, 000 edits vandalized a page or intentionally did harm (other than a few snide comments from time to time). So to tell me I can't be trusted to wield the mop because I got pissed off and came back (because I believe in the project) is ridiculous and amounts to spitting in my face and many, many, many other productive and reliable editors have had the same fate. Many stopped editing and some just said the hell with it and became the vandals and untrustworthy sorts they were blamed for being. Many more simply refuse to go through the RFA process. Now we are left with a continually dwindling RFA process that every year promotes half the number of admins the year before. In 2007 we promoted around 400 admins. This year we are look at roughly 20-25 at most. Next year if the pace continues it will be 10-15. We simply cannot hope to survive by keeping things as status quo. Wikipedia is on the verge of an editorial and administrative bankruptcy if we don't change things. This proposal is a step in the right direction with or without the includsion of Editinterface. Kumioko (talk) 18:58, 12 October 2012 (UTC)
- I view it as a step in the wrong direction. Unbundling the ability to edit protected pages would provide yet another excuse to oppose trustworthy candidates at RfA. ("You can just become a protected page editor instead.")
- You've suggested that the RfA process be abandoned (and presumably replaced with separate requests for each of the tools). I strongly disagree that this would solve the problem. It would force editors who need multiple tools to go through multiple processes, with no reason to assume that they'd be any less painful than RfA currently is. (In response to a recent proposal, a Wikimedia Foundation representative stated that certain tools must be granted via "exactly the same process" employed at RfA, "using the same criteria" and "operating on the same page".)
- Instead of a single process through which trustworthy editors are given the tools (i.e. the manner in which RfA is intended to operate), they'd be forced to justify the need for each tool individually, likely with a level of stress similar to that of RfA.
- You noted that attempts at RfA reform have been made. I can't say that I'm familiar with all of them, but those that I've encountered have entailed dramatic alterations to the process — essentially replacing RfA with something else entirely. This amounts to throwing out the baby with the bathwater. The underlying RfA process is sound and needn't be overhauled. The problems stem from the attitudes exhibited by certain segments of the community, which no amount of process tinkering will change.
- I don't believe that restoring RfA's former atmosphere will be easy, but I believe that it's the only viable course of action (and one to which proposals such as this one run counter). —David Levy 19:39, 12 October 2012 (UTC)
- Well as I mentioned above this proposal will likely be squashed like so many in the past and the RFA process will continue to degrade. I'm sorry I don't have your optimism that the RFA process can be turned around at this point. Too much stigma has been ingrained into it and too much time has been wasted talking about it with no actionable result. IMO the RFA process either needs to be scrapped completely for something new or someone in the foundation needs to step up and take charge of changing it. We as editors have failed to get a concensus to change it because we are too busy bickering about how the changes will be the end. Unfortunately we have all failed the system and now drastic steps in the form of this proposal or some other are now needed if we hope for it to survive at all. We simply cannot afford to continue promiting such small numbers of admins as more and more content gets protected (IMO largely unncessarily) and more and more things require admin intervention. I'm going to stop debating it at this point because I can see that nothing I say is going to change your mind and few editors have any respect for what I say or think anymore anyway, largely due to bad admin decisions against me in the past. So you'll excuse me if my attitude towards the general admin culture (no disrespect intended towards you or any number of other good admins I have encountered) isn't very high. Kumioko (talk) 19:50, 12 October 2012 (UTC)
- No offense taken. And to be clear, I respect your views and share many of your concerns.
- I wouldn't describe myself as "optimistic" that RfA's original atmosphere can be restored. But I remain hopeful, mainly because I believe that the alternatives suggested thus far would make matters worse.
- At this point, WMF intervention might not be a bad idea. I'm generally one of the last people to advocate such a thing, but when the community fails to come up with a viable solution on its own, something must be done. —David Levy 20:19, 12 October 2012 (UTC)
- Well as I mentioned above this proposal will likely be squashed like so many in the past and the RFA process will continue to degrade. I'm sorry I don't have your optimism that the RFA process can be turned around at this point. Too much stigma has been ingrained into it and too much time has been wasted talking about it with no actionable result. IMO the RFA process either needs to be scrapped completely for something new or someone in the foundation needs to step up and take charge of changing it. We as editors have failed to get a concensus to change it because we are too busy bickering about how the changes will be the end. Unfortunately we have all failed the system and now drastic steps in the form of this proposal or some other are now needed if we hope for it to survive at all. We simply cannot afford to continue promiting such small numbers of admins as more and more content gets protected (IMO largely unncessarily) and more and more things require admin intervention. I'm going to stop debating it at this point because I can see that nothing I say is going to change your mind and few editors have any respect for what I say or think anymore anyway, largely due to bad admin decisions against me in the past. So you'll excuse me if my attitude towards the general admin culture (no disrespect intended towards you or any number of other good admins I have encountered) isn't very high. Kumioko (talk) 19:50, 12 October 2012 (UTC)
- For the most part I agree with you however having seen no less than a dozen attempts to correct and revamp the RFA process and even participating in many of the discsussions myself, all to no avail, I realize that to continue to do is unrealistical in coming to any kind of consensus. I said as much so on Jimbo's page earlier this week. This leads me to the very realistic and inevitable solution to not use the RFA process. If this causes the RFA process to be circumvented and abandoned because its too painful and easier to get the tools we need without going through it then that's the cost of doing business. Using my RFA as an example, it was a crushing disappointment and many editors said I couldn't be trusted which I still feel is complete BS. I have never in my 6+ years and 400, 000 edits vandalized a page or intentionally did harm (other than a few snide comments from time to time). So to tell me I can't be trusted to wield the mop because I got pissed off and came back (because I believe in the project) is ridiculous and amounts to spitting in my face and many, many, many other productive and reliable editors have had the same fate. Many stopped editing and some just said the hell with it and became the vandals and untrustworthy sorts they were blamed for being. Many more simply refuse to go through the RFA process. Now we are left with a continually dwindling RFA process that every year promotes half the number of admins the year before. In 2007 we promoted around 400 admins. This year we are look at roughly 20-25 at most. Next year if the pace continues it will be 10-15. We simply cannot hope to survive by keeping things as status quo. Wikipedia is on the verge of an editorial and administrative bankruptcy if we don't change things. This proposal is a step in the right direction with or without the includsion of Editinterface. Kumioko (talk) 18:58, 12 October 2012 (UTC)
- It's true that a few admins will feel that the power if this goes through but there admins out there who feel this to be productive change to Wikipedia to allow non admins to assist in fully protected areas. I am willing to WP:AGF that they will truly choose what is best for the 'pedia. I do understand their concerns and even asked myself why I added that right to the package. I believe that only admins should edit pages that have site wide changes.—cyberpower ChatOffline 18:08, 12 October 2012 (UTC)
An admin of the day
I am proposing the initiation of a project that identifies one administrator each day to be the admin of the day. It would be very similar to the Wikipedian of the Day, but more focused and would be a reward given to an admin for a specific admin task he or she performed. The project would list openings ten days in advance, and users could nominate an admin for any of those days, although they would only be allowed to nominate an admin once per admin task being recognized (as in, you would only be allowed to nominate an admin one time in recognition of a specific action, but you could nominate him for all ten days for ten different reasons). Self-noms would be prohibited. The admin of the day would be the first admin to receive 5 supports (the admin could not support them-self) for that specific day. Likewise, 5 opposes would cause the nomination to be removed. AutomaticStrikeout 21:34, 12 October 2012 (UTC)