This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212
Since many Wikipedia medical aticles may hhavve bbeeeen editeteddpeo by non-professssionals, shoulld there be a tag heading these articles clarifying this??#02:30, 3 July 2016 (UTC) Vorbee ( talk)
I noticed that celebrities who are members of the Scientology religion are identified as "religion: Scientology", yet celebrities who are followers of the Jewish, Muslim, Christian and other religions have nothing in their bios about their religious beliefs.
I propose that all celebrities' religions be identified. — Preceding unsigned comment added by SmudgeTheDragon ( talk • contribs) 17:25, 4 July 2016
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
As INTDAB indicates, links in mainspace to disambiguation pages are usually (but not always) wrong. DPL bot does a great job of catching these links when they are added, and letting the editor know on their talk page, but, as Wikipedia:Disambiguation pages with links makes clear, there is significant non-response to these bot messages. It seems to me that we would have greater compliance if we could intercede before changes are saved.
I propose a high-attention message and two buttons that appear when "Save" is clicked (with the exception of disambiguation pages, which often intentionally link to other disambiguation pages), modeled on DPL bot, e.g.: "You have added [a link|links] pointing to the disambiguation page[s] [X, Y, and Z]. Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles." Buttons: [Return to edit][Save anyway]. So:
— swpb T 19:59, 11 May 2016 (UTC)
[[
is typed. I'd add extra features for disambiguation. This had been identified as something to port over from Wikia by the Usability team. However, the issue is political. The foundation demands a Microsoft Word functionality from the editor—to be programmed in house (WTF, I hear half the people at WMF can't/unwilling use MediaWiki). Anything that touches the editor is basically a minefield. So to program this, I would need buy-in from several admins for default JavaScript. —
Dispenser 13:07, 14 May 2016 (UTC)
Fred Gandt ·
talk ·
contribs
02:48, 19 May 2016 (UTC){{u|
Checkingfax}} {
Talk}
11:39, 3 July 2016 (UTC)mw-disambig
. So for our purposes we could implement some JavaScript that checks the post-save markup. Obviously less ideal, but we could show a popup that they've entered a link to disambiguation page, and even highlight it, after they saved. Doing it beforehand is still doable but tricky. I can also be a smart ass and say if you just use VisualEditor you get the autocompletion and a little preview of what you're trying to link to! :) Overall this proposal is sensible, but I worry about it's effect on new users. I suspect many are going to think to themselves, "WTF is a disambiguation page?", and abort the edit altogether —
MusikAnimal
talk 00:12, 19 May 2016 (UTC)
A Request for Comment on a proposal to create a new user group with an abbreviated set of administrator user-rights, as an option for editors to request instead of requesting the entire sysop user-right package. I welcome everyone's thoughts on this. - jc37 21:12, 8 July 2016 (UTC)
I think that Wikipedia:Protected Page Editor needs to be revived, it's a few years old I don't think anybody participated in the voting. Thanks! DatNuttyWikipedian ( talk) 15:23, 10 July 2016 (UTC)
{{Template:Welcome-anon-constructive}} that's used to welcome constructive IP edits was originally for the purpose of IP edits that fight vandalism, and thus it contained a broom icon. But it's not just for anti-vandalism efforts anymore. I've used it today, and I was baffled as to why it uses a broom that makes it look like the edit made was swept, or needed cleanup, etc, until I looked at the template's history, in which the template originally said "I greatly appreciate your efforts to fight vandalism and make [sic] constructive edits on Wikipedia ." So I suggest using instead, or any other suitable image that conveys thanks and appreciation. — Hexafluoride ( talk) 11:23, 7 July 2016 (UTC)
Not sure where to post this but I just realized that the drop-down book template citation maker makes no provision for citing an article in an anthology or edited collection. I just added a new ref to the wikiarticle Joske's to replace a bad ref, and found there is no way to show both the article title and author and the book title and editor. Guess I've never cited a ref like this one before in my ten years on Wikipedia, but some of the wikiwizards ought to make it possible. As it stands, the new ref I added (#5) has the article author's name paired with the book title, which is just not right. Other than typing it all in the long way between <ref> marks, anyone have a better idea? Textorus ( talk) 15:52, 10 July 2016 (UTC)
I did use the Show/Hide button, but the extra fields just don't work the way you guys suggest. Go try it yourselves and see. Textorus ( talk) 18:31, 10 July 2016 (UTC)
How did you force it to accept all that? Or are you saying you just typed it in the old-fashioned way? Some IT person really needs to be alerted to fix the template so it will accept this kind of thing. Textorus ( talk) 20:54, 11 July 2016 (UTC)
I just looked through all 4 citation templates, using the show/hide button, and nowhere in any of them do I see a "contribution" field. Where are you seeing it, exactly? Textorus ( talk) 20:54, 12 July 2016 (UTC)
It's ridiculous that most experienced editors avoid requesting adminship because they don't want to go through the RfA process. After 5 reforms, no major changes have been made. I think with a final RfA reform, the process should be completely recreated. Something i'm proposing is the creation of "RfA guidelines", where certain topics cannot be discussed in the RfA (edit count, incidents that occurred 8 years ago, etc.) I think with a new RfA reform, the number of sysops will increase significantly. Additionally, i'm proposing that WP:RECALL be promoted to policy and be required for all sysops, making it easier for administrators to be desysopped. — Music1201 talk 22:40, 16 June 2016 (UTC)
References
I suspect this has been suggested before, but I haven't found it. My idea is to create a new class of users below that of admins, giving them admin rights only in one specific area, such as AfD, without the right to execute admin actions with WP-wide effects, such as block/ban. Candidates for this would not go through RfA, but some new system we design to be streamlined. This also allows us to target specific areas with a high backlog that are specifically in need of admins. This should even help RfA, as established junior-admins that then go through RfA would likely be judged on their history of admin tasks, rather than non-admin things like having 10k edits, five FAs, etc. -- A D Monroe III ( talk) 20:15, 19 June 2016 (UTC)
eliminator
group that gets: 'delete' , 'deleterevision' , 'mergehistory' , 'protect' , 'suppressredirect' , 'deletedtext'
). To be useful for just closing xfd's they would probably only require "delete" -- however that would mean that 'undoing' would require a full admin. As
Opabinia regalis said above, this has been proposed and rejected numerous times. I'm not as worried about inflation - but what you would almost certainly see would be RfA's saying "go try being an eliminator for a while, then reapply" to a large number of candidates. One thing that may make it easier is if the group came with a built in recall feature -- that may get more people to support it from the offset. —
xaosflux
Talk 20:57, 19 June 2016 (UTC)
I can think of several historical AfDs involving football players where consensus appeared to be leaning in one direction, and the closing admin (one of several prominent members of WP:FOOTY with rigid and outspoken views on the notability line) would make the call based on that line. If the keepers were supporting on WP:GNG and deleters on WP:NFOOTBALL, they'd delete. If in a discussion where the balance of arguments was identical, keepers were supporting on NFOOTBALL and deleters on GNG, they'd close as no consensus. Such decisions would not be overturned because the close was within the realms of discretion, but the point that the discretion was being so blatantly used as a supervote fell on deaf ears. I'm in no doubt whatsoever that people in other topic areas would have had similar experiences of admins with outspoken opinions on the way in which certain policies and guidelines should be applied.
As a result, I was always quite conservative in supporting RfAs, and am sure I was far from alone. If it were possible to overturn such discussions with no prejudice (i.e. go back to the status quo, without any cloud over the closing admin) and wait for a completely uninvolved admin, there'd be far fewer people with a big problem in giving trustworthy editors the tools in the first place. StillWaitingForConnection ( talk) 07:32, 25 June 2016 (UTC)
Since Xeno's radical idea didn't actually get any opposition, I thought it may be worth brainstorming how such a proposal might look. My rough sketch:
This would allow us to give an alternative to RFA a shot, while making sure it doesn't scale out of hand before we have a chance to evaluate its success or failure. If we decide we like the results, we would either remove the limit per crat, or maybe change it to be 5, per year, per crat. Obviously, for this to be implemented, it would require a full scale RFC, so lets just discuss some ideas here and not !Vote, though in feeling the water, it would still be helpful to know how many people are going to strongly oppose it in any form. Monty 845 23:20, 20 June 2016 (UTC)
In my view, this proposal is very much to let Crats pick some admins. Its not to create RFA light, or RFA with Crat super vote, as those would carry over many of the diverse problems that plague current RFA. One of the reasons reforms fail, is that while most agree there are problems, we don't agree on what specific things are problems, and thus can't agree on the specific solutions. The Beauty of having a Crat appointment option is that we don't need to decide on all those issues. If one Crat feels RFA is basically a hazing experience, and has extensive personal knowledge of an editor who would make a fine admin, but who wouldn't want to go through the hazing of RFA, they can just appoint the editor based on their own judgement and trust of the editor. If another Crat feels differently, and wants to hold a public discussion of their proposed admin, they can run it how they feel is best. Maybe some Crats want to hold a tribunal to make a joint decision. In supportng the idea, one is saying they trust the Crats enough to let them appoint some admins directly, and so we should also trust them to come up with their own standards for how those appointments are made. Likely we will want a place to allow public discussions if crats want them, and also to serve as a central place to request consideration if you don't already know a Crat personally. Monty 845 22:48, 21 June 2016 (UTC)
"The main thing from my end is that people don't get access to deleted content without going some some sort of RfC style process. We think it's important that there's a community decision-making process before that one opens up. On the other hand, if you want to give out limited rights such as allowing people to assist with deletions or article maintenance without being able to see deleted content, that's more flexible and could be determined by user consensus. "
But, if they are appointed by a small group of crats, and normal users are allowed to comment, it may work. ThePlatypusofDoom (Talk) 11:14, 22 June 2016 (UTC)
ThePlatypusofDoom (Talk) 17:50, 22 June 2016 (UTC)
Everyone needs to slow down a minute and take a step back. Nobody should be putting this into action without full consensus support from the community at large. I am talking about a RfC, a post at T:CENT, and a watchlist notice. This is a complete change to not only the 'crat mandate but also to the very way administrators are chosen. Even the one year trial period requires a fully advertised RfC in my mind. We also have not heard back from WMF-Legal about whether or not they will even support this radical change (in regards to the viewdelete right). There also needs to be concrete, defined, rules regarding 'crat appointments. I'm really uncomfortable with anyone just being able to flip the admin switch for someone without any community input at all. Yes 'crats have a high level of trust but that doesn't mean they don't make mistakes. A decision by one person ('crat or not) without any other input is not exactly Wikipedia-esque. We are built on community input, not on single, go-it-alone, changes.
So, to-do list (in my mind). 1) Formulate a RfC that clearly and precisely defines the procedures and protocols for the 'crat picking of administrators. 2) See if there is consensus to even do this. 3) Get a response from WMF-Legal regarding their views on this. 4) If, and only if, 1-3 fall into place should this be put into action. There is no need to rush this. Administrative tasks are still being performed. We are not in a situation where this needs to happen immediately. This sort of situation needs to be handled correctly and needs to have the full backing of the community at large. Not a hand full of editors. -- Majora ( talk) 02:30, 23 June 2016 (UTC)
Another horse that won't run. Instead of being out on the track (RFC) where it will be doomed it is sulking around here in the barn. Once this sees the light of day it will bomb - the community has rejected the idea of king makers in the past. Leaky Caldron 08:14, 23 June 2016 (UTC)
I won't characterise on the pros or contras to Xeno's suggestion, but it would be met with resistantce not only from the community but from many of the bureaucrats themelves in that that's not in the mandate they were elected for. I'll take his opportunity however to repeat my worn out mantra: 'Fix the voters and RfA will fix itself}}' . Kudpung กุดผึ้ง ( talk) 18:48, 23 June 2016 (UTC)
Of the 10 RfAs than ran to completion [as of 8 June 2015]:
Participants !voted in an average of 2.7 RfAs.
Just under half (46%) !voted in only one RfA.
The average edit count of the singleton voters is ~32,000. Most are identifiably experienced users.
Only 15 of the singleton voters currently have under 500 edits. Three of those are alternate or renamed accounts of experienced users.
You can't detect trolling, meanness, or poor research with 15 minutes and a regex, but I would say that the pattern of one-off drive-by participation, where a new collection of participants reset the standards every time, seems to have abated in recent experience.
No, it wouldn't, KSFT, because in that moment the damage is already done. It's the personal attacks, unreflected, unresearched conjecture, and othe disingenous votes for which RfA has a reputation which are putting off candidates of the right calibre from coming forward in the first place. We have to look at making RfA a safer environment - character assassinations are not cool. Except for attempts at RfA by trolls and vandals, most attempts are probably made in good faith whether the candidate has a clue or not and whether or not they have bothered to read the advice pages. StillWaitingForConnection, I'm not quite sure I fully understand your comment - one of the remedies I would like to see introduced is to restrict voting and commenting on RfA to editors who have at least 90 days tenure and 500 mainspace edits, which is a rule (or similar) practiced by other Wikipedias. Kudpung กุดผึ้ง ( talk) 17:48, 25 June 2016 (UTC)
Just a note to say that the bureaucrats have been pinged at BN to alert us to this discussion. I won't speak for the other Crats, but for myself I'm unlikely to participate in much in the discussion. We're elected to carry out community consensus and I'll always do just that. You might find me speaking up if a single proposal emerges that looks to have a decent chance of attracting sufficient support to be successful but I'm unclear about aspects of implementation or to clarify an apparent clash with existing policy etc. -- Dweller ( talk) Become old fashioned! 12:35, 24 June 2016 (UTC)
The quote from WMF Legal above only gives a partial picture. Copying this from Maggie's talk page: "I mentioned that another possibility being discussed was having bureaucrats vote on these appointees. This would satisfy the community overview requirements. :) -- Maggie Dennis (WMF)". (I'm not making a suggestion, just showing that the options are broader than the first quote suggests.) - Dank ( push to talk) 03:44, 26 June 2016 (UTC)
@ KSFT: The main problem I have, and I think this will be a problem that most people have, is that this proposal would allow 'crats to override community consensus in a way. Technically they could do that now by using their discretion and discounting !votes at RfA but they don't. The discretionary range is set and anything below that is an auto-fail. Reversing that is concerning to me. Yes, this proposal also allows for a community discussion period but what exactly would that entail? Are we talking similar to resysops? Here is 24 hours if no major concerns are raised here's your bit, try not to break the site?
Something else that has concerned me regarding this is
Xeno's original statement, I can think of at least one user who I'd flip the bit for immediately
. I paused after reading that and thought to myself, oh? Really? And who would that be? And why haven't they run for regular RfA? What is stopping them? Are they not running because of the atmosphere at RfA? Or are they not running because the community would reject them? If it is the latter (the community would reject them) then allowing 'crats to override that is really concerning.
I am completely open to changing my mind if and when a RfC comes out that outlines and addresses my concerns. But right now, without that RfC and with the uncertainty of it all, I am not exactly in the support column for this proposal. -- Majora ( talk) 20:11, 26 June 2016 (UTC)
I'm actually very surprised by the statement quoted above that a vote by the crats would suffice as "community review". No disrespect to the crats, who are very valuable long-term Sane People, but you'd have a hard time finding any other established group on Wikipedia that is less representative of the overall community. There's only 22 of them, many are at best semi-active, the most recent new cratting was in 2014, the youngest crat by account age joined in 2008, and (AFAIK) there are currently no women in the group. Those here who are considering an RfA-by-crat-vote proposal should take a look at what happened last year with WP:BARC (a proposal for crat-based desysopping) and what kinds of arguments were made there. Opabinia regalis ( talk) 21:10, 26 June 2016 (UTC)
A usergroup that had the ability to appoint admins. They would have to be in an RFA or something similar, and have the same standards of passing as crats—are you seriously suggesting we hold an election to elect people who will have the right to participate in future elections? This is not going to happen. Why are you so obsessed with the idea of creating cliques of super-users? ‑ Iridescent 12:04, 28 June 2016 (UTC)
Although unbundling individual tools is a perennial proposal, given the shortage of admins and increase in deletion-related backlogs, I think it'd be a net positive to have an eliminator
group described
above by
Xaosflux. I can see this as a right easily granted and just as easily revoked at discretion by current admins, similar to the processes in place for rollback and template editor. -
FASTILY 05:48, 30 June 2016 (UTC)
I like what Nsk92 said earlier about setting low levels of protection for pages. A semi-protector or protector group (able to semi-protect and pending-changes protect) seems like it could work. I know that proposals for unbundling the admin tools haven't worked out in the past, but this might work. ThePlatypusofDoom (Talk) 23:35, 3 July 2016 (UTC)
There are actually only a few things we really need admins for, at the "this requires a huge amount of community trust" level. Some examples:
Everything else can be spun off, as the already-unbundled tools demonstrate. Doomsayer predict terrible results every time, and they just don't happen. The community is much more mature now that it was when the "adminship legend" was created (I mean ours, not Jimbo's original WP:NOBIGDEAL). The Wikiapocalpyse doesn't happen when we unbundle even pretty hardcore-seeming tools (template editor, file mover, account creator, page mover), because the community is not collectively stupid, and institutes vetting processes and rules for usage, and tightens them over time as problems pop up. Even things like page protection can be spun out. Page protection was a huge deal when we were in the Great Article and Content Creation Phase of the 2000s, with way more editors, and way more work to do even on basic topics. These days, page protection rarely negatively impacts people who aren't being asshats, other that as a temporary inconvenience, and they do other productive things in the interim.
Anyone who's been around for a few years (actively editing), is not a moron/nutter, and doesn't have a huge block log or bunch of permanent topic bans, should be able to do anything useful here that cannot cause long-term problems in one swell foop. "But this would reduce the role, distinction, honor of being an admin!" Yes, it sure would, so we were more like all a bunch of editors again, a few taking on some additional (mostly dreary) responsibilities, instead of there being the present admin gentry and peon editor caste system. It is not working any more and hasn't been for a long time. But the more the split between editors and admins gets blurred, the less of a big deal adminship is, and the less RfA drama there will be (and fewer under-qualified people going through that wringer). — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 17:30, 6 July 2016 (UTC)
suppressredirect
has allowed me help out on several "maintenance"-type tasks that would have required an Admin before (and thus which I would have ignored before, and "let somebody else figure it out..."). The more we can empower experienced editors to do stuff like this, the better it is for the project. --
IJBall (
contribs •
talk) 15:41, 14 July 2016 (UTC)I think that WP:BLUELOCK should be added to WP:RFPP and added to the Twinke/Huggle/Other gadgets that allow protection requests. I understand that it is only used on pages designated by ArbCom at this time, but it probably will be expanded to community use. Any target page that has a high level of disruptive editing from standard confirmed users but is too commonly edited for full protection should be eligible for extended confirmed protection. U S A 17:27, 15 July 2016 (UTC)
I would like to share an idea, maybe it's suitable to post it here: i wonder why wikipedia uses the reference list ordered in the order by their appearance in the article, from beginning to end, but not alphabetically, by sources/author names, and useing the numbering in the text by alphabetically arranged and then numbered sources?
There's a method called alphanumeric citatations. I haven't yet seen this style in wikipedia, but i thought it would be useful and suitable, maybe even preferrable.
Currently dominantly used method gives an alphabetically randomly ordered reflist. This lets an editor to easily make repetitions while adding citations, because the citations list is visually hard to grasp (similar names doesn′t appear side by side and one could not see..). For example: article Moon, source Taylor, G. Jeffrey (31 December 1998). "Origin of the Earth and Moon". Planetary Science Research Discoveries. Retrieved 7 April 2010. two times; source Pahlevan, Kaveh; Stevenson, David (October 2007). "Equilibration in the Aftermath of the Lunar-forming Giant Impact". EPSL 262 (3–4): 438–449. arXiv:1012.5323. two times etc. Possibly almost all longer articles have this type of repetitions. If the list of citations would be alphanumerically ordered, an editor could see more easily when the repetitions happens - helping to avoid/detect unnessecities.
How about using of this "alphanumeric citations" style in wikipedia? -- Mustvalge ( talk) 22:11, 11 July 2016 (UTC)
J. Johnson (JJ) does not understand what i have to say and is unable for constructive communication. Please don't post here to show your attitude. -- Mustvalge ( talk) 09:15, 13 July 2016 (UTC)
Whenever I turn to categories to try to find an example to work from, for whatever purpose, I am almost always looking for a high caliber article. It seems to me it would be quite useful if featured and good articles showed up in categories flagged as such:
Anyway, if there was any support for this, the first question would be technical feasibility – about which I have no idea. If it's not technically feasible, then there's little use in talking about whether we might want this.-- Fuhghettaboutit ( talk) 21:50, 15 July 2016 (UTC)
.mw-category-generated .good-content:after {content:url(https://upload.wikimedia.org/wikipedia/en/thumb/9/94/Symbol_support_vote.svg/9px-Symbol_support_vote.svg.png);}
I'm proposing to run a series of contests/editathons for different regions of Africa, and potentially get the African wikipedias involved too. Probably the biggest thing we can do to address systematic bias on here. If anybody would be interested in winning $1000-1500 for improving/creating a bunch of articles on Northern Africa in October please sign up in the participants section at the bottom. Even if contests aren't your thing if you think you might like to contribute to an editathon add your name. If there's decent support on this it stands a good chance long term in tackling one of our weakest areas.♦ Dr. Blofeld 20:19, 20 July 2016 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Many page movers assist with technical move requests at WP:RM/TR. A large number of requests occur because the new desired title is blacklisted. Allowing page movers to override the title blacklist was previously proposed upon creation of the user group, but the community did not reach a consensus to allow page movers to override the title blacklist.
See Special:PermaLink/730146201 as an example. This request has been standing here for a full 24 hours with none of the 1300 administrators bothering to perform the move. — Music1201 talk 19:00, 16 July 2016 (UTC)
*Support There are a number of situations where I could've used this right recently, mainly in relation to uncontroversial technical requests at requested moves, but also in situations such as
this thread at AN, where the title was blacklisted.
Omni Flames (
talk) 22:41, 16 July 2016 (UTC) Moving to Oppose.
Omni Flames (
talk) 23:39, 17 July 2016 (UTC)
To be clear what comes with this permission, besides being able to move a page to a blacklisted page:
tboverride-account
instead of tboverride
, which means that they can only override the blacklist when creating new accounts. Would it be possible to create a new user right, called, say, tboverride-move
which only grants that ability when a page is being moved?
Omni Flames (
talk) 01:38, 17 July 2016 (UTC)
Since the example was placed above and not in the discussion section I am responding here. Got any examples of it taking weeks to perform a blacklisted move? 24 hours is not exactly helping your cause here (and it has been 12 hours by the way). There is no deadline and a request waiting a day is not reason enough to grant the complete overriding of the entire blacklist. There is zero reason that they can't wait. This isn't some instant gratification site where everything you want is done at the drop of a hat. -- Majora ( talk) 01:41, 17 July 2016 (UTC)
There is a discussion at the Edit Filter Noticeboard which may interest some editors here -- samtar talk or stalk 11:03, 22 July 2016 (UTC)
After researching the history of Wikipedia and talking via email to some former Wikipedians I have a few proposals which would improve Wikipedia
New protection level called 'semi extended confirm protection' which would require editors with at least 255 edits and an account that is at least 17 days old to edit articles that have this protection on them
Restricting the moving of pages to only administrators
Giving the threshold to be an administrator at 60 percent (same as it is to be an arbcom member). Also maybe have admins who get between 60 and 70 percent of the vote have a trial period where an experienced admin takes them under their wing.
Create a vandal bot who will block vandals who have been warned at least 3 times. Callan Eccleston ( talk) 22:13, 20 July 2016 (UTC)
Actually I think that Wikipedia should have a protection level in between Semi and Extended confirm called 'semi extended confirm' .To edit articles under this protection ,editors would need at least 255 edits and an account that is at least 17 days old. This is good because it would add flexibility to protection levels and stop admins from over protecting some pages with extended confirm (if there was an option like semi extended confirm'. Callan Eccleston ( talk) 03:01, 21 July 2016 (UTC)
Are there any gadgets which automate this process? An automated (again Twinkle-like) menu would probably save days to months of editing time. -- Tom (LT) ( talk) 02:32, 24 July 2016 (UTC)
IS there a gadget (like TWinkle) where I can click a button and implement auto-archiving on a talk page? This would be a lot less cumbersome than doing it manually. -- Tom (LT) ( talk) 23:59, 23 July 2016 (UTC)
Wikipedia:Ability_to_follow_subcategories_recursively — Preceding unsigned comment added by 65.93.215.245 ( talk) 18:30, 24 July 2016 (UTC)
This is an old gripe I've had with Wikipedia: the de-facto standard is inline bibliography and footnes. Editors are practically required to follow it, not just because of inertia, but mainly because all of the editing tools insert all bibliographic information right into the article body. A far better standard would be to separate the bibliographic data as well as any footnotes from the main content. This is already technically possible, via List-Defined Refs, or Sfn. However, it is neither encouraged nor promoted , so 99% of editors use the inline standard.
Here's why I think the current practice of putting everything inline is horrible:
<ref name= .../>
? I have to comb the entire article to find where the bibliographical information is stored.I propose to change the standard so that all bibliography and notes are placed into a dedicated block(s). Different articles can have different variations of this standard: one may use {{sfn}}
with a dedicated bibliography and another may use {{r}}
with just a reflist. Both of these are optimal because they allow a book to be cited multiple times with different page numbers without duplicating references. An article should specify which of these two is recommended, and the Visual Editor and citation wizard should change the markup accordingly. ProveIt (which shows the list of references persistently, even if they are in stored a different section of the document), should be enabled by default and hopefully upgraded to allow the {{sfn}}
style. Editors should be noted about the new policy.
Anyone else think this is reasonable? It is just so painful to read the existing markup that I feel something should be done about it. Guccisamsclub ( talk) 20:46, 18 July 2016 (UTC)
<ref>...</ref>
system is somewhat better than the methods that we had early on (see e.g.
Wikipedia:Footnote1), but I prefer {{
sfn}}
(see
Shortened footnotes). In a nutshell: Wikipedia does not prefer any ref style, and it's far too late to enforce anything. --
Redrose64 (
talk) 18:55, 18 July 2016 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
(This proposal started at Wikipedia:Village pump (idea lab)/Archive 20#Phone view and includes ideas and information given there)
Most editors change pages on their laptop but most readers check Wikipedia on their phone or tablet. What we see is not what the reader gets. An article full of info boxes and images may look good on a laptop and terrible on a smaller screen. An editor can resize their edit window to get a sense of how it would look, but most would not. Even if they did, they would not see the different layout presented on a mobile device (see screenshot to the right). Better to have a button at the bottom of the edit window that prompts the editor to preview how the article would look on a typical phone or tablet:
It should give the option to check the views on both a typical phone and a typical tablet, since a page with too many images may look o.k. on a phone, where the images fill the width of the screen and alternate with the text, but bad on a tablet where the text zig-zags around the images.
The effect of a "Mobile view" button may be seen in Google Chrome by pressing Ctrl-Shift-I and then Ctrl-Shift-M, which lets you try different devices such as Galaxy s5 and iPad. If you view Wikipedia with a vector skin (don't ask), you can see the phone (but not tablet) view by using the gadget in
Special:Preferences#mw-prefsection-gadgets "Mobile sidebar preview: show page in mobile view while browsing the desktop site". Or you can disable the gadget in preferences and copy importScript('User:קיפודנחש/mobile-sidebarcopy.js'); // Linkback:
User:קיפודנחש/mobile-sidebarcopy.js
to your User:xxx/common.js to get the same effect, but not for edit preview.
The new button would be easier to use than the gadget or script, and would encourage editors to check how the article looks to the normal reader. Comments? Aymatth2 ( talk) 13:55, 22 June 2016 (UTC)
There is an RfC on Meta about creating a noticeboard to help editors who have been sanctioned. Your input is welcome. Ca2james ( talk) 03:59, 28 July 2016 (UTC)
When you see a script/cite error, you took many minutes and hours to fix them. If there is an autofix gadget of script/cite error, you might be able to save time to correct these errors with one click. When you add this gadget, would a lot of people will be able to easily fix these errors.-- Ijoe2003 ( talk) 05:16, 28 July 2016 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
There is currently a discussion regarding activating a filter against the WMF content translation tool from creating pages on the English Wikipedia. Please see Wikipedia:Administrators'_noticeboard#Content_translator_tool_creating_nonsense_pages if you are interested. Thank you, — xaosflux Talk 00:36, 27 July 2016 (UTC)
I've been thinking for a while we should have someone who speaks for us. Jimmy Wales speaks for the whole Wikimedia movement including the foundation and other projects but his foundation board membership obliges him to put the foundation's interests before ours. I'd like us, the writers and builders at en.Wikipedia, to have someone who can speak for us with the foundation, other Wikimedia entities and the wider world. I can think of a couple of people who would fill that role well, and would love to have the opportunity to nominate them. -- Anthonyhcole ( talk · contribs · email) 12:22, 21 July 2016 (UTC)
Actually, there's more than a couple. I'd trust User:Opabinia regalis, User:Drmies, User:Newyorkbrad, User:Gorilla Warfare, User:Bishonen User:Keilana and many others with the role. They all have good sense and good knowledge of en.Wikipedia governance and society and some have public roles. User:Doc James and User:Daniel Mietchen are very engaged on the wikiprojects' behalf with outside institutions. -- Anthonyhcole ( talk · contribs · email) 13:22, 21 July 2016 (UTC)
Aren't there prior discussions about this??? Millbug talk 02:38, 23 July 2016 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Earlier today, an edit filter was enabled to restrict the Content Translation Tool. There is currently a proposal to lower the 5000-edit requirement for users who wish to use the tool. If you are interested, please see Wikipedia:Administrators'_noticeboard#Lower/Change_the_5000-Edit_Bar?.
Thank you, Tony Tan · talk 11:43, 28 July 2016 (UTC)
If you want to be able to generate complete references with a single click, then you can use this script: User:Ark25/RefScript but it works only for a limited number of sources (newspapers). If you are using Visual Editor, then mw:Citoid doesn't fill all the fields. We just need the WMF board to create a super-simple web standard and to promote it. In time, more and more publications will adopt the standard, because it will benefit them to be cited on Wikipedia. The people in the WMF board know people in the media and in the blogosphere so they can start moving things. Please support the proposal to implement this standard here: mw:Topic:T8ai4z0p2fcql0ot and then you won't waste huge amounts of time doing robotic tasks like copy-paste author, publication date, title in order to fill the thousands of references you add into articles. We need to get out of the Stone Age and if you support this proposal then we have better chances to succeed. Thanks. — Ark25 ( talk) 20:22, 23 July 2016 (UTC)
"Can't find the word "translator" in the Zotero article"- You can now; I just added Zotero#Translators. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:01, 31 July 2016 (UTC)
@ Whatamidoing (WMF): @ Czar: Sorry, I really don't mean to be rude but I feel exasperation right now. So I came here again, after two years, asking again for creating a super-tiny standard that require about maximum 15 minutes to create, and to try to talk with various people (including the W3C staff) and websites to implement them. Because I am extremely tired to update my script all the time. Please notice that websites like nytimes.com or bbc.com have about 10 different formatting styles for their data. So you need about 10 different translators just for one website(!). And they are adding another formatting style every couple of years. On top of that, sometimes they change the formatting style for all (or many) of their past articles. My script (RefScript) doesn't only work for Wikipedia, it works for any other site. I am using for quickly posting nicely formatted links (references) on forums too, so it's not only for Wikipedia references. My script generates a reference in 1 second, while Citoid is slower. RefScript (and WebRef too) is doing in the source editor what both Citoid and Zotero do together in the Visual Editor.
And now you are asking me to improve Citoid too by always teaching and updating Zotero just like I am doing with RefScript! Just like my script, in order to keep up with the changes, Zotero will accumulate gazillions of lines of code - this is not the solution, and we need a standard, that, in time, it will be adopted, slowly but steadily.
Sorry to ask this but do you people understand that this is a Sisyphean task (= a work that is pointless and that never ends) simply because the newspapers always add new formatting styles all the time and sometimes they even change the formatting style of the title, publication date and author name for all the articles published in the past? I am working at RefScript since 2011 and I really know what I am talking about. I am sick of having to update it all the time. That's why standards exist and are necessary, in order to make the people's life easier.
If there would be a standard like the one I am talking about, then, for the publications that implement it, both RefScript and Citoid would generate the full references without having to add any translator, rendering Zotero useless, or at least reducing it to a 10-lines script. Also RefScript would be reduced to a 10-lines script. Just like Zotero, RefScript contains tons of translators that would become unnecessary for the sites that implement the standard.
None in the WMF board have their own blog and they even don't know anyone having a blog to test such a tiny standard? Really???
Right now I feel like I want to cry. I feel like this a dialogue of deaf people :( — Ark25 ( talk) 21:36, 29 July 2016 (UTC)
There is an existing standard: COinS. See also the proposed citation microformat. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:11, 31 July 2016 (UTC)
@ Czar: It is 15 minutes. Here is the standard (let's call it OpenCite):
Now you can take another 15 minutes to add a few cosmetic changes and it's done.
In order for a translator to check more (mutliple) different RegEx, you have to actually include more translators into that translator. As I said, the more translators you add, the more work it needs to update them since the newspapers constantly change the way they format those fields (date, author, title). So adding translators is not the solution, but creating a standard that would render the translators useless is.
@ Whatamidoing (WMF): what you said there about standards does not apply here. There is no such existing standard at all, so there won't be any competing standards. That's the reason I came here after all - because such a standard does not exist yet. Obviously, if there would be such a standard, I wouldn't have asked to create a new one. And competition is good, a new and better standard has better chances to be adopted than a half-baked, existing standard. Also, according to what you are trying to say, the creation of HTML5, HTML4, HMTL3, CSS4, CSS3, etc was useless, since the HTML2 and CSS1 standards already existed - and that's clearly not the case. Is anyone being paid for writing code or to update Zotero, by the way? I wouldn't write translators for Zotero or for RefScript even if I would be paid for that.
You didn't answer to the question if there is any blog in the reach of the WMF board where such a standard can be tested. So I've created an html page as an example. Let's imagine that I have a news web site and this is a news that I've posted today: https://dl.dropboxusercontent.com/u/46152682/rude-wikipedian-flames-the-board-2016-07-31.htm
That html page is formatting the title, date, author's name and publication name according to the standard presented above. Now, for any other publication that uses this standard, Zotero and RefScript (and any other script) needs only a single translator. That means maximum 20 lines of JavaScript code that works for every single web site that adopts this standard.
@ Pigsonthewing: COinS seems to be a standard for bibliographic references (for books) - is there any way it can be used by news websites? How can I use COinS for example in the news article on my web site in order to specify the title, publication name, publication date and author's name?
Thanks. — Ark25 ( talk) 19:30, 31 July 2016 (UTC)
@ Pigsonthewing: Wikipedia:WikiProject Microformats/citation looks very much like a standard that I'm asking for. However, I don't understand the role of class="reference-accessdate". This is an element specific only to Wikipedia references, I don't see the point for a newspaper to include such a field. Daily Mail has a somewhat related field: <span class="article-timestamp-label">Updated:</span> 19:35 GMT, 31 July 2016 - for example in this article. But "reference-accessdate" depends on when a Wikipedian creates a referece, and the newspaper can not predict when that will happen. — Ark25 ( talk) 21:01, 31 July 2016 (UTC)
I've just noticed that the user Pigsonthewing worked as a Wikimedian in Residence for the Royal Society of Chemistry, Thinktank, Birmingham Science Museum and many other institutions. Those institutions have news feeds - for example this section - http://www.rsc.org/news-events/articles/ - here is an example article - http://www.rsc.org/news-events/articles/2016/jul/uk-science-and-the-eu/
Since Wikipedia and those institutions already have a very good relation, it's extremely hard to believe that they won't implement the OpenCite standard or Pigsonthewing's citation standard — hCite(or COinS - if COinS can be used here) on such news, if the WMF board would ask them to do that. In time, more and more sites and publications would adopt the standard. — Ark25 ( talk) 20:32, 31 July 2016 (UTC)
There's another "standard" that's quite widespread now for scholarly publications: the one required for inclusion in Google Scholar (it is of course supported by the Zotero translators, hence Citoid). I doubt the WMF would have enough leverage to push for yet another standard which would be redundant with COinS or Dublin Core meta tags. Webmasters will only follow guidelines if they have a very clear interest to do so (for instance, inclusion in Google Scholar). − Pintoch ( talk) 17:22, 1 August 2016 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I'd wish to propose that the lower age limit for those serving on the Arbitration Committee be raised. Few other organisations or companies of Wikipedia's size, challenges, or assets would have Board Members in their early twenties. Twenty year olds, however capable, and intellectually and emotionally mature, lack the life experience and emotional experience necessary for optimum judgement on many of the sometimes stressful and fine grained issues that face the Committee. It is unfair on them, and it is not right for the project. I propose the age limit for Committee membership be 30 and upwards, but certainly at least older than what the current limit is. Engleham ( talk) 08:38, 3 August 2016 (UTC)
I've SNOW closed this, but {{ Archive top}} doesn't seem to like my sig. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:05, 3 August 2016 (UTC)
Hi, if anybody thinks they might be interested in working on some Frank Sinatra related articles feel free to sign up. At present it's just something to loosely tie a lot of material together and help organize it.♦ Dr. Blofeld 11:38, 5 August 2016 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
In conflict related pages, experienced editors often give DS alerts to new editors. Sometimes, this is being misused to scare new editors. New editors get confused seeing such notices on their talk page. This is a form of WP:BITE. Any new editor with a clean block and not more than two warnings in their talk page, should not be given such DS alerts.
Proposal- If any experienced editor gives Discretionary sanction alert on the talk page of new editor with a clean block log and no history of warnings as edit-warring, personal attacks, then the experienced editor should be blocked for WP:BITE. -- 1.39.38.230 ( talk) 15:07, 5 August 2016 (UTC)
Snow no per TransporterMan. These notices are information, not biting, and that is clearly stated. In any case, biting is not blockable. ― Mandruss ☎ 18:16, 5 August 2016 (UTC)
There could be a preference called "Display a green bullet next to the 'Watchlist' button to indicate one changed page in your watchlist", which could be useful to keep editors motivated in seeing what is going on.
Gamingforfun365
(talk) 22:31, 4 August 2016 (UTC)
As the above is a regular topic on the MP talk page, could a 'separate page for such discussions' be created - there appears to be some support for the idea.
Ideas when ready for general discussion (such as that involving linking the pictures to the topic on the list) can #then# be posted to the MP TP. Jackiespeel ( talk) 17:54, 11 August 2016 (UTC)
mode=packed
by default?This discussion has demonstrated that mode=packed is advantageous in many but not all situations. There is insufficient consensus to change the default behaviour and many editors have suggested splitting the default of desktop (default traditional) and mobile (default packed) versions. Editors are welcome to change instances of galleries to packed mode as they see fit. The decision on default mobile behaviour is left for a separate straw poll. Deryck C. 12:29, 21 September 2016 (UTC)
Galleries currently use mode=traditional
by default, producing a gallery like this:
Should they be change to use mode=packed
by default, as below?
(pictures from Wikipedia:Featured pictures/Fungi) — crh 23 ( Talk) 12:29, 24 June 2016 (UTC)
TRADITIONAL MODE | - - - - - - - - | PACKED MODE |
|
- - - - - - - - |
|
You would never see a printed encyclopedia with such a poor caption layout. The purpose of PACKED mode is to cram as many pictures and captions onto a webpage as possible, like sardines packed in cans. This is just a bad idea for WP.
Additionally, on a personal opinion level it may seem trivial but I actually like the traditional look. It reminds me of old-fashioned film slides which were often used in schoolrooms and laboratories before the advent of digital projectors. Somehow these just feel more "academic" to this old bear, and I am of the opinion that an academic feel is the right feel for an encyclopedia. Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 17:17, 19 July 2016 (UTC)
I've notified WikiProject Visual arts of this here. Bus stop ( talk) 17:22, 24 June 2016 (UTC)
mode=
being specified) and add mode=traditional
by bot. Would that suffice?
Adam Cuerden (
talk) 19:41, 24 June 2016 (UTC)
mode=traditional
? That seems like a good compromise to me. —
crh 23 (
Talk) 21:05, 24 June 2016 (UTC)-- [[
User:Edokter]] {{
talk}}
16:42, 25 June 2016 (UTC)
Standard gallery with heights and widths optimized:
Packed
| | | | |
Packed mode
Current default gallery:
Test, mode=nolines:
"be handled on a case-by-case basis"then what is the purpose of using such a mode as "default"? Aren't the concepts of default and customized diametrically opposed or perhaps even mutually exclusive? Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 10:34, 20 July 2016 (UTC)
Please accept my deepest apology for this edit, and my sincere gratitude to Redrose64 for reversing it. I am utterly clueless how that happened and deeply sorry that it did. The only thing I was trying to do is add a comment in reply to Kusma's statement (see the Line 485 section in the diff) -- the "doesn't make sense" edit summary was describing that comment -- but somehow I royally screwed up and I am so very sorry. I would never intentionally delete another editor's comments. I have in fact counseled others on the evil of that behavior. My mind was boggled at how this could have happened. If you look at the Line 456 & Line 469 sections of the diff you will see quite a bit of text being added so it is even more confusing as to what occured. In the end it does not actually matter how this happened, only that it should not have happened, that it was not intentional, and I am truly sorry that it happened at all. -- Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 17:24, 20 July 2016 (UTC)
|
code=packed
the default, not due to the way the pictures are presented (which I am quite partial to in most cases), but due to the mess it tends to make of captions. I would propose mode=nolines
as an alternative, but it looks like the captions are not vertically aligned on that, which is also inferior. I still think mode=traditional
looks a bit odd (I don't like grids!), but at the current time I can't see a good alternative for default. —
crh 23 (
Talk) 19:02, 20 July 2016 (UTC)Selection of random images, shown in mode=packed
(captions are the file name)
To see these images (and others) in the current default mode, see Wikimedia Commons, Category:Images, Media in category "Images". The assumption that disparate aspect ratios exist only (or predominantly) in the visual arts is erroneous. Coldcreation ( talk) 12:40, 3 July 2016 (UTC)
$mode = "framed";
with $mode = "packed";
in one place that deals with mobile galleries. Caching should not be a concern when the change is made in just one place. The possibility should not be dismissed out of hand if there is consensus here that it would be a real improvement.
Aymatth2 (
talk) 10:56, 5 July 2016 (UTC)widths=
and heights=
parameters set as well.
Adam Cuerden (
talk) 22:27, 15 July 2016 (UTC)
Packed mode with upright panoramic images (selected from here). Note the streaming down of captions, here simply the file name, rendered non-readable.
Packed mode with horizontal panoramic images (from here). Note the enormous size of the images, unsuitable for a gallery presentation.
Packed mode with horizontal and upright panoramic images. Note that both problems observed above are compounded here.
Traditional mode with horizontal and upright panoramic images. Note, images are homogeneous in size, captions are readable, the viewer can click to enlarge. Perfect for a hypothetical gallery presentation.
Coldcreation ( talk) 15:45, 16 July 2016 (UTC)
These are also hardly realistic examples. Show me one extant gallery that looks at all like the last one, and I'll show you a gallery that should've been hand-tweaked years ago. Adam Cuerden ( talk) 14:29, 16 July 2016 (UTC)
I guess there is something we could do serverside to improve the concernes surrounding 'thin' elements in packed mode. First, we could set a minimum width on a thumbnail, so that it will never be smaller than say 100px. This would improve the visibility of the text, but would break up the 'packedness' of the packed mode. Then again, if you are adding thumbnails less wide than 100px, you are already doing something wrong in my opinion (adding an almost indistinguishable image), and this would just be a 'safesty net'. Call it the readability-over-prettyness option. An alternative would be to detect when the width of a thumbnail is below 100px, and automatically adapt heights to make sure the width is at least 100px. That might have some technical blockers however. Can't be sure until I have looked further into that. — TheDJ ( talk • contribs) 20:27, 4 July 2016 (UTC)
The largest drawback of the traditional layout seems to be the gery grid. As one editor pointed out, Tufte's advice is to get rid of decorative "ink" that doesn't provide information. If you get rid of the grey box, you get the improved looks of the packed version without the drawbacks of distorted captions and messy layout of irregular images.
You can give it a try yourself - if you squint slightly and look at the traditional layout, the grey lines vanish and you'll get a glimpse of the result, which looks like an orderly version of the packed layout with more white space and more regular captions. Diego ( talk) 08:58, 20 July 2016 (UTC)
Hello, I would like to create two wikipedia based keyboard shortcut layouts. They would cover the two Wikipedia implementations for editing 1) Source Editor and 2) VisualEditor. Here are the specifics I need help on:
The items above are BASIC ideas, please let me know of anything else that you can think of while reviewing this workup.
Here is the link for BOTH the 'Source Editor' and 'VisualEditor' shortcuts DRAFT;
http://vwanweb.blogspot.com/2016/07/wikipedia-shortcuts-source-edit.html
I have an idea to create a combined color and Color Blind friendly version by applying different stroke (boundary) styles to a given set of keys that make up a 'group of keys'. As an example all Site Navigation Keys will be enclosed with brackets [ X ], while Current Article Tools would be completely enclosed in a rectangle, see graphic link above.
Your feedback is welcomed.
Vwanweb ( talk) 08:03, 5 August 2016 (UTC)
VisualEditor 01 and Source Editor 02 Shortcuts
VisualEditor draft 01 notes:
Source Editor draft 02 notes:
Any and all feedback is appreciated, please help.
Vwanweb (
talk) 01:07, 9 August 2016 (UTC)
If Ctrl-[ is really a Visual Editor shortcut, it's a terrible one. What, for example, am I meant to press? Alt Gr-8 is the [ on my keyboard. The / shortcuts also don't work as well when / is Shift+7. Adam Cuerden ( talk) 10:39, 13 August 2016 (UTC)
This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212
Since many Wikipedia medical aticles may hhavve bbeeeen editeteddpeo by non-professssionals, shoulld there be a tag heading these articles clarifying this??#02:30, 3 July 2016 (UTC) Vorbee ( talk)
I noticed that celebrities who are members of the Scientology religion are identified as "religion: Scientology", yet celebrities who are followers of the Jewish, Muslim, Christian and other religions have nothing in their bios about their religious beliefs.
I propose that all celebrities' religions be identified. — Preceding unsigned comment added by SmudgeTheDragon ( talk • contribs) 17:25, 4 July 2016
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
As INTDAB indicates, links in mainspace to disambiguation pages are usually (but not always) wrong. DPL bot does a great job of catching these links when they are added, and letting the editor know on their talk page, but, as Wikipedia:Disambiguation pages with links makes clear, there is significant non-response to these bot messages. It seems to me that we would have greater compliance if we could intercede before changes are saved.
I propose a high-attention message and two buttons that appear when "Save" is clicked (with the exception of disambiguation pages, which often intentionally link to other disambiguation pages), modeled on DPL bot, e.g.: "You have added [a link|links] pointing to the disambiguation page[s] [X, Y, and Z]. Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles." Buttons: [Return to edit][Save anyway]. So:
— swpb T 19:59, 11 May 2016 (UTC)
[[
is typed. I'd add extra features for disambiguation. This had been identified as something to port over from Wikia by the Usability team. However, the issue is political. The foundation demands a Microsoft Word functionality from the editor—to be programmed in house (WTF, I hear half the people at WMF can't/unwilling use MediaWiki). Anything that touches the editor is basically a minefield. So to program this, I would need buy-in from several admins for default JavaScript. —
Dispenser 13:07, 14 May 2016 (UTC)
Fred Gandt ·
talk ·
contribs
02:48, 19 May 2016 (UTC){{u|
Checkingfax}} {
Talk}
11:39, 3 July 2016 (UTC)mw-disambig
. So for our purposes we could implement some JavaScript that checks the post-save markup. Obviously less ideal, but we could show a popup that they've entered a link to disambiguation page, and even highlight it, after they saved. Doing it beforehand is still doable but tricky. I can also be a smart ass and say if you just use VisualEditor you get the autocompletion and a little preview of what you're trying to link to! :) Overall this proposal is sensible, but I worry about it's effect on new users. I suspect many are going to think to themselves, "WTF is a disambiguation page?", and abort the edit altogether —
MusikAnimal
talk 00:12, 19 May 2016 (UTC)
A Request for Comment on a proposal to create a new user group with an abbreviated set of administrator user-rights, as an option for editors to request instead of requesting the entire sysop user-right package. I welcome everyone's thoughts on this. - jc37 21:12, 8 July 2016 (UTC)
I think that Wikipedia:Protected Page Editor needs to be revived, it's a few years old I don't think anybody participated in the voting. Thanks! DatNuttyWikipedian ( talk) 15:23, 10 July 2016 (UTC)
{{Template:Welcome-anon-constructive}} that's used to welcome constructive IP edits was originally for the purpose of IP edits that fight vandalism, and thus it contained a broom icon. But it's not just for anti-vandalism efforts anymore. I've used it today, and I was baffled as to why it uses a broom that makes it look like the edit made was swept, or needed cleanup, etc, until I looked at the template's history, in which the template originally said "I greatly appreciate your efforts to fight vandalism and make [sic] constructive edits on Wikipedia ." So I suggest using instead, or any other suitable image that conveys thanks and appreciation. — Hexafluoride ( talk) 11:23, 7 July 2016 (UTC)
Not sure where to post this but I just realized that the drop-down book template citation maker makes no provision for citing an article in an anthology or edited collection. I just added a new ref to the wikiarticle Joske's to replace a bad ref, and found there is no way to show both the article title and author and the book title and editor. Guess I've never cited a ref like this one before in my ten years on Wikipedia, but some of the wikiwizards ought to make it possible. As it stands, the new ref I added (#5) has the article author's name paired with the book title, which is just not right. Other than typing it all in the long way between <ref> marks, anyone have a better idea? Textorus ( talk) 15:52, 10 July 2016 (UTC)
I did use the Show/Hide button, but the extra fields just don't work the way you guys suggest. Go try it yourselves and see. Textorus ( talk) 18:31, 10 July 2016 (UTC)
How did you force it to accept all that? Or are you saying you just typed it in the old-fashioned way? Some IT person really needs to be alerted to fix the template so it will accept this kind of thing. Textorus ( talk) 20:54, 11 July 2016 (UTC)
I just looked through all 4 citation templates, using the show/hide button, and nowhere in any of them do I see a "contribution" field. Where are you seeing it, exactly? Textorus ( talk) 20:54, 12 July 2016 (UTC)
It's ridiculous that most experienced editors avoid requesting adminship because they don't want to go through the RfA process. After 5 reforms, no major changes have been made. I think with a final RfA reform, the process should be completely recreated. Something i'm proposing is the creation of "RfA guidelines", where certain topics cannot be discussed in the RfA (edit count, incidents that occurred 8 years ago, etc.) I think with a new RfA reform, the number of sysops will increase significantly. Additionally, i'm proposing that WP:RECALL be promoted to policy and be required for all sysops, making it easier for administrators to be desysopped. — Music1201 talk 22:40, 16 June 2016 (UTC)
References
I suspect this has been suggested before, but I haven't found it. My idea is to create a new class of users below that of admins, giving them admin rights only in one specific area, such as AfD, without the right to execute admin actions with WP-wide effects, such as block/ban. Candidates for this would not go through RfA, but some new system we design to be streamlined. This also allows us to target specific areas with a high backlog that are specifically in need of admins. This should even help RfA, as established junior-admins that then go through RfA would likely be judged on their history of admin tasks, rather than non-admin things like having 10k edits, five FAs, etc. -- A D Monroe III ( talk) 20:15, 19 June 2016 (UTC)
eliminator
group that gets: 'delete' , 'deleterevision' , 'mergehistory' , 'protect' , 'suppressredirect' , 'deletedtext'
). To be useful for just closing xfd's they would probably only require "delete" -- however that would mean that 'undoing' would require a full admin. As
Opabinia regalis said above, this has been proposed and rejected numerous times. I'm not as worried about inflation - but what you would almost certainly see would be RfA's saying "go try being an eliminator for a while, then reapply" to a large number of candidates. One thing that may make it easier is if the group came with a built in recall feature -- that may get more people to support it from the offset. —
xaosflux
Talk 20:57, 19 June 2016 (UTC)
I can think of several historical AfDs involving football players where consensus appeared to be leaning in one direction, and the closing admin (one of several prominent members of WP:FOOTY with rigid and outspoken views on the notability line) would make the call based on that line. If the keepers were supporting on WP:GNG and deleters on WP:NFOOTBALL, they'd delete. If in a discussion where the balance of arguments was identical, keepers were supporting on NFOOTBALL and deleters on GNG, they'd close as no consensus. Such decisions would not be overturned because the close was within the realms of discretion, but the point that the discretion was being so blatantly used as a supervote fell on deaf ears. I'm in no doubt whatsoever that people in other topic areas would have had similar experiences of admins with outspoken opinions on the way in which certain policies and guidelines should be applied.
As a result, I was always quite conservative in supporting RfAs, and am sure I was far from alone. If it were possible to overturn such discussions with no prejudice (i.e. go back to the status quo, without any cloud over the closing admin) and wait for a completely uninvolved admin, there'd be far fewer people with a big problem in giving trustworthy editors the tools in the first place. StillWaitingForConnection ( talk) 07:32, 25 June 2016 (UTC)
Since Xeno's radical idea didn't actually get any opposition, I thought it may be worth brainstorming how such a proposal might look. My rough sketch:
This would allow us to give an alternative to RFA a shot, while making sure it doesn't scale out of hand before we have a chance to evaluate its success or failure. If we decide we like the results, we would either remove the limit per crat, or maybe change it to be 5, per year, per crat. Obviously, for this to be implemented, it would require a full scale RFC, so lets just discuss some ideas here and not !Vote, though in feeling the water, it would still be helpful to know how many people are going to strongly oppose it in any form. Monty 845 23:20, 20 June 2016 (UTC)
In my view, this proposal is very much to let Crats pick some admins. Its not to create RFA light, or RFA with Crat super vote, as those would carry over many of the diverse problems that plague current RFA. One of the reasons reforms fail, is that while most agree there are problems, we don't agree on what specific things are problems, and thus can't agree on the specific solutions. The Beauty of having a Crat appointment option is that we don't need to decide on all those issues. If one Crat feels RFA is basically a hazing experience, and has extensive personal knowledge of an editor who would make a fine admin, but who wouldn't want to go through the hazing of RFA, they can just appoint the editor based on their own judgement and trust of the editor. If another Crat feels differently, and wants to hold a public discussion of their proposed admin, they can run it how they feel is best. Maybe some Crats want to hold a tribunal to make a joint decision. In supportng the idea, one is saying they trust the Crats enough to let them appoint some admins directly, and so we should also trust them to come up with their own standards for how those appointments are made. Likely we will want a place to allow public discussions if crats want them, and also to serve as a central place to request consideration if you don't already know a Crat personally. Monty 845 22:48, 21 June 2016 (UTC)
"The main thing from my end is that people don't get access to deleted content without going some some sort of RfC style process. We think it's important that there's a community decision-making process before that one opens up. On the other hand, if you want to give out limited rights such as allowing people to assist with deletions or article maintenance without being able to see deleted content, that's more flexible and could be determined by user consensus. "
But, if they are appointed by a small group of crats, and normal users are allowed to comment, it may work. ThePlatypusofDoom (Talk) 11:14, 22 June 2016 (UTC)
ThePlatypusofDoom (Talk) 17:50, 22 June 2016 (UTC)
Everyone needs to slow down a minute and take a step back. Nobody should be putting this into action without full consensus support from the community at large. I am talking about a RfC, a post at T:CENT, and a watchlist notice. This is a complete change to not only the 'crat mandate but also to the very way administrators are chosen. Even the one year trial period requires a fully advertised RfC in my mind. We also have not heard back from WMF-Legal about whether or not they will even support this radical change (in regards to the viewdelete right). There also needs to be concrete, defined, rules regarding 'crat appointments. I'm really uncomfortable with anyone just being able to flip the admin switch for someone without any community input at all. Yes 'crats have a high level of trust but that doesn't mean they don't make mistakes. A decision by one person ('crat or not) without any other input is not exactly Wikipedia-esque. We are built on community input, not on single, go-it-alone, changes.
So, to-do list (in my mind). 1) Formulate a RfC that clearly and precisely defines the procedures and protocols for the 'crat picking of administrators. 2) See if there is consensus to even do this. 3) Get a response from WMF-Legal regarding their views on this. 4) If, and only if, 1-3 fall into place should this be put into action. There is no need to rush this. Administrative tasks are still being performed. We are not in a situation where this needs to happen immediately. This sort of situation needs to be handled correctly and needs to have the full backing of the community at large. Not a hand full of editors. -- Majora ( talk) 02:30, 23 June 2016 (UTC)
Another horse that won't run. Instead of being out on the track (RFC) where it will be doomed it is sulking around here in the barn. Once this sees the light of day it will bomb - the community has rejected the idea of king makers in the past. Leaky Caldron 08:14, 23 June 2016 (UTC)
I won't characterise on the pros or contras to Xeno's suggestion, but it would be met with resistantce not only from the community but from many of the bureaucrats themelves in that that's not in the mandate they were elected for. I'll take his opportunity however to repeat my worn out mantra: 'Fix the voters and RfA will fix itself}}' . Kudpung กุดผึ้ง ( talk) 18:48, 23 June 2016 (UTC)
Of the 10 RfAs than ran to completion [as of 8 June 2015]:
Participants !voted in an average of 2.7 RfAs.
Just under half (46%) !voted in only one RfA.
The average edit count of the singleton voters is ~32,000. Most are identifiably experienced users.
Only 15 of the singleton voters currently have under 500 edits. Three of those are alternate or renamed accounts of experienced users.
You can't detect trolling, meanness, or poor research with 15 minutes and a regex, but I would say that the pattern of one-off drive-by participation, where a new collection of participants reset the standards every time, seems to have abated in recent experience.
No, it wouldn't, KSFT, because in that moment the damage is already done. It's the personal attacks, unreflected, unresearched conjecture, and othe disingenous votes for which RfA has a reputation which are putting off candidates of the right calibre from coming forward in the first place. We have to look at making RfA a safer environment - character assassinations are not cool. Except for attempts at RfA by trolls and vandals, most attempts are probably made in good faith whether the candidate has a clue or not and whether or not they have bothered to read the advice pages. StillWaitingForConnection, I'm not quite sure I fully understand your comment - one of the remedies I would like to see introduced is to restrict voting and commenting on RfA to editors who have at least 90 days tenure and 500 mainspace edits, which is a rule (or similar) practiced by other Wikipedias. Kudpung กุดผึ้ง ( talk) 17:48, 25 June 2016 (UTC)
Just a note to say that the bureaucrats have been pinged at BN to alert us to this discussion. I won't speak for the other Crats, but for myself I'm unlikely to participate in much in the discussion. We're elected to carry out community consensus and I'll always do just that. You might find me speaking up if a single proposal emerges that looks to have a decent chance of attracting sufficient support to be successful but I'm unclear about aspects of implementation or to clarify an apparent clash with existing policy etc. -- Dweller ( talk) Become old fashioned! 12:35, 24 June 2016 (UTC)
The quote from WMF Legal above only gives a partial picture. Copying this from Maggie's talk page: "I mentioned that another possibility being discussed was having bureaucrats vote on these appointees. This would satisfy the community overview requirements. :) -- Maggie Dennis (WMF)". (I'm not making a suggestion, just showing that the options are broader than the first quote suggests.) - Dank ( push to talk) 03:44, 26 June 2016 (UTC)
@ KSFT: The main problem I have, and I think this will be a problem that most people have, is that this proposal would allow 'crats to override community consensus in a way. Technically they could do that now by using their discretion and discounting !votes at RfA but they don't. The discretionary range is set and anything below that is an auto-fail. Reversing that is concerning to me. Yes, this proposal also allows for a community discussion period but what exactly would that entail? Are we talking similar to resysops? Here is 24 hours if no major concerns are raised here's your bit, try not to break the site?
Something else that has concerned me regarding this is
Xeno's original statement, I can think of at least one user who I'd flip the bit for immediately
. I paused after reading that and thought to myself, oh? Really? And who would that be? And why haven't they run for regular RfA? What is stopping them? Are they not running because of the atmosphere at RfA? Or are they not running because the community would reject them? If it is the latter (the community would reject them) then allowing 'crats to override that is really concerning.
I am completely open to changing my mind if and when a RfC comes out that outlines and addresses my concerns. But right now, without that RfC and with the uncertainty of it all, I am not exactly in the support column for this proposal. -- Majora ( talk) 20:11, 26 June 2016 (UTC)
I'm actually very surprised by the statement quoted above that a vote by the crats would suffice as "community review". No disrespect to the crats, who are very valuable long-term Sane People, but you'd have a hard time finding any other established group on Wikipedia that is less representative of the overall community. There's only 22 of them, many are at best semi-active, the most recent new cratting was in 2014, the youngest crat by account age joined in 2008, and (AFAIK) there are currently no women in the group. Those here who are considering an RfA-by-crat-vote proposal should take a look at what happened last year with WP:BARC (a proposal for crat-based desysopping) and what kinds of arguments were made there. Opabinia regalis ( talk) 21:10, 26 June 2016 (UTC)
A usergroup that had the ability to appoint admins. They would have to be in an RFA or something similar, and have the same standards of passing as crats—are you seriously suggesting we hold an election to elect people who will have the right to participate in future elections? This is not going to happen. Why are you so obsessed with the idea of creating cliques of super-users? ‑ Iridescent 12:04, 28 June 2016 (UTC)
Although unbundling individual tools is a perennial proposal, given the shortage of admins and increase in deletion-related backlogs, I think it'd be a net positive to have an eliminator
group described
above by
Xaosflux. I can see this as a right easily granted and just as easily revoked at discretion by current admins, similar to the processes in place for rollback and template editor. -
FASTILY 05:48, 30 June 2016 (UTC)
I like what Nsk92 said earlier about setting low levels of protection for pages. A semi-protector or protector group (able to semi-protect and pending-changes protect) seems like it could work. I know that proposals for unbundling the admin tools haven't worked out in the past, but this might work. ThePlatypusofDoom (Talk) 23:35, 3 July 2016 (UTC)
There are actually only a few things we really need admins for, at the "this requires a huge amount of community trust" level. Some examples:
Everything else can be spun off, as the already-unbundled tools demonstrate. Doomsayer predict terrible results every time, and they just don't happen. The community is much more mature now that it was when the "adminship legend" was created (I mean ours, not Jimbo's original WP:NOBIGDEAL). The Wikiapocalpyse doesn't happen when we unbundle even pretty hardcore-seeming tools (template editor, file mover, account creator, page mover), because the community is not collectively stupid, and institutes vetting processes and rules for usage, and tightens them over time as problems pop up. Even things like page protection can be spun out. Page protection was a huge deal when we were in the Great Article and Content Creation Phase of the 2000s, with way more editors, and way more work to do even on basic topics. These days, page protection rarely negatively impacts people who aren't being asshats, other that as a temporary inconvenience, and they do other productive things in the interim.
Anyone who's been around for a few years (actively editing), is not a moron/nutter, and doesn't have a huge block log or bunch of permanent topic bans, should be able to do anything useful here that cannot cause long-term problems in one swell foop. "But this would reduce the role, distinction, honor of being an admin!" Yes, it sure would, so we were more like all a bunch of editors again, a few taking on some additional (mostly dreary) responsibilities, instead of there being the present admin gentry and peon editor caste system. It is not working any more and hasn't been for a long time. But the more the split between editors and admins gets blurred, the less of a big deal adminship is, and the less RfA drama there will be (and fewer under-qualified people going through that wringer). — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 17:30, 6 July 2016 (UTC)
suppressredirect
has allowed me help out on several "maintenance"-type tasks that would have required an Admin before (and thus which I would have ignored before, and "let somebody else figure it out..."). The more we can empower experienced editors to do stuff like this, the better it is for the project. --
IJBall (
contribs •
talk) 15:41, 14 July 2016 (UTC)I think that WP:BLUELOCK should be added to WP:RFPP and added to the Twinke/Huggle/Other gadgets that allow protection requests. I understand that it is only used on pages designated by ArbCom at this time, but it probably will be expanded to community use. Any target page that has a high level of disruptive editing from standard confirmed users but is too commonly edited for full protection should be eligible for extended confirmed protection. U S A 17:27, 15 July 2016 (UTC)
I would like to share an idea, maybe it's suitable to post it here: i wonder why wikipedia uses the reference list ordered in the order by their appearance in the article, from beginning to end, but not alphabetically, by sources/author names, and useing the numbering in the text by alphabetically arranged and then numbered sources?
There's a method called alphanumeric citatations. I haven't yet seen this style in wikipedia, but i thought it would be useful and suitable, maybe even preferrable.
Currently dominantly used method gives an alphabetically randomly ordered reflist. This lets an editor to easily make repetitions while adding citations, because the citations list is visually hard to grasp (similar names doesn′t appear side by side and one could not see..). For example: article Moon, source Taylor, G. Jeffrey (31 December 1998). "Origin of the Earth and Moon". Planetary Science Research Discoveries. Retrieved 7 April 2010. two times; source Pahlevan, Kaveh; Stevenson, David (October 2007). "Equilibration in the Aftermath of the Lunar-forming Giant Impact". EPSL 262 (3–4): 438–449. arXiv:1012.5323. two times etc. Possibly almost all longer articles have this type of repetitions. If the list of citations would be alphanumerically ordered, an editor could see more easily when the repetitions happens - helping to avoid/detect unnessecities.
How about using of this "alphanumeric citations" style in wikipedia? -- Mustvalge ( talk) 22:11, 11 July 2016 (UTC)
J. Johnson (JJ) does not understand what i have to say and is unable for constructive communication. Please don't post here to show your attitude. -- Mustvalge ( talk) 09:15, 13 July 2016 (UTC)
Whenever I turn to categories to try to find an example to work from, for whatever purpose, I am almost always looking for a high caliber article. It seems to me it would be quite useful if featured and good articles showed up in categories flagged as such:
Anyway, if there was any support for this, the first question would be technical feasibility – about which I have no idea. If it's not technically feasible, then there's little use in talking about whether we might want this.-- Fuhghettaboutit ( talk) 21:50, 15 July 2016 (UTC)
.mw-category-generated .good-content:after {content:url(https://upload.wikimedia.org/wikipedia/en/thumb/9/94/Symbol_support_vote.svg/9px-Symbol_support_vote.svg.png);}
I'm proposing to run a series of contests/editathons for different regions of Africa, and potentially get the African wikipedias involved too. Probably the biggest thing we can do to address systematic bias on here. If anybody would be interested in winning $1000-1500 for improving/creating a bunch of articles on Northern Africa in October please sign up in the participants section at the bottom. Even if contests aren't your thing if you think you might like to contribute to an editathon add your name. If there's decent support on this it stands a good chance long term in tackling one of our weakest areas.♦ Dr. Blofeld 20:19, 20 July 2016 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Many page movers assist with technical move requests at WP:RM/TR. A large number of requests occur because the new desired title is blacklisted. Allowing page movers to override the title blacklist was previously proposed upon creation of the user group, but the community did not reach a consensus to allow page movers to override the title blacklist.
See Special:PermaLink/730146201 as an example. This request has been standing here for a full 24 hours with none of the 1300 administrators bothering to perform the move. — Music1201 talk 19:00, 16 July 2016 (UTC)
*Support There are a number of situations where I could've used this right recently, mainly in relation to uncontroversial technical requests at requested moves, but also in situations such as
this thread at AN, where the title was blacklisted.
Omni Flames (
talk) 22:41, 16 July 2016 (UTC) Moving to Oppose.
Omni Flames (
talk) 23:39, 17 July 2016 (UTC)
To be clear what comes with this permission, besides being able to move a page to a blacklisted page:
tboverride-account
instead of tboverride
, which means that they can only override the blacklist when creating new accounts. Would it be possible to create a new user right, called, say, tboverride-move
which only grants that ability when a page is being moved?
Omni Flames (
talk) 01:38, 17 July 2016 (UTC)
Since the example was placed above and not in the discussion section I am responding here. Got any examples of it taking weeks to perform a blacklisted move? 24 hours is not exactly helping your cause here (and it has been 12 hours by the way). There is no deadline and a request waiting a day is not reason enough to grant the complete overriding of the entire blacklist. There is zero reason that they can't wait. This isn't some instant gratification site where everything you want is done at the drop of a hat. -- Majora ( talk) 01:41, 17 July 2016 (UTC)
There is a discussion at the Edit Filter Noticeboard which may interest some editors here -- samtar talk or stalk 11:03, 22 July 2016 (UTC)
After researching the history of Wikipedia and talking via email to some former Wikipedians I have a few proposals which would improve Wikipedia
New protection level called 'semi extended confirm protection' which would require editors with at least 255 edits and an account that is at least 17 days old to edit articles that have this protection on them
Restricting the moving of pages to only administrators
Giving the threshold to be an administrator at 60 percent (same as it is to be an arbcom member). Also maybe have admins who get between 60 and 70 percent of the vote have a trial period where an experienced admin takes them under their wing.
Create a vandal bot who will block vandals who have been warned at least 3 times. Callan Eccleston ( talk) 22:13, 20 July 2016 (UTC)
Actually I think that Wikipedia should have a protection level in between Semi and Extended confirm called 'semi extended confirm' .To edit articles under this protection ,editors would need at least 255 edits and an account that is at least 17 days old. This is good because it would add flexibility to protection levels and stop admins from over protecting some pages with extended confirm (if there was an option like semi extended confirm'. Callan Eccleston ( talk) 03:01, 21 July 2016 (UTC)
Are there any gadgets which automate this process? An automated (again Twinkle-like) menu would probably save days to months of editing time. -- Tom (LT) ( talk) 02:32, 24 July 2016 (UTC)
IS there a gadget (like TWinkle) where I can click a button and implement auto-archiving on a talk page? This would be a lot less cumbersome than doing it manually. -- Tom (LT) ( talk) 23:59, 23 July 2016 (UTC)
Wikipedia:Ability_to_follow_subcategories_recursively — Preceding unsigned comment added by 65.93.215.245 ( talk) 18:30, 24 July 2016 (UTC)
This is an old gripe I've had with Wikipedia: the de-facto standard is inline bibliography and footnes. Editors are practically required to follow it, not just because of inertia, but mainly because all of the editing tools insert all bibliographic information right into the article body. A far better standard would be to separate the bibliographic data as well as any footnotes from the main content. This is already technically possible, via List-Defined Refs, or Sfn. However, it is neither encouraged nor promoted , so 99% of editors use the inline standard.
Here's why I think the current practice of putting everything inline is horrible:
<ref name= .../>
? I have to comb the entire article to find where the bibliographical information is stored.I propose to change the standard so that all bibliography and notes are placed into a dedicated block(s). Different articles can have different variations of this standard: one may use {{sfn}}
with a dedicated bibliography and another may use {{r}}
with just a reflist. Both of these are optimal because they allow a book to be cited multiple times with different page numbers without duplicating references. An article should specify which of these two is recommended, and the Visual Editor and citation wizard should change the markup accordingly. ProveIt (which shows the list of references persistently, even if they are in stored a different section of the document), should be enabled by default and hopefully upgraded to allow the {{sfn}}
style. Editors should be noted about the new policy.
Anyone else think this is reasonable? It is just so painful to read the existing markup that I feel something should be done about it. Guccisamsclub ( talk) 20:46, 18 July 2016 (UTC)
<ref>...</ref>
system is somewhat better than the methods that we had early on (see e.g.
Wikipedia:Footnote1), but I prefer {{
sfn}}
(see
Shortened footnotes). In a nutshell: Wikipedia does not prefer any ref style, and it's far too late to enforce anything. --
Redrose64 (
talk) 18:55, 18 July 2016 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
(This proposal started at Wikipedia:Village pump (idea lab)/Archive 20#Phone view and includes ideas and information given there)
Most editors change pages on their laptop but most readers check Wikipedia on their phone or tablet. What we see is not what the reader gets. An article full of info boxes and images may look good on a laptop and terrible on a smaller screen. An editor can resize their edit window to get a sense of how it would look, but most would not. Even if they did, they would not see the different layout presented on a mobile device (see screenshot to the right). Better to have a button at the bottom of the edit window that prompts the editor to preview how the article would look on a typical phone or tablet:
It should give the option to check the views on both a typical phone and a typical tablet, since a page with too many images may look o.k. on a phone, where the images fill the width of the screen and alternate with the text, but bad on a tablet where the text zig-zags around the images.
The effect of a "Mobile view" button may be seen in Google Chrome by pressing Ctrl-Shift-I and then Ctrl-Shift-M, which lets you try different devices such as Galaxy s5 and iPad. If you view Wikipedia with a vector skin (don't ask), you can see the phone (but not tablet) view by using the gadget in
Special:Preferences#mw-prefsection-gadgets "Mobile sidebar preview: show page in mobile view while browsing the desktop site". Or you can disable the gadget in preferences and copy importScript('User:קיפודנחש/mobile-sidebarcopy.js'); // Linkback:
User:קיפודנחש/mobile-sidebarcopy.js
to your User:xxx/common.js to get the same effect, but not for edit preview.
The new button would be easier to use than the gadget or script, and would encourage editors to check how the article looks to the normal reader. Comments? Aymatth2 ( talk) 13:55, 22 June 2016 (UTC)
There is an RfC on Meta about creating a noticeboard to help editors who have been sanctioned. Your input is welcome. Ca2james ( talk) 03:59, 28 July 2016 (UTC)
When you see a script/cite error, you took many minutes and hours to fix them. If there is an autofix gadget of script/cite error, you might be able to save time to correct these errors with one click. When you add this gadget, would a lot of people will be able to easily fix these errors.-- Ijoe2003 ( talk) 05:16, 28 July 2016 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
There is currently a discussion regarding activating a filter against the WMF content translation tool from creating pages on the English Wikipedia. Please see Wikipedia:Administrators'_noticeboard#Content_translator_tool_creating_nonsense_pages if you are interested. Thank you, — xaosflux Talk 00:36, 27 July 2016 (UTC)
I've been thinking for a while we should have someone who speaks for us. Jimmy Wales speaks for the whole Wikimedia movement including the foundation and other projects but his foundation board membership obliges him to put the foundation's interests before ours. I'd like us, the writers and builders at en.Wikipedia, to have someone who can speak for us with the foundation, other Wikimedia entities and the wider world. I can think of a couple of people who would fill that role well, and would love to have the opportunity to nominate them. -- Anthonyhcole ( talk · contribs · email) 12:22, 21 July 2016 (UTC)
Actually, there's more than a couple. I'd trust User:Opabinia regalis, User:Drmies, User:Newyorkbrad, User:Gorilla Warfare, User:Bishonen User:Keilana and many others with the role. They all have good sense and good knowledge of en.Wikipedia governance and society and some have public roles. User:Doc James and User:Daniel Mietchen are very engaged on the wikiprojects' behalf with outside institutions. -- Anthonyhcole ( talk · contribs · email) 13:22, 21 July 2016 (UTC)
Aren't there prior discussions about this??? Millbug talk 02:38, 23 July 2016 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Earlier today, an edit filter was enabled to restrict the Content Translation Tool. There is currently a proposal to lower the 5000-edit requirement for users who wish to use the tool. If you are interested, please see Wikipedia:Administrators'_noticeboard#Lower/Change_the_5000-Edit_Bar?.
Thank you, Tony Tan · talk 11:43, 28 July 2016 (UTC)
If you want to be able to generate complete references with a single click, then you can use this script: User:Ark25/RefScript but it works only for a limited number of sources (newspapers). If you are using Visual Editor, then mw:Citoid doesn't fill all the fields. We just need the WMF board to create a super-simple web standard and to promote it. In time, more and more publications will adopt the standard, because it will benefit them to be cited on Wikipedia. The people in the WMF board know people in the media and in the blogosphere so they can start moving things. Please support the proposal to implement this standard here: mw:Topic:T8ai4z0p2fcql0ot and then you won't waste huge amounts of time doing robotic tasks like copy-paste author, publication date, title in order to fill the thousands of references you add into articles. We need to get out of the Stone Age and if you support this proposal then we have better chances to succeed. Thanks. — Ark25 ( talk) 20:22, 23 July 2016 (UTC)
"Can't find the word "translator" in the Zotero article"- You can now; I just added Zotero#Translators. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:01, 31 July 2016 (UTC)
@ Whatamidoing (WMF): @ Czar: Sorry, I really don't mean to be rude but I feel exasperation right now. So I came here again, after two years, asking again for creating a super-tiny standard that require about maximum 15 minutes to create, and to try to talk with various people (including the W3C staff) and websites to implement them. Because I am extremely tired to update my script all the time. Please notice that websites like nytimes.com or bbc.com have about 10 different formatting styles for their data. So you need about 10 different translators just for one website(!). And they are adding another formatting style every couple of years. On top of that, sometimes they change the formatting style for all (or many) of their past articles. My script (RefScript) doesn't only work for Wikipedia, it works for any other site. I am using for quickly posting nicely formatted links (references) on forums too, so it's not only for Wikipedia references. My script generates a reference in 1 second, while Citoid is slower. RefScript (and WebRef too) is doing in the source editor what both Citoid and Zotero do together in the Visual Editor.
And now you are asking me to improve Citoid too by always teaching and updating Zotero just like I am doing with RefScript! Just like my script, in order to keep up with the changes, Zotero will accumulate gazillions of lines of code - this is not the solution, and we need a standard, that, in time, it will be adopted, slowly but steadily.
Sorry to ask this but do you people understand that this is a Sisyphean task (= a work that is pointless and that never ends) simply because the newspapers always add new formatting styles all the time and sometimes they even change the formatting style of the title, publication date and author name for all the articles published in the past? I am working at RefScript since 2011 and I really know what I am talking about. I am sick of having to update it all the time. That's why standards exist and are necessary, in order to make the people's life easier.
If there would be a standard like the one I am talking about, then, for the publications that implement it, both RefScript and Citoid would generate the full references without having to add any translator, rendering Zotero useless, or at least reducing it to a 10-lines script. Also RefScript would be reduced to a 10-lines script. Just like Zotero, RefScript contains tons of translators that would become unnecessary for the sites that implement the standard.
None in the WMF board have their own blog and they even don't know anyone having a blog to test such a tiny standard? Really???
Right now I feel like I want to cry. I feel like this a dialogue of deaf people :( — Ark25 ( talk) 21:36, 29 July 2016 (UTC)
There is an existing standard: COinS. See also the proposed citation microformat. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:11, 31 July 2016 (UTC)
@ Czar: It is 15 minutes. Here is the standard (let's call it OpenCite):
Now you can take another 15 minutes to add a few cosmetic changes and it's done.
In order for a translator to check more (mutliple) different RegEx, you have to actually include more translators into that translator. As I said, the more translators you add, the more work it needs to update them since the newspapers constantly change the way they format those fields (date, author, title). So adding translators is not the solution, but creating a standard that would render the translators useless is.
@ Whatamidoing (WMF): what you said there about standards does not apply here. There is no such existing standard at all, so there won't be any competing standards. That's the reason I came here after all - because such a standard does not exist yet. Obviously, if there would be such a standard, I wouldn't have asked to create a new one. And competition is good, a new and better standard has better chances to be adopted than a half-baked, existing standard. Also, according to what you are trying to say, the creation of HTML5, HTML4, HMTL3, CSS4, CSS3, etc was useless, since the HTML2 and CSS1 standards already existed - and that's clearly not the case. Is anyone being paid for writing code or to update Zotero, by the way? I wouldn't write translators for Zotero or for RefScript even if I would be paid for that.
You didn't answer to the question if there is any blog in the reach of the WMF board where such a standard can be tested. So I've created an html page as an example. Let's imagine that I have a news web site and this is a news that I've posted today: https://dl.dropboxusercontent.com/u/46152682/rude-wikipedian-flames-the-board-2016-07-31.htm
That html page is formatting the title, date, author's name and publication name according to the standard presented above. Now, for any other publication that uses this standard, Zotero and RefScript (and any other script) needs only a single translator. That means maximum 20 lines of JavaScript code that works for every single web site that adopts this standard.
@ Pigsonthewing: COinS seems to be a standard for bibliographic references (for books) - is there any way it can be used by news websites? How can I use COinS for example in the news article on my web site in order to specify the title, publication name, publication date and author's name?
Thanks. — Ark25 ( talk) 19:30, 31 July 2016 (UTC)
@ Pigsonthewing: Wikipedia:WikiProject Microformats/citation looks very much like a standard that I'm asking for. However, I don't understand the role of class="reference-accessdate". This is an element specific only to Wikipedia references, I don't see the point for a newspaper to include such a field. Daily Mail has a somewhat related field: <span class="article-timestamp-label">Updated:</span> 19:35 GMT, 31 July 2016 - for example in this article. But "reference-accessdate" depends on when a Wikipedian creates a referece, and the newspaper can not predict when that will happen. — Ark25 ( talk) 21:01, 31 July 2016 (UTC)
I've just noticed that the user Pigsonthewing worked as a Wikimedian in Residence for the Royal Society of Chemistry, Thinktank, Birmingham Science Museum and many other institutions. Those institutions have news feeds - for example this section - http://www.rsc.org/news-events/articles/ - here is an example article - http://www.rsc.org/news-events/articles/2016/jul/uk-science-and-the-eu/
Since Wikipedia and those institutions already have a very good relation, it's extremely hard to believe that they won't implement the OpenCite standard or Pigsonthewing's citation standard — hCite(or COinS - if COinS can be used here) on such news, if the WMF board would ask them to do that. In time, more and more sites and publications would adopt the standard. — Ark25 ( talk) 20:32, 31 July 2016 (UTC)
There's another "standard" that's quite widespread now for scholarly publications: the one required for inclusion in Google Scholar (it is of course supported by the Zotero translators, hence Citoid). I doubt the WMF would have enough leverage to push for yet another standard which would be redundant with COinS or Dublin Core meta tags. Webmasters will only follow guidelines if they have a very clear interest to do so (for instance, inclusion in Google Scholar). − Pintoch ( talk) 17:22, 1 August 2016 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I'd wish to propose that the lower age limit for those serving on the Arbitration Committee be raised. Few other organisations or companies of Wikipedia's size, challenges, or assets would have Board Members in their early twenties. Twenty year olds, however capable, and intellectually and emotionally mature, lack the life experience and emotional experience necessary for optimum judgement on many of the sometimes stressful and fine grained issues that face the Committee. It is unfair on them, and it is not right for the project. I propose the age limit for Committee membership be 30 and upwards, but certainly at least older than what the current limit is. Engleham ( talk) 08:38, 3 August 2016 (UTC)
I've SNOW closed this, but {{ Archive top}} doesn't seem to like my sig. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:05, 3 August 2016 (UTC)
Hi, if anybody thinks they might be interested in working on some Frank Sinatra related articles feel free to sign up. At present it's just something to loosely tie a lot of material together and help organize it.♦ Dr. Blofeld 11:38, 5 August 2016 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
In conflict related pages, experienced editors often give DS alerts to new editors. Sometimes, this is being misused to scare new editors. New editors get confused seeing such notices on their talk page. This is a form of WP:BITE. Any new editor with a clean block and not more than two warnings in their talk page, should not be given such DS alerts.
Proposal- If any experienced editor gives Discretionary sanction alert on the talk page of new editor with a clean block log and no history of warnings as edit-warring, personal attacks, then the experienced editor should be blocked for WP:BITE. -- 1.39.38.230 ( talk) 15:07, 5 August 2016 (UTC)
Snow no per TransporterMan. These notices are information, not biting, and that is clearly stated. In any case, biting is not blockable. ― Mandruss ☎ 18:16, 5 August 2016 (UTC)
There could be a preference called "Display a green bullet next to the 'Watchlist' button to indicate one changed page in your watchlist", which could be useful to keep editors motivated in seeing what is going on.
Gamingforfun365
(talk) 22:31, 4 August 2016 (UTC)
As the above is a regular topic on the MP talk page, could a 'separate page for such discussions' be created - there appears to be some support for the idea.
Ideas when ready for general discussion (such as that involving linking the pictures to the topic on the list) can #then# be posted to the MP TP. Jackiespeel ( talk) 17:54, 11 August 2016 (UTC)
mode=packed
by default?This discussion has demonstrated that mode=packed is advantageous in many but not all situations. There is insufficient consensus to change the default behaviour and many editors have suggested splitting the default of desktop (default traditional) and mobile (default packed) versions. Editors are welcome to change instances of galleries to packed mode as they see fit. The decision on default mobile behaviour is left for a separate straw poll. Deryck C. 12:29, 21 September 2016 (UTC)
Galleries currently use mode=traditional
by default, producing a gallery like this:
Should they be change to use mode=packed
by default, as below?
(pictures from Wikipedia:Featured pictures/Fungi) — crh 23 ( Talk) 12:29, 24 June 2016 (UTC)
TRADITIONAL MODE | - - - - - - - - | PACKED MODE |
|
- - - - - - - - |
|
You would never see a printed encyclopedia with such a poor caption layout. The purpose of PACKED mode is to cram as many pictures and captions onto a webpage as possible, like sardines packed in cans. This is just a bad idea for WP.
Additionally, on a personal opinion level it may seem trivial but I actually like the traditional look. It reminds me of old-fashioned film slides which were often used in schoolrooms and laboratories before the advent of digital projectors. Somehow these just feel more "academic" to this old bear, and I am of the opinion that an academic feel is the right feel for an encyclopedia. Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 17:17, 19 July 2016 (UTC)
I've notified WikiProject Visual arts of this here. Bus stop ( talk) 17:22, 24 June 2016 (UTC)
mode=
being specified) and add mode=traditional
by bot. Would that suffice?
Adam Cuerden (
talk) 19:41, 24 June 2016 (UTC)
mode=traditional
? That seems like a good compromise to me. —
crh 23 (
Talk) 21:05, 24 June 2016 (UTC)-- [[
User:Edokter]] {{
talk}}
16:42, 25 June 2016 (UTC)
Standard gallery with heights and widths optimized:
Packed
| | | | |
Packed mode
Current default gallery:
Test, mode=nolines:
"be handled on a case-by-case basis"then what is the purpose of using such a mode as "default"? Aren't the concepts of default and customized diametrically opposed or perhaps even mutually exclusive? Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 10:34, 20 July 2016 (UTC)
Please accept my deepest apology for this edit, and my sincere gratitude to Redrose64 for reversing it. I am utterly clueless how that happened and deeply sorry that it did. The only thing I was trying to do is add a comment in reply to Kusma's statement (see the Line 485 section in the diff) -- the "doesn't make sense" edit summary was describing that comment -- but somehow I royally screwed up and I am so very sorry. I would never intentionally delete another editor's comments. I have in fact counseled others on the evil of that behavior. My mind was boggled at how this could have happened. If you look at the Line 456 & Line 469 sections of the diff you will see quite a bit of text being added so it is even more confusing as to what occured. In the end it does not actually matter how this happened, only that it should not have happened, that it was not intentional, and I am truly sorry that it happened at all. -- Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 17:24, 20 July 2016 (UTC)
|
code=packed
the default, not due to the way the pictures are presented (which I am quite partial to in most cases), but due to the mess it tends to make of captions. I would propose mode=nolines
as an alternative, but it looks like the captions are not vertically aligned on that, which is also inferior. I still think mode=traditional
looks a bit odd (I don't like grids!), but at the current time I can't see a good alternative for default. —
crh 23 (
Talk) 19:02, 20 July 2016 (UTC)Selection of random images, shown in mode=packed
(captions are the file name)
To see these images (and others) in the current default mode, see Wikimedia Commons, Category:Images, Media in category "Images". The assumption that disparate aspect ratios exist only (or predominantly) in the visual arts is erroneous. Coldcreation ( talk) 12:40, 3 July 2016 (UTC)
$mode = "framed";
with $mode = "packed";
in one place that deals with mobile galleries. Caching should not be a concern when the change is made in just one place. The possibility should not be dismissed out of hand if there is consensus here that it would be a real improvement.
Aymatth2 (
talk) 10:56, 5 July 2016 (UTC)widths=
and heights=
parameters set as well.
Adam Cuerden (
talk) 22:27, 15 July 2016 (UTC)
Packed mode with upright panoramic images (selected from here). Note the streaming down of captions, here simply the file name, rendered non-readable.
Packed mode with horizontal panoramic images (from here). Note the enormous size of the images, unsuitable for a gallery presentation.
Packed mode with horizontal and upright panoramic images. Note that both problems observed above are compounded here.
Traditional mode with horizontal and upright panoramic images. Note, images are homogeneous in size, captions are readable, the viewer can click to enlarge. Perfect for a hypothetical gallery presentation.
Coldcreation ( talk) 15:45, 16 July 2016 (UTC)
These are also hardly realistic examples. Show me one extant gallery that looks at all like the last one, and I'll show you a gallery that should've been hand-tweaked years ago. Adam Cuerden ( talk) 14:29, 16 July 2016 (UTC)
I guess there is something we could do serverside to improve the concernes surrounding 'thin' elements in packed mode. First, we could set a minimum width on a thumbnail, so that it will never be smaller than say 100px. This would improve the visibility of the text, but would break up the 'packedness' of the packed mode. Then again, if you are adding thumbnails less wide than 100px, you are already doing something wrong in my opinion (adding an almost indistinguishable image), and this would just be a 'safesty net'. Call it the readability-over-prettyness option. An alternative would be to detect when the width of a thumbnail is below 100px, and automatically adapt heights to make sure the width is at least 100px. That might have some technical blockers however. Can't be sure until I have looked further into that. — TheDJ ( talk • contribs) 20:27, 4 July 2016 (UTC)
The largest drawback of the traditional layout seems to be the gery grid. As one editor pointed out, Tufte's advice is to get rid of decorative "ink" that doesn't provide information. If you get rid of the grey box, you get the improved looks of the packed version without the drawbacks of distorted captions and messy layout of irregular images.
You can give it a try yourself - if you squint slightly and look at the traditional layout, the grey lines vanish and you'll get a glimpse of the result, which looks like an orderly version of the packed layout with more white space and more regular captions. Diego ( talk) 08:58, 20 July 2016 (UTC)
Hello, I would like to create two wikipedia based keyboard shortcut layouts. They would cover the two Wikipedia implementations for editing 1) Source Editor and 2) VisualEditor. Here are the specifics I need help on:
The items above are BASIC ideas, please let me know of anything else that you can think of while reviewing this workup.
Here is the link for BOTH the 'Source Editor' and 'VisualEditor' shortcuts DRAFT;
http://vwanweb.blogspot.com/2016/07/wikipedia-shortcuts-source-edit.html
I have an idea to create a combined color and Color Blind friendly version by applying different stroke (boundary) styles to a given set of keys that make up a 'group of keys'. As an example all Site Navigation Keys will be enclosed with brackets [ X ], while Current Article Tools would be completely enclosed in a rectangle, see graphic link above.
Your feedback is welcomed.
Vwanweb ( talk) 08:03, 5 August 2016 (UTC)
VisualEditor 01 and Source Editor 02 Shortcuts
VisualEditor draft 01 notes:
Source Editor draft 02 notes:
Any and all feedback is appreciated, please help.
Vwanweb (
talk) 01:07, 9 August 2016 (UTC)
If Ctrl-[ is really a Visual Editor shortcut, it's a terrible one. What, for example, am I meant to press? Alt Gr-8 is the [ on my keyboard. The / shortcuts also don't work as well when / is Shift+7. Adam Cuerden ( talk) 10:39, 13 August 2016 (UTC)