→Proposal: rp |
→Proposal: c |
||
Line 609: | Line 609: | ||
*** How might there be "reader confusion" from seeing references, typically in their own section, in the same font size as the rest of the text? [[User:Gimmetoo|Gimmetoo]] ([[User talk:Gimmetoo|talk]]) 18:32, 1 December 2010 (UTC) |
*** How might there be "reader confusion" from seeing references, typically in their own section, in the same font size as the rest of the text? [[User:Gimmetoo|Gimmetoo]] ([[User talk:Gimmetoo|talk]]) 18:32, 1 December 2010 (UTC) |
||
**** Just a stylistic point; it gives additional weight to the article text (in my mind we could happily even just collapse the references) --'''[[user:tmorton166|Errant]]'''{{small| [tmorton166] {{sup|([[User_talk:tmorton166|chat!]])}}}} 18:35, 1 December 2010 (UTC) |
**** Just a stylistic point; it gives additional weight to the article text (in my mind we could happily even just collapse the references) --'''[[user:tmorton166|Errant]]'''{{small| [tmorton166] {{sup|([[User_talk:tmorton166|chat!]])}}}} 18:35, 1 December 2010 (UTC) |
||
*** @Errant: I take the opposite viewpoint: references are there for readers first, so that they can use them to dig deeper into the material if they want to use the encyclopedia as a starting point. Disputes between Wikipedians belong on the talk page. I agree with Gimmetoo that the change in font size is a relic from print, but it seems to have become endemic here. — Carl <small>([[User:CBM|CBM]] · [[User talk:CBM|talk]])</small> 18:39, 1 December 2010 (UTC) |
|||
== Gadget Proposal: NoSmallFonts == |
== Gadget Proposal: NoSmallFonts == |
Revision as of 18:39, 1 December 2010
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.
New Userrights Proposal
I have noticed that there have been several RFA's recently where the candidate needed a particular area of the Administrator tools, but not all of them. Many users find some of the tools useful, but not all of them. There are three major areas of administrator work. I know there have been several debates surrounding splitting up the administrator rights into sections. I propose that several userrights be added. These rights would be granted to trusted users by administrators and/or bureaucrats at Wikipedia:Requests for permissions and revoked by Bureaucrats These rights would not replace the standard sysops right. They are intended to help editors who do work in one particular area where a certain tool normally reserved for sysops would be useful, but don't want the full sysops right. It would also decrease the "authority gap" between administrators and non-administrators. Here are the rights I propose: Thoughts? --Alpha Quadrant talk 19:04, 27 October 2010 (UTC)
- As a general note we'd be fools to think that block, deletion rights, and ability to give user rights to other people would not be the most controversial rights in all of this. If this is the hang up for you, just mention you'd support this assuming right X is excluded from the bunch. "File Uploader" would still be an amazing right to have for file uploaders without deletion rights, and "Patroller" would allow vandal fighters to be all that much more efficient at it, even without the ability to block them. If the rights are modular rather than bundled up, those who want to (for example) do cleanup in files or templates wouldn't have to have to have their enthusiasm crushed because of opposes such as "Well I like your file work, but I don't think you have enough vandal fighting experience to get the tools" or similar and told "come back 6 months" or some other arbitrary delay. Headbomb {talk / contribs / physics / books} 20:06, 27 October 2010 (UTC)
My proposed tools, by no means be given out like rollback. There would be a strict process of evaluating whether or not a user can be trusted with a specific tool. It is not meant to replace RFA and likely never will. Giving out module tools are only meant to make trusted editors who don't have enough work in specific areas. The community normally wouldn't be able to safely agree to giving the editor the whole administrator bundle. This proposal would potentially eliminate the accused "caste system" that many new users assume exists. It could potentially make RFA run smother, by having a admin hopeful apply for a module first, then later applying for adminship it would make it easier for the community to evaluate the editor. Naturally editors will be prohibited from gaining access from all three modules without a proper RFA. There willl still be several tools limited to the administrator group: Editfilters, editing interface, and other's .js and .css will remain restricted to administrators. The tools would be easier to remove than a full administrator because any bureaucrat could remove them if they are ever abused. The standards would be somewhat lower than a RFA because only part of the tools would be given. Hersfold pointed out one issue in the proposal. If the module idea succeeds issues like this would eventually come up: if a editor with the "Purge" module comes across a persistent attack page vandal they would be unable to block them. The editor could file a report to AIV so that a full administrator or a "Patroller" blocks the vandal. This would be no different than what a rollbacker does when they find a page that comes across persistent vandalism on a page, they file a request at RFPP.
Proposed User rights
|
---|
*The first three proposed rights would be granted by either a Administrator or Bureaucrat and revoked by a Bureaucrat if abused. The "Flooder" and "File Uploader" would be granted and revoked by Administrators at Requests for permissions. See relevant pages and below for details.
Relevant pages: Patroller - Antivandalism fighters who patrol recent changes and revert vandalism. Would be assigned to users who are trusted vandal fighters who have a good record of appropriately warning and reporting vandals.
Protector - Users who perform various cleanup tasks such as moving pages and improving articles. Would be assigned to editors who do good work maintenance and content improvement areas.
Purger - Would be assigned to users who are trusted in New Page patrol work as well as good work in AFD and properly using CSD.
Flooder - AWB users and users who make extremely high numbers of edits
File Uploader - Useful for users who transfer files from Wikipedia to Commons
Possible Process
In the event of abuse a Bureaucrat will remove the tools. Example: If Patroller inappropriately block a user it would result in removal of the tools --Alpha Quadrant talk 19:37, 27 October 2010 (UTC) |
Discussion
- Resounding FUCK YES. This way one wouldn't have to go through the horrors of RfAs to be able to do completely uncontroversial janitorial work. Headbomb {talk / contribs / physics / books} 19:07, 27 October 2010 (UTC)
- The exact details would need to be worked out in details later, of course, but I'm talking about the general idea. Like "File Uploader" would be pretty useful to have even without the file deletion/undeleting rights. Headbomb {talk / contribs / physics / books} 19:19, 27 October 2010 (UTC)
- Strong Support per Headbomb and the proposer. The sock that should not be (talk) 19:12, 27 October 2010 (UTC)
- Support. However, the 'purger' group won't be made, I think. per MGodwin, the WMF will not allow viewdeleted to be given without community input. → ROUX ₪ 19:14, 27 October 2010 (UTC)
- (edit conflict) I have never been a big fan of splitting the core rights (block, delete, protect). If one is trusted to block, one should be trusted to delete and protect, and so on. Use of these admin tools should be sought at RfA as at present. Viewing deleted material is a definite no per an announcement by Mike Godwin in 2008. There are some less damaging rights that I think could be given to a lower-level group, but this isn't the proposal here. PeterSymonds (talk) 19:16, 27 October 2010 (UTC)
- I like the idea but have issues with the details. Specificaly the block button of patroler & the delete button of purger. I don't support these being handed out without community input. The key problem with the block button, there's no technical way to separate the ability to use it for simple vandalism blocks and the highly difficult area of blocks of established users for more controversial reasons.--Cube lurker (talk) 19:21, 27 October 2010 (UTC)
- Well it could always be configured so that the "patroller" can only block IP's and non-autoconfirmed users. The controversial blocks, or rather, the full ability of the block button, would be in a normal administrator's jurisdiction. The sock that should not be (talk) 19:23, 27 October 2010 (UTC)
- There could also be a special request for permissions where the community decides over the course of, say three days, over whether they think the editor can be trusted with the flag. That would also allow the "purger" right to be permitted. Naturally it would not be as difficult as a RFA. --Alpha Quadrant talk 19:27, 27 October 2010 (UTC)
- Neutral (having seen more information, this is where I will stay).
Abstain for now because I want to see more details.Previous opinion was: Oppose this proposal as currently stated. Not just because of the user-rights, but because of the fact that it's handed out by admins with no community approval. You say that they're not a replacement for admin userrights, but "block" and "delete" are probably the two most controversial tools, and I would say that if you give one person both of those things, they're effectively an admin, and I am uncomfortable with the idea that an admin can just make a bunch of new almost-admins with no community input. At most there should be an RfA-like process for granting these userrights. I may change my opinion if this is rewritten to include an RfA-like process. I should add that it's the groups beginning with "P" that are the most worrisome. "Flooder" may be a good idea, as it exists already on Simple and some other wikis, and though I think we don't have as much need for it here, that doesn't mean it would be bad. —Soap— 19:29, 27 October 2010 (UTC)
- I at first thought this was a way to help get anti-vandal patrollers with little content creation experience an easier path to adminship, but now I see this is really for specialist admins, since an anti-vandal candidate really needs all of the tools (or at least the three "P" packages) and not just some of them. As such, I don't have a firm enough opinion to be able to comfortably put myself in the "support" or "oppose" column and will remain neutral. —Soap— 12:46, 28 October 2010 (UTC)
- Support—this reduces bureaucracy and increases efficiency. Seems a good plan to me. ╟─TreasuryTag►Africa, Asia and the UN─╢ 19:34, 27 October 2010 (UTC)
- Nope not this way at least. Giving the block-button to non-admins? Ah dear... there are already admins who are trigger-happy. Choyoołʼįįhí:Seb az86556 > haneʼ 19:35, 27 October 2010 (UTC)
- And what exactly would make this different from electing an admin, praytell? Choyoołʼįįhí:Seb az86556 > haneʼ 19:39, 27 October 2010 (UTC)
- Because it's only certain tools, not the full admin bit. The sock that should not be (talk) 19:42, 27 October 2010 (UTC)
- Not all editors want/need all of the tools. However some users would find particular rights useful for their work. Patrollers would find the block tool useful when they are fighting vandalism. Rather than running complicate RFA process for one tool they would find useful and the rest of them not so useful, they could just request the tool they needed. If they required all of the tools they could run a RFA. --Alpha Quadrant talk 19:46, 27 October 2010 (UTC)
- Look at the list. It's "an admin who can't delete" or the like; anyways, I meant... "socially"... the "dynamic"...? If I hear somebody gets the block-hammer, I don't care what the flag is called. Same scrutiny, same discussions, same reasons. Choyoołʼįįhí:Seb az86556 > haneʼ 19:45, 27 October 2010 (UTC)
- Why not seven days? Or fourteen? If anything, I'd expect these RfT's to be less attractive to potential voters than full RfA's, and the votes would come in more slowly. Not trying to harass, but just to get at the ideas behind this proposal. —Soap— 19:40, 27 October 2010 (UTC)
- Good point Soap, I'll increase the suggested number of days. The number was just a suggestion. --Alpha Quadrant talk 19:47, 27 October 2010 (UTC)
- Oppose. I agree with PeterSymonds. Someone who can be trusted with one administrative tool can be trusted with all of them (including those that he/she doesn't intend to use). If adminship requests are being rejected on the basis that candidates will make frequent use of only some administrative tools, we should address this flaw in the RfA process. —David Levy 21:49, 27 October 2010 (UTC)
- That's just not true. If that were the case, people would not be rejected for RfA when they want vandal fighting tools, but are opposed for not having experienced in deletion, or content work, or whatever. Modular rights is the only way to fix RfA, because as it stands, people are denying RfA candidates the tools they request, because they wouldn't trust them with tools they wouldn't use anyway . Headbomb {talk / contribs / physics / books} 22:05, 27 October 2010 (UTC)
- I referred to a hypothetical scenario in which an adminship request is rejected because the candidate intends to use only some of the administrative tools. Actually distrusting someone with certain tools (irrespective of whether he/she intends to use them) is an entirely different matter.
- The various aspects of adminship are heavily intertwined and difficult to isolate, so I believe that a reasonable understanding of Wikipedia as a whole is essential for someone possessing most of the individual tools in question. If a prospective administrator wishes to concentrate primarily or solely on one area, that's fine, and I don't regard that as a valid reason to oppose his/her adminship request. But if someone knows so little about a key process that the community actually distrusts him/her with relevant tools, that's an indication that he/she should gain a better understanding of the site as a whole. —David Levy 22:47, 27 October 2010 (UTC)
- And I'm talking about actual cases. The problem isn't the candidates are grossly unfamiliar with Wikipedia, the problem is that the candidates have preferences, and just don't care about some of these tools. Vandal fighters are denied tools because they aren't experienced in deletion debates. Template editors are denied them because they don't have content work. AfD/MfD/etc...-types of admins are opposed because of lack of vandal fighting. Were RfA sane, or the tools unbundled, this would not be a problem. If Jimmy Longpants is an expert template-writer, with no history of edit wars, etc... what does it matter if doesn't have lots of experience with CSD criteria or vandal fighting? Maybe you wouldn't oppose him for that, but tons of people would, and that makes the difference between Wikipedia seeing it's more clueful editors being empowered, rather than disfranchised. Headbomb {talk / contribs / physics / books} 23:23, 27 October 2010 (UTC)
- Then the solution is to make RfA "sane," not to overcomplicate something intended to be "no big deal."
- Below, Mr.Z-man points out some significant flaws in the proposed setup. —David Levy 01:55, 28 October 2010 (UTC)
- I have revised and crossed off the rights that caused concern. The undelete would require WMF approval before being set up. This proposal is about whether or not creating such a right is supported. None of the rights would be given out lightly. The reason Bureaucrats should only be able to take away one of the userights is so that administrators would not be able abuse their position in a dispute. If the tools were given out by community consensus they shouldn't be revoked without community consensus, except in emergency cases. "Removal Administrator discretion" would not work. Instead of having to wheel war all the admin would have to do would be to remove the editor's rights because they were a full administrator and the other editor wasn't, therefore the opinion of the full administrator is correct. This would more than likely occur eventually, hence the issue. Bureaucrats are trusted to remain civil and do a pretty good job gauging abuse and violations of policy, whereas administrators are more likely to lose their cool and make those kind of threats. For example, there are quite a few reports of block treats at AN/I. --Alpha Quadrant talk 03:04, 28 October 2010 (UTC)
- Please see Mr.Z-man's message from 28 October at 01:23 (UTC) for some concerns that haven't been addressed. —David Levy 03:49, 28 October 2010 (UTC)
- I have revised and crossed off the rights that caused concern. The undelete would require WMF approval before being set up. This proposal is about whether or not creating such a right is supported. None of the rights would be given out lightly. The reason Bureaucrats should only be able to take away one of the userights is so that administrators would not be able abuse their position in a dispute. If the tools were given out by community consensus they shouldn't be revoked without community consensus, except in emergency cases. "Removal Administrator discretion" would not work. Instead of having to wheel war all the admin would have to do would be to remove the editor's rights because they were a full administrator and the other editor wasn't, therefore the opinion of the full administrator is correct. This would more than likely occur eventually, hence the issue. Bureaucrats are trusted to remain civil and do a pretty good job gauging abuse and violations of policy, whereas administrators are more likely to lose their cool and make those kind of threats. For example, there are quite a few reports of block treats at AN/I. --Alpha Quadrant talk 03:04, 28 October 2010 (UTC)
- And I'm talking about actual cases. The problem isn't the candidates are grossly unfamiliar with Wikipedia, the problem is that the candidates have preferences, and just don't care about some of these tools. Vandal fighters are denied tools because they aren't experienced in deletion debates. Template editors are denied them because they don't have content work. AfD/MfD/etc...-types of admins are opposed because of lack of vandal fighting. Were RfA sane, or the tools unbundled, this would not be a problem. If Jimmy Longpants is an expert template-writer, with no history of edit wars, etc... what does it matter if doesn't have lots of experience with CSD criteria or vandal fighting? Maybe you wouldn't oppose him for that, but tons of people would, and that makes the difference between Wikipedia seeing it's more clueful editors being empowered, rather than disfranchised. Headbomb {talk / contribs / physics / books} 23:23, 27 October 2010 (UTC)
- That's just not true. If that were the case, people would not be rejected for RfA when they want vandal fighting tools, but are opposed for not having experienced in deletion, or content work, or whatever. Modular rights is the only way to fix RfA, because as it stands, people are denying RfA candidates the tools they request, because they wouldn't trust them with tools they wouldn't use anyway . Headbomb {talk / contribs / physics / books} 22:05, 27 October 2010 (UTC)
- A poll on the village pump isn't really the best format for a complex proposal like this (and it will almost certainly need a larger discussion before any implementation, but my opinions:
- Weak support patroller - There are some unnecessary rights here - ipblockexempt, proxyunbannable (which does nothing on Wikimedia sites, since we don't use MediaWiki's proxy blocker), stablesettings (this is closer to protecting than blocking), versiondetail (what?), +/-rollback and +/-IP block exempt (this is an administrative task, not a antivandal one).
- Oppose protector - There's not a high enough volume of admin work regarding protection to justify this. editinterface, edituserjs, and editusercss should be restricted as much as possible due to the potential damage if abused. Ideally, not even all admins should have it.
- Oppose Purger - Won't happen unless undelete/deletedtext are removed, which would then lead to a situation where users couldn't undo their own actions
- Oppose Flooder -
This is essentially bot, without a few rights that don't really matter because most users already have them or won't need them. This basically creates a way to bypass the bot approval process.
- I re-read the list and saw the proposal was to give markbotedits and not bot. In this case, its just pointless. The only rate limits that affect established users are 8 pagemoves per minute, 200 emails per day, the account creation throttle, and 100 rollbacks per minute (for rollbackers); normal edits aren't limited at all. These aren't something that people are going to run into with AWB.
- Weak support file uploader - I would support this as "file mover" if delete/undelete are removed. upload_by_url is disabled here.
- Also, if admins can add the rights, they should be able to remove them. This will help to make these less of a big deal à la rollback. Mr.Z-man 22:30, 27 October 2010 (UTC)
- Something needs to be done about this according to this and this it has been going on since at least 2005. Something needs to happen. Splitting the core administrator components would be extremely useful. There are four components to the Sysops group, Deletion/Undeletion, Protection/Page Moves, Block/Unblock, and reverting aka Rollback (which, after a long debate was finally given out to non-admins). Not all users want to do all admin tasks. The modules would not be given to users without support from the community. It would actually make it easier for editors to do tasks. There are basically three aspects of the administrator's job. All editors fall into one of the categories. They either primarily fight vandalism (patroller would particularly help them), spend much of their time improving article content (protector would help them with their article work), and new page patrollers/article taggers, users who CSD articles and nominate articles for deletion as well as tag article problems (Purger would help them delete attack pages as well as other inappropriate content. Undelete would be useful in allowing them to undo their action when they make mistakes). This is why I think addingg userights would help. --Alpha Quadrant talk 23:55, 27 October 2010 (UTC)
- The simpler solution is to make it easier to lose adminship. One potential risk with splitting it up is that it might make it harder to get full admin rights. I can imaging RFA votes like "Oppose - candidate hasn't demonstrated need for blocking, should only get protector and purger." And of course, there's the golden hammer issue; in many cases there are multiple ways to deal with an administrative issue. Someone without full admin rights may use a suboptimal solution because that's all they can do. Mr.Z-man 01:23, 28 October 2010 (UTC)
- Something needs to be done about this according to this and this it has been going on since at least 2005. Something needs to happen. Splitting the core administrator components would be extremely useful. There are four components to the Sysops group, Deletion/Undeletion, Protection/Page Moves, Block/Unblock, and reverting aka Rollback (which, after a long debate was finally given out to non-admins). Not all users want to do all admin tasks. The modules would not be given to users without support from the community. It would actually make it easier for editors to do tasks. There are basically three aspects of the administrator's job. All editors fall into one of the categories. They either primarily fight vandalism (patroller would particularly help them), spend much of their time improving article content (protector would help them with their article work), and new page patrollers/article taggers, users who CSD articles and nominate articles for deletion as well as tag article problems (Purger would help them delete attack pages as well as other inappropriate content. Undelete would be useful in allowing them to undo their action when they make mistakes). This is why I think addingg userights would help. --Alpha Quadrant talk 23:55, 27 October 2010 (UTC)
- Support patroller - I can see a definite use for that, but quite frankly, I'm not sure about the other stuff. I'm also not sure; do these people really need to be able to assign userrights? There are 1,700 admins; surely they can be responsible for that. Ajraddatz (Talk) 22:51, 27 October 2010 (UTC)
- Strong support: My main areas of work (when it comes to maintenance) is CSDs, particularly F8's. I have "tagged" hundreds of files and pages for CSD, only to wait for another admin to click the delete button hundreds of times again. I failed the RFA twice as simply being "not ready" in all admin areas; pretty much lost my interest in going for the third. I find special deletion rights very useful to editors who offer to perform specific admin tasks. Rehman(+) 00:20, 28 October 2010 (UTC)
- Very strong support for the modular rights; the modules and process will need to have the bumps and whatnot ironed out by the community though. Is is just me, or are the admins opposing, while non admins are supporting? 930913 (Congratulate/Complaints) 01:23, 28 October 2010 (UTC)
- Oppose, I agree with PeterSymonds, I see no reason to split up the powers, if a person is trusted to delete pages why can't they protect pages too? -- d'oh! [talk] 01:59, 28 October 2010 (UTC)
- There is a difference between content creators and new page patrollers/issue taggers. Content creators are more likely to need the protection tool than a new page patroller. Content creator often work on templates (which are often full protected). It is logical for Protection to be in the same module as page moving. In order to move protected pages properly you need also to move the page protection. New page patrollers are less likely going to need to protect a page. In the event they do they can make a request at Requests for Protection. There may be issues where the fields occasionally cross and they need to request help from someone with the right. If it happens often enough they could apply for adminship, or for that particular module. --Alpha Quadrant talk 02:16, 28 October 2010 (UTC)
- As discussed above, there also is a difference between needing a tool and being trusted with a tool. Anyone who can be trusted to not abuse the deletion tool can be trusted to not abuse the protection tool (irrespective of whether he/she intends to use it). —David Levy 02:26, 28 October 2010 (UTC)
- Yes, there is a difference. However, some users would be trusted with one module, but not the others because of lack of contributions in that particular area. They would get opposes in a RFA due to lack of contributions in a particular area.As I have said before above, if some editors don't need the entire sysops right why should they be discouraged because lack of contribs in a area. It would make it easier for editors to get the tools that they would be trusted with, rather than fighting through a RFA to get a few tools they will use as well as some that they won't. Nothing will happen to the sysops group. What would be wrong with making administrator modules? --Alpha Quadrant talk 02:49, 28 October 2010 (UTC)
- As I've stated above, the various aspects of adminship are heavily intertwined and difficult to isolate, so I believe that a reasonable understanding of Wikipedia as a whole is essential for someone possessing most of the individual tools in question. If someone cannot be trusted with one of these tools, I don't believe that he/she should be trusted with any. (It's fine if someone doesn't wish to use some of the tools, but we should be able to trust him/her with the capability.) —David Levy 03:49, 28 October 2010 (UTC)
- Yes, there is a difference. However, some users would be trusted with one module, but not the others because of lack of contributions in that particular area. They would get opposes in a RFA due to lack of contributions in a particular area.As I have said before above, if some editors don't need the entire sysops right why should they be discouraged because lack of contribs in a area. It would make it easier for editors to get the tools that they would be trusted with, rather than fighting through a RFA to get a few tools they will use as well as some that they won't. Nothing will happen to the sysops group. What would be wrong with making administrator modules? --Alpha Quadrant talk 02:49, 28 October 2010 (UTC)
- As discussed above, there also is a difference between needing a tool and being trusted with a tool. Anyone who can be trusted to not abuse the deletion tool can be trusted to not abuse the protection tool (irrespective of whether he/she intends to use it). —David Levy 02:26, 28 October 2010 (UTC)
- (edit conflict) Support for patroller, but given out by the community rather than a single user. Let's not give userrights to this group, cos that would allow them to grant and revoke every group in existence. The add/remove groups thing is separate, but I know what you mean Support for flooder - concerns of bot editing etc are meaningless, because it's only stuff like rollback that can be marked as a bot edit anyway (IIRC). Should be OK for a single admin to determine this one. Support for protector too, again with community agreement, but I don't like that unwatchedpages is included in that tbh - the info in that is quite dangerous if someone malicious gets hold of it. Weak Oppose for purger, IMHO you can't include deletedtext in that one, which basically knocks the usefulness of this group quite a long way. For the use it'll have, you might as well knock undelete, deleterevision, browsearchive, nuke and deletedhistory too. Which leaves delete as the main function of this group, and will prevent a user from undoing a mistake. So knock delete out too. What does that leave? Weak Support for file uploader, but delete is in there (see above). Yes, a file can be uploaded again, etc, but I see little point in this too, as most of what is in there is probably (IIRC) mainly in the autoconfirmed group (feel free to correct me, as always). I do like the idea of unbundling the rights, but not to a huge extent - this is getting to the far end of unbundling in my opinion. and whoever commented that admins didn't like this, here's an admin who likes the idea in principle [stwalkerster|talk] 02:17, 28 October 2010 (UTC)
And a cookie to anyone who manages to fix the bold/italics at the beginning of my above comment - I can't see what's gone wrong. :( [stwalkerster|talk] 02:17, 28 October 2010 (UTC)Fixed it :) [stwalkerster|talk] 02:19, 28 October 2010 (UTC)
- Lemmings! –MuZemike 02:44, 28 October 2010 (UTC)
- Oppose all These rights do not need to be split. A user gets the package deal by becoming a sysop. Acps110 (talk • contribs) 03:55, 28 October 2010 (UTC)
- Strongly oppose - and I apologize for TL;DR-ness - for a number of reasons. Firstly, this will not solve the problem it is meant to resolve, that being that non-admins will more easily be able to complete tasks in admin-related areas they are involved in. Yes, someone who does a lot of work in new page/CSD patrolling could benefit from this "Purger" right. Yes, someone who does vandal patrol could benefit from the Patroller right so they could block users. And so on. But in my experience, even if what you're doing falls squarely in one of those areas, you'll often need the other admin tools as well. For example, this: I'm doing new page patrol and notice a user making attack pages. I have Purger, so no problem, page deleted. Five minutes later it's back, so I delete it again. And so on. I don't have Patroller, so I can't block the vandal, and I don't have Protector, so I can't salt the title. What do I do? I go post on AIV and RFPP, and find myself back in the situation I was in before I asked for Purger in the first place. Or, scenario two: I notice this page but don't have any rights. I tag the page for CSD, and the admin who handles the tag not only deletes the page but also blocks the user and adds the page to his/her watchlist in case it needs salting in the future. Much more efficient, no? Very frequently I will start doing one task and find myself doing something that you'd think would be entirely unrelated at first glance. It would be much better for someone to go through RFA, so that they have access to all of these tools, so that they may use them should the need arise.
Reason the second: let's take that first scenario and say that our hypothetical Purger decides that this is a good reason for them to ask for the Patroller right. They do so, and after a review by the community, they see no reason not to give him the right. Life continues. Our Purger/Patroller finds that they're coming on that scenario multiple times, and would really like Protector as well. So they ask for it, and get it. Now, with access to the block, delete, and protect buttons, they are an admin in everything but name. Are they still held to the same standards as administrators (as established by numerous ArbCom cases)? Likely not, as they don't wield a mop, but rather a large number ofSwiffersfeather dusters. Are they held to the same level of scrutiny in gaining these tools? Likely not, as they pick them up one at a time. This seems like an excellent way for someone to clear RFA without actually clearing RFA; it'll take a lot longer, but someone that may not be able to pass RFA may be able to jump all the hurdles needed to make themselves an admin with this process.
Finally, as pointed out before, there are a number of other minor issues with this. Legal issues associated with deleted revisions. Security issues associated with access to Unwatched Pages, private abuse filters, and so forth. Consistency issues that we trust a user with one button that can cause major disruption and drama but not THAT button. And so forth. As most of those points have been made already and I've already rambled on for far too long, I won't go into detail about them, but I do not see this as a good idea, and in fact see it as something that has great potential to cause serious problems. Hersfold (t/a/c) 04:15, 28 October 2010 (UTC)
- So the logic is that because sometimes you need a hammer, and sometimes you need a screwdriver, you're rather have no tools at all than have some of them. Or put differently, you'd rather have 2 people with hammers and screwdrivers, than 2 people with hammers and screwdrivers, plus 5 with screwdrivers, and another 5 with hammers. We lose nothing by letting clueful people have access to tools that would allow them to be more efficient at what they are good at and want to help with. Headbomb {talk / contribs / physics / books} 06:04, 28 October 2010 (UTC)
- Unless of course one of those people with a hammer tries to use it to drive in a screw, and ends up breaking things worse than if they'd done nothing. When all have is a hammer, everything looks like a nail. Mr.Z-man 14:25, 28 October 2010 (UTC)
- Sorry, but the "Well since I can't edit mark your edits as patrolled [not a patroller], I'll move a file instead [since I'm a File Uploader]!" seems both pretty damn far-fetched and terribly useless. Remember the big fuss about how rollbacking would be the end of Wikipedia, which would enabling users to revert war at ungodly rates, etc... and how it turned out that we're still here, and we're now pretty glad rollback was unbundled? Headbomb {talk / contribs / physics / books} 16:51, 28 October 2010 (UTC)
- Not that (file mover is actually the one that I support the most, since its the least intertwined with other tools), more like "This edit war might be better solved by protecting the page, but I can only block, so I'll just block the users" or "This page is getting a lot of vandalism from one IP range, but I can only protect" – cases where it would be better to report it to someone who can deal with it properly, rather than deal with it yourself in a suboptimal way. Mr.Z-man 20:33, 28 October 2010 (UTC)
- So then why not support a version of this which does not include the blocking tools? Headbomb {talk / contribs / physics / books} 21:01, 28 October 2010 (UTC)
- We have that, its called rollbacker, most of the rights other than rollback and block are just superfluous. Mr.Z-man 21:07, 28 October 2010 (UTC)
- Rollbackers can't move pages without leaving redirects behind, move files, edit protected templates, etc.... So no, we do not have "that", whatever "that" is. Headbomb {talk / contribs / physics / books} 03:39, 29 October 2010 (UTC)
- But only one of those is part of the proposed group that includes blocking. The issue (or one of the issues) is that each of these groups only includes one of the major admin rights (except Flooder, which doesn't include any), when, as myself, David Levy, Hersfold, and Beeblebrox have said (to quote David), "the various aspects of adminship are heavily intertwined and difficult to isolate." If people want something like this to do maintenance work, then these are probably still too bundled; the proposals here are basically just the admin package, chopped into thirds. If none of them included the "big" rights (block/protect/delete) and extraneous things like noratelimit, unwatchedpages, and tboverride, and just included specific rights needed to do specific maintenance tasks there would probably be a lot more support. There's no reason we can't have user groups with only 1 or 2 rights. Admin only has a whole bunch of stuff tacked on because that's how MediaWiki was designed, there's no policy for it. Mr.Z-man 04:47, 29 October 2010 (UTC)
- Oppose, stop with the attempts to unbundle the tools. All it has done is create a whole new class of prizes to reinforce the Reward Culture, passing out tools to unprepared immature editors. SandyGeorgia (Talk) 04:37, 28 October 2010 (UTC)
- On the contrary it would finally defuse that culture. Because right now, since we're giving access to all the tools at once, people are paranoid about letting someone who farted once in 2006 touch them for "fear or abuse". Criteria go up, admins go down. Make the tools comes in smaller bundles, and you'll both encourage more people to step forwards and volunteer their skills to improve Wikipedia in various areas (Vandals, templates, files, page patrol, ...), and remove the "monolithic prestige" of getting access to tools. I've yet to see someone fawn over rollbackers and account creators, and I very much doubt patrollers and uploaders or whatever would gain any amount of worship. Headbomb {talk / contribs / physics / books} 06:14, 28 October 2010 (UTC)
- Oppose; Sandy pretty much hits it on the head. There's a culture developing here where more and more people play Wikipedia like some kind of great big Game with different Levels and Status Points. This isn't the answer. (Not sure I know what the answer is, mind you; this just isn't it.) Antandrus (talk) 04:47, 28 October 2010 (UTC)
- Oppose as defective. The Patroller (blockemail) (userrights), Protector (move-rootuserpages), and Purger (nuke) would be given rights that should be reserved for sysops and crats. Otherwise I would approve a 3–6 month trial. – Allen for IPv6 06:18, 28 October 2010 (UTC)
Without being a total nag, let me repeat my question (^above): Why do the proponents think that this will not turn into the same "hurdle-drama" as the current process? ("In other words"? sure:) Why would people suddenly quit being suspicious, skeptical, over-critical, have the candidate do the pole-run? What exactly will change? If you could convince me that this will indeed make the process of giving people these tools easier, I could be warmed up to the whole idea. thanks. Choyoołʼįįhí:Seb az86556 > haneʼ 06:30, 28 October 2010 (UTC)
- I assume they think people would set the hurdles lower, presumably on the basis of fewer rights = less potential harm. Not that I am a proponent personally. --Cybercobra (talk) 08:56, 28 October 2010 (UTC)
- Totally opposed This will just multiply the opportunities for patronage and partiality and would turn a democracy toward feudalism. Anthony (talk) 08:34, 28 October 2010 (UTC)
- Support viewing deleted content, but oppose other I agree some of these tools are too powerful for non admins but why for all sanity can't normal users view deleted content, there is no harm right? why are we censoring people from deleted stuff (this is wikipedia saying no you can't look at that because its offensive/disruptive) this is a nanny culture, if I want to have a laugh reading over deleted content where some user is insulting another user I should be able too, we are all adults here we shouldn't be censored--Lerdthenerd (talk) 13:13, 28 October 2010 (UTC)
- I think it's mainly for the sake of security. Note that there is a type of deletion called suppression (or "oversight") that even administrators can't see. —Soap— 13:17, 28 October 2010 (UTC)
- what about on just articles, I've had users ask me to give them the content on their articles that have been deleted, and I've had to turn them down because I don't have access, confirmed users should have this right so they can have a copy of their deleted work, to work on--Lerdthenerd (talk) 13:23, 28 October 2010 (UTC)
- In an ideal world, there would be enough administrators to handle those requests promptly. We don't have that, but I don't think turning viewdeleted into an automatically assigned userright in the manner of autoconfirmed is a good solution. On some wikis, such as Simple English, the RfA process is much more lenient than ours is, and they manage to survive without the constant disasters predicted by those who oppose loosening RfA standards over here. I think what we should work towards is finding out what they're doing right that we're doing wrong. —Soap— 13:41, 28 October 2010 (UTC)
- Actually, I think viewdeleted is one of the most dangerous admin rights to give someone. With, say, the ability to block or delete, at least it's obvious that someone's abusing it, and you can quickly revert and block/remove usergroups. With viewdeleted, there's neither a log of what was viewed, nor any way to undo its effects. (Being able to view deleted articles you edited/created is a different issue. And is WP:REFUND really that backlogged?) --ais523 15:55, 28 October 2010 (UTC)
- In an ideal world, there would be enough administrators to handle those requests promptly. We don't have that, but I don't think turning viewdeleted into an automatically assigned userright in the manner of autoconfirmed is a good solution. On some wikis, such as Simple English, the RfA process is much more lenient than ours is, and they manage to survive without the constant disasters predicted by those who oppose loosening RfA standards over here. I think what we should work towards is finding out what they're doing right that we're doing wrong. —Soap— 13:41, 28 October 2010 (UTC)
- whats dangerous about viewdelete? with the other rights you could seriuosly mess up wikipedia if they fell into the wrong hands, with view delete all you're doing is reading, not changing anything.--Lerdthenerd (talk) 11:01, 29 October 2010 (UTC)
Strong support for trial How is not different than when Rollback and autopatroled were unbundled from the admin package. Feinoha Talk, My master 15:36, 28 October 2010 (UTC)
- I can tell you how it's different: rollback and autopatrol do not affect other users and you cannot wield power with them; if I don't have rollback, I can use undo which is slower, but w/ the same effect. The crux here are block and delete, at least for me. These can really piss people off if misused. Choyoołʼįįhí:Seb az86556 > haneʼ 16:59, 28 October 2010 (UTC)
- We're not going to be handing these rights out to people like candy on Halloween... There's probably going to be strict standards for these tools. What exactly those standards are yet, I don't know. The Thing // Talk // Contribs 17:37, 28 October 2010 (UTC)
- Wikipedia:Requests for tools and Wikipedia:Guide to requests for tools is the first draft. The fine details would need to be worked out. --Alpha Quadrant talk 18:00, 28 October 2010 (UTC)
- The requirements for the patroller right should be raised significantly, to a few thousand at least. I could get 500 reverts and 500 warnings in a single day if I put my mind to it. I believe one should have vandal-fighting experience spanning about 8 or 9 months at the very least, with few mistakes, particularly 1 or 2 months before requesting the right.The Thing // Talk // Contribs 18:07, 28 October 2010 (UTC)
- Done changed to a minimum of 5000 anti-vandalism edits and 8 month experience. --Alpha Quadrant talk 18:22, 28 October 2010 (UTC)
- The requirements for the patroller right should be raised significantly, to a few thousand at least. I could get 500 reverts and 500 warnings in a single day if I put my mind to it. I believe one should have vandal-fighting experience spanning about 8 or 9 months at the very least, with few mistakes, particularly 1 or 2 months before requesting the right.The Thing // Talk // Contribs 18:07, 28 October 2010 (UTC)
- Wikipedia:Requests for tools and Wikipedia:Guide to requests for tools is the first draft. The fine details would need to be worked out. --Alpha Quadrant talk 18:00, 28 October 2010 (UTC)
- We're not going to be handing these rights out to people like candy on Halloween... There's probably going to be strict standards for these tools. What exactly those standards are yet, I don't know. The Thing // Talk // Contribs 17:37, 28 October 2010 (UTC)
File Uploader I could see a use for in terms of Commons people, especially Commons admins, getting rights that will make migration easier; though I'd want the rights limited to the File namespace. The others... probably more trouble than they're worth, in terms of complexifying things overall. The vast majority of WP backlogs don't require these rights to handle. Rd232 talk 15:57, 28 October 2010 (UTC)
- Oppose. This proposal, if implemented, will create more problems that it can solve. I would only support splitting 'movefile' userright into a separate usergroup—it has never been intended as admin only right. Ruslik_Zero 18:59, 28 October 2010 (UTC)
- No no no even though I wish I have at least one of the buttons again, it has the potencial of being grosly abused. If a user can't pass RFA, is their own fault. I agree with Sandy. Secret account 20:38, 28 October 2010 (UTC)
- Oppose This type of thing has come up again and again, and has been shot down again and again for the same reasons. Adminship is for trusted users. If a user isn't trusted enough to be full admin there should not be a back door they can sneak through, and they definitely should not be blocking other users. Also, as been stated, admins often use mre than one tool to deal with a situation, such as blocking a spammer and deleting all the spam they have added. Situations that one admin can handle would be require several of these partial admins, or they would have to go find a real admin to finish the job, actually reducing efficiency. Beeblebrox (talk) 20:46, 28 October 2010 (UTC)
- No means no. Killiondude (talk) 20:57, 28 October 2010 (UTC)
- Support abandoning the idea of "adminship" Opposers keep saying things like "this is a back door to adminship". That completely misses the point. We shouldn't have anything called "adminship". It's been a major cause of misunderstanding that we've taken this bundle of technical permissions and called them something that is traditionally associated with additional authority. The only way we can fix this is to make it clear that it is indeed just technical permissions. I think it will actually eliminate "level upping" if we remove the heirarchy aspect of it by unbundling the significant functions. Of course the more sensitive functions like blocking and deletion will have higher bars, just as checkuser is harder to get than rollbacker. Gigs (talk) 21:20, 28 October 2010 (UTC)
- Support some bits of this RFA is broken, our number of active admins is dwindling and has dropped from 1,021 to less than 800 in the last two and a half years. At some point things will have to change, however unpalatable the idea of change is to some. I would prefer that we as a community reform ourselves before things reach crisis point, not least because a gentle change of direction in good time is usually smoother than a last minute panic. I think these particular solutions are over complex, involve too many rights in each package and have odd mixes of content creator and vandal fighter. My suggestion for the next unbundled right would be the block button, it is the second most heavily used admin tool, but the one where we need to always have people available who can block vandals. If we create a block button that can only be used against IPs and autoconfirmed editors then I believe we have created a useful group of users, and I would hope that the "must have a GA or FA" brigade could tolerate the appointment of trusted vandalfighters to this role. Most AIV reports could be resolved by such users, and it wouldn't matter if occasionally they left a few speedies for an admin to delete - the urgent thing is to stop the vandal in mid spree. ϢereSpielChequers 21:45, 28 October 2010 (UTC)
- Limiting rights by domain is more likely to get community approval. I suggested File Uploader with rights limited in software to File namespace; block tools limited in software to use against IPs and non-auto-confirmed might get my vote too, though there would be concerns about encouraging WP:BITEyness. Rd232 talk 11:57, 29 October 2010 (UTC)
- I noticed your the only adminstrator supporting this proposal so far, all the other people supporting are non-adminstrators, that tells us that people are interested in the tools, but won't be willing to go though RFA. We need to fix RFA back to the standards of a few years ago, where it was more forgiving for an editor who make mistakes, not give out admin tools. Right now it's impossible to forgive any editor who does one messup in a question, or made poor decisions that led to desysopping (like myself). Secret account 22:22, 28 October 2010 (UTC)
- Secret, User:stwalkerster is also a administrator as well. Also, being a administrator is not a supervote. --Alpha Quadrant talk 00:00, 29 October 2010 (UTC)
- To me that's exactly the problem. "Becoming an administrator", "being an administrator". It's just a bit in a database. It doesn't define you as a person or as an editor. We used to call it "the bit" more often to remind everyone what it really means. The normal non-wiki connotation of the word "administrator" has tainted things, I think. They should have given it a silly name like they did to the bureaucrat bit. Gigs (talk) 01:52, 29 October 2010 (UTC)
- Err, being male/female or dead/alive are just "bits in a database" too, but that doesn't mean they're unimportant. It's time to retire the "just a bit"/"only a mop" analogies. They're misleading, like pretending an injection was "only a little prick" in the days before disposable needles. - Pointillist (talk) 11:37, 29 October 2010 (UTC)
- To me that's exactly the problem. "Becoming an administrator", "being an administrator". It's just a bit in a database. It doesn't define you as a person or as an editor. We used to call it "the bit" more often to remind everyone what it really means. The normal non-wiki connotation of the word "administrator" has tainted things, I think. They should have given it a silly name like they did to the bureaucrat bit. Gigs (talk) 01:52, 29 October 2010 (UTC)
- Very much oppose because this is now the fourth time I've seen a discussion over this within the past few months. The consensus is and has always been a resounding "no". Someone address all my concerns at Wikipedia talk:Vandal fighters#My opinion (which apply not only to vandal fighter semi-admin rights, but to all such proposals) and I'll support. But this is becoming forum shopping by many users (intentional or not), and there are still two threads on WT:RFA related to separating rights, too, neither of which has any consensus at all. Someone tell me, also: why should we be making more convoluted RfA-type processes without first fixing RfA? and to take TTTSNB as an example, why should I trust him with extra rights when he has not listened to users who ask him to work with content more? If I cannot trust him with delete, I see no reason to trust him with block, because they are based on similar principles. If a user only CSDs articles as his or her onwiki-work, why should they get the delete ability if we cannot trust them with blocking or protecting? Everything crosses over; you either know all the major policy or you don't, and you either get all the rights or you don't, because something could seriously go wrong, especially without any standard desysop or de-right process. /ƒETCHCOMMS/ 01:28, 29 October 2010 (UTC)
- Support the idea if not so much the implementation. The idea of giving out admin abilities separately is one that's been around for a while. I've broadly supported it, but the general consensus has been to keep the status quo, which hasn't been particularly bad. I think that though it may be decried as "game-like" in some ways, having a clear path from low trust and responsibility to the broad rights and trust of an admin seems like a good idea that would help cut the stress of going for the full spectrum of admin rights. I particularly like the idea of task-oriented packages, which is something that genuinely adds to the proposal. I don't think, however, that we ought to jump straight to accepting some particular set of packages: we need to settle upon some principles first for what rights these packages ought to include. For example, I think that the ability to undo one's own actions is important, and I would not support the "delete" right being given out without "undelete". However, "undelete" has implications in that it is important on a higher level that we carefully vet who gets it because of the nature of deleted content. I think that this is a good idea, but let's, well, edit this proposal. :) {{Nihiltres|talk|edits|⚡}} 01:45, 29 October 2010 (UTC)
- You'll have to forgive me, but I find the idea of admins being trusted to be a little bizarre. Trust might come with accountability, but that's lacking at the moment. Malleus Fatuorum 01:53, 29 October 2010 (UTC)
- You'll have to forgive me, but I find the idea of admins not being trusted to be a little bizarre. There are endless ways that an admin could cause major damage to the encyclopedia if they used their administrative privileges inappropriately. Leave the "accountability" drama for another day: it has very little to do with this discussion. {{Nihiltres|talk|edits|⚡}} 04:00, 29 October 2010 (UTC)
- You've just demonstrated very nicely how out of touch with reality you are. The fundamental problem that needs to be addressed isn't whether or not vandal fighters should be given right X or Y, it's that admin is effectively a job for life. If it wasn't, then all of the rights could be handed out (and of course taken away) without all of this recurring babbling nonsense. Malleus Fatuorum 13:41, 29 October 2010 (UTC)
- Concur. All this would be unnecessary if there was a way to easily desysop in case of abuse; as it stands, people given the bomb (it really is called NUKE) and there is no way to take that away from them again (yeah, yeah, in theory, there is, but it doesn't happen in practice). Instead of arguing over splitting this, just make desysopping easier. Choyoołʼįįhí:Seb az86556 > haneʼ 15:17, 29 October 2010 (UTC)
- Malleus, the "out of touch with reality" bit was rather unnecessary. I think that the "job for life" issue of adminship is tangential to this discussion, but if you really want to bring it in, I think it rather supports the idea of role-oriented rights packages. The reason that English Wikipedia doesn't have a good policy for desysopping is that it's very dramatic. It's a Big Deal, or at least a great deal is made of it. By allowing the rights to be assigned with greater granularity, at least some of the drama can be removed. For example, suppose we have an admin who has abused the block button a couple of times: we might remove adminship but grant one or more of the other packages, meaning that the user would be free to continue productive admin-type work in other areas. The social damage inherent in the removal measure can be minimized. Lowering the barriers to gaining admin privileges (which this initiative would arguably support) will also help lower the barriers towards removing them (which you seem to argue is highly desirable). {{Nihiltres|talk|edits|⚡}} 16:25, 29 October 2010 (UTC)
- You've just demonstrated very nicely how out of touch with reality you are. The fundamental problem that needs to be addressed isn't whether or not vandal fighters should be given right X or Y, it's that admin is effectively a job for life. If it wasn't, then all of the rights could be handed out (and of course taken away) without all of this recurring babbling nonsense. Malleus Fatuorum 13:41, 29 October 2010 (UTC)
- You'll have to forgive me, but I find the idea of admins not being trusted to be a little bizarre. There are endless ways that an admin could cause major damage to the encyclopedia if they used their administrative privileges inappropriately. Leave the "accountability" drama for another day: it has very little to do with this discussion. {{Nihiltres|talk|edits|⚡}} 04:00, 29 October 2010 (UTC)
- You'll have to forgive me, but I find the idea of admins being trusted to be a little bizarre. Trust might come with accountability, but that's lacking at the moment. Malleus Fatuorum 01:53, 29 October 2010 (UTC)
- Support the idea of Patroller I support the idea of Patroller as it can help with many antivandalism fighters, however, the practice can be debated quite heavily. The others I feel neutral at the moment.--iGeMiNix 02:22, 29 October 2010 (UTC)
- Support In principle. I'm not particularly interested in adminship, but would like to have some of the "Protector" tools, especially the ability to move pages over redirects. This would allow me to do more maintenance work myself rather than having to hassle an admin every time I need it done. Sasata (talk) 03:05, 29 October 2010 (UTC)
- Support Protection Rights but not the others. Deleting and blocking are harsher than protection. But in my point of view, I think it is safe to only semi-protect pages, and unprotect those with the grey padlock, as autoconfirmed non-admins can still edit a protected page. However, I wouldn't give protection rights to users who have an intention to protect the sandbox, unprotect the Main Page or any licensed text like this for example. To sum it up, I would think protectors would only be allowed to put or drop the grey padlock. Minimac (talk) 14:36, 29 October 2010 (UTC)
- What about adding and removing Pending changes protection? Assuming that it remains implemented. --Alpha Quadrant talk 15:20, 29 October 2010 (UTC)
- Support File Uploader, Patroller, Protector and Flooder per WereSpielChequers and Stwalkerster. —Ғяіᴆaз'§Đøøм • Champagne? • 12:27pm • 01:27, 30 October 2010 (UTC)
- Extreme support! It could help in the clearing of administrative backlogs. Also, it may improve the response time for some incidents. I believe that this is an excellent proposal, and, as said before, not all admins use all admin rights, and so, a RFA would also make it more difficult for them to help. As for Patroller, if you notice, many rollbackers are reviewers, and this right gives them both, as well as a few other anti-vandalism tools. Hazard-SJ Talk 16:37, 30 October 2010 (UTC)
- Strong support; I feel that these would be valuable tools to put in a few more hands, and avoiding the problem of concentrating all rights in one user role (administrator) which have been discussed over and over again... : Not handed out to the masses, but at least with community scrutiny slightly less painful than the hell-week of an RfA, we can get more good people to do these valuable jobs. My personal preference would be to tweak some of the details by removing a small number of rights from these proposed roles (for instance, if "Patroller" is a vandal-fighter, do they need to subsume autopatrol which is for content creation, and already an established user role?). I'd rather move away from bundling rights. Crossing a small number off the list might help assuage some other people's concerns too. bobrayner (talk) 17:01, 30 October 2010 (UTC)
- Support in principle, with the details to be discussed by the community later. shoy (reactions) 13:45, 1 November 2010 (UTC)
- Oppose all—perhaps a trial, but this seems like something for the trophy collectors. Also, it would cripple our abilities to deal with multiple problems (from the same user) at once. ǝɥʇM0N0 04:43, 12 November 2010 (UTC)
- Question I've just wondered. Has the rollback button been unbundled in the administrative package a few years ago? If so, then that could be the reason why some people may be opposing this proposal. Minimac (talk) 13:24, 12 November 2010 (UTC)
- Support. I initially proposed the "Patroller" and "Flooder" rights as well. Frozen Windwant to be chilly? 00:54, 16 November 2010 (UTC)
- Support - I mostly support this however I also think that most of the items could/should individually granted. With over 150, 000 edits I should have proven myself worthy of doing things like editing protected pages, Not be affected by rate limits (noratelimit), Use higher limits in API queries (apihighlimits) and various others eventhough I long ago lost interest in becoming an administrator. --Kumioko (talk) 05:42, 26 November 2010 (UTC)
Trial Proposal
Ok, I now put forward this question, should we create these rights to enable them for a trial as was done with Pending Changes? —Ғяіᴆaз'§Đøøм • Champagne? • 7:49pm • 08:49, 3 November 2010 (UTC)
- We would need Wikimedia Foundation Permission in order to create the Purger userright. --Alpha Quadrant talk 13:29, 3 November 2010 (UTC)
- Why? --Yair rand (talk) 00:57, 4 November 2010 (UTC)
- It is against Wikimedia foundation policy to give users non-administrator users the ability to view deleted content. In order implement the purger right it would be required for the Wikimedia Foundation to give their approval. So it would need the Wikimedia Foundation board approval. I sent a email to Jimmy Wales last week asking for WMF contact information, but I haven't gotten a reply yet. --Alpha Quadrant talk 01:29, 4 November 2010 (UTC)
- Why? --Yair rand (talk) 00:57, 4 November 2010 (UTC)
- We would need Wikimedia Foundation Permission in order to create the Purger userright. --Alpha Quadrant talk 13:29, 3 November 2010 (UTC)
- I propose three options for the vote. Oppose (self explanatory), Support principle oppose bundles (SPOB) (Support the principle of bundling rights, while disagreeing to the proposed bundles) or Support (Support principle and agree with above bundles)
{| class="wikitable" |- ! Oppose !! Support principle oppose bundles !! Support |- | 0 || 2 || 0 |}
- SPOB and suggest a page where users can propose new bundles, explain them, and then have bundles with community consensus passed. 930913 (Congratulate/Complaints) 00:46, 4 November 2010 (UTC)
- SPOB This "vote" or whatever this is is doomed to fail because what we're voting on is ill-defined. The best thing to do would be to work on a draft for a "Request for tools" or similar, and when the draft is finalized, submit each individual bundles to community approval, otherwise some will oppose them all because they oppose one. And because blocking and deletion will monopolize the opposes, let's just remove them from the proposed bundles immediately. Headbomb {talk / contribs / physics / books} 01:07, 4 November 2010 (UTC)
- Rushing to get this implemented will likely result in it failing. This vote is probably not the best way to get consensus. I will start working on a proposed process. Would anyone like to help me write a second draft? I will set up a issues section on the wikipedia talk page for any issues or concerns editors might have about the draft so they can be addressed. If you would like to assist in the drafting before we submit this for broader consensus, please list your name below: Alpha Quadrant talk
- May I suggest making bundles by a similar means to the fundraising banners? 930913 (Congratulate/Complaints) 01:56, 4 November 2010 (UTC)
- Creating dozens of userrights would make it more difficult for editors to understand. By creating these userrights it would make it easier for editors to do their jobs, not make it more confusing. Making custom userrights for each user would just create confusion. --Alpha Quadrant talk 13:38, 4 November 2010 (UTC)
- Dozens may be proposed, I would imagine no more than a few gain community consensus though. I fail to see how getting consensus on each proposed bundle before use will make it confusing. Where did custom userrights come from? 930913 (Congratulate/Complaints) 21:53, 4 November 2010 (UTC)
- Creating dozens of userrights would make it more difficult for editors to understand. By creating these userrights it would make it easier for editors to do their jobs, not make it more confusing. Making custom userrights for each user would just create confusion. --Alpha Quadrant talk 13:38, 4 November 2010 (UTC)
- May I suggest making bundles by a similar means to the fundraising banners? 930913 (Congratulate/Complaints) 01:56, 4 November 2010 (UTC)
- Writing a Request Process 2nd Draft
- Alpha Quadrant talk
- I'd be happy to help. Mr. R00t Talk 02:01, 9 November 2010 (UTC)
- Rushing to get this implemented will likely result in it failing. This vote is probably not the best way to get consensus. I will start working on a proposed process. Would anyone like to help me write a second draft? I will set up a issues section on the wikipedia talk page for any issues or concerns editors might have about the draft so they can be addressed. If you would like to assist in the drafting before we submit this for broader consensus, please list your name below: Alpha Quadrant talk
- Oppose as per my comments above and isn't voting evil? -- d'oh! [talk] 01:52, 4 November 2010 (UTC)
- Oppose - I think there may be some potential user groups that might make things easier for some non-admins to do work, but this isn't the way to go about doing it. It doesn't really seem like a lot of thought was put into these groups. "Protector - Users who perform various cleanup tasks such as ... improving articles" - That's like 95% of users. Before creating a new user group, there needs to be some sort of specific problem that its solving and a justification for each right in the group. It doesn't have to be a "bundle" - if just having one right would be useful, we can create a one-right group; it doesn't need to be filled with useless junk just to make it seem better. Mr.Z-man 19:50, 4 November 2010 (UTC)
- So rather than oppose, you want SPOB. If we choose bundles by similar means to the fundraising (see above), the proposers would have to justify the need for any bundle and the need for each right, otherwise the community would oppose it. 930913 (Congratulate/Complaints) 21:53, 4 November 2010 (UTC)
- Not really, I disagree with more than the specific bundles. I think the entire process here is completely flawed. Its starting from the wrong point. The question here seems to be "Should we have bundles? If so, what should they be?" The first question is pointless. We already have rollback, accountcreator, edit filter manager, and autopatrolled. We don't need to go out of our way to come up with new user groups. If there's going to be any sort of process about this, it should just be asking users what they personally would find useful, then determining what groups might be possible to help those users. If the idea is to simply split up the admin tools based on some hypothetical situations, then no, I would just oppose it completely. Mr.Z-man 22:52, 4 November 2010 (UTC)
- There is only one usergroup that can be created—'filemover'. It already exists on Commons and would be useful here. Ruslik_Zero 19:53, 5 November 2010 (UTC)
- So rather than oppose, you want SPOB. If we choose bundles by similar means to the fundraising (see above), the proposers would have to justify the need for any bundle and the need for each right, otherwise the community would oppose it. 930913 (Congratulate/Complaints) 21:53, 4 November 2010 (UTC)
- Oppose I just know that some drunken editors will be thinking "OK, my objective is to block as many users as I can within one week". This idea of a timed trial can still cause as many problems as say when you do get the admin privilege; you can still cause a lot of harm to the encyclopaedia. Minimac (talk) 14:58, 19 November 2010 (UTC)
- Oppose Was some thought actually put into this proposal, or was it made up in 30 seconds of giddy excitement? This whole thing is flawed and unnecessary. ----Divebomb is not British 18:33, 23 November 2010 (UTC)
Creation of Special:SuffixIndex
I think that an additional special page to complement Special:PrefixIndex would greatly help users in searching for certain pages with certain suffixes; see this discussion for more information. (Sorry if there was a discussion before about it that I did not see; if anybody finds one, please link it here so that I know better the next time. Thanks.) :| TelCoNaSpVe :| 01:45, 21 November 2010 (UTC)
- If you want to find articles whose titles end in ville, you can enter *ville in the search box and click on the Search button. [1]
- —Wavelength (talk) 02:21, 21 November 2010 (UTC)
- Ah, but Special:Search/*/FAQ does not give any FAQ subpages. :| TelCoNaSpVe :| 05:54, 23 November 2010 (UTC)
- This is a long standing bug btw - bugzilla:10808. Basically its inefficient in the current db schema (currently pages are stored in alphabetical sorted order, so you can hop right to the first page that starts with some prefix, but to hop to the first page that ends in some prefix, you have to look at the title of every page, and there is a lot of pages). It could be made to be efficient, but (from what I understand) there is not enough interest for it to be deemed worth the effort currently. Bawolff (talk) 04:52, 28 November 2010 (UTC)
- Ah, but Special:Search/*/FAQ does not give any FAQ subpages. :| TelCoNaSpVe :| 05:54, 23 November 2010 (UTC)
Proposal to close the Working Group Wikipedia
- wg:Main Page ( | talk | history | links | watch | logs)
Since this wiki is relevant only to the English Wikipedia project, I have decided to place the proposal here instead of meta, where they would normally decide whether to close down Wikimedia wikis. This is not a real encyclopedia even though it is registered under the .wikipedia.org domain name. It is an entire wiki dedicated to a single issue on the English Wikipedia. I do not believe that we should have wikis opened for every incident on any Wikimedia wikis; we would not have to open some new domain called http://wg.ur.wikipedia.org for example. And anyway, according to this wikiproject and its associated report from 2008 this wiki should have been closed as the disputes for the wikiproject have been resolved. :| TelCoNaSpVe :| 05:29, 22 November 2010 (UTC)
- It is de facto closed. I think the sitenotice that appears when you try to view any page illustrates that. Killiondude (talk) 06:36, 26 November 2010 (UTC)
Collapsible {{Infobox musician awards}}
Hi, the template {{Infobox musician awards}} is extremely long and very difficult to navigate as it constricts all the tables present beside it. Hence I was proposing to have the awards portion of the template as collapsible, so that it would not constrict the tables. Also it looks more professional. An example of such a manually coded collapsible template can be found at List of accolades received by Precious. I am not very good with coding in HTML hence don't know how to change the template to reflect the collapsible thing. The linked article uses this code.
{{!}} colspan=3 {{!}}<br> {{{!}} class="collapsible collapsed" width=100%<br> ! colspan=3 style="background-color: #D9E8FF; text-align: center;" {{!}} Awards and nominations<br> {{!}}-<br> What say everyone? — Legolas (talk2me) 09:56, 22 November 2010 (UTC)
- That infobox uses a nested, collapsible table. The best way to address is to discuss this on the template's talk page (Template talk:Infobox musician awards). — Edokter • Talk • 13:17, 22 November 2010 (UTC)
Spam Links
Right spot for this? Is there a way we can make auto-confirmed or some other criteria of user, to allow said user to link to black listed links? It is a ridiculous when I can't show a link in a GAC to a website, because other users, use it for spam. CTJF83 chat 02:32, 23 November 2010 (UTC)
- It is technically possible for a user group to have a right which makes them exempt from the spam blacklist. I don't know if the right exists yet, but even I know how to make one for this. And that's saying something :P Ajraddatz (Talk) 03:45, 23 November 2010 (UTC)
- No. A quick look at WT:WPSPAM reveals several spammers who have spammed Wikipedia for more than a year. MER-C 02:02, 26 November 2010 (UTC)
Cap editing protection on pages in the mainspace at 1 year
Just throwing out a suggestion to place a "cap" of 1 year for any edit protection (normally semi-protection) on any mainspace article. My reason is what setting edit protection to "indefinite" is more like a "set it and forget it" feature, and I think, as seen with the Pending Changes trial, there were quite a few articles which clearly did not necessitate permanent (semi) protection, though it definitely needed to be protected at that time. This would be beneficial in continuing to allow new users or anonymous users to edit more articles. –MuZemike 01:01, 24 November 2010 (UTC)
- There is a list of protected pages, which can show indefinite protections. It isn't that hard to go through that list every once and a while, but I see and agree with what you are saying. Realistically, no page should be indefinitely protected, save the main page and other very high use pages and templates. Ajraddatz (Talk) 02:12, 24 November 2010 (UTC)
- Not convinced. For example, low-profile BLPs with a certain demonstrated vulnerability to vandalism shouldn't suddenly be exposed to that again after 1 year, nor be dependent on somebody remembering to extend or re-protect. Indefinite should be used sparingly, and the list of pages using it should be checked regularly, but there are uses for it. Rd232 talk 02:44, 24 November 2010 (UTC)
- I strongly disagree; sometimes protection is turned on and "forgotten" for a reason. An excellent example of this would be Elephant, which has been protected effectively ever since July 31, 2006. Every time we take it down, vandalism ramps right back up immediately, and so it gets restored quickly. EVula // talk // ☯ // 20:19, 30 November 2010 (UTC)
Censored mode and Uncensored mode
Here's an idea: There should be a mode select for articles with cussing, sex references, gore, e.t.c., that censores and uncensores all these things. 82.13.79.52 (talk) 07:57, 24 November 2010 (UTC)
- Please see Wikipedia:Wikipedia CD Selection for that sort of thing. Doing it in Wikipedia itself has been suggested a number of times and is very heavily opposed. However if you want to write an add-on for some browsers to do various types of commonly desired censorships please do, I think it would help Wikipedia reach more people who currently avoid it. Various other types of censorship you might like to consider are - evolution for creationists, liberalism climate change, abortion and Obama for republicans, Xenu for scientologists, guns and violence for liberals, you could even redirect selected articles like 9/11 to a different site that more conformed to their beliefs for taliban readers. Provided it was obvious to the readers that wikipedia was no longer being accessed I think this would help in bringing Wikipedia to people and showing them what they are missing. Dmcq (talk) 10:43, 24 November 2010 (UTC)
- The made-for-schools version of Wikipedia is probably the best option at this point in time. Killiondude (talk) 06:32, 26 November 2010 (UTC)
- Probably not, as it's made for schools, and I'm no good at programming. Are there any add-ons for censorships around that I could use? 82.13.79.52 (talk) 16:56, 29 November 2010 (UTC)
- Probably not. Killiondude (talk) 17:12, 29 November 2010 (UTC)
- ME: :( That's too bad. I don't like sex refrences, gore, cussing, e.t.c.
- Voice: GIGANTIC PUSSY!
- ME: No, I am not a...
- Voice: GIGANTIC PUSSY!
- ME: Stop it!
- Probably not. Killiondude (talk) 17:12, 29 November 2010 (UTC)
- Probably not, as it's made for schools, and I'm no good at programming. Are there any add-ons for censorships around that I could use? 82.13.79.52 (talk) 16:56, 29 November 2010 (UTC)
- The made-for-schools version of Wikipedia is probably the best option at this point in time. Killiondude (talk) 06:32, 26 November 2010 (UTC)
82.13.79.52 (talk) 08:47, 1 December 2010 (UTC)
Annual CSB Improvement Drive
Proposal: every January, for the whole month, organise a prominent Wikipedia:WikiProject Countering systemic bias Improvement Drive. By "prominent", I mean prominent, with a watchlist notice, WP:SIGNPOST coverage, and coordinated outreach to non-English Wikipedias. A key part of the Drive would be a landing page where editors can find out more about the issues, and investigate what aspect of CSB improvement they might be interested in. I imagine that a part of this might be a sort of Wizard or Guide, as a way for example to suggest to people interested in Baseball what aspects of Baseball are systemically neglected, i.e. with a listing of underserved baseball topics outside the US. Besides which, it would be part of the Drive itself, especially in the first year, to construct such a Wizard/Guide; I'd expect individual WikiProjects to play a particular role here in kicking things off. Basically, the core points of the proposal are (i) try to harness people's existing interests in a way they might like but haven't thought of; (ii) improve understanding of the nature of the CSB coverage issues (iii) generally raise the profile of CSB issues. Rd232 talk 11:42, 24 November 2010 (UTC)
- Yes, let's do it! Probably essential to create a to-do list during December to make this happen, as well as breaking down the task in meaningful ways: geographical bias (make A, B, C, D... articles reflect a worldwide view), underrepresented groups on Wikipedia list, etc.--Carwil (talk) 14:22, 27 November 2010 (UTC)
I propose changing {{PD-self}} to {{Self|Cc-zero}} on all upload forms. Why? We live in a world of open standards. We already use a lot of Creative Commons templates to indicate license status, but for indicating that something is released into the public domain by the author, we have our own custom template. By changing this we make it easier for authors and (re)users to determine the license status of a work. At Commons we already changed see this topic. multichill (talk) 20:09, 24 November 2010 (UTC)
- It's strange to "brand" a public-domain dedication, but the CC dedication is worded better. "To the greatest extent permitted by law", etc. I say go for it. —Noisalt (talk) 20:33, 24 November 2010 (UTC)
- There's nothing wrong with CC-0 (but see below), but I don't think we should use it as our default public domain dedication, which is how it will be perceived if we make this change. Creative Commons doesn't own the concept of the public domain, and we shouldn't imply that they do. Having said that, I don't personally like the {{Pd-self}} wording either. Like CC-0 and most other PD boilerplate texts, it is just not strong enough against the potential of judicially-invented "rights" that weren't given away in the original dedication because they didn't exist - and the history of "moral rights" in European jurisprudence implies that such double-secret rights will continue to be invented. I'd much rather see us use language in line with the PD portion of User:Gavia immer/Copyright, though I suspect most people don't share my exact views on the matter. — Gavia immer (talk) 21:46, 24 November 2010 (UTC)
- Support, also is there any reason why the width for copyright tags is different from Commons? Can the template width (Template:CC-Layout, etc) be changed to 100% to match Commons? -- d'oh! [talk] 01:04, 25 November 2010 (UTC)
- Support - CC-0 seems much more thorough than the alternatives. Going with a standard also means less work for us, and probably more expertise behind the design of the license. Discomfort over "branding" seems a small price to pay. --Avenue (talk) 14:13, 27 November 2010 (UTC)
- Support CC-0 has received more legal vetting and is likely to stand up better in court. --Cybercobra (talk) 03:04, 29 November 2010 (UTC)
- Support, but I wonder why we still have an upload form for English WP. It is a free encyclopedia that needs free images. We should only use the upload form of Commons.--Wickey-nl (talk) 12:35, 29 November 2010 (UTC)
- I agree with Gavia above. Nothing wrong with CC-0, but there's nothing wrong with our standard PD templates. Killiondude (talk) 17:15, 29 November 2010 (UTC)
- How much vetting by actual lawyers have our PD templates had? --Cybercobra (talk) 18:16, 29 November 2010 (UTC)
- Probably about as much as any other template we have relating to licensing. Killiondude (talk) 18:38, 29 November 2010 (UTC)
- How much vetting by actual lawyers have our PD templates had? --Cybercobra (talk) 18:16, 29 November 2010 (UTC)
- Support - CC0 is certainly much better designed, legally, than anything we can come up with. CC's goals are very much in line with our own, so the "branding" thing is a non-issue IMO. Mr.Z-man 00:24, 1 December 2010 (UTC)
- Support. Commons has already done this recently. However, note that we cannot redirect PD-self to CC0, or otherwise mass convert PD-self to CC0, because they are not legally equivalent (among other things, CC0 waives neighboring rights). Of course CC0 media should be uploaded at Commons, not here, but some newbie users are not comfortable travelling to another wiki to contribute. Dcoetzee 01:49, 1 December 2010 (UTC)
- comment The main issue I see s that very few people know what CC-0 means, but they will probably have heard of public domain. However it does have the advantage that releasing something to public domain is not possible in many countries. And those moral rights that cannot be released apply whether it is either license anyway. Graeme Bartlett (talk) 09:39, 1 December 2010 (UTC)
Newcomers' help page
I'd like to propose that we link Wikipedia:New contributors' help page a lot more from places that might rather increase the number of newcomers finding somewhere helpful and friendly to go. I'm looking at MediaWiki:Anoneditwarning, perhaps also MediaWiki:Semiprotectedpagewarning and MediaWiki:Protectedpagewarning. I'd also like it to be linked from an editnotice seen by new accounts who are not yet auto-confirmed, but I'm not sure there's any way of targeting them. The proposal is associated with my proposed redesign of that page (Wikipedia_talk:New_contributors'_help_page#Redesign), which will make it a friendlier landing page and better able to cope with an increase in traffic. Pre-emptive counter to one inevitable objection: if it generates too much traffic and overwhelms the page and we can't figure out a way to handle it, we can get rid of the links again. I feel the more we have issues with declining editorship, and the larger and more complex Wikipedia gets, the more effort we need to put into easing newcomers into becoming Wikipedians, rather than remaining readers or just dipping a toe in and finding it too hard. Linking this help page more prominently would help a little, but I'd love to hear any other ideas. Rd232 talk 22:15, 24 November 2010 (UTC)
- Do it. Fences&Windows 22:25, 25 November 2010 (UTC)
- Thanks. I'd welcome some help with the redesign, incidentally - I'm happy with the basic approach but I can't quite get the layout to look right. Wikipedia:New contributors' help page/header-redesign. Why don't the boxes line up? :( Rd232 talk 22:49, 25 November 2010 (UTC)
- There used to be a link to the new contributors' help page on Help:Contents; but since the redesign of that page, one has to click through "Ask a question" down near the bottom to get to a page with a not-very-prominent link. That may be one reason why people clicking on the "Help" link on the left side of a WP page are failing to find the NCHP. Deor (talk) 22:46, 27 November 2010 (UTC)
- Thanks. I'd welcome some help with the redesign, incidentally - I'm happy with the basic approach but I can't quite get the layout to look right. Wikipedia:New contributors' help page/header-redesign. Why don't the boxes line up? :( Rd232 talk 22:49, 25 November 2010 (UTC)
Alternate accounts from Contributions page
Simple suggestion: link alternate accounts (WP:SOCK#LEGIT) from a user's Contributions page. This would require a simple software change (unless somebody has a clever way to do it without that), with an additional entry in Preferences for alternate accounts, and then a link to the other account(s) being given at the top of the page. We already have templates for the user page, but this would be clearer and harder to miss, and more convenient. Rd232 talk 13:36, 25 November 2010 (UTC)
Editnotice bot
Problem: We have a system of editnotices which is currently basically only maintainable by admins. We can expand this in a way that remains safe (the core problem is that editnotice vandalism would be particularly hard to detect and fix for most editors.) Proposal: create a bot which maintains editnotices on the basis of templates added to the article talk page. Category:Editnotice templates would be expanded, and a standard editnotice template added by the bot into the editnotice if it finds an appropriate template request on the talk page. For example, if it finds {{British English}} on the talk page it adds {{British-English-editnotice}} to the page's editnotice. It would operate from a fully protected list of templates, translating the talkpage request templates into editnotice templates (which would themselves be fully protected).
As a slight variation, it would also be possible to do the same thing based on categories within the article, rather than templates on the talk page; this would work in exactly the same way, with a protected list of categories to be translated to editnotices. I'm not quite sure if this is better, it's perhaps marginally more intuitive(?) and perhaps likely to be implemented more widely (perhaps over-used?), but the template method would ensure a note on the talk page as well if appropriate, which may be useful.
Why? Because it'll make it much easier to use editnotices much more widely, eg to advertise Arbcom restrictions at the edit stage exactly where it's needed, to pick one example. In terms of possible overuse, because it's controlled by a bot and a central list, it should be relatively manageable to keep track of and ensure it's only used where necessary (eg, the bot could only apply the editnotice template if the request applies to a page within a certain category). Comments? Rd232 talk 02:15, 26 November 2010 (UTC)
- I am undecided whether I support the idea or not, but User:AnomieBOT II already has tboverride so it can do the job if the community supports the idea. One thing to consider is the possibility of editors warring over e.g. whether {{British English}} belongs on the article or not. Anomie⚔ 02:47, 26 November 2010 (UTC)
- If you are going to note the language variation, we might as well get the rest of the article style options. ---— Gadget850 (Ed) talk 15:17, 26 November 2010 (UTC)
- That was just an example. The proposal is for the system; it's good to know what the content might be (and I agree other style options could be included; it would probably need a custom template with different style parameter options to squeeze them in reasonably neatly), but it's totally open-ended about how the community uses it. Rd232 talk 15:57, 26 November 2010 (UTC)
- I agree that this sort of style issue is probably more widespread (usually by misinformation rather than malice) than many others and wouldn't object to a system like this. It might serve to make edit notices somewhat more (safely) useful as well, which is always nice. Ale_Jrbtalk 15:25, 26 November 2010 (UTC)
- I think editnotices like {{British-English-editnotice}} should be used only when there is demonstrable cause, as editnotices can have a small destabilizing effect on editors. If there are requests for bots to edit editnotices, I think they should be considered on a case by case basis through BRFA. For what it's worth, we may have per-category editnotices at some point in the (distant) future, which could provide better solutions to such issues. Cenarium (talk) 01:32, 27 November 2010 (UTC)
- I've just voted for those bugs - that would be good to have. But the pace of development is slow enough that it might be worth doing this anyway. If we have concerns about specific editnotices we can either leave them off the central bot list completely, or require a clear consensus for the relevant template or category to be added. Rd232 talk 01:44, 27 November 2010 (UTC)
- I think editnotices like {{British-English-editnotice}} should be used only when there is demonstrable cause, as editnotices can have a small destabilizing effect on editors. If there are requests for bots to edit editnotices, I think they should be considered on a case by case basis through BRFA. For what it's worth, we may have per-category editnotices at some point in the (distant) future, which could provide better solutions to such issues. Cenarium (talk) 01:32, 27 November 2010 (UTC)
- If you are going to note the language variation, we might as well get the rest of the article style options. ---— Gadget850 (Ed) talk 15:17, 26 November 2010 (UTC)
"From Wikipedia, the free encyclopedia" - reocurring text under article's title
Screenshot here. There's already the same message / text at topmost-left corner (under 'puzzle' baloon). So wouldn't be it nice if we get rid of unnecessary / repetitive stuff? A cleaner / simpler scope / interface is better anyway. Userpd (talk) 19:12, 26 November 2010 (UTC)
- Oppose Mirror sites would not have the logo, only the "From Wikipedia" message at the top of the article it copies from. :| TelCoNaSpVe :| 19:33, 26 November 2010 (UTC)
- Mirror site like what? I guess anybody who once been to wikipedia had read that it's free / knows, why is there need to push at throats, too many texts which are not related to article's content only make it too bureaucratically stuffed. Besides still majority will read from wikipedia itself and not from someones who decide to mirror contents of wikipedia. Anyway, those who want to copy content from wikipedia wouldn't anyway copy this message along with the content, so this repetitive mentioning in an article's page is uncalled for. Would be better to make as simple as possible since it's a populated project. Userpd (talk) 22:28, 26 November 2010 (UTC)
- Read Wikipedia:Mirrors and forks, which tells you about such websites. They sometimes don't include either the logo or the wording, but retain the other. :| TelCoNaSpVe :| 23:14, 28 November 2010 (UTC)
- Mirror site like what? I guess anybody who once been to wikipedia had read that it's free / knows, why is there need to push at throats, too many texts which are not related to article's content only make it too bureaucratically stuffed. Besides still majority will read from wikipedia itself and not from someones who decide to mirror contents of wikipedia. Anyway, those who want to copy content from wikipedia wouldn't anyway copy this message along with the content, so this repetitive mentioning in an article's page is uncalled for. Would be better to make as simple as possible since it's a populated project. Userpd (talk) 22:28, 26 November 2010 (UTC)
- Support -- d'oh! [talk] 00:06, 29 November 2010 (UTC)
- Oppose The logo is omitted from printed copies that honor the CSS; the byline provides attribution in such cases. Also, call me nostalgic :) --Cybercobra (talk) 02:46, 29 November 2010 (UTC)
- Using the same CSS rules the wording can be hidden until the page is printed. If the CSS rule is not 'honored' the logo will be there instead, win-win. -- d'oh! [talk] 03:13, 29 November 2010 (UTC)
- Then putting it at the end of printed versions of articles should do the trick. Userpd (talk) 03:51, 29 November 2010 (UTC)
- I often browse Wikipedia with a text-only browser. The logo doesn't show up for me there. --Carnildo (talk) 02:14, 30 November 2010 (UTC)
- Support No superfluous text.--Wickey-nl (talk) 15:03, 30 November 2010 (UTC)
- Support, there are any number of technical workarounds to solve the mirror site "problem". Meanwhile, we should be making our own interface as useful and uncluttered as possible.--Kotniski (talk) 16:49, 30 November 2010 (UTC)
- Oppose The tagline helps readers know where the article comes from. Use
#siteSub { display:none; }
in your skin.css if it bothers you that much. Anomie⚔ 18:40, 30 November 2010 (UTC)
- I would think the big Wikipedia logo to the left will get the readers a clue on where they are. In terms of mirrors, all mirrors I know of has removed the wording, but still attributes Wikipedia at the bottom of the page. In addition, that CSS causes a misalignment of the top icons. -- d'oh! [talk] 23:44, 30 November 2010 (UTC)
- And removing it in some other manner won't misalign the top icons in the same way? Never mind that the "removal" will probably wind up being "edit MediaWiki:Vector.css to stop setting
display:inline
on#siteSub
", which is pretty much equivalent to using that bit of CSS in your skin.css? Anomie⚔ 00:57, 1 December 2010 (UTC)- Obviously we personally could do whatever we want with it (I could equally well argue that you could use Java to put the tagline back if you wanted it that much), but it's a question of how we present pages to our millions of readers who don't have any such options. What reason is there for making the same vapid statement twice, within a few centimetres of itself? --Kotniski (talk) 07:00, 1 December 2010 (UTC)
- And removing it in some other manner won't misalign the top icons in the same way? Never mind that the "removal" will probably wind up being "edit MediaWiki:Vector.css to stop setting
- I would think the big Wikipedia logo to the left will get the readers a clue on where they are. In terms of mirrors, all mirrors I know of has removed the wording, but still attributes Wikipedia at the bottom of the page. In addition, that CSS causes a misalignment of the top icons. -- d'oh! [talk] 23:44, 30 November 2010 (UTC)
- Apathy I don't really have a problem with it one way or the other; it's a bit redundant, sure, but there's a difference (on a technical level) between text in an image and actual text on the page. I'd be fine with it being hidden in the screen-media CSS (and visible in the print-media CSS). EVula // talk // ☯ // 20:13, 30 November 2010 (UTC)
- Support It's been there forever and I don't really see it anymore, but that's really a bit of space that's better dedicated to article content. Plenty of mirrors remove the tag as well, and of course the tag itself is not enough to ensure license compliance, so the mirror issue isn't a big factor for me. Dcoetzee 01:47, 1 December 2010 (UTC)
Proposal to discourage "parent–child links" at WT:LINK
See Wikipedia talk:Manual of Style (linking)#Parent–child links.
Is an article on the gender of objects, animals and countries possible?
Hello you all the English speaking wikipedians in the world. Please excuse my approximative English, I'm a froggy. Some months ago, I asked a question on the Reference Desk (languages) about the gender of non humans things in English. I was thinking particularly about ships and boats etc.. I got many interesting answers such : a ship is "she", a boat is "it" with the joke "How to recognise one from the other? Answer: You can put a boat on board a ship".
I learnt that most means of transportation are "she" except trains (without knowing why, he said). But what about motobikes? About bicycles?
Please notice that it would help EVERYBODY whishing to improve his/her English and that even my wife, an English teacher (fairly good at English) doesn't know everything about that. Her grammar books, for example are not comprehensive on this subject.
For example this page: http://en.wikipedia.org/wiki/Gender_in_English#Modern_English doesn't speak about trains, bicycles, mountain-bikes, etc...
One of the answers, consideriging that these kinds of questions are frequent on that Desk proposed that it would be a good thing to write an article on that subject.
All that introduction to ask you if you could creat an article on this subject or, more simple, enhance the one I quote above.
Thank you very much for everything you do. Jojodesbatignoles-Rheims-France---90.18.67.249 (talk) 13:33, 27 November 2010 (UTC)
- I wonder if there is a misunderstanding of the whole idea of gender here. Nouns do not have gender in English in the same way as in other languages...we really do have neuter definite articles ("the" rather than just French "le" vs "la"). It's not that "ship" is a female noun, but that a specific ship is usually considered as a female object. And very few objects are treated as any gender at all (almost everything is just "it"). It would be interesting to find the origin of ships being "she". DMacks (talk) 20:36, 30 November 2010 (UTC)
- Ships have been referred to as "she" since at least the time of the Phoenicians, because it was the custom to dedicate a ship to a goddess, under whose protection she sailed. (Brasch, R (1969). How Did it Begin?) Jojodesbatignoles-Rheims-France may be on to something, perhaps there is a need for an article to explain why some objects are often considered to be female. Malleus Fatuorum 21:14, 30 November 2010 (UTC)
- I support an article called Grammatical gender in English and I have pre-emptively added it to my watchlist.
- —Wavelength (talk) 22:08, 30 November 2010 (UTC)
- There is already Gender in English which seems to cover this topic adequately; I've redirected the suggested title there. It could use expansion. Dcoetzee 01:43, 1 December 2010 (UTC)
Suggestion
For example:
War is now/current continue. is available in a Wikipedia text
Please not use the now and current words. you must warning the all members on this issue. Now and current words is remove.
Becuase;
For example:
War is now/current continue text with now or current word is write at 1 September 2009 I am see the this text at 1 June 2010.
maybe the war ended on 1 June 2010. I am think war is still continue.
Please warning the robot and members which correcting errors. They/We are remove this words. They/We are change with a more appropriate sentence and the words
88.235.131.60 (talk) 14:45, 27 November 2010 (UTC)
- Use of "current" depends on context. If there is a use of the word "now" or "current" that is no longer current, an editor would simply have to change it. Wikipedia changes. It's impossible to say that certain words cannot be used on this site, especially without any real context. Is there a specific article you think needs to be changed? Ian.thomson (talk) 14:52, 27 November 2010 (UTC)
- {{As of}} addresses this. Fences&Windows 23:39, 27 November 2010 (UTC)
- See also Wikipedia:Manual of Style#Precise language. PrimeHunter (talk) 05:18, 28 November 2010 (UTC)
- {{when}} --Cybercobra (talk) 02:43, 29 November 2010 (UTC)
Article on Jimmy Wales (Internet Meme)
Hey Guys, its been a while
Would it be appropriate yet to write an article on the new internet meme revolving around Wikipedia founder Jimmy Wales? Several notable media sources have covered the rise of this meme and I am not sure if it fufills general notability guidelines for inclusion. Thanks. Marlith (Talk) 17:57, 27 November 2010 (UTC)
- I'd start with a small and balanced look at Wikipedia's fundraising efforts within Wikipedia, avoiding the recentism and naval-gazing of focussing on the furore around Jimmy's face staring out at us. Fences&Windows 23:04, 27 November 2010 (UTC)
- A good secondary source is [2]. Note however that KnowYourMeme wiki is not licensed compatibly, so you can't copy it directly. Dcoetzee 01:26, 1 December 2010 (UTC)
- Try adding material to History of Wikipedia#Fundraising. Fences&Windows 01:36, 1 December 2010 (UTC)
Proposal to add something to default Vector Skin
Please check out this page, look in the bottom left of the screen, and scroll down to see my proposal in full effect. I made this myself and I think a modified version of it would be a usefull, cool and maybe even necassary tool, especially for those with slow scrolling like me. It would help with long articles if you randomly or purposely decide to search another article. A Word Of Advice From A Beast: Don't Be Silly, Wrap Your Willy! 03:37, 28 November 2010 (UTC)
- I'm afraid it doesn't play along with the expandable toolbox, and probably not with interwiki links either. That's the standard problem with absolute positioning, and it's not likely to be fixable. If the entire sidebar were done that way it would work, but then you couldn't have more than one screen height worth of sidebar links without serious problems. Note that there is already an accesskey assigned to the search box, so you can hit alt-shift-f (on Firefox; other browsers may differ slightly) to set input focus on the search box from anywhere that displays it. — Gavia immer (talk) 03:56, 28 November 2010 (UTC)
- Indeed, it's painfully easy to bring focus to the search box as it is; on my machine (Mac 10.6, Safari 5.03), all I have to do is hit tab to get to the search box. (which is to say nothing of how badly that would interact with a long list of interwiki links) EVula // talk // ☯ // 20:07, 30 November 2010 (UTC)
Special:Undelete and Special:RevisionDelete
Currently, DeleteRevision merely marks the contents of deleted revisions as unavailable, and admins may noticed such that revisions do not show up under Special:Undelete. In order to delete a revision the "normal" way, an admin still has to delete the entire page and then restore the revisions that they want to keep. It would be nice if DeleteRevision had an actual "delete" function. --Ixfd64 (talk) 23:05, 28 November 2010 (UTC)
- There's no real reason to use the old way of deleting a revision. Special:RevisionDelete should be considered the "normal" way now. Mr.Z-man 23:29, 28 November 2010 (UTC)
- As in Special:RevisionUndelete? :| TelCoNaSpVe :| 23:57, 28 November 2010 (UTC)
- I find that the old method (delete&restore) is "cheating" the average person looking at the history. I think the only time it should be done is in cases of history merges. עוד מישהו Od Mishehu 09:47, 1 December 2010 (UTC)
- As in Special:RevisionUndelete? :| TelCoNaSpVe :| 23:57, 28 November 2010 (UTC)
Change to template:reflist fontsize wiki-wide?
It seems like {{reflist}} is used on most new articles. Historically, when the template was developed we left <references/> on the articles that already had it. Should we have a bot go through and convert the remaining uses of <references/> to use the reflist template instead? The advantage would be uniform styling, since the template gives a slightly different appearance (a smaller font) than the <references/> tag does. The disadvantage would be that we would be changing the established style on the pages that use <references/>. — Carl (CBM · talk) 20:28, 29 November 2010 (UTC)
- If we want to apply the styling of {{reflist}} in all articles, wouldn't it be easier to change the CSS than the articles? Algebraist 20:31, 29 November 2010 (UTC)
- If that's possible then we should (a) do that and (b) declare that replacing references/ with reflist should be done only if an additional option available in reflist is used. It's not helpful to make that many bot edits for a minor formatting change, or (if the CSS is updated) no formatting change at all. Rd232 talk 20:42, 29 November 2010 (UTC)
- Yes, should be possible to style all cite.php references by modifying the style for ol.references in Mediawiki:Common.css. This would affect articles that use either <references> or {{reflist}}. However, it has to be synchronized with the styling of div.references-small so that articles with {{reflist}} don't have the font size reduced twice. I agree with the minor edit issue if the styling was already the same; presumably it could be made a minor fix in AWB or something. But at the moment the style isn't the same, which is why I want to assess whether the consenus favors a uniform style or favors preserving the existing style for pages that use <references/> — Carl (CBM · talk) 20:46, 29 November 2010 (UTC)
- Let's do the CSS change then, and make the style uniform (standardising on the reflist style). That way, as I said, a switch from references/ to reflist is only needed if a reflist option is actually used. Reflist, after all, is just a wrapper for references/, so there's no need to use it unnecessarily, is there? Rd232 talk 22:13, 29 November 2010 (UTC)
- The only option for which reflist remains are columns, which is used a lot. Synchronizing is easy enough simply by editing common.css. I would support moving the CSS font-size to ol.references. The only problem I foresee is people who have custom declarations in their skin CSS; they would see a cumulative decrease in their font size, unless we removed .references-small from the template, as that classname has no meaning anymore. — Edokter • Talk • 22:24, 29 November 2010 (UTC)
- The risk in removing it is that if people have a cached version of the css file, and we remove the div from the template, they may not get any font reduction until they get a fresh version of the css file. So it may be safer to leave the references-small for a little while (longer than the default cache delay). — Carl (CBM · talk) 22:49, 29 November 2010 (UTC)
- Sounds like a good idea all around, I support it. However, I do note that some people prefer notes to be bigger than references. This is a very minority use, and could easily be handled on a case-by-case basis by something like
{{reflist|text-size=regular}}
, or similar. Headbomb {talk / contribs / physics / books} 23:09, 29 November 2010 (UTC) - Then we remove the div classname 30 days after we change common.css. — Edokter • Talk • 23:18, 29 November 2010 (UTC)
- Sounds like a good idea all around, I support it. However, I do note that some people prefer notes to be bigger than references. This is a very minority use, and could easily be handled on a case-by-case basis by something like
- The risk in removing it is that if people have a cached version of the css file, and we remove the div from the template, they may not get any font reduction until they get a fresh version of the css file. So it may be safer to leave the references-small for a little while (longer than the default cache delay). — Carl (CBM · talk) 22:49, 29 November 2010 (UTC)
- The only option for which reflist remains are columns, which is used a lot. Synchronizing is easy enough simply by editing common.css. I would support moving the CSS font-size to ol.references. The only problem I foresee is people who have custom declarations in their skin CSS; they would see a cumulative decrease in their font size, unless we removed .references-small from the template, as that classname has no meaning anymore. — Edokter • Talk • 22:24, 29 November 2010 (UTC)
- Let's do the CSS change then, and make the style uniform (standardising on the reflist style). That way, as I said, a switch from references/ to reflist is only needed if a reflist option is actually used. Reflist, after all, is just a wrapper for references/, so there's no need to use it unnecessarily, is there? Rd232 talk 22:13, 29 November 2010 (UTC)
- Yes, should be possible to style all cite.php references by modifying the style for ol.references in Mediawiki:Common.css. This would affect articles that use either <references> or {{reflist}}. However, it has to be synchronized with the styling of div.references-small so that articles with {{reflist}} don't have the font size reduced twice. I agree with the minor edit issue if the styling was already the same; presumably it could be made a minor fix in AWB or something. But at the moment the style isn't the same, which is why I want to assess whether the consenus favors a uniform style or favors preserving the existing style for pages that use <references/> — Carl (CBM · talk) 20:46, 29 November 2010 (UTC)
- If that's possible then we should (a) do that and (b) declare that replacing references/ with reflist should be done only if an additional option available in reflist is used. It's not helpful to make that many bot edits for a minor formatting change, or (if the CSS is updated) no formatting change at all. Rd232 talk 20:42, 29 November 2010 (UTC)
- This is not about the font size of the references. Its about replaced
<references />
with{{Reflist}}
because of the additional features Reflist provides, such as "colwidth". Personally, I do not want to see<references />
banned from Wikipedia, but general recommendation to use Reflist would be nice. —bender235 (talk) 23:19, 29 November 2010 (UTC)
I support a general establishment of preference for {{Reflist}} over <references/>, with or without bot conversion. —chaos5023 (talk) 23:20, 29 November 2010 (UTC)
Comment on AWB: AWB doesn't change {{Reflist}} over <references/> unless the editor who introduced it requested small font size. -- Magioladitis (talk) 23:23, 29 November 2010 (UTC)
- Yes. However, if the styles were the same, the change could in principle be added as a minor general fix to AWB. — Carl (CBM · talk) 23:26, 29 November 2010 (UTC)
I usually use <references/> when the references are really few (maximum 3 or 4) and reflist for 5 or more references. For over 30 or something I use refelist with 2 columns. -- Magioladitis (talk) 23:24, 29 November 2010 (UTC)
- I vastly prefer in-reflist cite details via the
|refs=
argument to {{Reflist}}, so never use <references/>. —chaos5023 (talk) 23:27, 29 November 2010 (UTC)
The Wikipedia window is alreay cluttered with so much stuff that smaller and smaller font sizes are resorted to inorder to present enough content on one screen to make comprehension easy. I oppose any use of fonts smaller than the size used for running text on the grounds it is too hard to read. Jc3s5h (talk) 00:31, 30 November 2010 (UTC)
- We've discussed this issue many times before, iirc. I support using {{reflist}} always, but seriously, it's not a big deal for a page with a few references that doesn't use it. Now, if a page has like 50 refs, we should probably condense the font size a little with {{reflist}}, but writing the articles themselves is more important, no? :) /ƒETCHCOMMS/ 01:57, 30 November 2010 (UTC)
- We're talking about standardising that marginally smaller size (90% AFAIR) via a sitewide CSS change. If we can avoid distracting ourselves with issues of replacing references/ with {{reflist}} or vice versa, it's really quite a small and simple change which ensures that it doesn't matter which is used (unless an editor wants to use the advanced options of reflist). Rd232 talk 02:16, 30 November 2010 (UTC)
- Yeah, well, the problem there is that CBM wrote a section header that's about font size and an opening paragraph that's about replacing <references /> with {{Reflist}}, so it's a coin toss what any given participant thinks the discussion is actually about. This doesn't make me real happy when I was already looking askance at CBM engaging in questionable behavior and justifying it with barely tangentially related discussion. —chaos5023 (talk) 02:20, 30 November 2010 (UTC)
- ? The substantive effect of replacing <references /> with {{Reflist}} is a change in fontsize, enabling standardisation of fontsize in reference lists. A better alternative for standardising this was mooted, and clarified by CBM. It's really not that mysterious. Rd232 talk 02:32, 30 November 2010 (UTC)
- Mmmkay. I suppose it doesn't parse that way to me because when I use {{Reflist}}, it's not because I care about the font size, it's because I want
|colwidth=
and|refs=
. I think we could've left bot enforcement out of it, in any event, but that's fine. Askance gaze withdrawn. —chaos5023 (talk) 02:44, 30 November 2010 (UTC)- The questionable behavior has been editors changing the references tag to the reflist template without getting a consensus first that a widespread change has consensus. The historical consensus was that a widespread change was not desired, but that might have changed. I think this thread has already been gathering useful feedback about the font size issue, and will likely gather more. It's more productive to phrase a thread as an actually plausible proposal, that might change, than to make it completely open ended. It gets better feedback. — Carl (CBM · talk) 03:13, 30 November 2010 (UTC)
- Mmmkay. I suppose it doesn't parse that way to me because when I use {{Reflist}}, it's not because I care about the font size, it's because I want
- ? The substantive effect of replacing <references /> with {{Reflist}} is a change in fontsize, enabling standardisation of fontsize in reference lists. A better alternative for standardising this was mooted, and clarified by CBM. It's really not that mysterious. Rd232 talk 02:32, 30 November 2010 (UTC)
- Yeah, well, the problem there is that CBM wrote a section header that's about font size and an opening paragraph that's about replacing <references /> with {{Reflist}}, so it's a coin toss what any given participant thinks the discussion is actually about. This doesn't make me real happy when I was already looking askance at CBM engaging in questionable behavior and justifying it with barely tangentially related discussion. —chaos5023 (talk) 02:20, 30 November 2010 (UTC)
- We're talking about standardising that marginally smaller size (90% AFAIR) via a sitewide CSS change. If we can avoid distracting ourselves with issues of replacing references/ with {{reflist}} or vice versa, it's really quite a small and simple change which ensures that it doesn't matter which is used (unless an editor wants to use the advanced options of reflist). Rd232 talk 02:16, 30 November 2010 (UTC)
- No, we shouldn't be forcing a smaller font on references. It's contentious. Enough editors object to smaller font references that, were the smaller font moved into CSS, one could reasonably expect a template would be created to reverse the CSS. Gimmetoo (talk) 02:49, 30 November 2010 (UTC)
- Do you object to the smaller font references? I'd assign more weight to a real, live objector than a vague idea of "enough" objectors out there somewhere. —chaos5023 (talk) 02:51, 30 November 2010 (UTC)
- Can you give examples of articles that use <references> instead of {{reflist}} explicitly to avoid the font change? What you are describing is what I always thought was the consensus, but people have been telling me lately there is now a general consensus to use the smaller font. If that isn't true, this thread would be a good place to re-establish the consensus. — Carl (CBM · talk) 03:13, 30 November 2010 (UTC)
- For my part, I'm saying what I would like to see happen, not what I think consensus is, and I kinda wish more people would do the same instead of invoking vast, nebulous bodies of silent editors and readers. That said, I always thought that the fact that {{Reflist}} did it a particular way represented, in itself, consensus that that's the best way to do it. I mean, the purpose of templates is standardization, right? So if the community wanted it done a particular way, I assumed the template would reflect that. This is the same argument that, when presented to me, led to me ceasing to put <small></small> around citation quotes, as was once common practice — reasoning that if it were supposed to generally be that way, the template would implement it that way. —chaos5023 (talk) 04:19, 30 November 2010 (UTC)
- If there had been agreement to make a broad switch to the smaller font size when the template was created, they would have changed the global CSS then instead of making the template change the font size. That would have been standardization. The fact that the template has to change the font size reflects the original lack of agreement about the matter. Maybe that has changed now; I guess we'll see. — Carl (CBM · talk) 04:54, 30 November 2010 (UTC)
- For my part, I'm saying what I would like to see happen, not what I think consensus is, and I kinda wish more people would do the same instead of invoking vast, nebulous bodies of silent editors and readers. That said, I always thought that the fact that {{Reflist}} did it a particular way represented, in itself, consensus that that's the best way to do it. I mean, the purpose of templates is standardization, right? So if the community wanted it done a particular way, I assumed the template would reflect that. This is the same argument that, when presented to me, led to me ceasing to put <small></small> around citation quotes, as was once common practice — reasoning that if it were supposed to generally be that way, the template would implement it that way. —chaos5023 (talk) 04:19, 30 November 2010 (UTC)
- I, personally, use Reflist over references/. I support either a change to a consistent use of Reflist over references/ or a change to the CSS of references/ so it formats in the same way anyways. Either way would work. I understand the arguments for both sides, but since we should really be supporting the use of more references anyways, which looks much nicer and formats better with a column. So...whichever way is decided on, either method works. Changing the CSS would probably be easier though, I would expect. SilverserenC 03:17, 30 November 2010 (UTC)
Again, I am urging you not to be distracted from the original topic. What brought User:CBM here was this WP:ANI. It's about whether Wikipedia users should be allowed to replaced <references />
with {{Reflist}}
(or vice versa) as part of the standard fixing minor errors process. I said yes, CBM opposed. —bender235 (talk) 12:04, 30 November 2010 (UTC)
- What you're claiming is that there's a consensus to change articles that use <references/> to use {{reflist}} instead. That change is not a minor fix - it changes the style of the references. However, I think you might be right that there's a consensus to make that change broadly. If so, we can do it much easier by simply changing the CSS for the <references/> tag so that it provides the same style.
- That's the point of the proposal here. We have had the two parallel systems for a long time, and maybe it's time to merge them. If there's consensus now that the change to a smaller font size is appropriate wiki-wide, we can change the font size in CSS and not have to edit articles pages to achieve it. — Carl (CBM · talk) 12:43, 30 November 2010 (UTC)
- Please don't derail a constructive debate with your personal issues with the proposer: yes, those issues are highly relevant to the subject, but the proposal, if passed, would neatly make those issues go away. So I've re-proposed this more clearly, under my name. Rd232 talk 13:23, 30 November 2010 (UTC)
Proposal
Let's be absolutely clear: it is now being proposed to change Mediawiki:Common.css so that <references /> has the same styling as {{Reflist}}. This ensures standardisation. If this is done, it doesn't matter formatting-wise which of <references /> and {{Reflist}} is used, unless a page needs the advanced options of {{Reflist}}. All in favour say aye. Rd232 talk 13:23, 30 November 2010 (UTC)
- Aye — Edokter • Talk • 14:03, 30 November 2010 (UTC)
- Aye -- d'oh! [talk] 14:13, 30 November 2010 (UTC)
- Aye.—Emil J. 14:20, 30 November 2010 (UTC)
- Aye cap'n. - Pointillist (talk) 14:23, 30 November 2010 (UTC)
- Aye (smaller size of {{reflist}} is stylistically better & uniformity is definitely a good idea --Errant [tmorton166] (chat!) 14:25, 30 November 2010 (UTC)
- Aye, consistency please. —chaos5023 (talk) 14:48, 30 November 2010 (UTC)
- Aye I'm all for consistency. This has actually bugged me for a while now. --Dorsal Axe 15:03, 30 November 2010 (UTC)
- Aye, aye /ƒETCHCOMMS/ 16:07, 30 November 2010 (UTC)
- aye - Regards, SunCreator (talk) 16:50, 30 November 2010 (UTC)
- no - font is too hard to read. Jc3s5h (talk) 16:53, 30 November 2010 (UTC)
-
- I second Jc3s5h's objection. Although I myself use reflist for its flexibility, it's too small for comfortable reading. You say 100:90, I see 3:2. East of Borschov 19:34, 30 November 2010 (UTC)
-
- Aye Consistency is good and very much desired. Plus, placing this at the CSS level means that people who like bigger refs can update their stylesheet to cover both {{reflist}} and <references/> (and we could now make reference size an option in the user preferences). Headbomb {talk / contribs / physics / books} 18:55, 30 November 2010 (UTC)
- Aye. I hate the 90% font size and all that it stands for, and will immediately busy myself trying to get it deprecated - and yet, nonetheless, this standardization is the way forward for now. One hopes that column support can be built into the bare <references /> eventually so that there will be no need for any separate template. — Gavia immer (talk) 19:48, 30 November 2010 (UTC)
- Aye Once it's standardized, those that feel it's too small can increase it and have it update correctly (perhaps just toss up a simple gadget for an easy, one-click solution). EVula // talk // ☯ // 20:15, 30 November 2010 (UTC)
- MediaWiki:Gadget-NoSmallFonts / MediaWiki:Gadget-NoSmallFonts.css created. I'm bound to miss a few elements; feel free to add. Now to get this approved. — Edokter • Talk • 22:05, 30 November 2010 (UTC)
- Aye This should improve both organization and look of articles on Wikipedia, along with making them follow a standard for how the references look. SilverserenC 20:27, 30 November 2010 (UTC)
- Aye much better. Goodvac (talk) 22:10, 30 November 2010 (UTC)
- Support (what is this, Congress?) Standardization for the win. --Cybercobra (talk) 05:20, 1 December 2010 (UTC)
- Comment: Since
{{Reflist}}
offers more features, why not have a guideline that says "the use of{{Reflist}}
is recommended"? Or at least one that says "in case there are 10+ refs, multiple columns (e.g.{{Reflist|colwidth=30em}}
) are recommended"? Because the columns are the major advantage of{{Reflist}}
compared to<references />
, not the smaller font size. —bender235 (talk) 14:00, 1 December 2010 (UTC) - Oppose. Some people object to the smaller font size. Smaller text for refs is arguably a remnant of the practices and costs associated with paper media publishing, which don't directly apply to web media. Smaller text is harder to read and it de-emphasizes the references. If there are many who find that "the 90% font-size is hardly distinguishable from the regular font-size on Windows", and "consistency" is the goal, one could achieve consistency by having reflist produce 100% font size text. Gimmetoo (talk) 18:16, 1 December 2010 (UTC)
- I'm pleased this point has come up, because I have a reply I wanted to make in relation to it. Basically; in an article the content is the thing of interest to a reader. References shouldn't worry the majority of them; the only reason we place references in articles is for convenience, and mostly for the convenience of editors. The references are there to verify content that could be challenged (or quotes, or contentious material etc.). So, to my mind, it is acceptable to have references at reduced size to avoid reader confusion --Errant [tmorton166] (chat!) 18:26, 1 December 2010 (UTC)
- How might there be "reader confusion" from seeing references, typically in their own section, in the same font size as the rest of the text? Gimmetoo (talk) 18:32, 1 December 2010 (UTC)
- @Errant: I take the opposite viewpoint: references are there for readers first, so that they can use them to dig deeper into the material if they want to use the encyclopedia as a starting point. Disputes between Wikipedians belong on the talk page. I agree with Gimmetoo that the change in font size is a relic from print, but it seems to have become endemic here. — Carl (CBM · talk) 18:39, 1 December 2010 (UTC)
- I'm pleased this point has come up, because I have a reply I wanted to make in relation to it. Basically; in an article the content is the thing of interest to a reader. References shouldn't worry the majority of them; the only reason we place references in articles is for convenience, and mostly for the convenience of editors. The references are there to verify content that could be challenged (or quotes, or contentious material etc.). So, to my mind, it is acceptable to have references at reduced size to avoid reader confusion --Errant [tmorton166] (chat!) 18:26, 1 December 2010 (UTC)
Gadget Proposal: NoSmallFonts
Sparked by the discussion above and suggested by EVula, as well as by past discussions relating to element- and page design, where there is always the few that object change because "the font is too small!", I propose a gadget that provides a one-click solution to those that loathe small fonts. It basically resets the fontsize of those elements, such as navboxes, infoboxes and reference lists to 100%. The list can be extended as I am bound to have forgotten a few. This should help readability for those that have problems with small fonts.
The code is here: MediaWiki:Gadget-NoSmallFonts / MediaWiki:Gadget-NoSmallFonts.css. Those wanting to testdrive it can simply copy the CSS code to their vector.css file. — Edokter • Talk • 02:16, 1 December 2010 (UTC)
Proposal for an information bot
I propose a bot that monitors the RC feed and updates a page at a timely interval (I suggest hourly) with various statistics.
Some statistics I suggest are:
- Number of edits in the previous hour
- Number of new accounts in the previous hour
- Number of new pages in the previous hour
- Number of reverted edits in the previous hour ("vandalism")
- Percentage of reverted edits
- A standardised measure of vandalism information, ideally to supersede the template
{{Vandalism information}}
- Number of Huggle users at time of update
- Average number of Huggle user in the previous hour
and many more such as moving averages, daily averages etc.
I believe that this will give us a wealth of information, which we can use as an example to make graphs showing server load time by hour over the week.
Is the community interested in such a bot, and what further improvements and statistics do you suggest? 930913 (Congratulate/Complaints) 09:53, 1 December 2010 (UTC)