Knowledge:Village pump (proposals)/Archive 129

14711:

banners in general & Valentine's day too. The proposal doesn't take into account that it would annoy loads of people and result in only a tiny amount of traffic. Only a tiny percentage of the people who would get spammed would be interested in using something like that. The money and developer time could've been spent on creating something useful for the community, like fixing phabricator tickets, but instead it was wasted on what seems to be a vanity project. My browser has had the ability to bookmark pages since day one. Normally people create things to fix a problem. This playlist (bad name) doesn't fix any problems and it isn't an improvement over other ways to share a list of wikiarticles. It isn't even an improvement over a list of URLs, because there are many browserplugins that allow you to quickly load and save such lists. "Build it and they will come" no longer works on the internet. You actually got to offer people something useful, otherwise they will leave your website in seconds. Unfortunately I am unable to see the statistics but I am certain that more than 90% of the visitors of that page do NOT click on the awkwardly placed Create a Playlist-button. If you look at succesful websites you will notice that they spend a lot of time and money optimizing their

15704:

that brings users to a page where they can read about edit requests. This still is not an action. From there, the user is supposed to copy the "edit request" template, go back to the article they want to edit, click "talk", scroll to the bottom, then make their post. This is a burdensome chain of requirements. Instead, if someone is blocked they should get an option to make a suggestion with just one additional click. Until and unless we have better infrastructure for seeking contributions from those who do not pass protection, I do not want more people blocked. It is a Knowledge ideal that everyone can edit, and I want some kind of allowance made to encourage more useful contributions. I would rather subject people to lots of reverts and rollbacks rather than prohibit them outright from doing anything. That said - if it were easier for people to post suggestions on the talk page, then I would support this proposal. It is a reasonable proposal for a new kind of page protection based around a new userright.

14461:), but we'd also like the general public to share articles. Since we're launching the Wiki Playlist next week, I thought a Valentine's Day banner of "What Knowledge articles do you love?," with a prompt to create a Playlist to share on social media, could bring some positive attention to Knowledge's content. We'd like to target the banner to English Knowledge in the US and Canada, and only from February 12 to 14 to capitalize on the love theme. I see this as a low-visibility banner — show it no more than 5 times, and to only a certain percentage of users. My understanding from reading through the CentralNotice guidelines on Meta is I should bring it up here, so: I would like to propose this Valentine's Day themed banner run for 3 days on English Knowledge geo-targeted to the US and Canada, promoting readers to create Playlists of their favorite Knowledge articles. -- 9553:

article, then any error of that kind would be evident immediately on preview, as the references would be shown below the text of the article. But if I am editing a section, they aren't. Now I consider myself to be an editor "with some experience", yet I still make syntax errors. So imagine how it is for inexperienced editors? I remember that when I was starting out, reference syntax was by far the greatest challenge. Therefore, my proposal is that on preview of a section edit, there be a preview of the references following the preview of the text of the section itself. I'm guessing that this wouldn't be all that hard a change to make, but believe me, it would make Knowledge editing life a whole lot easier. It would also make Knowledge editing a more accessible activity for newbies.

7810:

for seven years and have the distinct impression (of which I am certain) that the nasties have in fact driven away many good and gentle people. As far as the diversion of human resources, I disagree. I suspect that those who are attracted to education will come here to assist with that function but stay to improve Knowledge when they see a need. In addition, I suspect that the new crew this proposal will attract just might be the type of people needed to improve the population of editors. In summary, what Knowledge needs (in addition to this proposal) are many more adults to watch the kids. Simply having more adults around, I suspect, will prompt the kids to behave. Thanks for considering the proposal.

7890:

out "gaps" in the article is very true. Personally, if I was reading an article and found something lacking or had a question I would prefer to follow the simplest path to an answer via a button on that article. I have enough experience that I am comfortable with the "Talk" page but very few people who come here to simply read are. The editor used fro that purpose is intimidating. As for introducing redundancy, as a structures engineer I believe, "Roses are red, violets are blue, redundancy is good for you." If we didn't believe redundancy was of use why would people buy books, they would simply use the library or if encyclopedias existed before this, then why Knowledge?

9303:

non-encyclopaedic. Are we going to create articles about every major, corporal, general who took part in some war. Are we going to create article about every politician, union leaders who took part in some protests and revolution. Zee money will continue creating such articles. Then editors from other countries will also create articles of every deceased soldier from their country and they will might say if Zee money can create, we too can. I feel nominating them for deletion won't work as people might vote keep. That's why I asked that Knowledge must have a strict rule about biography articles of sportsmen, soldiers and politicians.

8709:, there is a functional "Edit" link at the top. If they edit the revision, it reverts all edits made after the time of that revision. I've done this unintentionally once; I decided to edit the article and simply forgot I was looking at an old revision. I've also seen this done once by another editor. In that case, it probably would have gone undetected had I not noticed the problem three days after the fact. I happened to view the diff and noticed that the edit reverted recent edits that had nothing to do with the edit summary provided. After three days, the edit was un-undoable and somewhat difficult to fix. 6686:

you're viewing 500 revisions, when it's not quick to find all the appearances of your name), or you could sort it alphabetically by edit summary (presumably this would sort by section name first, hugely useful for organizing all the edits to a certain section, as well as tracking when a section name got changed), or perhaps even by the amount of text added or subtracted in each version, so you could see which edits caused the biggest changes. We'll need a Phabricator request to accomplish this, and I definitely hope that we get enough support here to make such a request appear worthwhile to the developers.

8066:. And there never will be—it'd be a colossal waste of effort." Yes, true, and how does that relate to this proposal? "People have built-in preprocessing filters to avoid that." Agreed, but what is your point? "So please, just a proposal, no advocacy." Are you suggesting that I should not respond to insipid and pointless responses? "Figure out why not, try again... later... in a different venue"? I have figured out that there are some very negative people lurking here, it has been one day, and what other venue are you suggesting? Is Village Pump not the place for such a proposal? I am puzzled. 14407:

believe that Knowledge's 15th anniversary is a great opportunity to raise the public's awareness of how much has already been achieved in this area. We see this new tool as a way of paying tribute to the longtime effort of Knowledge contributors (including our program participants) who continuously increase content quality. We hope this social media campaign will also remind people that the world of Wikimedia is not all about drama, but about how we all enjoy improving articles, uploading images, and curating content. We'll be launching this tool in the context of the

15265:- Just curious, should this proposal (which appears to be proposing a form of protection/edit restriction which is higher than semi-protection but lower than full protection) be accepted and implemented, how will its implementation be done? For example: could articles be put under this for long-term periods or indefinitely, similar to semi-protection of articles, or is such an action going to be discouraged, similar to full protection? Can such requests be made at RFPP, or can they only be done via decisions (i.e. ArbCom decisions)? 7941:

feature that enhances the ability of Knowledge to educate is a positive thing. Your blind opposition to any proposal that would increase WP's "complexity" is seems almost like a knee-jerk reaction, that would apply to any and all proposals. At which point you come across in a totally negative manner. Are you seriously thinking about this proposal or some other vaguely expressed idea floating about in your mind to the effect: "It is complicated." I would prefer to respond to critiques that are somehow backed up with real data.

16369:

at the "30-500" level yet but I found this interesting, encyclopedic, neutral, and well-sourced fact about this page. Can someone else add it in?" followed by the proposed edit. Typos, grammar issues, and the like can be done the same way. The talk pages of protected articles have lots of this stuff. The main thing would be making it clear when someone is stopped from editing it what is happening, but something parallel to one of the current protection schemes should work. This isn't so much "support" as

8258:"all" of wikipedia. I only mentioned that one specific example, but that was to show a bigger more critical issue that involves the entire Knowledge space. Just like WP:Village/Proposal and WP:Village/idea aren't for small single-wikiprojects, but for the grander scope of Knowledge. This works well with idea lab especially for reoccuring ideas involving the same subject. WP:VILLAGE policy and miscellaneous are not exactly "help resources". Help desk and WP:Noticeboard are aimed for smaller scopes. 7576:) 19:35, 13 January 2016 (UTC)), wherein a person would be able to easily ask a question about a subject (article) and receive answers from people who volunteer to assist with answering questions about the subject. It is a bit long, so at present I have it on my talk page. Is this page or my talk page the appropriate place for a discussion of that proposal; perhaps I should post it here? I understand that there is a Reference Desk, but that strikes me a less dynamic and convenient then my proposal. 7771:

the argument about resources goes, I honestly don't know how many resources are available. If you know and can use that data to provide a critique that has some solidity to it I would appreciate your effort. Share the data with me so I can respond, but as it stands that argument is simply groundless. I agree that the system seems complicated, but much of the complexity is the result of a poorly thought out interface. A change that actually enhances the education value of Knowledge would be a plus.

13598:

think of a compromise will come out of the woodwork. As for the second point, we could always edit the misuse of warning templates template to include erasing of templates. Just a suggestion. I tend to give editors the benefit of the doubt, and start off with a level one warning, in the case where a level four warning was left, and it has rolled into a new month. Having all of the warning templates for the last month visible would make problem editors, and vandals a lot more obvious.

16085:. I have a feeling that the easier it becomes to restrict users from editing an article, the more this restriction will be used (and misused) to "break the back of a dispute". If this proposal passes, which looks very likely, I urge the community to draft a lucid and strict policy regarding this tool. 500/30 should only be used as a last resort, but without strong guidelines policing its use, I predict it will inevitably become part of the standard dispute resolution toolkit. 16692:

a fast downward spiral of acrimony, tainting the "judges-jury-and-executioners" against the person attempting to defend themself. The only truly viable defense strategy is for third parties to argue the case for the accused. What we have now is a pseudo-legal process in which the defendant has the right to remain silent or to be condemned for engaging in self-defense. This overstates the matter only slightly, as any longtime observer of the ArbCom process will acknowledge.

1463:

down the website, which is why it is only done under supervision of one of 2 sysadmins. This should not be done by 1000+ people, because with big numbers, if it can go wrong, it will go wrong. If admins want to be more helpfull, make it so admins fill in the rename request themselves and post a link to the user's request. Maybe make an admin tool for this. This way the user does not have to go anywhere outside their own talk page and admins can ask for renames. Sincerely,

8109:

furthermore could never be done as well as Wiki editors would like. I'm sorry, nice idea, if we were in a perfect world....but. In my opinion, this suggestion should be filed in the Wiki equivalent of that part of the filing system which no-one ever gets to look at again. Zedshort, be realistic. If your proposal was ever to get off the ground you would have had to have had someone agreeing with you by now. No-one has. I reckon you should just drop it, my friend.

16315:

do without a new usergroup, it would be a kludge that would have required either explicitly listing all pages covered by a topic (e.g., the gamergate filter) or dealing with magic templates/categories that can only be added or removed by admins. Neither are the right technical answer, because we shouldn't be bending over backwards when there's already a clear, simple answer built into the software. Of course, from a policy standpoint, it's probably a good idea, as

16782:, even making rhetorical points, can be adduced as additional evidence by an ill disposed arbitrator. Even comments made in error and self-reverted have been used thus. The purity of an all-open all on-wiki editing community is attractive, but in reality a lot goes on (and has for a long time) in semi-public, on IRC (no public logging allowed) and mailing lists and in semi-private - meet-ups and restircted mailing lists, and in total privacy. All the best: 14427:

the gap between Knowledge and academia in the US and Canada, and our ultimate goal is to improve Knowledge's quality. We're building this tool as a way to highlight on social media some of the great content developed by Knowledge volunteers, including our program participants. More than half of us on staff are content contributors to the projects outside of our jobs, and we all care deeply about the quality and integrity of Knowledge.

13560:, however, it just seems like an unnecessary step that can be prevented if users are prohibited from removing any sort of warning template from their talk page. The user that used as an example above honestly should've been blocked already considering the amount of warnings left on their talk page. The only reason it hasn't happened yet is because the editor removed all warning templates from their talk page. I was even fooled by this 9480:

articles. But, do you also also think all of Zee money's articles are notable? I realize you may be pissed off that you were the editor named in the original post when you've been following the guidelines all along. I'd probably feel the same. But 223.176 has raised a legitimate problem with some of Zee money's edits, which do indeed appear to be problematic – especially the removal of another editor's comments.

14422:

had never used and thought had been disabled (clearly it hadn't!). In reading through the discussion earlier on this page, I see many people supportive of the idea of socially sharing a list of Knowledge articles, which is good because that's what our tool does too! But Wiki Playlist has key differences that mean it should not affect the Knowledge community in the same problematic ways of Gather. Specifically:

8544:; pages moved from VFD to AFD still have links to the VFD titles. And I don't imagine any automation or other script-related work being affected, since they changed the naming convention 6½ years ago; it's not like people are routinely making title-dependent automated or scripted edits to pages from 6½-or-more years ago. I did leave a note at the clerks' noticeboard, however, so they'll be aware of this. 6311:, but as our dependence on Wikidata increases, editors will need an efficient way to watch the data which are relevant to them: Currently, if you enable Wikidata in the Knowledge watchlist, it will be cluttered with label/description/alias/sitelink/multilanguage_string edits for languages irrelevant to the editor. These should be filtered away to show only the languages that the editor is interested in. 8983: 8040:. And there never will be—it'd be a colossal waste of effort. People have built-in preprocessing filters to avoid that. So please, just a proposal, no advocacy. If you don't like the first half dozen responses, don't take it personally—consider it as the product of evolution. You pitched an idea—it didn't gain traction. Figure out why not, try again... later... in a different venue, if necessary. — 16982:. I'm proposing that we expand the system of disambiguation templates so that we officially approve a template for each category, in a manner somewhat comparable to stub categories and templates. The point? It should be easier to maintain pages when a single piece of code transcludes both template and category, and it will get rid of having lots of pages in both parent and child categories. 10288:- categorization is frequently useful. The fact that many categories are disputed doesn't make them a bad idea. Categories help users find topics they're interested in, and they help associate articles on similar topics. If some category is too ambiguous to be useful, it can either be renamed/rescoped to a less ambiguous name, or it can be deleted - and in either case, it would be done at CFD. 12625:

to be due to the fact that I had customized my body text to a font that doesn't support lighter. The lighter text doesn't look as blurry as the grey text does—consider the impact of using grey on sub pixel rendering etc—and still has a similar contrast to the rest of the comment. With the change of font styles also even for computers that don't render lighter the difference should be clear.

6952:

wants to tackle it. Also, while a "selfie" may be outside of scope on commons, the uploader may be able to justify its inclusion there on some other grounds (e.g. "This image demonstrates traditional clothing and hairstyle of people living in such-and-such") which, if argued correctly, could be an educational justification for the image, and may keep the image in-scope for commons.

14715:. Banners to advertise your service are useless if you do not offer anything of value to the visitor. Prediction: a huge amount of people will be spammed, a small percentage of those will click, a handful will actually create a list, and only a couple of people will be return visitors. Don't take my word for it, go ask your local expert, this is how the internet works. 5442:

operator and don't want him to get complaints, but seeing no good reason to need consensus from the community to perform this action, I hereby request community consensus for Hasteur to be able to tell such people to go suck an egg, because this is a simple enough situation that the community doesn't need to grant permission. Final note — all this is separate from

9442:

Bot-like speed) it appears to be Zee money editing while logged out. And the removal of other editors' comments is troubling. 223.176, I don't know if your proposal here is going to get much traction, but you may want to move this to ANI to have the behaviour of Zee money examined if you think administrator action is required (if no admin takes action here).

7789:

faced with. Every new feature adds a degree of complexity to that landscape, adds new elements (words, links, icons) to a page that the user sees, whether they use them or not. In my opinion, that complexity, and the community's failure to require people to behave like adults or leave, are the two main things that drive potentially good editors away. ―

16007:

not very many users use alternate accounts and this would only apply to a subset of editors who edit restricted pages and whose alternate accounts don't meet the requirements. Even then, is the editing so crucial that it can't wait until they return from their travels, get home from work, leave the library, etc. and just edit from their main account?

5604:) to help establish a broad consensus for this so that the proposal has more strength if and when someone complains about the creations. BRFA is such a dusty corner of wikipedia that it is more likely than not that the request will have already been through creation/discussion/approval before someone who is affected by this complains and screams " 16594:

admins wide discretion in its use (one questionable edit by a new user for example). Not sure if it is technically possible to implement, it would require a usergroup for each topic area, storing a list of banned users with the topic area and the end date of the ban, and running an agent to change the group membership when the date is reached.

13436:) are perfect examples of why users should not be able to delete their user talk pages. Both of these users had received numerous warnings for unconstructive edits within the last 3 days. If all of the notices were displayed on the user's talk page, they would have been blocked a lot sooner. Three warnings were left on on day for 128.61.20.111 12222:- A very noticeable difference that makes #585858 more acceptable. But there doesn't appear to be an easy way to test that, I can't readily see how that change would be implemented from looking at the HTML, and in any case I'm not sure what to do at this point with respect to the proposal. In hindsight, this probably should have been at 13721:- I don't understand how you could still have that concern after reading this thread, and in particular the first two sentences I wrote. If any vandal is "under the radar", it's because others are failing to report them. If no capable editor is aware of what the vandal is doing, no change to warnings will make any difference. ― 1541:(though that's not the best example as it's outdated). It's not possible to provide it for all articles, as Knowledge is edited by volunteers in their spare time. Text-to-speech software could be used, but that's not always reliable, and Knowledge doesn't need to provide that, as most operating systems already do. 10057:; if any user makes a rename request, in any public location on Knowledge, such that it is clear that the user really means it, as well as the intended user name and the reason, it should be forwarded. The user being blocked is irrelevant in this case, since we do want the user to have his/her username changed. 9964:. Sounds sensible to me. If the request is put in with a link to the unblock, it should indeed be safe enough. The ideal would be for the unblocking admin to make the request - I just never have done before as I've always assumed they have to do it themselves (as that's what the default unblock template says). 8055:

they fail to explain what that means; or "It has already been done here as Reference Desk," when Reference desk is little used. Believe me, I don't take this personally, but the proposal has been offered for all of one day and attacked by people who cannot articulate what they mean. That is a bit disturbing.

8237:, and probably more that don't come to mind at the moment. If you're not sure where to go with a problem or question, you can get direction at the Teahouse or Help desk; they will either answer your question or point you in the right direction. I don't see a need for yet another help resource, sorry. ― 16691:

One of the contradictions of Knowledge, to insert a bit of Marxist jargon, is the dilemma of a person brought before ArbCom — a pseudo-legalistic Discipline Committee. Multiple people pile on with diffs indicating the bad behavior of the "accused." Point-by-point refutation of these charges can start

16593:

If we want to provide technical solutions to implement ArbCom restrictions, let's first discuss which kind of restrictions we want ArbCom to impose. I would support a system where admins can impose bans of fixed duration for specific topic areas. Let ArbCom decide the topic areas available, and allow

16589:

I beg to differ. This discussion is exactly the place to discuss it: A technical solution to implement the 30-500 restriction will encourage ArbCom to impose it in other cases as well, ignoring the long-term adverse effects. New users being forced to edit topics they aren't interested in will abandon

14710:

Bad idea and bad execution. I do not understand how creating a Playlist of 3-5 Knowledge articles and sharing it on social media leads to our goal: "a world in which every single person on the planet is given free access to the sum of all human knowledge". I hate CentralNotice and SiteNotice banners,

14074:

again because I can't accept the proposal is failed. In my opinion, I support users can enable the Flow beta function. I think WMF should change the policy on Flow. My suggestion is, the Flow beta can skipped community consensus and allow for users to enable in some days (in major language versions).

13704:

Ah, a good point indeed. I'm worried, mainly, about how long these cantankerous editors can fly under the radar until their contribution history until administrators find, and take care of them. I also just realized, also, that it would be a lot of work going through every warning template so "Please

13213:

near the top. I really think folks should try out some options in actual use for awhile before !voting (unless they want to agree with my !vote (7), in which case that's less important ;). The samples at the top are NOT good predictors of the actual experience. By "awhile" I mean like a day or two of

12105:

Trying the setting out on my alt account which I use for UI checks as it doesn't have any other setting / UI tweaks from the default. FWIW, seems to work well enough at least with my glasses and monitor. Note that in addition to the brightness difference the autocomment text is obliqued / italicized

9552:

Although I've been editing Knowledge for four years or so, a thousand or two edits on I still make syntax errors from time to time when typing in references. More often than I care to mention, to be honest. Let's face it, references are always the hardest part to get right. If I was editing a full

9441:

for Cricket notability guidelines. I haven't examined Lugnuts' Cricket article creations in depth, but the couple I looked at from the OP's links above seem to meet the notability criteria. As for 119.118.221.0, based on the similarity of edits (creating talk pages tagged with WikiProjects at almost

7869:

If there is a relevant Wikiproject then they can ask their questions there or in the talkpage of the related article. For your idea, how are people going to get notified of such a question and how will the reader know if there is an editor out there that considers themselves an expert on the subject?

7770:

I fully expect critiques of the proposal, but statements such as "It has already been done" are just plain silly. What is Knowledge but another encyclopedia, many of which existed prior to Knowledge? If the critique that "It has already been done" was sufficient, nothing anywhere would change. As for

6434:

Personally I would not remove any from here as a general move and leave it to individual article maintainers to decide what should be done. After looking at the differences for a couple of years my confidence in the wikidata is very low and needs to be looked at closely before it can be used with any

1442:

It's would not be a lot of work from a technical perspective (perhaps to add the restrictions MaxSem had originally envisioned), but because renamers are now always 'global renamers' (except in case of Stewards, who can still access the local rename facility for very limited purposes and reasons), it

1375:

as the admin was expecting. Since requests made at GlobalRenameRequest are only visible to global renamers and stewards, the administrators that actually do the blocking/unblocking have no idea what's going on. In other words, there is a communication barrier between the administrators that block and

16256:

an edit protection level 'between' semi and full, e.g. where only editors can edit with a 'given' right can edit (including a sensible new right that allows then for that). At the same, I would advocate that we have the possibility to remove the 'autoconfirmed' from editors who have shown that they

16034:. So Arbcom is sensible to the fact that some good editors are prevented from editing by this ruling. Based on this and other comments, I believe ArbCom would have no objection to amend their rulings to also allow edits by manually promoted users (subject to the policy I stated in my original post). 14889:

NAC:There are good arguments both supporting and opposing, but the number of !votes supporting significantly exceeds the number of !votes opposing. Consensus is in favor of implementing this feature, with the noted reservation that it only is to be used with respect to pages where the ArbCom or the

14430:

Playlist.wiki makes no edits to Knowledge. It is not integrated into MediaWiki. You don't even need a Wikimedia account to use it (although you can log in with your Wikimedia account to create a Playlist). This is a reader-focused, social media sharing tool only. Playlists are not saved on Knowledge

14426:

To dispel any WMF concerns starting off, Wiki Ed is an independent nonprofit organization — we aren't affiliated with the Wikimedia Foundation, and we're independently funded. We believe that Knowledge's content should be at the core of what we're all focused on. That's why we run programs to bridge

14128:

of Flow, but there are serious problems with the actual implementation, that I don't think will ever be resolved (even with full support from Wikimedia that it doesn't have anymore). Flow is not like Visual Editor - it's either on or off and an editor that doesn't like it will be forced to use it if

13741:

The reason other editors are failing to report vandals is because they see no warnings on the vandals talk page, leave a level 1 warning, and move on their way. If the vandal is smart, they'll remove the warning, and make no edits for a few days before making another unconstructive edit. Their doing

13597:

I just reported him to AIV, and am currently awaiting a result. You also make a good point about who is going to watch to make sure that warning templates stay on user talk pages, and creating a new warning template. For the first point, I don't have an answer, but I'm hoping another editor that can

13371:

An example such as {{GOCEreviewed|user=Dthomsen8|date=January 2016|issues=awaiting deletion decision}} should be made sortable by user, date, and especially issues. Some of the articles not copyedited some time ago because they were considered for deletion and then kept should be tagged for copyedit

12147:

You're right. The letters are slightly oblique on my alt account—sans-serif maps to Helvetica on this computer. Probably best to have at least two differences between the text segments. shade/tone is one difference. Changing the hue, face, font size or thickness might be another. I'd actually prefer

10729:

Instead of encouraging the undocumented hack, shouldn't we instead propose a change to how the image size preferences work, where, instead of choosing a pixel size for the default, you choose a scale factor to apply to all images? There may need to be a hard-coded maximum above which an image won't

9691:

Thanks for the suggestions, guys. I had no idea of those methods. Similarly, few relatively-inexperienced editors will, and of course no newbies will, either. Which makes, DMacks, your consideration that MW devs should prioritise this (among other things) before pushing ahead with new initiatives

9250:

offers some guidance for suitability of inclusion for soldiers. Remember that they may be notable for a reason other than their military service. However, it appears that some of the soldiers you've listed do not meet these notability guidelines and their articles could be nominated for deletion. It

8773:

being able to edit an old version is also a good way to bring forward partial fixes for older vandalism that can't simply be undone. IE click edit on old version copy the text to be restored out. Click edit on current version paste the text back in place. I've also used in reverse as well to reapply

8054:

I am puzzled. What do you think I should be doing here? Am I simply to throw out some idea only to see the people who have apparently decided that no proposed idea should be considered due to reasons such as "it's too complicated" when they don't explain what that means; or "It's too expensive," but

8017:

Knowledge is an encyclopedia that is destined to grow into something more dynamic and not just a repository of factoids. Central to the idea of an encyclopedia is to present knowledge so that others can self-educate themselves. I am convinced that only a very small fraction of the population is able

7712:

You haven't offended me. I have been on WP for seven years and have developed a very thick hide and solid and tough kernel; believe me, there is nothing anyone could say that will offend me as I have heard it all. I am bothered when people act in a disingenuous fashion and throw up the blue flags of

7679:

by any stretch of the imagination. Please try to respond in a constructive manner with respect to this proposal. That doesn't mean you have to agree with me just don't throw up the blue flags in a random manner. If you intend to blindly oppose all changes to WP I suspect you should not be commenting

7128:

Some of the TimedText namespace content is non-free content but there is no marking at all about this, or any practice to put Non-free use rationales or such things. Again, any such markings can only be put on the TimedText talk namespace. Discussion on whether having non-free TimedText is desirable

6951:

It might also be possible to create a noticeboard, here, where problematic files from commons can be listed. Editors who are interested could then take the next step and make the nomination there. That said, it would take a dedicated community to keep the page from becoming so backlogged that nobody

6051:

Any registered user can create pages which is right, as they contribute to this project, but I think only auto-confirmed users must be allowed to create stub articles (unsourced). When a new user creates unsourced auto-biographies as: "Hi, I am Ravi" and "Mohan Kumar is a 12 year old student from

5947:

In principal, a good idea, but technically challenging. The Mediawiki software doesn't actually have a user group called autoconfirmed; instead, it checks with every edit if the user has the 10 edits and 4 days. Making the criteria more complex would likely slow down the editing process too much. As

5441:

responded with what I inferred to be a willingness to help, but he refused to do anything without a community discussion first, because people are wont to make complaints at bot operators for unilaterally fulfilling even simple requests like this. Of course I understand Hasteur's situation as a bot

1943:

Unfortunately, not many follow this. And i'm covering arbitrary lists. There's lists about almost everything now. the internet has been subject of arbitrary lists, but that doesn't mean that all lists are 'notable'. Having an article to support the notability actually does strengthen the GNG because

1205:

so that they could rename such users themselves when unblocking. Of course, this means that we would drastically increase the number of people who can perform potentially large-scale changes, so I propose that we technically limit admins to renaming new users (with less than 100 edits) only. If this

16762:

My impression is that when AMA was active, most of the discussion was on-wiki, though some of it was by email (I have only a vague idea). I imagine this would be true in the new version as well. I think the idea was to use the email communication to provide a sympathetic hearing (I am just guessing

16714:

How about a name whose acronym is not a match for that of the American Medical Association? (No offense intended to the numerous other organizations having the same acronym, including three other medical associations.) Since Knowledge has users, not members, perhaps Association of Users' Advocates,

16449:

if as mentioned by others "that the protection level may only be added to a page as the result of community consensus or by the Arbitration Committee". Also would be nice to have an "suggest button" that brings people to the talk page with an explanation on how they can suggest changes as mentioned

16368:

As far as I know, any potential edit by anyone (including IPs) can always be taken to the talk page before being made to the article. Without this proposal, it would be simple enough for an editor who could not edit an article directly under this provision to just go to the talk page, say, "I'm not

16314:

answer in this instance, regardless of one's opinion on whether a 30-500 "tier" is ideal. I had actually started looking into dealing with implementing some edit filters related to the 30/500 ARBPIA sanction last month (when I had more time) and came to the conclusion that while it was possible to

16127:

This is something we need for fair enforcement. If arb com wants to use this sanction they will do so. If they do, this is the only effective fair way of enforcing this. (as a personal guess, Arb com would not decide whether or not to use it again, until a suitable case came up. Nor do I know what

15817:

500/30 is only approved for very limited use in areas of extreme and persistent disruption. Simply upping the bar for autoconfirmed would require expanding 500/30 to the entire project. That hasn't been suggested, but considering how difficult it was to gain consensus to use 500/30 even in the most

15703:

I want something else first. When a page is protected to prevent autoconfirmed users from editing, they ought to still get instant encouragement to do something. Right now, page protection leads people to a splash page for reading, but not action. The action that is recommended is clicking a button

15564:

thanks for the explanation. I had assumed that the autoconfirmed group invoked the same code that this new 30/500 group would, and as far as I knew, autoconfirmed still works fine. Is autoconfirmed handled by something different, or is it functional because it was configured before the problem with

14421:

You might now be thinking, "Wait, is this Gather?" — let me assure you, it's not! In fact, my only knowledge of Gather until I came to this page to post this proposal and discovered the discussion and RfC was a vague recollection that WMF had created some article collection tool in their app that I

14271:

If Flow beta function still unable in English Knowledge, I would like to call WMF to change the policy. My suggestion is, the Flow beta can skipped community consensus and allow for users to enable in some days (in major language versions). If the feedback's result is OK, the Flow beta function can

13816:

in about five minutes via this page's archives. Things are rarely that easy to find in my experience, due to various factors such as the limitations of our search engine (Google it ain't) and the fact that a given issue can usually be in any of multiple venues (how many archives can one be expected

12624:

Updated support especially as I commented above that having two differences makes the distinction clearer. Having played around a bit with "font-weight: lighter;" I'm more of the opinion that it would be a better choice then using a shade of grey. The problem I had with testing earlier seems mostly

11836:

I actually think this has a good chance. 808080 is kinda light for accessibility as Earwig points out below. But it's nice to be able to test out different values as well as pick a personal setting if those end up different. It also may be some time before anything changes so if it's an improvement

10445:

talk page about its categories). Both should be used ideally but the category talk page would allow for a little better coordination and routine as to individual articles in a category. That's said I hate the whole people convicted of crimes category structure as a giant pointless mess but that's a

9861:

Since becoming an admin eight years ago, I've periodically seen requests for unblock-to-change-username, almost always left by people unfamiliar with the system, and always thought that the post-unblock part of the system was clunky: this person's new, and yet we require him to post his own request

9799:

I support Boscaswell's call for development work. From the UI point of view, it seems very simple to me: a section preview should behave just as any whole page (preview or saved) now helpfully does: if there's no explicit reflist, an implicit reflist is at the end of the displayed content. I'm sure

9432:

do you have any reason to believe 223.176 is socking, or editing while logged out to evade scrutiny? If so file an SPI, but he has a valid point – at least where Zee money is concerned. Some of those articles don't appear to meet the current MILHIST notability standards. As to Cricket articles, see

8507:

Sounds useful. Can you estimate the total number of cases to be moved, and the total number of incoming links to be fixed? Will you proceed to change links that occur in the body of Arbcom cases, or in the ANI archives? Will you leave links in the old case locations? Some of the Arbcom clerks might

8198:

this may seem minor, but if put the example of what I believe is an issue, is having dead or not so strong wikiproject to key articles people visit often. I've been attempting to work on WP:Comics but not gaining any traction due to less than supportive (but clearly existent) community. But I don't

7889:

I have posted the proposal on my Talk Page as I was uncertain as to where to post it. Is this the appropriate place? I don't know how to respond to the point that "Reference Desk already exists." Is the Reference Desk heavily used? Is it convenient? The idea that people asking questions would point

7809:

Thanks for a more solid response, I really do appreciate it and I am in alignment with you on most of that, and in particular the idea that "the community's failure to require people to behave like adults or leave, are the two main things that drive potentially good editors away"." I have been here

6826:

Many school kids/non-notable people upload selfies in commons and come here to create their auto-biography. The page is deleted but in most cases the picture remains in commons. Administrators can have the right to delete the picture uploaded in Wikimedia commons, even if they are not administrator

6721:

Not quite sure what you mean. A button that, when clicked, causes all the edits by the most frequent editor to appear at the top, then all the edits by the second-most-frequent editor, etc.? A mere alphabetical order/numerical order sort, if applied to multiple columns, would have the same effect

1462:

All accounts nowadays are global and a rename would be for all 800+ projects. Adminship on one project does not mean you understand all other projects. Furthermore, giving such an ability to 1000+ unexperienced people is not a good idea. For example renaming someone with alot of edits wrongly could

16697:

For myself, I have acted as an informal advocate in a big ArbCom case and in two or three subsequent "clarification" hearings. I feel that there was positive benefit to the project through my participation, that in all likelihood a prolific content contributor was saved for the project at least in

16052:

I still think we need the committee as a whole to make an amendment to their findings before we allow administrator discretion. If they do choose to amend it, it would be worth asking if it's easier to just revert the problematic edits of those who don't meet the requirements rather than having to

16006:

As it's written, it allows admins to grant this right to whomever on the basis that they're "good contributors". The criteria of being a good contributor is subjective amongst admins. I don't feel comfortable with this part in place. As for alternate accounts, is it necessary? From my experience,

14434:

Playlists are not findable unless the creator shares them on social media, and then they're only findable if you click through from that person's social media post. The home page of playlist.wiki is a hand-curated list picked by Wiki Ed staff; otherwise the only way to find others' playlists is by

13840:

is good reading. Every item on there has been brought up literally dozens of times in multiple fora for a decade. The community has rarely budged on any of them. I know that not every newish user would have been involved in these discussions. I apologize for my exasperation; but this makes the

11815:

Tell ya what ... if this proposal fails, I'll assume I'm the only one who has the problem or ever will, and I'll try your suggestion. For now I'm assuming I'm not so unique, and I'm interested in the overall welfare of the project, not just myself. I've found many people have trouble grasping that

11732:

It was proposed below (quite rightly in my opinion) that a switch in font, between italic and roman (regular), is at least as noticeable as a difference in darkness, so new options were added for that. Both 5 and 6 include such a switch. And there's a possibility of a 7 that would be the same as 6

9461:

meet the notability criteria. Every single one of them. Again, if anyone has issues over any notability criteria, I suggest they raise them at the relevant project's talkpage, rather than fishing here. I make no secret of the articles I've created - they can all be found from links on my userpage.

9273:

And the fact that there's not been any complaints or deletion nominations proves nothing about policy whatsoever. With over 5 million articles here, sometimes stuff that is questionable doesn't draw attention for months or years. The IP editor has obviously noticed and if he is concerned he should

8257:

The idea isn't exactly a "help resource" but a place to make issues "known" in order for that help to get reached more effectively. There's a reason why i suggested a new section for Village Pump. Although it is closer to a noticeboard, this is a place to cover broad, general issues that encompass

7940:

Sorry I used the structures analogy. I should have pointed out that there are bottle-necks in the education system that people have been attempting to widen for decades but to little effect. One solution to a bottle-neck is to build a path around it. Knowledge is one alternate path to education. A

7904:

I don't think all that should copied to this page. This discussion serves as your proposal, the contents of your talk page is reference information. A user subpage would probably be better suited to the purpose than your talk page, however. Eventually this discussion will be archived and it should

7788:

The complexity I refer to has more to do with the mind-boggling morass of overlapping, unnecessarily complex, confusing, overly verbose, and often contradictory policies and guidelines created by a cast of thousands with no central coordination or control, and it's all part of what new editors are

7424:

It's possible to add warnings about an associated TimedText when moving or deleting files. As for adding a doc to TimedText, it would indeed require code changes, but there doesn't seem to be a phabricator request for this. We should probably open one as this would alleviate copyright concerns. As

6685:

I strongly agree — being able to sort the history, whether by page revision size or by some other criterion, would be quite helpful. Imagine that several different criteria were sortable: you'd be able to sort it by editor to get all the edits on the page that you'd made (particularly useful when

6129:

There have been battles between proponents and opponents of Wikidata on whether we should use directly their data in the template. One strong objections, which I do not necessarily agree with, is that requirements for reliable sources in Wikidata is currently weaker than our requirements, and many

6100:

In practice, if the community as a whole focused on it for a few minutes, all of those questions could be resolved. With respect to articles not yet existing, it is perfectly appropriate to change a disambiguation link into a red link pointing to the title that should be occupied. Doing so informs

6085:

In theory we could, but not in practice. I've had some fun fixing several links (it's a handy tool), but many of the DABs require either an expert or perhaps even the original author to understand what was meant. And, in many cases, there is no appropriate article to link to (yet) so the fix would

15044:

Also, we can give the userright to edit these pages to bots and sysops, and prevent them from being given automatically the new group which would then be redundant (using APCOND_INGROUPS). We'll have to find a name for the usergroup, and the protection level (maybe 'restricted' ?). For example of

14791:

I reviewed sitenotice history and looks like we haven't done anything like that in the last decade. The few times external sites were put on sitenotice more than a decade ago it looks like consensus was that it should not have happened. In this case it would raise particular confusion, making the

14759:

Looks pretty cool, althoug how to have the site notice reflect the third party data collection may require some thought. On first hit, the following are accessed by a browser: CloudFlare, Amazon, Google, New Relic, Twitter, and Facebook. On first playlist click, wikiedu.org's stats server is also

12639:

Hm, I'm not so sure about that. I definitely see what you're going for, but AFAICT the italics are not an accessibility issue. Is it only so the autocomment remains clearly differentiated? I'm not in love with the look of roman text for edit summaries, but I can live with it if that's what people

12037:

Switched to #7. Would prefer #6 but that doesn't seem to work in all cases. If there was a way to use just lighter ( inheriting #252525 ) in browsers that supported it and fallback to #585858 in other browsers that would be my ultimate choice. But again I support anything that meets accessibility

10962:

When comparing old versions of an article via page history, it would be quite useful to be able to directly edit the current version of a page (e.g., in order to restore something which has been inadvertently removed from a page several edits ago). Yet if you click edit, you are presented with an

8084:

have to do the work to get other people interested. No one is going to sell it for you. "Are you suggesting that I should not insip and pointless responses?" Yes. There are questions you must answer. Work until you are not puzzled, make another try. No one is evidently going to do it for you. You

6976:

3 ways of slicing the same problem : I want to be able to view subsets of my watchlist by topic areas. Either having multiple lists, or being able to apply tags to items in the list, or being able to select a category, and view only items that are in that category (including subcats!) would be a

16107:

topics. Currently, it's a free-for-all with the rather silly situation that an edit that contravenes the 500/30 restriction can be reverted without limit. This proposal is suggesting that more sophisticated technical procedures should be implemented to reduce uncertainty and edit warring, and to

10768:

Upright is the victim of an evolution in technology and in the community's thinking about image sizes. I haven't been involved in a lot of it, but there has been a ton of debate about image sizing (and our software support for it) over the years. The status quo reflects the current consensus, or

8464:

for an example of this situation's problems; the links all refer to real cases, but lots of them are red because of mistakes I made when compiling the list, due largely to the conflicting naming conventions. And like in any other situation, the enforcement of a single naming convention makes it

7605:

There are many very, very mediocre Q&A sites and Knowledge can do something more than they can. If there are other sites it does not follow that Knowledge should not try to improve itself, and I am certain that this proposed change would do just that. Have you read my proposal? Please try to

6247:

PS. I am not aware of any previous discussions of this topic; I will appreciate links if appropriate. PPS. I in principle intend to advertise this as RfC, however, I would like to wait for a day for comments before adding the template - possibly the issue has been discussed already, or some good

14767:

This looks nice (I especially like that, unlike Gather, this tool attributes images, so it can be used to help advertise Free Content). I think we could help advertise this, but I feel the sitenotice (which should be used sparingly) is a too prominent place for this. We should not advertise any

14406:

would like to run a Valentine's Day themed CentralNotice banner on February 12–14, geo-targeted to the United States and Canada, to feature Wiki Playlist, a tool that enables readers to share their favorite Knowledge articles. Our organization is focused on improving Knowledge's content, and we

14205:

if anyone wants to look it over or make suggestions. I'm tempted to just post it as a followup to this thread, but there's no rush and I think it may be better not to hit the WMF with multiple negative RFCs at the same time. From what I've seen Community Feedback on Flow has generally been very

12651:

To really get into the bike shed I think I might have the section link be roman and the rest of the comments remain italics. Means the comment the the editor wrote is the only thing in italics... everything else including the name of the section which might have been named by other editor is is

11936:

While I couldn't see any difference between the different options until I zoomed in, Earwig makes a good argument for changing the colour for accessibility reasons. If this is indeed the case, however, I'd have thought that this should be a central change rather than simply changing it locally.

8350:

The Wikimedia Foundation (WMF) has launched a consultation to help create and prioritize WMF strategy beginning July 2016 and for the 12 to 24 months thereafter. This consultation will be open, on Meta, from 18 January to 26 February, after which the Foundation will also use these ideas to help

8013:

Why is this not a "question and answer place"? Has there been some discussion about that that has resulted in a solid consensus and a guideline (a temporary rule waiting to be broken)? It seems that in order to get a real discussion of a proposed change, I must first run a gauntlet of knee-jerk

7785:

Sorry, no hard data. It's intuitive to me that few people would come to Knowledge just to answer questions. That means that, for the most part, any time spent answering questions would be time not learning policy/guideline and contributing to article content. That's what I meant by diversion of

6402:

Numerous articles have more than one link to Commons using different targets so removing the information from the article should not be done globally. Several categories on Commons do not exactly map to articles here and so the wikidata entry does not map to the article or to Commons correctly.

1635:

and millions of websites. They are not a "misrepresentation of wikipedia", and to "demand a right of reply on their site" is not how the Internet works,. We sure as hell aren't letting Conservapedia get a right to include their point of view in our articles. Free speech means you have to accept

1561:

I have just become aware of the existence of this site - so of course I went to the wikipedia article on Conservapedia - excellent. I am surprised though that wikipedia are not more proactive in destroying this gross misrepresentation of wikipedia - open knowledge. To ignore Conservapedia is to

14096:

a couple of days ago but might not have noticed the mood there: there are plenty of websites where people can chat, and Knowledge need not provide another. The suggestion that people use one set of procedures for editing an article (the reason we're here), and a different set of procedures for

10835:

Note that this is also a concern with developers. Basically, we added scaling functionality to upright as a value to that paramater, but that was 'incorrect' in hindsight, likely it should have been two paramaters like "upright" and "scale". We've been talking about how to fix that for a while

9479:

Lugnuts, I have no doubt that the articles you created meet the notability guidelines – as I said previously, the two I checked certainly seem to be fine. And I believe your assertion that they all are notable. If you look at what I've posted above, I've never questioned the notability of your

15786:

topics and it has very successful at reducing disruption. One problem is that editors are authorized to engage in silly edit wars and can repeatedly revert edits which don't satisfy 500/30. It would be much better for the software to be enhanced to avoid that turmoil, and to avoid klunky edit

14858:

As the proposer, I’ll withdraw the proposal — it’s not worth continuing to draw volunteer attention away from other higher priority items for something that’s clearly heading toward consensus to oppose. Thanks everyone for your consideration and for the feedback on the tool itself — it’s much

14690:

I don't think we routinely promote projects/extensions etc in this manner. While I have a limited degree of sympathy with a desire to do so, conflating it with Valentine's Day is plain old dumbing down. There doesn't seem to be any logical connection between 14 February and the purpose of the

7873:

If you could explain why we need this over Reference Desk/Wikiproject/talkpages? However, this sparked an idea where people can review articles and ask questions based on any particular "gaps" that could work well for a "ask a question". Something that if someone was looking into improving an

7620:

Sorry, I don't mean to be brusque. I think your proposal is a very good one, and it would be a very good start if it were a good idea in principle. I think it's fundamentally a bad idea, however. Like the Unix principle of having small discrete items of software to do discrete tasks, websites

16349:

that's ideally solvable with this form of protection, I'm almost certainly not going to jump through the hoops of extra consensus-building and request-filing; either I can quickly add protection, log the remedy, and move on to the next report, or I'm simply going to keep scrolling and/or use

13520:

but the same applies there (and you're expected to provide diffs of the disruption there). In any case, how likely is it that a vandal is going to observe a Knowledge policy about non-removal of warnings from their talk page? Are we going to create a new template for warnings about deleting

13141:

Yeah, just wondering about political ramifications. Other wikis saying, we agree there's an accessibility issue, but we weren't involved in choosing the best solution to it and we don't appreciate having the choice forced down our throat, yada yada yada, ten people astutely offer ten better

8108:

Good grief! Sorry, Zedshort, but I have to agree with everyone other than yourself here. There's more than enough for Knowledge editors to try to do without adding what would be a phenomenal amount of extra work. It would detract from the work that needs to be done on Knowledge itself and

6505:

subpages. This was the "namespace" previously designated for non-confirmed editors to create drafts, but that has since been replaced by the "Draft:" namespace. However, I just found out that non-confirmed editors can still create subpages of "Knowledge talk:Articles for creation/" as shown

1145:

Account rename are now out of the remit of local Knowledge projects and have been moved entirely to Meta after the Globalization of accounts. Admins can already apply on meta to become renamers if they wish to. There is nothing Enwiki can decide by themselves with regards to global renaming

16344:

be up to an admin to add it on their own cognisance so long as it's within those specific topic areas (or otherwise has clear consensus) and it's not done in bulk (i.e., it should be in response to an issue that's arisen on a page). I mainly say this because when one inevitably pops up on

13451:

I'd like to get your opinion on this, as well.), who also left a level one warning template when the IP editor vandalized Knowledge previously in the day. Being able to remove warning templates allows vandals to stay 'under the radar', so to speak. This editor was also given a wrong level

9302:

non-notable article created by Zee money. Zee money creates article about deceased soldiers and politicians almost everyday. New page patrollers ignore as they are dead. They also assume that non-English sources might be available. There must be 200 articles created by Zee money which is

10643:

The example linked looks to me like a case where some people were discussing what the scope of a given category should be. I don't know if it should be a paradigm (no obvious consensus seems to have emerged), but it looks like things are working the way they're supposed to, more or less.

10867:

This is more of a concern for Wikimedia Commons, but it would affect English Knowledge too. I am seeking comments and hopefully endorsements on a draft request to the Wikimedia Foundation for grant funds. Opposition and statements of doubt are also useful. If you like, please comment at

9874:

I understand the system pretty well, unlike the new person who's trying to figure out how to participate at this website after such a rocky start, and the new person's already submitted a good request for a new username. Shouldn't I go ahead and help the guy? And perhaps alternately,

8199:

know how I can fix it. And I don't think I can come up with a good idea. But this is too specific. It can fall under a category. There could be plenty of issues people have but don't know how to fix it. Since there isn't a place to highlight issues, we can't really follow up with them.

1582:

Plenty of people and organizations complain about Knowledge. I can think of many that are far more consequential than Conservapedia. Most people don't even know it exists, so I think the best response is to maintain scrupulous neutrality in our article about it and otherwise ignore it.

10161:

Articles can be disputed too, so let's get rid of those. Seriously though, does this originate with the issue that categories don't need to be sourced to reliable sources? Maybe disputed categories could be required to be sourced, on the talk page and/or commented out in the article.

1562:

ignore creeping detestablity - 1933 et al. Just as we are proactive in ridding wikipedia of sockpuppets, vandals and such, I believe we should be equally proactive in identifying and isolating such perversions as conservapedia. Perhaps we could demand a right of reply on their site.

6009:

headcases, it won't stop them. I've dealt with these folks a lot. They are more than obsessive enough to jump through the hoops and game a requirement like this. Given that it could discourage good-faith new users without having the desired deterrent effect I just can't support it.

12935:

look almost identical to me, but the version using 585858 has blurrier letters. But I'm guessing that normal and lighter look the same in your browser. Guessing Arial Light and/or Helvetica Light are not standard across all computers. I would support such an option 7, added above.

9653:

There are some interesting corner cases for actually getting this feature, but at least some implementation of it has been in a backlog of patches for many months now. Maybe MW devs should do a code-sprint on clearing all that out before pusing ahead with so many new initiatives?

6923:

Commons users check new files but it isn't possible to mark them patrolled like new pages. It will change very soon: probably next week it'll be possible to patrol files on Commons and at enwiki (both new files and reuploads). It will be possible to show only unpatrolled files at

11969:- All other displays of edit summaries appear to use the same class "autocomment", so I assume this would automatically extend to them as well. This includes contribs and watchlist. This is probably a desirable thing, but it should be stated since I didn't do it in the opening. ― 14632:

from WMF to get us going, but once we got external funding, we returned the rest of the unspent money from our starter grant, so we haven't used WMF money since March 2014. The funding for this particular tool was a grant we received from the Simons Foundation in support of the

13470:. Had no-one checked, which editors tend not to do, this vandal could have sunk back into the shadows, both evading a necessary block, and an opportunity to vandalize Knowledge continually. People that are clever could pick up on this quick, and abuse it until it is dealt with. 1350:

Hello, I'm the first non-admin global renamer (to my knowledge, at least), and thanks Xeno for pinging me. I don't think this proposal will go very far, because as others have said, renames are now done globally by global renamers and stewards, and they require knowledge in how

16198:

with the understanding that this would strictly be a means to more easily and fairly enforce relevant arbitration decisions, and not a new form of protection that any administrator could enact on any page. However, per Mike V, allowing administrators to discretionarily promote

14743:

We have run such banners before (e.g. for Wiki Loves Monuments and after the launch of Wikivoyage), but this arguably makes more sense in the context of a larger publicity initialize. (And this proposal seems to have a deadline that is way too close to get proper consensus...)

7621:

shouldn't try to do everything for everyone. Questions and answers are very hard to do well and I don't see that we need to duplicate that here, when there is so much to be done in terms of building an encyclopaedia. Fundamentally, your proposal is contrary to one of the major

5948:

a result, the software would need to be rewritten to use an entirely different concept for granting the autoconfirmed right. Probably by adding a user to the confirmed group when they hit that magic edit, so it only has to check for the user right and not the actual criteria.

12710:

Was more worried that I was getting close to bike shedding myself. Does the font-weight: lighter work for you? Seems to work on all my browsers once I switched the class of the text to more like what would be on a history page instead of inheriting body text customizations.

9755: 16483:

so; it's a desperate measure taken as a limited-deployment experiment. Doing this at the software level artificially ossifies these choices before we've actually finished and evaluated the experiment. In any future userright implementation, I'm not too fussed about admins

13515:

the radar. The person doing the reporting can mention that the user deletes warnings, but I don't think that's really necessary. Any admin handling AIV reports very likely knows enough to check the talk page history. If it's disruptive editing, not vandalism, the place is

14435:

looking for them on social media sites. This significantly reduces the reach and visibility of problematic Playlists, although we do have a Wiki Ed staff person who will review any Playlist flagged to us as inappropriate or otherwise in violation of our terms of service.

16671:. It has been ten years since it was discontinued. Knowledge is a much different place now and perhaps it is time to give it another try. Comments are welcome, as well as suggestions on how to proceed. How exactly does one revive a historical Wikiproject, for instance? 12084:

to try it in actual use for awhile. Does it always provide enough contrast between the section title and the rest of the editsum? Or do you sometimes have a little trouble seeing where one ends and the other begins? I don't wish to solve one problem and create another.

8159:

I propose a new section for Village Pump called "Known Issues" where people report anything (non technical) that anyone feels needs attention to but doesn't know how to solve it. The most common issue will be placed above in a new box (similar to FAQs) in the idea lab.

14734:. While the website is Gather done correctly, we don't do these kinds of promotions per Sitush. I would suggest getting in touch with the Reading Team to migrate the existing collections over and work with them and us to find more appropriate ways of integrating this. 14129:

you change your user talk page over (which is one of Flow's fatal flaws). The solution is to implement the one-page-per-topic structure of Flow on our current talk pages and then to create a talk page visual editor. That way, anyone can opt out simply by not using it.

5983:

edits for a checkuser to identify multiple accounts created by the same individual (subject to the usual magic-pixie-dust caveats of checkuser). Short- to medium-term sleeper accounts which have stayed clear of trouble areas are no easier to detect under the proposed

10603:

I think this is a case of 'I've never used it- can't see what the point is.' For ten years I never searched on one, then while training I was asked questions about an unfamiliar area and I dived into the tree. Still can't think of another approach for that situation.

16350:

something less effective and let someone else deal with it if they really want. :P Granted, this is just me talking, but I have a feeling that the sentiment will be similarly shared by other admins strapped for time who otherwise avoid ARB venues like the plague. --

14565:

Just responded to the fair use question above. About the geography, Wiki Ed operates only in the U.S. and Canada, which is why that was my geographic request, but if community members in other locations would like to use the tool too, I'm happy to expand the reach.

13443:. After they were erased, it was as if the user was never warned. I understand it is the user's responsibility to check the user talk page log, but it is a tedious task that is rarely ever done by editors. One of of the warnings that was left was an Administrator ( 10355:

Like 'List of xxx' pages, Categories are indexing - or possibly are thesaurus-like (not the same but nearish). Search looks for fairly close matches for a word/phrase. Lists and categories group things that may not be close in name, but have a relation in subject.

5908:

Maybe a good idea, technically impossible with the current MediaWiki setup - this would require and extension or edit filter. The former is a lot of work for little gain - the latter there is no consensus to use, and would be very very expensive and unsustainable.

14629: 6574:

Talk pages anywhere can be created by anyone. If someone recently created a subpage of WT:AFC, it might be because some old project page still references WT:AFC and should be updated. You may add a warning about WT:AFC being deprecated in the group editnotice, at

1187:

It keeps bugging me that we're not being newcomer-friendly enough when we first block them for bad username, then force them to grok templates to requests an unblock (easy as it may sound to us oldies, I see a lot of people experiencing problems even with simple

10967:), which does have its practical advantages. Surely it would be possible to add a link to this "old version" editbox which would take you to an editbox for the article as it currently is. All that would be needed would be to change to text in the pink box from: 8361:

Apologies for English, where this is posted on a non-English project. We thought it was more important to get the consultation translated as much as possible, and good headway has been made there in some languages. There is still much to do, however! We created

14881: 10884: 5706:— a potentially controversial set of changes needs to get community consensus from some sort of discussion, but with simple fixes, there's no need to have a discussion, so (to pick the first example from Special:Recentchanges) nobody's going to complain at 5849:

The proposal is not about making unprotected articles semi-protected (is this what you meant by spp?), but about making fully-protected articles semi-protected, so it has no influence on anonymous editors. Anyway, I don't like double autopromotion either.

12170:. Doesn't look like weight renders properly which doesn't surprise me as it requires a font with a thin or ultra-thin weight. Edit: Works if I specify the font family (Helvetica, Arial, sans-serif) which is similar to what Knowledge uses: color (#585858) 15742:

the idea, with the obvious caveat as to whether this is technically possible. Questions as to whether this kind of protection is a good idea aren't relevant to the question of whether we should do this, as that decision has been made by other processes.

7916:, if not worse, so to my mind a new feature has to be more than "nice to have". Given that RD already provides ~75% of this benefit, and given that both are outside the scope of Knowledge's main mission, I consider your proposed feature a "nice to have". 7741:

RD may be less dynamic and convenient (and many don't even know it exists), but it gives fairly good answers (or assistance in finding good answers elsewhere) considering their price (0). I can't see devoting developer time, and adding complexity to an

6510:. I believe that the ability for non-confirmed editors to create the aforementioned subpages should be disabled. In fact, at this point, the only major reason why the aforementioned subpages should be created is if s draft needs to be recovered via the 10199:

Yes, the scope of categories can be ambiguous too. I feel that categories are useful for navigation and sorting, both for readers and editors, but there are weaknesses especially related to bios and any area affected by strong and conflicting agendas.

6086:

require extensive writing. Still, every bit helps, I guess. I wasn't aware of that page and I thank you for the pointer. If I'm reading the list correctly, we're now at 42, but many of those have also been fixed up (but not refreshed on the list yet).

10305:

Categorizing is vital for navigation. Having said that, articles can be over-categorized: having dozens of categories on an article can be time consuming for those who need to add them, as well as a distraction from the wider content within articles.

15399: 11076:

There is no technical issue with that, if I'm reading this right, the additional text would just go to the same target as pressing the EDIT tab at the top of the page, is that your intent? If so please work up what you want it to say and propose at

10416:, because categories are an absolutely simple method of organising our articles. Yes, they're often used in a problematic way, but that's not a reason to throw out the baby with the bathwater. If there were a fundamental problem with the idea, the 5714:

without getting approval first, because it's a simple fix, and nobody disagrees with ordinary spellchecking. In the same way, when it's practical to use a bot to perform ordinary housekeeping, you shouldn't need approval before going through BRFA.

16825:

to overhaul the Knowledge healthcare system. Just kidding. Perhaps it is best to start a new Wikiproject with a new name, rather than use the older one. Since I have little idea of the details of the old one anyway. ACA seems as good a name as any.

16565:

from a technical perspective; if we're going to do this, this is obviously the right way to do it. I think that some of the concerns people have raised above about potentially using this sort of restriction too frequently are well-founded, but we

14368: 13126:

Core means a dev; there are more volunteer devs than WMF devs, but the WMF devs are likely to be involved (at least in approving the change). Also, doing it in core means that all future MediaWiki wikis would benefit (e.g., private wikis, too).

7907:

In my opinion, most of the solutions that justify increased complexity have already been implemented. In the software world, this is called a mature system. This is why I tend to oppose most new features that add complexity for most or all users.

14965:

To resolve these issues, it is proposed to create a usergroup that is autopromoted after 30 days and 500 edits, and a new protection level, so that only users in the new usergroup can edit pages subject to this new protection level. In addition:

1503:

this would help ppl who want to learn the language (I myself regularly use wikipeda to practise languages im not fluent in by reading the articles in both the foreighn and my native language) and are struggling with pronouncing certain words. :

16548:. See the verse on my user page for an explanation of my concerns. I think this will put us yet further on the path to shrinking the number of editors as this "you must be this tall to edit" set of restrictions creeps outward over the years. 13636:

Btw your vandal has been blocked for 31 hours despite removing warnings, see how easy that is? If they come back and start again after the block expires, repeat. The next block should be longer than 31 hours, maybe 3 days or a week. And so on.

1146:

procedures. There is no way Meta would accept to let all enwiki administrators become global renamers (because local consensus at an RfA is largely insufficient to be the sole basis of granting global rights), but in any case such a discussion

13286:

That just means you can safely remove the "span" from the "span.comment". "Over-qualification" means you have made the selector too specific, which down the road can cause minor issues when you go to override the CSS through some other means.

11837:

for you now why wait? While I supported a higher contrast grey below its likely that I would personally use a lighter color for my own CSS. I heavily tweak the appearance of the watchlist and history to make it easier for me to history drive.

9522:

The articles created by the other user don't look notable to me, but then again, I don't know anything about the notability requirements of the Military history project. The main issue is that most of them have no sources whatsoever. They all

1443:

is required that anyone who wants to use the global rename facility apply through meta so that users from all projects can comment on the suitability of the request since they will now be acting at some times, on all projects simultaneously. –

13783:. If they have read it, they have read it and don't need to keep it. If it is a shared or dynamic IP, and it wasn't intended for them, it doesn't need to be kept either. There is no conceivable reason why a user should be forced to wear a 12855:

No detectable difference between lighter and normal, and I put the two in separate tabs and toggled between them. And I added color 585858, since I feel we still need some color difference between the two halves. The more I look at that (see

8711:

When this happens, there is no indication in the page history that an old revision was restored, only the edit summary as entered by the user. Thus, it can easily go undetected unless the diff is closely examined and compared to other recent

15959:

on one point. I disagree with admins being able to promote a user based upon their own discretion. You either meet the restrictions imposed by the arbitration committee or you don't. The community isn't able to make exceptions to this rule.

13185:. When working on a laptop in bright light, option six is very difficult to read, and option seven is indistinguishable from the plain black text. Five is also pretty close to black in those conditions, but at least the italics separate it. 9078:. I can imagine the mistake being done, but forcing me to (View Source, copy/paste it into the edit window, and save) is a real waste of time, and it would be unhelpful in the numerous situations that reverting several edits is necessary. 16492:

by individual admins - unbundling has already resulted in the routine wiki-activities of many users becoming much more exposed than it used to be to the vicissitudes of "admin discretion", and this would be way too much of a drama magnet.

6004:

While I understand and appreciate the intention here, I don't think it will have the desired effect. This would stop impatient schoolboy vandals, who are mostly stopped by the current low threshold. If the target is disruptive trolls and

1901:

I propose we make a rule that any arbitrary list regarding media, fictional elements, or anything similar to that needs to be accompanied by a full-length article covering the notability of the subject. For example: There is currently a

16031: 8018:

to self-educate, in particular young people. We need to open this up just a bit wider to make Knowledge a real success. We have a compilation of facts, now it is time to breath some life into the project. Otherwise it might slowly die.

5975:

Further, how well does this solve the (somewhat ill-defined) problem? Again speaking from my experience, it strikes me that the most pernicious block/ban evaders will just move their most obnoxious behavior to pages not under full- or

14292:

Hello! You are correct: the WMF's policy on Flow is stupid. Flow was a bad idea and they have stopped working on it. In its current state it is completely unusable. It will take a lot of work to repair the damage that Flow has caused.

14985:

Although this was inspired by ArbCom, this is strictly a community proposal and community consensus is required for these configuration changes. Moreover, the community has repeatedly showed interest in such a system, see for example

9879:. What if the unblocking admin forgets, for example? Aside from a typo, there's no chance of submitting the wrong username, and as long as a diff is provided, we shouldn't need to worry about someone faking someone else's request. 9456:

A "new" editor who's first edit is to question long-standing notability guidelines by forum shopping on this messageboard? No, why would that raise any suspicions?! And my articles don't "...seem to meet the notability criteria" they

16479:. The thresholds being used for these restrictions are essentially arbitrary, and we don't have a strong evidence base yet that they are well-chosen. Implementing this as an edit filter is a kludge, but it has the advantage of being 14143:

I would like to cite the Chinese aphorism: Lagging behind leaves one vulnerable to attacks (落后就要挨打). The English Knowledge is the largest language version, so English Knowledge should to enable Flow beta function, as same as Chinese

11466:- I found that the differences are more noticeable if you (1) apply a user CSS change from the collapsed table below and (2) look at actual page history pages. I recommend doing that and trying the change in actual use for awhile. ― 6454: 6386: 5693:

If everyone exactly agreed with me, the following situation would be explicitly permitted: you're a bot operator, and suddenly you observe a group of articles that largely lack a group of related-title redirects (in this situation,

12689:

at all. I'm for doing the absolute best we can, even if it means ten options or starting over with a fresh proposal. Most editors look at this so much that seemingly insignificant improvements add up to something very substantial.

10480: 5491:. I agree with the changes, but keeping in mind several previous editors who went through creating many redirects in such a way that it was precieved as bot created/bulk creation, I wanted to hear a positive consensus to do this. 11142:'s suggestion, I usually try to imagine the link text without a link; does it still seem appropriate? Without a link, "Edit the current revision" looks like an instruction, an imperative. Suggest the alternative: "You may wish to 16570:

using it in several places already, and it seems silly to do it in a confusing, technically-inefficient way. This discussion isn't really the place to focus on whether or not using the 30-500 restriction itself is a good thing.

15453:

Given that the I-P and GG topic areas are populated mainly by entrenched people who have a strong COI on the subject that edit such pages relatively rapidly (which contraindicates PC1, let alone PC2) how the hell would PC2 help?

14987: 12928:

but it sounds like lighter isn't working for you which is what I was afraid off. The difference between lighter and normal, should sort of be the difference between normal and bold. For example the lighter and #585858 options on

8934:

you refer to, it is easy to overlook the warning that one is editing an old revision, as it is the middle one of three red boxes, and the semi-protection one is more prominent. How can we improve the interface in this situation?

11096:

Can't say I care for the idea of implementing any old little thing that somebody dreams up, as long as there are no objections on a page with such limited exposure. The page has 31 watchers and we all know that doesn't mean 31

7032:

Javascript could be used to generate or conveniently modify the pseudo-watchlist pages in userspace. The problem is that watchlists should be secret, but userspace pages are not, so I believe that the tags are the way to take.

6971: 14655:

Oppose. The CentralNotice is extremely overused. Having a giant banner over the entire site for three days just to promote this tool is not worth it. Also, the proposed time overlaps with the banner for the Steward elections.

10226:. List articles give more information and nuance to article subjects than categories ever can. Categories are a huge waste of time. I personally don't bother with them anymore, and would not be sad to see them eliminated. 15363:. 500 edits seems to be a poor measure of anything and seems trivial to game. So, such use of edit count as a measure should not be encouraged. There seem to be plenty of technical tools already for managing problem pages. 15227:- As long as the only pages to receive the 30-500 protection are explicitly specified by ArbCom, this seems superior to the current edit filters. I do not presently support automatically adding this usergroup, perhaps called 15140:- as to bots, I think that any bot without enough edits/time to qualify will be added on request by the operator should there be any potential need for the bot to edit these pages; this would probably be relatively few bots. 16891:

college-level course in "arbitration" so that their "kill them all" solutions would be seen as the egregious violation of logic that they are, and that they would properly weigh what passes for "evidence". Too much to ask?

5873:

The primary goal of the proposal is to eliminate sock puppetry (which sometimes leads to pages being fully-protected). The possibility to lower (not raise) the protection level of some pages is just a (welcome) side effect.

15296:

Sure, TODAY, but it would not be impossible to adjust the protection policy to allow another step between SPP and FP; nor would it be unheard of to deploy in exceptional situations via WP:IAR, just as PC2 is rarely used. —

9140: 6874:

While it does seem the specifics of the proposal are unworkable, the idea behind it seems sound. Maybe there's a way to address that in some language to be added somewhere? For example, maybe some boilerplate text added to

2822: 14899: 10471:

and I agree. In my experience editors rarely discuss ANYTHING on cat-talk-pages. The problem is that the few who do are harshly "punished" by category-patrolling-ADMINs who are the only editors around. See for example

5861:

Full protection is not meant to protect against things spp is (such as vandalism) - if you want to qualify editors, make it clear - but making more protected pages that are harder to edit is not the goal of the project. —

5550:

feared getting a pile of complaints from the same people who would be complaining at Hasteur. The proposal passed easily, with several people saying "this is such a simple situation that we didn't need to come to VP/Pr".

16228:

be added to page as the result of community consensus or by the Arbitration Committee as it has been to the Arab-Israeli conflict (it should not be able to be added by an admin on their own cognisance whether AE or not).

10115:

There is a clear consensus against removing categorization at this time. I did offer a comment in this discussion, but it was more observational than taking a stance, and I rather think the consensus is clear enough that

5987:

In other words, absent a much more evidence-driven case – which also addresses and balances the negative effects on legitimate, good-faith new users – I am not persuaded this would be a useful or beneficial development.

2826: 2349: 10869: 10733:

Let's stop trying to hack the software using a parameter, "upright" with a default setting of .75 when a sensible default setting for the undocumented use would be 1, and instead ask our coders for a sensible solution.

10535:

process in place to avoid much of the tangle of the category hierarchy. I don't really favor outright deletion, but a Noah's Flood to wash away the Biography categories so we can start fresh certainly seems attractive.

8478: 7462: 3416: 3110: 2534: 1423:

I agree with what's being said here: it would be nice if such a thing were practical, and I would support the proposal were that the case, but I don't believe that it's possible to do without a massive amount of work.

10862: 9397:

and sadly nobody noticed it. And the Ip is creating multiple talk pages. Are we going to allow Knowledge become a politicians directory and Soldier database? Every deceased soldier of high rank can't have an article.

8482: 7298: 7279: 3420: 3114: 2538: 14385: 10625:

and I hope no-one will try, in any serious way, to remove them. Proposals like this rely on knowledge by readers which they do not have - especially when accessing a wikipedia that is not in their own native tongue.

15058: 14999: 13075:

You are correct. However, Edokter above said, and I agreed with him on the point, that this change should be made in core rather than locally, since the accessibility problems impact all wikis and not just our own.

10089:

Yeah, I've seen a lot of these requests and I assumed we weren't allowed to make requests for username changes by proxy. I think this kind of procedure is sensible and makes it more likely folks will stick around.

8877:- I appear to be using the "edit" link for restoring revisions. Much easier than having to copy all of the source code (which itself has issues too, such as having to remove excessive numbers of dashes and spaces). 6763: 6052:

Patna" :: an automated filter will stop the creation of such stub articles, if the account is not auto-confirmed. As "unsourced stub articles" can have notability, only autoconfirmed users can create stub articles.

14868: 14840:. Hosting non-WMF related ads is a route we shouldn't even consider going down. If we're going to start hosting ads like this on the grounds that the product somehow relates to the use of Knowledge, why shouldn't 14470: 11816:

concept, but I can't help it. I also hope this, while providing some benefit for some people, is so inconsequential as to stand a chance of passing, so I can experience that joy just once in my Knowledge career. ―

5820: 2124: 8593:) reference, it will not be possible to display the nested reference by hovering on the link in the tooltip. Is there a support for being able to display the references recursively by just hovering on the links? 15923:), but the edit button still being visible is quite editor-unfriendly. The filters are still available as a temporary implementation, should we wish to consider that (full disclosure, I helped implement them :) 9547: 5387: 5391: 16003:

Users who don't (yet) meet the autopromotion criteria can be manually promoted by admins when based on their history, they are expected to contribute positively to these areas and no evidence of sockpuppetry

14970:

9407: 9215: 8725:

PROPOSAL: I feel this Edit link offers more potential for unintentional harm than for good, and it should be changed to view the source in a read-only mode, with the text "View source" or something similar.

14691:

notification, however it is done. What next? Promo banners for St St Patrick's Day or any other saint to which some form of whimsicality is attached? We are an encyclopaedia, not an arm of Hallmark Cards. -

11270:

Granted, I could use a new glasses prescription, but these titles are always a bit hard to read. A minor thing to many (especially those whose glasses prescriptions are just fine), but it's an easy fix too.

8831:

Utterly unnecessary. The minuscule number of times this could happen is no reason to alter the way edit function works. For one thing you can always revert to the version before the mistake and start again.

8470: 8430: 5414: 8716:

There are other ways to restore an old revision, and they create edit summaries that explicitly indicate that an old revision was restored. While those "other ways" may require one to enable a tool such as

7918:

In engineering, as I understand it, redundancy is good because it increases reliability. That is not the case here. To the contrary, redundancy here increases complexity with insufficient benefit in return.

6529: 8422: 7352:

to the subtitle text, then you are right, that cannot work (and neither it does for Modules). The transclusion has to be done by the namespace handler. It's a bit complicated, but I think it's doable, see

6986: 5418: 2435: 2039: 14011:

Per the above, whether the software supports such an ability or not, the way it has always been here is that a page is either live and public, or deleted. You may find it helpful in the future to explain

10903: 6144:

where we do not require sourcing by any means. If the template is there, anybody can check whether the category is available on Commons and whether it corresponds to the content of the article. Note that

1200:

to file a request (more templates, yay!), being passive-aggressive about blocking them again if they don't do so. How many potential contributors are we losing along the way? To remedy this, I propose to

14479:

hmm technical note you want Sitenotice not CentralNotice for something on a single wiki. Also you are asking for a banner ad on one of the highest traffic websites going. How much server capacity do you

7528: 2439: 2043: 16737:

However, reading some of the Wikipediocracy thread, it appears I may have assumed incorrectly as to communication. At some point, I would like to hear the justification for such secrecy in the process.

13678:

time, and creates long term resentment. I would venture to say that beyond a recent warning, which always can be readily seen, admins are not that fussed about the number of warnings on a talk page. --

8714:

While the edit session gives a red warning about this at the top, it is easily missed. Clearly, it was not enough to prevent the error in the two cases cited. We should be idiot-proof wherever possible.

7870:

And to be honest, its a relatively small proposal. Its not something that would really improve Knowledge because we already have Wikiprojects and talkpages. Its not "silly" its just not that intuitive.

9206:

The BLP policies of actors/directors/actress/musicians is very tough and actors with two films have their article redirected or deleted. But when it comes to sportstars Wikipedians are a bit lenient!--

16147:. I'm not sure if I see the need for an arbitrary 30/500 level, but given that this is something ArbCom has decided it wants to do anyways, better to implement it properly than use an edit filter. -- 10717: 7694:

It seems fairly simple to me. Knowledge is an encyclopedia. Question and answer is something very different from an encyclopedia. Not totally unrelated, but very different. It's also something that's

9701: 9562: 16763:

here). One of the unofficial rules on the AMA page was that the advocate would make clear their role as an advocate in the discussion. So I don't think this would mislead the discussion in any way.

8141:

Thsi proposal is very vague, to the point of being opaque, and the user who advanced it is now blocked. No prejudice against re-submitting a more coherent proposal along these lines in the future.

14220:

I would prefer to hold off a Flow RfC for the moment. I wouldn't object to an RfC being based on my text but in that case I would withdraw myself as a proposer. Let's see what happens with Gather.

9811: 5405: 2030: 16615:

because I can't vote to enable PC2 instead. If people want to limit it to Arbcom or community sanctions, that's fine. It would perhaps quiet the fears of some editors that it would be overused.

13970:

While mediawiki can support most of this, the English Knowledge is not likely to adopt any sort of READ permissions; it is contrary to our standard licensing model and open-content philosophy. —

7883: 6842:

This proposal is impossible as Commons is not within our jurisdiction. Everyone is however free to submit a deletion request at Commons, where selfies by random people are generally out of scope.

10686: 8118: 7551: 6499:

Now that the "Draft:" namespace has been implemented in full over the course of the past couple of years, there seems to no longer be a reason why non-confirmed editors should be able to create

5409: 4824: 4365: 2034: 13142:

solutions, which have to be debated until the whole thing really does become a case of bikeshed, and a simple change mutates into Flow Jr. But I'll defer to y'all's vastly superior experience. ―

12361:. I think there probably is a way for CSS to take care of this, since FOOBAR is outside the span for italics. #comment should inherit rather than italicize, while #autocomment should italicize. 10712: 7661:. Your proposal would be taking effort and attention away from building an encyclopedia and putting it into a difficult medium to get right – Q&A. There are sites that already do that well. 14453:

campaign this year, and we're working on getting high-profile scientists and science institutions in the U.S. and Canada to create and share Playlists of scientific articles (see, for example,

10742: 7675:

You are expressing your personal opinion as if it is enshrined in WP Pillars, but that is a grotesque stretch. Also, having a simple question and answer feature is certainly not a violation of

7585: 5229: 3636: 2201: 14764:

seems to have a differently defined scope. Incidentally, the Wiki Education privacy policy, served through an IP hosted by Athenix, gets some JS and uses a tracking pixel on wp.com subdomains.

13657:

Yes, I just checked it out before I noticed you posted this. Thanks for the heads-up, though. Also, I'm looking for other opinions, whether for, or against. So don't be afraid to chime in. :)

5608:

violation" to get sanctions applied. I'm exceedingly gun shy about items that have the potential of being controversial because of previous interactions/complaints from vexatious disputants.

15407: 10441:

Don't throw the baby out with the bathwater. The problem I find is that people rarely use the category talk page to discuss which articles are appropriate for a category (and instead use the

7187: 3074: 2205: 16420:

be used as justification for promotion when the user does not meet the requirements.) In addition, since use of the new protection level must be mandated by ArbCom, only ArbCom decision and

6178:. That we recognize that it is advantageous to read the information about the Commons category on Wikidata rather than to keep it locally - meaning removing the category name parameter from 13705:

do not remove this template for one month after warning date", would be a lot of work. I would have no problem in helping with this, if it became the case. I stand by my suggestion, as I'm

4995: 4833: 3641: 3546: 3078: 13759:

As a side topic, it's removing the "shared IP" templates that concerns me. They're easily missed and it's useful to know if an IP is from a school, etc. And not all Admins check for that.

16841:

Yeah, if the old AMA has any political baggage, a change would probably make a meaningful symbolic statement. Might as well throw in Association of Editors' Advocates for consideration. ―

14521:

About Sitenotice — my understanding is Sitenotice can't be geotargeted, so I had to use CentralNotice for that, but if I've misread something, I'm fine asking for a Sitenotice instead. --

4392: 3645: 2223: 1919: 16285:- I strongly oppose a new protection level, and support this proposal only as a more user-friendly way than the edit filter to implement ArbCom's decisions. Accordingly, it must be made 10857: 6055: 6024:

Will it discourage the trolls? Or otherwise will it discourage good faith newcomers? It seems, at a first glance, like the metaphor "putting one policeman officer stood on all corners".

5283: 3015: 2790: 2552: 2142: 2075: 1877: 15282:

are not enough, since they only authorize semi, full or move protection. These are likely to be long term or indefinite, as disputes that reach ArbCom are some of the most persistent.

14331:, bugs that will never be fixed. What we need now are tools to convert Flow pages back to normal talk pages. I do not understand why the WMF has wasted so much time and money on Flow. 13386: 6767: 1309:

I can't go to Meta before making sure that we as a community want this. This is a problem mostly of our Knowledge and maybe 2-3 other large wikis, as others just don't have the scale.

13406: 11179: 11011: 10957: 7137: 7132:

TimedText pages can easily become orphaned if the corresponding filepage is deleted/moved; there is no warning to deleting administrators or filemovers that there is a TimedText page.

6836: 4757: 4599: 2943: 2633: 2556: 2079: 15034: 14943:, or when not covered by it, these edits can be reverted by other users. Although this system might somewhat reduce the disruption in those areas, it has some significant drawbacks: 14939:, be forbidden from being edited by users who don't have 30 days of registration and 500 edits. To enforce this, an edit filter was created to disallow edits on some of these pages: 10553:

Categories made it so much easier for me to organize and add content. Categories is how I patrol content associated with the articles I create. I see no benefit to eliminating cats.

9305:

And biographies of living persons as created by Lugnuts shouldn't be single sourced. Every player linked in espncricinfo can't be notable as every actor with IMDB page is not notable

5566:

Of course, if someone leaves objections at BRFA, community consensus would need to be obtained before the BRFA is approved, but because the creation of unprintworthy redirects (e.g.

8407: 6899:

If prior to deletion the article contained a photograph that was uploaded to the Commons by the creator (e.g., a "selfie"), consider nominating it for deletion there as "outside of

5355: 5049: 4986: 4968: 4761: 4752: 4257: 3915: 3834: 3339: 3303: 3006: 2988: 2637: 2601: 1975: 1961: 6079: 5543: 14044:

This feature has been strongly rejected by the community, and the WMF isn't even trying to fix it anymore. This is a dead issue regardless of one users' inability to accept that.

13935: 13902: 10373:: In terms of information efficiency, the category system may benefit from a reduction in branch depth. Branches that are almost never used should be pruned back (merged upward). 5175: 4923: 4914: 4806: 4694: 4505: 4428: 4334: 3951: 3893: 3686: 3213: 2979: 2880: 8490:

a bot be written to move all cases following the old naming convention to titles matching the current naming convention, and human editors encouraged to help if they feel like it

16099:

The proposal is nothing to do with changing policy, and is not creep. The proposal concerns the method that should be used to implement procedures that are already in place for

14724: 13907:

Hi. As an example, lets assume that I would like to share my mobile number (or anything for that matter) on my userpage or a specific user subpage. And, I would like to either:

6576: 6188:(in the situation Wikidata has the info) would not be considered as disruptive and can be, in principle, carried out by bot on a large scale. (I do not intend to do it myself). 4698: 4559: 4509: 4338: 4185: 3897: 3690: 3285: 3222: 3141: 2934: 14981:

Pages may be protected by admins with the new level only when a decision of the arbitration committee mandates it (note that standard discretionary sanctions do not include it)

14500:

We're set up to handle plenty of traffic with this; we've have some auto-scaling infrastructure in place for it. The potential for this to go viral is something designed for.--

10769:

inability to reach a new consensus, and there is a lot of politics involved. My perception is that the issue is tabled for the time being, but feel free to try to untable it. ―

14340: 14322: 14302: 11128:-- Not because I would use it or have ever felt the need for it, but because the rationale makes sense to me, I recognize that not all editors are the same nor should be, its 7643:." I just glanced at the Pillars and did not see how that is true. Could you expand and be very specific as to how this proposal is fundamentally in opposition to WP Pillars? 6966: 4932: 4563: 4329: 3762: 3267: 3033: 2970: 2961: 2889: 2862: 2178: 1910:

article, in order to support the notability of it. And the stand-alone article would need to be strongly supported. Of course this makes these lists that much less arbitrary.

1907: 1802: 8741: 8688: 8612:

So, I actually wrote the code necessary for that back in September 2012, but I never got around to pushing it to the gadget. I'll see if I can merge some changes in now... --

8000:

here. This is an encyclopedia project, not a Q&A site. You should go ahaead and crowd-source and build the thing you're proposing. This just isn't the place. Regards,

8385: 5103: 5000: 4032: 3753: 16964:. Most of these categories are added manually, and the retention of the disambiguation template causes those pages to be in both parent and child categories; for example, 9676:

at the bottom of my edits, but I kept forgetting to remove it afterwards and it didn't support named references from other sections. The script sorts that all out for you.

7461:

Phab works on my end. Your warning on the Movepage and Deletepage MediaWiki pages won't catch all TimedText pages, though - not all TimedText pages have the same language,

5702:), so you just write up a bot to create these redirects, submit the bot to BRFA, and (assuming it's approved) your bot goes ahead and creates them. Consider the rules for 16717:

I assume that all communication between advocate and advocee would be in the open rather than e-mail or other off-wiki, and that this would be an explicitly stated rule. ―

13607:

I'm not going to remove the RfC template, but I'd suggest that you do so. This page gets enough attention from experienced editors, so this is not RfC-worthy. Good luck. ―

6992:

I believe the only solution currently available is to create a page (in your userspace) with links to the relevant pages; then use the "Related changes" link at the side.

6821: 6759: 5004: 2817: 2048: 1692: 1607: 16203:

account that doesn't meet the requirements would run contrary to the ArbCom's decision. However, I can still see a use for manually promoting accounts that are declared,

15546:

This was the last attempt to use the auto-promote feature, and no users were autopromoted by it, seemingly because it was broken nowadays as opposed to misconfiguration.

15502: 15467: 15012: 14190: 11708:, Maybe it has been asked and answered but whey are one to five in italics but 6 is regular? And, I see 6 as being a speck darker now that the sun is going down. Cheers! 7153: 1318: 16836: 16812: 15514:

because "Using the edit filter affects performance and is user-unfriendly since the edit button still appears", assuming it is technically possible to do this given the

15319:, amongst other issues related to new auto confirmed accounts. That, and since pending changes level 2 was not a community-accepted option, this is the next best thing. 14815: 13719:

I'm worried, mainly, about how long these cantankerous editors can fly under the radar until their contribution history until administrators find, and take care of them.

12774:

I'm seeing something close to your second example, but I can't see that weight difference on this page no matter how hard I look at it. Care to do me a favor and update

9316: 7082:. You can "switch" watchlists by saving your current watchlist to a text file in your computer and replacing it by contents of a different text file from your computer. 6671:

That's actually a brilliant idea. The use of this option isn't obvious to me, but the use for this kind of thing is never obvious at first, and later becomes essential.

5759:

This allows trolls to create a bunch of accounts and not use them until they need them, then make 10 back-to-back edits right before they use them for abusive purposes.

3677: 2052: 1980: 17006: 14852: 14832: 14442:

While the tool is reader-focused, editors are obviously readers, too, so I encourage you to create a Playlist and see what you think. Do let me know (either here on on

14075:

If the feedback's result is OK, the Flow beta function can still exist. So I would like to restart to talk about Flow function. Please define your opinion, thank you.--

13010:

Because the implementers have tasks on their plates already that have been on their plates for four years and still need to get cleared out first. That is why. Cheers!

9973: 1867: 1296: 16685: 15291: 15269: 14665: 14590: 14575: 14560: 10214: 10194: 10176: 7181: 6832: 3681: 1521: 16624: 16502: 16400:

if needed) and a new protection level corresponding to the new userright to enforce a 30-500 editing restriction. It is far better than using the non-editor-friendly

14682: 14287: 14263: 14249: 14159: 14138: 13880: 9293: 8918: 7542:

This proposal to turn Knowledge from an encyclopdia into a Q&A site has clearly been strongly rejected. Closing to avoid pile-on and further pointless bickering.

7208:

That's a documentation to your template, but I meant a different thing: Like in the TimedText namespace, it is not possible to transclude anything to be displayed at

6851: 1550: 16793: 15372: 15202: 15067:), but as many bots wouldn't, we shouldn't manually include them in the group: it would be a big waste of time. Instead, just add it to their rights packages. The 13976: 11167:

Thanks everyone - yes, Xaosflux, that was exactly my intention as far as what I hope it will do. I will propose it at Editingold with Mandruss's correction. Cheers,

10937: 10545: 10325: 10010: 9990: 9517: 9513: 9403: 9312: 9211: 8661: 8535: 7522: 7392: 7381: 7363: 7343: 7321: 7273: 7255: 7244: 7226: 7203: 6915: 6801: 6787: 6680: 1763: 1745: 1724: 17047: 16918: 16167: 15905:

I wholeheartedly agree. If we are to go this route, a new user group is naturally the best approach. Edit filters can work without much concern of performance (see

15830: 15448: 14700: 14110: 13768: 11620: 10517: 10492: 10344: 9685: 1953: 1938: 16901: 15725:

All of the opposes seem to be saying that we shouldn't protect pages in this way, but we already are via the edit filter. This just improves the existing process.

15219: 14801: 14783: 14738: 14646: 14623: 13965: 13869: 10951: 7500: 7478: 7125:

The namespace TimedText is generally poorly documented in its purpose, and because of technical restrictions documentation can only be put on TimedText talk pages.

6815: 5997: 5942: 1845: 1815: 1589: 16536: 16277: 16257:

can not be trusted .. yet. It is fine that it is used for Arbitration sanctions, but I would also support it if it would be used outside of that restriction. --

15866: 15812: 15717: 14530: 14495: 13157: 11435: 10836:

already, but it's a difficult thing to change in hindsight. There is a more expansive discussion about these and a few more related image thumb nailing issues in

10784: 10045: 9935: 9591: 9577: 9423: 9364: 9333: 9237: 8893: 8571: 8553: 7722: 7707: 7689: 7670: 7652: 7634: 7615: 7600: 7069: 7058: 7039: 7027: 6695: 6328: 5518:

No, really, I agree with your proposal, there should be no need to get consensus twice to use a bot to create a bunch of non-controversial redirects like this. ~

1711:

I don't think it's a matter of changing priorities as much as providing a Gerrit patch to have the code changed, as well as to get the questions raised addressed.

16950: 16856: 16773: 16753: 16732: 16603: 15934: 14215: 13863:

respect the warning against removing the warning? And if they do quit it, I don't care if they remove the warning or not; at that point it's served its purpose.

13813: 13800: 13754: 13736: 13661: 13652: 13631: 13622: 13602: 13592: 13022: 13005: 12985: 11888: 11874: 11752: 11720: 11646:

If someone could tell me the hex triplets for the existing two colors, I could play with it and make the proposal more specific, with color samples—if it hasn't

9916: 9888: 9247: 9157:

don't have much notability. Knowledge is not a sports database that every player must be listed. However every article created by Lugnuts is not poorly sourced.

8653: 8642: 8621: 8331: 8267: 8252: 8208: 8193: 8008: 7899: 6665: 6317: 3200: 1653: 50: 16707: 15877: 15849: 15734: 15183: 15169: 15147: 14509: 13572: 12680: 12011: 11961: 11931: 11242: 10824: 10803: 10382: 9848: 9723: 9627: 9606: 8991: 8800: 8094: 8075: 8049: 7456: 7434: 7088: 7013: 6999: 6869: 6712: 6617: 6567: 6376: 6358: 6344: 6034: 5880: 5868: 5856: 1705: 1623: 16580: 16471: 16248: 15871:

Certainly we could request amendments on those ArbCom cases to change the topic bans exclude this entire group, regardless of how the membership was gained. —

15857:: per Mike V, admins should not be able to add users to this group manually as they would still be banned from 30/500 protected articles by the ArbCom ruling. 15334: 13683: 13433: 12585:

I'm not convinced I understand what's changed for option 5, but per my previous comment I support any change that's agreed to be an accessibility improvement.

11069: 10672: 10617: 10562: 10455: 10295: 10276: 10262: 10098: 10064: 9535: 9489: 9474: 9451: 9346: 9260: 9070: 8840: 8823: 8517: 8163:

The purpose of this is so that editors could help focus on the right areas of improving Knowledge by thinking of ideas that people feel need to be addressed.

7106: 6753: 6588: 6019: 5957: 5918: 5903: 5664: 5483: 3204: 16648: 16384: 16261: 15951: 15891: 15796: 15351: 15303: 15257: 14025: 14004: 13854: 13832: 13281: 13259: 13229: 13197: 13136: 13085: 13070: 12945: 12875: 12850: 12793: 12769: 12748: 12720: 12705: 12241: 12201: 12142: 12115: 12100: 12047: 12032: 11984: 11846: 11831: 11810: 11481: 11453: 11201: 11161: 11116: 11087: 11055: 10913:

Wiktionary has a feature wherein each new entry to a category shows on the category page. Can wikipedia enable a similar feature to appear on its categories?

10635: 10595: 10081: 9826: 9663: 9126: 9032: 8869: 8783: 8765: 8723:

While it might be possible to pre-fill the edit summary field with something meaningful, I doubt we could prevent the editor from removing that before saving.

8027: 7970: 7950: 7935: 7853: 7839: 7819: 7804: 7780: 7765: 6941: 6444: 6429: 6116: 6095: 5844: 5685: 5647: 5531: 1681: 16319:

and others mention, to restrict its use to an otherwise-case-by-case-consensus basis (and, as is obviously the case with ARBPIA, existing ARB directive). --

16117: 16094: 15770: 15753: 15419: 15393: 15106: 15092: 14229: 13551: 13331: 13036: 10655: 10579: 10234: 10030: 9777: 9087: 9049: 8975: 8285: 6257: 6130:

data are unsourced. Without really wishing to discuss this, I would like to note that there are some things which do not need to be sourced (in the sense of

5833: 1773: 1517: 1433: 16519: 16441: 16302: 16190: 16067: 16043: 15974: 15682: 15660: 15534: 14890:

community has applied the 30/500 limitation, not in response to a request for page protection or any other reason. Closing as rough consensus to support.

14750: 14670:

The highest-impact promotion for this tool would probably be to import all the public Gather lists and notify each user of the move. As long as the code is

12973:– any change because it makes absolutely zero difference on any of my computers. I tried full zoom, a magnifying glass, and I got zip, no hay nada. Cheers! 12646: 12615: 12601: 12068: 10433: 10365: 9095:- Re relative emphasis of the warning message, it appears the message already has the highest level of emphasis supported by the template that produces it, 8857: 5741: 5724: 5617: 5500: 1529: 1414: 16557: 16327: 15627: 15606: 13429: 13372:

and the GOCEreviewed template should be removed. I am proposing that the GOCEreviewed template be changed to show the user, date, and issues parameters. --

8950: 8606: 6295: 4793: 2345: 1264: 1170: 15581: 13381: 13360: 13316: 13296: 13121: 13107: 12634: 12558: 12508: 12378: 11699: 11679: 11665: 11634: 9013: 6731: 5897:" (In both cases, the autopromotion will occur immediately after the fourth edit, i.e. before anyone being able to revert it, but that is not a problem.) 5578:

proposal above) is generally an obvious housekeeping matter, we need not go through the bureaucracy of filing a discussion for situations like this one.

1472: 16872: 16216: 16139: 15651:

The phabricator task linked by Mdann52 is a configuration issue (see more details above), the underlying core Autopromoteonce mechanism works perfectly.

15130: 12733:- Um I guess so, I don't see a difference between first half of 6 and last half of 5. They both look like this here text to me. Firefox 44 with Vector. ― 12461: 12447: 10508:

Those are discussions about the names of the category not about the categorizing. It could be done on each page with a mention on the cat talk pages. --

9954: 9897:, where someone's justifiably gotten upset that he's having to wait a long while for his new username. Three people commented there (I haven't), so I'm 9791: 9762: 9748: 9734: 5803: 5767:

This would force trolls to actually edit with their sleeper accounts on at least 3 different days before they could use them, making it easier to spot a

4797: 1451: 16991: 16358: 14086: 13746:

check their contributions, and talk page edits. Maybe another solution to this is to make sure users are checking those two things by outlining them in

10408: 5809:

Don't like it, as using more spp also discourages anonymous good faith editors. However, looks like a new class of editor "500edits and 30days" (e.g.

1400: 1345: 1238: 1215: 16021: 15996: 15398:

The autopromote feature is not broken, autoconfirmed works just fine right here on enwiki. Autopromoteonce works just as good on plenty of wikis, e.g.

13674:

removing warnings from their talk pages. Such a policy results in numerous completely lame edit wars, drives away otherwise productive editors, wastes

10241:

If you are seriously proposing this, a post here is not the way to go about it. This would be a major change and would require broad input in a formal

8450: 5537: 3389: 3191: 2696: 16662: 12580: 11444:

I added option 6 and switched everything to use html code closer to what actually shows up in history list and added comments describing the options.

9568:

Speaking of syntax, or maybe it's semantics, do you maybe mean "references" as opposed to just internal links, which should render in a page preview?

13502: 13423: 9615:. Then hit preview, review your references, and then be sure to remove the reflist code before you actually save. That's how I've done it for years. 5656: 3393: 3195: 2700: 2021: 1542: 14053: 10766:

Your use of "hack" appears to be a pejorative shorthand for "the wrong solution to the problem in my opinion". I won't quibble over those semantics.

7591:

There are many Q&A sites on the web. Some of them (e.g. Stack Overflow and its sisters) are very good. Knowledge would not do a good job of it.

1371:), where an admin got confused when the blocked user claimed to have filed a rename request, but they did it at Special:GlobalRenameRequest and not 16961: 14990:. Should it get consensus, I believe that the ArbCom will agree that this system is better than the current one and incorporate it in its rulings. 7698:

hard to implement in a good way, as many, many websites have proven over the last two decades. I've clearly offended you and I'm sorry about that.

7112: 5054: 4811: 2120: 2025: 1667: 1509:

i hope you take my suggestion into concideration and i hope ii send this to the right department. I simply couldnt find another place to submit it

15483:

can't be constrained without ARBCOM intervention is a good thing. This proposal (and my preference for PC2) is meant to limit the sockpuppets and

9856: 8501: 6391: 5455: 12841:

in place of the 3 lines you currently have at the end of your config. You can switch lighter to normal and back to see the effect that it makes.

10922: 8562:. Of course they'll need to be changed to avoid double redirects, but I don't imagine any reasons to be editing the contents of non-redirects. 7713:

Knowledge in a seemingly random manner. No one can have a discussion when you have people doing what amounts to running interference on an idea.

5893:

Sounds reasonable to me, I think it is a question of the security gained being worth the developers' work. I would just reword the criterion to "

5058: 4815: 2318: 10722:

Currently, the preferences allows you to set a default pixel size for images, but keeps all other images the same size as the coding, unless an

9582:

Haha! Yes, of course! I've edited my initial proposal. Please feel free to delete as you see fit, including these two lines of mine. Thanks!

8369:

If you have questions, please reach out to me on my talk page or on the strategy consultation's talk page or by email to mdennis@wikimedia.org.

13543: 9103:. Some of the other red messages around it could be de-emphasized, which might help a little. Any other color change would require a change to 7874:

article, they can look at the questions that the article brought up and see if it can improve sort of like something that pre-peer review/GAR.

2723: 2322: 1131: 1127: 1123: 1119: 1115: 1111: 1107: 1103: 1099: 1095: 1091: 1087: 1083: 1079: 1075: 1071: 1067: 1063: 1059: 1055: 1051: 1047: 1043: 1039: 1035: 1031: 1027: 1023: 1019: 1015: 1011: 1007: 1003: 999: 995: 991: 987: 983: 979: 975: 971: 967: 963: 959: 955: 951: 947: 943: 939: 935: 931: 927: 923: 919: 915: 911: 907: 903: 899: 895: 891: 887: 883: 879: 875: 871: 867: 863: 859: 855: 851: 847: 843: 839: 835: 831: 827: 823: 819: 815: 811: 807: 803: 799: 795: 787: 783: 779: 775: 771: 767: 763: 759: 755: 751: 747: 743: 739: 735: 731: 727: 723: 719: 715: 711: 707: 703: 699: 695: 691: 687: 683: 679: 675: 13670:

talk page edits to see the user's response/justification. Previously, when removing warnings wasn't allowed, we had lots of users blocked for

7278:

Ok, but still, why "talk"? Why not see the doc directly at the TimedText page above or below the subtitle source code? Look, I can transclude

1368: 15278:(which has its own requests page), so it must be supported by an ArbCom decision specifically authorizing the "30-500" restriction. Standard 14961:

Users who are known, based on their history, to contribute negatively to these areas cannot be prevented from editing them, short of blocking

11416:

Option 4 was added later by another editor, and is halfway between 2 and 3 in darkness. Options 1–4 are shown in ascending darkness sequence.

11250: 10182: 8434: 5775:

and make it easier to find sleepers that have only edited enough to be autoconfirmed but which haven't been "put to use" yet by the troll.

2727: 2381: 2327: 671: 667: 663: 659: 655: 651: 647: 643: 639: 635: 631: 627: 623: 619: 615: 611: 607: 603: 599: 595: 591: 587: 583: 579: 575: 571: 567: 563: 559: 555: 551: 547: 543: 539: 535: 531: 527: 523: 519: 515: 511: 507: 503: 499: 495: 491: 487: 483: 479: 475: 471: 467: 463: 459: 455: 451: 447: 443: 439: 435: 431: 427: 423: 419: 415: 411: 407: 403: 399: 395: 391: 387: 383: 379: 375: 371: 367: 363: 359: 355: 351: 347: 343: 339: 335: 331: 327: 323: 319: 315: 273: 269: 265: 261: 257: 253: 249: 245: 241: 237: 233: 229: 225: 221: 217: 213: 209: 205: 15157:

again. Point of clarification: does "a decision of the arbitration committee mandates it" cover the recent decision in ARBPIA linked above?

9057:- Sorry to pile on but I occasionally use the edit function on prev revisions to remove vandalism .... No need to remove the feature IMHO. – 8308: 8172: 6700:

If we are going to add sorting, I would also appreciate sorting on editor contribution (number of edits, not bytes). I support this idea. --

6412: 5596:

I endorse this generic category, however suggest that this proposal be advertised to groups outside the regular VP/Pr community (specificly

1498:

I, and im sure many other reader as well, would be thankful if there was a automatic readers voice that could read the article to the user.

16668: 12148:

if both text were black and it was just a font weight difference as that is the effect that the lighter text is emulating. color (#585858)

8150: 2385: 2331: 1376:

unblock user accounts with inappropriate usernames, and the renamers that do the actual renaming to stop an account from being reblocked. —

311: 307: 303: 299: 295: 291: 287: 283: 279: 201: 197: 193: 189: 185: 181: 177: 173: 169: 165: 161: 157: 153: 149: 145: 141: 137: 133: 129: 125: 121: 117: 113: 109: 105: 101: 13713: 13497: 11132:

factor seems minimal, it doesn't look like a big developer effort, and PaleAqua supports it. The proposer may wish to return the favor in

8461: 6240:. To keep the link to the category on Commons on the left panel, similarly to how it is used in Wikivoyage and some other Wikipedias, see 5966:

for trolls/vandals/griefers/harrassers to create multiple accounts, age them, and abuse in the in the manner described, how often is this

1576: 13563:, leaving only a level 2 blanking warning. Cluebot NG was also fooled by this on a few occasions, leaving the same level warning template 10250: 5587: 5270: 2183: 2165: 1659: 15433:

basis, let's implement PC2! There is consensus for PC2 to exist but not how to implement. I think this situation is what PC2 envisions.

14950:

Users who don't strictly meet the criteria but who, based on their history, are expected to contribute positively in these areas cannot

10875:

For some time I have been collecting examples in Wikimedia projects in which there is some disagreement about whether an image violates

10809:

Can't remember something I never knew! Thanks. My definition, from m-w.com: "to decide not to discuss (something) until a later time". ―

10155: 16822: 13859:

My question is, what good does this do? If a vandal doesn't heed the warning to cease vandalizing pages, why would we expect that they

13536: 11060:

The phrasing "Click here" is typically considered bad practice, I think. Perhaps the link could be just "Edit the current revision". --

8426: 5274: 4739: 2741: 2624: 2187: 2169: 14542:

The fair-use issue, of course. All the images I saw came directly from Commons instead of en.wp, so this may already have been solved.

13493:

I'm not very good at suggesting these sort of things, and putting them together, so any suggestions would be very helpful. Cheers! :)

9355:, yes, I was referring to the Chinese soldier biography articles linked in the OP (as well as Zee money's other such contributions). 7231:

Yes, there is a function that transcludes /doc subpages in the Module namespace, but I know of no such thing working in TemplateTalk.

4743: 2745: 2628: 2291: 1686: 15840:

provided that this is technically possible and on condition that the new protection level only be used for arbitration enforcement.

14628:

Hi Alsee, you're correct on the first one — we spun off from the Wikimedia Foundation to an independent nonprofit in 2013. We had a

11032:

would probably be a better place to ask about if it was possible, though assuming the notices work similar to templates my guess is

10333:

Static content categories need to be replaced with properties and dynamic list pages. I don't see this as imminent. All the best:

10129: 9672:, which is brilliant. It's superior in almost every way to normal page preview, even forgetting the references issue. I used to put 16979: 16424:

should result in demotion from this group. For those that are demoted, there should be a defined method of being promoted again. —

13779:

Really? This again? There is still no compelling reason to force users to maintain warnings for any length of time. The warning

9862:

for username change with a demand that he'll be reblocked if he doesn't submit the username change request pretty soon? Proposal:

9501: 9497: 9394: 9390: 7368:

Doesn't seem like it will work barring a tech change. In the meantime, the function I assembled in the template will have to serve.

6396: 5306: 3938: 3929: 2543: 2295: 1851: 16412:

should be given the technical ability to promote and demote users from this group. Policy should require that admins only promote

11274:

PROPOSAL: Make the section titles in page history darker, while remaining distinguishable from the remainder of the edit summary.

9274:

feel free to create an account and do the things he says are not being done. Otherwise, someone will get around to it eventually,

8355: 7750:

I know it's painful, but anyone bringing any proposal must be prepared to accept "sorry, I think it's a bad idea" as a response. ―

6420:, do you think it is ok to remove this info when it is unambiguous (only one commons category around, which completely matches)?-- 10388: 6722:

of congregating each editor's edits together, allowing you to observe quite rapidly who was the most active editor of the page.

6636: 6124: 5324: 5310: 4820: 4460: 4361: 3942: 3933: 3884: 3551: 2660: 2570: 2547: 14974:

Users who meet the autopromotion criteria and were therefore automatically added to the usergroup may be manually removed as an

11503:

to test each option (remember to remove when finished with testing). If you do not already have a common.css, simply create it.

8721:, doing so is well within the ability of an editor who has enough experience and competence to consider restoring old revisions. 7018:

Agreed - Being able to access or filter through watchlist categories and subcategories would be beneficial and save users time.

6806:

I'd also like article sorting in search, categories and "what links here". By first edit, last edit, article size, name, etc. --

1944:

it means we'll have less non-notable arbitrary lists, while other lists that are notable will be strengthen and not challenged.

1405:

Is this even technically feasible with SUL (short of allowing local admins to rename globally, which seems like a non-starter)?

16032:

Knowledge:Arbitration/Requests/Clarification and Amendment#Palestine-Israel articles_3_.283.29: Arbitrator views and discussion

15023: 10587:

various wikignome projects that I have worked on are far easier to proceed with by using categories rather than list articles.

10319: 9800:

making MW do that with a section preview isn't as simple as I describe it, but IMHO it's obvious that that's how it should be.

8342: 8230: 5763:

I propose that this be changed so you must have 4 edits, each of which is at least 24 hours after the last "edit that counted."

5328: 5225: 4464: 4442: 4037: 3888: 3632: 3555: 3155: 2894: 2664: 2574: 2498: 2156: 2147: 67: 5925:

Against, less because it's unworkable and because this is further restriction for no gain. The best sockpuppets are those who

16933: 14848:, get the same opportunities? As others have commented, I also fail to see how this relates to Valentine's Day in any way. ‑ 10964: 9160:

There is another editor Zee money who creates one after another unsourced biographies of deceased soldiers and politicians.

5747: 5567: 5423: 5396: 5090: 4446: 4226: 4208: 4041: 3659: 3524: 3344: 3308: 3159: 3038: 2898: 2588: 2502: 2444: 2160: 2151: 1137: 16805:

Why not Association of Contributors' Advocates? If the majority of ARBCOM cases involve contributors, it makes more sense.

7140:

to provide for this template, but I'd like input on the template scope and functionality from the broader community. Thanks!

7118: 6507: 5542:

This is the second time I've come to VP/Pr to request consensus for bot-creating a bunch of simple redirects; the first was

1808:

Globally meaning across all projects? That is something that would have to be proposed at Meta. We couldn't do that here.

87: 16927: 16161: 15193:

superior to the edit filter solution. But I would not support making more and more groups as it would just get confusing.

14911: