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.
Thanks for the feedback. Jytdog (talk) 05:17, 22 July 2017 (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.
(also posted at Jimbo's talk page and at
WT:COI
)
I want to ask - at a high and initial level, does anybody here oppose the formation of something like a "guild or WikiProject of paid editors", by paid editors? I have proposed this initially in three places, but I want to also float this balloon here, and if it doesn't get terminally shot down here, I want to go to work doing what I can to help them plan and form it, and then at some point bringing it to a community-wide forum to get validation before it would actually launch.
If you read self regulation you will see that many industries have a level of self-regulation. The American Bar Association is cited in that article; the ABA operates within the bounds of the law of course, but it has additional rules and ethics, and if you break them, the ABA will throw you out and you can't practice law. Same deal with practicing medicine - you have to be certified by various boards, that are run by the medical profession itself.
If we had something like a guild of paid editors here (again, formalizing what it is going with the Statement), people who are part of it would pledge to follow PAID (disclose, not edit directly, and follow the other policies and guidelines) and the members of the guild would a) watch each other, and b) watch non-members, and c) train new members. They would throw out people who violated PAID or who socked, etc. They would also never: refuse entry to someone who said they would follow the "rules"; never lobby for changes in policies or guidelines; never implement each other's edits; never advertise their services in WP or chase people here.
Outside of that they would be like other editors, and the guild would give them no special privileges.
The community and WMF could say to the public, "There are paid editors who violate WP's rules and are not members of the WP community, and many of them have been banned and have to lie just to write in Wikipedia - they should be avoided. There are paid editors who are members of the community in good standing; people in the Guild of Paid Editors are examples of that, as far as we know."
There are lots of ways this could go wrong if it is set up wrong (there always are) and of course in its execution, but there are many potential benefits.
The thing I am most interested in, is starting to influence the market for paid editing. The public has no idea that there are "white hat" paid editors who are different from "black hat" paid editors, and pretty much the only message that WMF and the editing community put out there, is "paid editing is bad." This leaves the market wide open, and it is kind of like Prohibition in the United States where the gangsters are flourishing. Which is kind of foolish. I am not saying that anybody should endorse paid editing but we should make it clear there are "good guys" and "bad guys".
We could point to the "Statement" now, but that is kind of loose not formal, and if the paid editors themselves form the Guild/WikiProject and invest in it working, paid editors in it will have more of a stake in keeping it clean. And we would all have something more substantial to point to as examples than "signatories of the statement" which is kind of flimsy, and I don't know how rigorous the signatories are in throwing people out who violate their pledges.
If this is effective, it will decrease the amount of undisclosed paid editing that happens from the demand side - from people making better choices if they choose to use a paid editor.
Again, just looking for initial buy-in or "blockers" (to use the WMF dev term) at this very initial stage of thinking. Jytdog (talk) 00:43, 15 July 2017 (UTC)
I think the idea is worth looking into. • • • Peter (Southwood)(talk): 05:13, 15 July 2017 (UTC)
One thing to consider is whether members of such a guild should be required to disclose their real identities: a) to the guild, and b) on Wikipedia. • • • Peter (Southwood)(talk): 05:19, 15 July 2017 (UTC)
Anything that encourages compliance with the COI guideline, utilizing carrots as well as sticks, is constructive. Figureofnine (talk • contribs) 12:10, 15 July 2017 (UTC)
And now the proposal is dead. The requirement is disclosure, not self doxxing. When you make the rules harder for being honest, you encourage dishonesty. --v/r - TP 14:46, 15 July 2017 (UTC)
User:Pbsouthwood Tparis is kind of emotional about these things and tends to over-react. I think his concern is that we make this onerous paid editors will not use it. In my view the main thing is that paid editors use a stable WP identity and don't sock. Because paid editors who follow PAID need to disclose their employer, many of them do disclose their RW identity in WP. (see signatories to the Statement, linked in the OP) but I don't see a need to place an extra burden on paid editors outside of what is already required in PAID. Jytdog (talk) 19:56, 15 July 2017 (UTC)
Strong oppose ....in no way should the Wikipedia Community look like it's endorsing paid edited by hosting a special place for these people. We should form a Wiki project that searches out these people and looks over their work.--Moxy (talk) 17:18, 15 July 2017 (UTC)
User:Moxy, this is not about endorsing, really. I understand that there is a risk that people will take it that way, but it is not that. The points here briefly are:
1) paid editing is never going away
2) There actually are "white hat" paid editors and "black hat" paid editors, but the public doesn't know this.
3) If we were to educate the public, this would do a lot to dry up the market for black hat paid editors
4) As part of that, we need something to point to, as "white hat" -- the "guild" would be people who say they follow PAID and the other guidelines and have not been indeffed. In other words as far as we know (always, "as far as we know"), the members are paid editors in good standing. This is essential for communicating to the public
5) there would be a bunch of other benefits to the self-regulation and having a centralized location for dealing with certain aspects of paid editing (e.g maybe listing all articles worked on by legit paid editors in one place). There are lots of things we could do with it if it were up and running.
I hope that all makes sense. But this is very much about dealing with the reality that paid editing is never going away, and thinking about strategies to manage the market for it. Jytdog (talk) 19:51, 15 July 2017 (UTC)
I am not convinced that it won't work in WP. There will be turbulence getting there, but that is not unexpected. But meta could be an option, sure. Jytdog (talk) 19:51, 15 July 2017 (UTC)
I don't see why such a thing could not be done off-wiki, with a Facebook group or the like. I don't think such a thing belongs on the project. bd2412T 22:42, 15 July 2017 (UTC)
Strong oppose - Sorry, Jytdog, but the fact that "paid editing is not going away" is not a reason to give it the imprimatur of our approval, any more than the fact that socking isn't going away is any reason to stop blocking socks and their masters. Beyond My Ken (talk) 20:34, 15 July 2017 (UTC)
User:Beyond My Ken This is not giving it "approval" and it is disappointing to hear this framed that way. Paid editors who follow PAID (and the other PaG of course) are members of the community in good standing. There is no argument against that, that you or anyone else can make. Let me come at this from a different direction -- you didn't !vote at the MfD on the Statement. How would you have !voted, if you had, why? Jytdog (talk) 21:08, 15 July 2017 (UTC)
I disagree, allowing such a guild to be formed would indeed give tacit approval to their efforts.Personally, I am opposed to paid editing in any way, shape, or form. The WMF's most recent pronunciation on it tip-toed right up to the line of banning it altogether, and I have no idea why they didn't bite the bullet and do the deed. In any case, paid editing, whether they adhere to
WP:PAID or not. If that's harsh, well, tough, they shouldn't be attempting to sully the integrity of our project with their PR. Beyond My Ken (talk
) 21:26, 15 July 2017 (UTC)
User:Beyond My Ken taking a moral stance "against paid editing" is like taking a moral stance against drinking alcohol. People feel how they feel about it, but we as a society came to realize people are going to drink, and trying to stop it is pointless. So we regulate it. Likewise, we put PAID in place, but given the nature of this place it is easy for bad faith people to just ignore it. But there are people who follow PAID and we are shooting ourselves in the foot by not acknowledging that. We need to let the public know that good faith PAID editors exist, and we can dry up the market for bad faith paid editors by establishing something more solid for good faith PAID editors to inhabit and maintain - this guild or WikiProject. The moral absolutism is not helpful. We need to move past that by now. This is a strategy to influence the market that works on a bigger scale than the whack-a-mole of catching individuals. (I still do a lot of that work; it needs to keep going, of course). But please do hear me - I am not offering this lightly, and it comes with a lot of thought. So please, put away the emotion. Please. Jytdog (talk) 22:19, 15 July 2017 (UTC)
Your comparison to Prohibition is silly, frankly, as what paid editors are doing is a job, and their employment is damaging the encyclopedia I've spent a lot of time and effort on improving, and don't wish to see harmed. I fully understand that you have put a lot of thought into this, and I accept that you offer it in total good faith -- I would expect nothing less from an editor such as yourself -- but that doesn't make it any better of an idea. You say that it will "sway the market", and I say that it will throw the doors of the market wide open and make paid editing even less subject to control than it is now, as more and more people realize that they can get away with pure promotionalism and swamp our already meager ability to police it. I ask you to believe that this is a fully rational, well thought out stance which has little, if anything to do with "emotionalism". You asked for opinions on your idea, and this is my opinion: it is a bad idea. Beyond My Ken (talk) 22:33, 15 July 2017 (UTC)
The point of the Prohibition metaphor, is that doing what we have been doing - namely saying with straight backs and all moral fiber in place, "Paid editing is bad!"..... does absolutely nothing to affect whether people buy the service and what is worse, leaves those purchasers mostly at the mercy of the "gangsters" (the people who sold alcohol lucratively during prohibition)
tThis reported article in the Entrepreneur (and I mean "reported" - the author went out and talked to people including the WMF) gives no inkling that there are paid editors who are "white hats" and follow policy and there are "black hats". That really, really bothered me. The reporter tried to find out the score and walked away clueless. And communicated that to her audience, which is probably one of our biggest sources of shitty paid articles (startups, business people looking for exposure). I want the public to know there are legitimate people offering paid editing services, who follow policy and that there is a "black market". And just like buying anything on the black market, you do so with risks that you don't take with legit enterprises.... and that using this black market is actually kind of filthy, and actually harms the public good that is WP. The harm comes from undisclosed paid editors who sock and lie and directly dump garbage in WP. It doesn't come from the legit paid editors. Jytdog (talk) 02:54, 18 July 2017 (UTC)
Oppose. I disagree about the "good" vs. "bad guys" dualism mentioned in the proposal. There are many shades of paid editing, and the best ones still contribute to a systemic bias in favor of recent products and companies, which would usually have gotten fairly decent coverage anyway -- at best we're talking about a "bad guys" vs. "more-or-less neutral guys". There is nothing Wikipedia would gain from letting them organise into an interest group and (attempt to) gain public validation with this. DaßWölf 21:38, 15 July 2017 (UTC)
Strong Oppose per BMK. I'd also disagree with Jytdog's statement that declaring your paid status makes you a community member in good standing. Following the TOU does not necessarily mean that. It means that you are not excluded from using the website by the legal owner of the servers. Spamming is still against community policy even if the paid editor has declared their affiliation, and there are paid users who spam even when this is declared and think that somehow their following the terms of use makes this okay. I fear if this proposal was adapted it would further the misconception that paid editors who declare and create otherwise unacceptable articles should be allowed to do so (even though I know that was the intent of the proposal). TonyBallioni (talk) 21:43, 15 July 2017 (UTC)
You are killing me and worse you are not responding to what I have actually written here. When I say "following PAID" - what that means (if you actually read PAID) is, that they don't edit directly, they don't hammer people at talk pages, etc. Paid editing is not banned (and is impossible to ban given how WP is structured); we need to take that seriously. We don't love paid editors, but you cannot say that they are not members of the community when they are following what PAID actually says. Please go slower in responding to this. Leaving the market as it is, means just more of the same. This is a strategy to influence the market and having something substantial like what is being proprosed will help better regulate paid editing internally and will give us something to point the public to. I arrived at this proposal after a lot of thought. Jytdog (talk) 22:08, 15 July 2017 (UTC)
It references the COI guideline and NOTSPAM as well, but the core of it is the terms of use, which is what is normally meant when people say following PAID. I have read the page, and while your interpretation of it is the one that is most in line with our other community policies beyond TOU, PAID itself does not go into that much detail. I stand by my comments above: making it so that there is a semi-official grouping within Wikipedia lends legitimacy to the idea that paid editors complying with the terms of use allows them to violate other community policies on promotion. I am not actually anti-paid editor as a whole, there are some good ones (people who get grants to do this is just one example). The majority, however, are going to be spammers, and that is easier to deal with when there isn't an organized group sanctioning it. TonyBallioni (talk) 22:33, 15 July 2017 (UTC)
I would say that people who get grants to edit Wikipedia might be a form of paid editing I could accept, if their grant is on the order of "to improve Wikipedia's coverage of X subject" and not in the form of "reverse the bias in Wikipedia regarding X subject", since people who edit with the intent of undoing a bias generally end up editing with the entirely opposite bias, instead of endeavoring to edit neutrally. We had the recent example of the teacher who assigned their students the task of showing how Trump's policies were going to damage the environment. I believe the teacher ended up being indef blocked after an extremely long community discussion that went across numerous venues. That wasn't a grant situation, but it could certainly be one, depending on who is giving out the grants and what their purpose is. Non-profits aren't required to be neutral, nor are academics, but we are -- and PR people are never neutral concerning the subjects they're paid to promote. I see no reason whatsoever to open our arms to them, welcome them to Wikipedia, and give them their own clubhouse. Beyond My Ken (talk) 23:20, 15 July 2017 (UTC)
Leaning oppose but could be persuaded. Jytdog, I think I agree most with the opinion expressed by Daß Wölf here but leaning towards BMK. I have to ask, what do we hope to have happen if such a guild existed? How would it improve the current situation? I think the argument for self-regulation is not persuading me because the undeclared paid's already exist so far outside the bounds of what is considered acceptable (even legally per ToS and US commercial laws vis-a-vis FTC disclosures for advertising). ☆ Bri (talk) 02:49, 16 July 2017 (UTC)
A few comments based on what has been said above:
It's unclear to me that the signatories to the statement from the communications firms in question are truly interested in proceeding with forming a support group of sorts, given that they haven't in the past three years since the statement was released. But if they do proceed, I'd as soon it have some presence within Wikipedia to make it easier to monitor (and apply sanctions against, if necessary).
Wikipedia editors and readers are sufficiently savvy to understand that the views given in any number of essays in Wikipedia space are not tacitly approved by the community. I trust they will understand this regarding any project pages used by a paid editor support group.
Paid editors who wish to ignore Wikipedia policies and guidelines will do so anyway, no matter what pages exist in Wikipedia. A support group page or the absence of one won't influence them.
As I mentioned elsewhere, I am not optimistic that there will be any self-policing of membership in a support group run by paid editors, so I personally don't see this as making much difference in helping identify paid editors who follow the rules versus those who don't (I know others do; let's agree to disagree). (Editors interested in sorting this out are welcome to help keep Wikipedia:WikiProject Integrity/Editor Registry up to date.) In the collaborative spirit of a wiki, though, I think it is desirable for editors to support each other in following policies and guidelines, and I can't see any grounds to prevent non-banned editors from doing so. isaacl (talk) 03:44, 16 July 2017 (UTC)
It all comes down to what the community wants. If they don't want such a guild to exist, and an RfC shows that, then the guild will not exist. There doesn't have to be a specific policy giving the community the authority to stop it from forming or shut it down if it already has. We make policy, policy doesn't make us. Beyond My Ken (talk) 05:31, 16 July 2017 (UTC)
Sure, any group can be prevented from forming on-wiki (can't stop a group from forming off-wiki, as I mentioned). As much as possible, though, I'd prefer to base opposition on general principles, rather than on personal preferences, or else every conversation will just be an "I like it" discussion. isaacl (talk) 13:15, 16 July 2017 (UTC)
Oppose. I've been scanning over this discussion of dealing with paid editing for the past few days. This...is an interesting way to deal with it. Very interesting. A lateral way to deal with such situation. But no. The key priority is keeping transparency with paid editing, and enforcing transparency with paid editing. This path...seems lucrative, but any
fear, uncertainty and doubt is very justifiable, if this system operated. That's not saying that I would not trust the editors, but we have seen that past (and current) works of black-hat editing have used very sophisticated means to hide their editing. This...is another thing to care about. And it could all go very wrong if it isn't cared for properly. I support Count Iblis's idea on Wales' talk page. My name isnotdave (talk/contribs
) 12:57, 16 July 2017 (UTC)
With apologies, nothing you wrote makes sense. This doesn't make anything less visible and there is no new "system". I don't know what you are reacting to, but it is not this proposal. Count Ibis's idea on Jimbo's talk page means committing fraud, as I wrote there, and neither the WMF nor the community will engage in illegal behavior. If you want to go commit crimes, that is your deal, of course. Jytdog (talk) 21:45, 16 July 2017 (UTC)
I oppose paid editors, period. Wikipedia should be neutral, and paid editors aren't . --NaBUru38 (talk) 15:11, 16 July 2017 (UTC)
Jytdog, maybe you can give this one or a few more days. So far, I see unanimous/huge opposition toward the proposal. I'll let you decide when you can withdraw this proposal. Okay? --George Ho (talk) 21:30, 16 July 2017 (UTC); Never mind; after seeing a few "support" votes below, I'll give it some appropriate time. --George Ho (talk) 03:46, 17 July 2017 (UTC)
The conversation at Jimbo's talk page is going quite differently, and likewise the one at WT:COI - both places where people have been considering and discussing these issues for a long time. This thread has a very weird jag of emotional, kneejerk reactions that I was somewhat worried about when I posted this. But it doesn't matter that people don't "like" paid editing or that they imagine that this would change in any way the underlying policy basis under which paid editing should happen. And almost no one who has opposed seems to be aware of the activities around the Wikipedia:Statement on Wikipedia from participating communications firms that this would merely formalize. This isn't facebook and we don't decide things on "like"s or people shooting from the hip. Please don't close this prematurely. Jytdog (talk) 21:45, 16 July 2017 (UTC)
It seems to me that we should oppose undisclosed paid editing with a vengeance. But paid editors who are conscientious about following
WP:PAID can make useful contributions, albeit only on a short leash. We must never give the appearance of giving approval to spammers. But if some good-faith editors are willing to voluntarily, and perhaps unofficially, patrol for violations and give advice about best practices, that could be a good thing. Maybe we just don't need to put an official name on it. --Tryptofish (talk
) 22:34, 16 July 2017 (UTC)
Possible support While I oppose all paid editing, to the extent that I would long ago have actually proposed a ban if there were a feasible way to accomplish this, there is no fair method of detection--all that a ban would do is drive all paid editing underground. Given that it exists, we need to provide incentives for paid editors to declare themselves. This project could assist this, by providing clear standards to those in the trade in their own language, and enable us to keep a better watch on the declared paid editors to ensure that they were actually following the rules. It would assist the critical effort that ought to be made by the foundation to make it unambiguously clear by its own PR efforts that all advertisements of paid editors that do not specifically say they will guarantee the terms of use are opposed to our terms of use, and in many cases pure scams--and to clarify that there is a legitimate alternative. I'm aware that the declared paid editors have a commercial interest in discouraging the undeclared, but it coincides with our own priorities.
But this has to be named and run like any other wikiproject , with open membership and general participation. No wikiproject is "official". I've joined a few wikiprojects whose work I do not necessarily approve of, to keep tabs on what they are doing; many others do likewise. DGG ( talk )
Oppose. This would encourage EVEN MORE unconstructive paid editing. KMF (talk) 00:31, 17 July 2017 (UTC)
Comment. The following is something I suggested years ago, so I offer it here again. I would like to see an organization that acts as a neutral go-between, so that Wikipedians can be paid for their work, but not directly by article subjects or their agents.Ideally, the Wikimedia Foundation would set up a team with an email address and website, or OTRS-type multiuser system, to which people wanting to pay for articles could apply, and to which all approved paid editors would have access. The Foundation's team would set the fees; choose the editors from a list of Wikipedians who sign up for the scheme (who must have a minimum number of years spent only as volunteers, and a minimum number of edits); pay those editors as independent contractors; and take a percentage of the fee for having organized the transaction. The Foundation's brief to the paid editors would be to write a neutral, policy-compliant article. The payers would have no say over which editor was given the job. Editors producing non-compliant articles would have their paid privileges removed. This system would remove or at least reduce the COI; would give people requesting articles somewhere to go; and would provide fees for editors who understand the policies and have the project's interests at heart. It would be win-win. The Foundation is unlikely to do this, but I wonder whether it could be persuaded to help set it up and maintain s close tie with it. Peteforsyth and WWB would be ideally placed to lead it. SarahSV(talk) 01:17, 17 July 2017 (UTC)
This is something I definitely would not support, and I think is a direct contradiction to our basic principles. It essentially amounts to turning us officially into a partially paid encyclopedia. I consider it similar to book review journals which review some books for free, but will also renew anythign else if you pay for it--the most prominent example I know of this is now no longer accepted as a source for WP. It would give the WMF every incentive to maximize the proportion of paid articles, if they received part of the fee. Even volunteer editors often have a great attachment to the articles they work on, and OWNership is an ever-present if subliminal temptation--if the same people did it for money it would be much intensified. It would also put the WMF in the position of "approving" editors, which essentially means interfering with our content, and that would destroy the site entirely. Not only should the WMF not do it, but it should never let itself be connected to any entity doing it. It might even affect our safe-harbor status in terms of copyright and libel. There have been sometimes problems with organizations giving the foundation grants to support Editors in Residence, and Editor in Residence sometimes getting too much involved with articles closely connected with the organization that pays them, but these are at least supposed to be highly reputable non-profits. Having current legitimate paid editors organize it would be the worst way of all--they would essentially be establishing a monopoly. DGG ( talk ) 02:54, 17 July 2017 (UTC)
Support per DGG. I've worked pretty deeply on the problem for years, with hundreds of blocks at SPI, hundreds of AFDs and if I've learned anything, it is that it is impossible to prove paid editing most of the time, so managing the problem is better than trying to pretend we could really "outlaw" it. Better to have a system of self-policing with input from the entire community, to have self-declaring, some ethical standards, and then perhaps they would be helpful in getting rid of the bad players, because they have a stake in keeping in the community's good graces as well. It would be the lesser of two evils, which is still the better choice. Dennis Brown - 2¢ 02:26, 17 July 2017 (UTC)
Support. Paid editing is here to stay, so it's overall beneficial for Wikipedia to turn some of these edits to be useful. Paid editors who want their work to survive would benefit from this project, while those who refuse to abide by Wikipedia policies will continue to ignore this project. feminist 16:48, 17 July 2017 (UTC)
Comment I'd like to push back agains the idea that it is better to have this out in the open with an endorsed organization rather than shunned and underground simply because we aren't able to stop it that DGG has brought up. I disagree completely. As it stands, we are actually pretty good about picking out the clear spam and getting rid of it through one of the deletion processes. People hide the fact of their employment status and then when it is put up for deletion and they gang up, it is very easy to spot and we deal with it quite well when the editors are undeclared. We can't prove the paid editing, but we can get rid of the non-notable spam articles.Working with new pages, I've been on the end of several declared paid editing AfDs where the declared paid status of the editor is used as a way to lend legitimacy to the article outside of policy concerns about notability and promotionalism. The editor is free to game the process circulating press release stories and sometimes canvassing sympathetic !votes to the process. This is without a guild of paid editors, but based solely on the idea that compliance with the TOU is enough if someone is paid. A guild would make this mentality worse and I think would be a step towards the effective end of AfD as a useful process for dealing with articles created by paid accounts on the merits. I respect the work of Jytdog quite a lot and know that they have put a lot of thought into the process, but this is not a kneejerk reaction: before articles get to COIN, they pass through NPP. I really believe this would make the already tough task of dealing with paid editors who will pester you about why their non-notable article should be kept even worse and make our task there much more difficult. As I mentioned above, I am not against all paid editing, but I don't see how this would do anything other than make Wikipedia's processes easier to game. TonyBallioni (talk) 17:03, 17 July 2017 (UTC)
User:TonyBallioni - Thanks for your kind words. The goal here is to promote best practices for paid editors - disclosing and proposing, and not being a jerk and being pushy. There are paid editors who behave this way, and one of the key goals of having a WikiProject of paid editors would be to promote and propagate these best practices. Besides the goal of having something to point the public to (so they have somewhere to go, to choose a "white hat" editor instead of a "black hat"), there benefits internal to WP. Like that propagation of best best practices. Another thing I would want to do is have a page within the project where all articles where paid editors are working, are listed. Another benefit would be, that the kind of pushy paid editors you raise, could go there and ask for advice, and the more experienced ones would tell them that they are barking up the wrong tree. This would all happen out in the open, and self-interest among white hats would drive propagation of best practices. This would be so valuable. Jytdog (talk) 17:17, 17 July 2017 (UTC)
I certainly get the concept in theory. I just don't think it will work in implementation. The paid editor has both ethical and practical obligations to their client: ethical in that they're being paid to promote the clients interests on Wikipedia, so the client should always come first, practical in that they are getting paid for a task and even if you come up with some sort of code of professional standards that includes things such as being paid per hour and not based on articles being kept, it is still going to be bad for business to have articles deleted. Both of these motivations are very compelling motivators to find ways to game the system with the TOU. The really good PR people will find ways to game the system whether they are "white hat" or "black hat", and as DGG has pointed out in the past, in exceptionally rare circumstances they actually help us by producing a good and neutral article about a notable client. My fear is that this will help mediocre and bad PR professionals game Wikipedia more easily. TonyBallioni (talk) 17:42, 17 July 2017 (UTC)
Virtually all editors at Wikipedia have no idea how flooded we are with paid accounts. A few years ago, I estimated it was many thousands of accounts, many per person. Again, I worked here as admin on this problem at SPI and elsewhere. Paid editors games the system in part because it is easier to avoid the rules than follow them here. And there are so few admin compared to paid editors, it is laughable to think we can keep up. Putting some sunshine on paid editing, setting standards, allow them to use one account instead of having to sock (our TOU is problematic as well, but that is another story), and generally allowing them to do so in the open under the same rules that everyone follows, meaning the ones that edit ethically and follow WP:RS, WP:V and WP:N are more likely to be successful here and with their clients. The ones that don't won't be. It reminds me of the illegal nature of cannabis in the US. Everyone practically laughs about it, enforcement can't keep up, the real damage is less than the damage of over-policing it. Paid editing is a problem, but I would rather manage it than be foolish enough to think that we can "stop" it. We can't. I tried, really hard, I failed, it can't be stopped. It can be managed better. Not all paid editors are evil, but we need a system to manage and allow them to self-manage and point out the problem editors, as they will want to protect their own self interest by doing it right. Or we can continue the way we are, and for every sock we block, two more pop up. Dennis Brown - 2¢ 19:15, 17 July 2017 (UTC)
Strong oppose (ec) Tomy Ballioni above raises excellent points. Paid editing is a problem that consumes vast amounts of volunteer time and resources, taking away from more worthwhile pursuits. Why? Because there is demand from people and companies for articles that they can utilize in their marketing. The fact that it "is going to happen anyway" is no reason to create a Wikiproject about it, co-equal with Wikiproject Biographies and dozens of other legitimate subjects, giving it an implicit blessing by the project. And no, the fact that there are "white hat" paid editors is no reason to uncork the champagne. There are advantages of abiding by the rules (Tony Ballioni raised a couple above that I hadn't thought of), and one can accomplish most paid editing objectives by doing so. There is no reason to feel such gratitude for compliant paid editors, whose activities require constant policing by other editors,, to give them their own project as a kind of reward and acknowledgement of their service to the project. Lastly, a Wikiproject Paid Editors would be a significant public relations gaffe, albeit one that doesn't dismay me as the WMF deserves a p.r. thrashing for its ambivalent attitude toward this problem. Coretheapple (talk) 17:08, 17 July 2017 (UTC)
the purpose of the project ought to be to keep watch over it. It would be a good place to monitor if they kept their promises, or were just making pious gestures of good will. Companies put considerable effort into accurate disclosure forms. Unlike the government, we cannot penalize them civillly or criminally if they aren't correct, but we can certainly expose them to public embarrassment. DGG ( talk ) 20:06, 17 July 2017 (UTC)
Then perhaps there should be a paid editors registry, so organized and named that it would provide no marketing advantage to paid editors. "Guild" or "Project" implies Wikipedia approval, and gives paid editors something real nice to put in their advertising. Wikipedia should not be helping paid editors, even so called "white hat" ones, get business. Coretheapple (talk) 21:02, 17 July 2017 (UTC)
I think that registry is one of the purposes of the proposal. I do not particularly want to help whiteh at paid editors, but if the only way we can get rid of the black hats is to extend some coperation to them under our own terms, it's a good bargain. I would even say a necessary bargain. DGG ( talk ) 05:37, 18 July 2017 (UTC)`
I'd suggest there's an underlying fallacy, which is that we can get rid of, or substantially reduce, the so-called "black hats" without taking a variety of steps not acceptable to WMF or the community. However, I think that they can be discouraged - while still retaining Wikipedia's integrity and brand identity - by creating a "consumers guide" for subjects of articles, a variation on ideas that TParis and Smallbones have made. Essentially, potential subjects of articles should get a scary portrait of what happens and how it can and often is a net negative to hire someone to put an article on Wikipedia. If they do so, they should look for various stringent and rarely-met characteristics. Or perhaps better use can be made of article requests. There are a whole bunch of things like that that can be done to attack the problem from the consumer end. For instance, WMF, instead of just responding to requests for comment from journalists, can be more proactive in waging p.r. wars against paid editing. Creating a "white hat project" undermines the rationale behind such an effort, which is that Wikipedia is a volunteer project and that commercial exploitation is contrary to that and undermines public trust in the project. Coretheapple (talk) 13:20, 18 July 2017 (UTC)
Conflict of interest is everywhere in the world. What undermines public trust is unmanaged conflict of interest. This is a tool to help better manage the specific form of COI that is paid editing. Jytdog (talk) 15:05, 18 July 2017 (UTC)
No, what undermines public trust is conflict of interest. Period. What undermines puiblic trust even more is condoned COI. Coretheapple (talk) 17:10, 18 July 2017 (UTC)
Coretheapple, potential COI is everywhere, and every responsible organization has ways to manage it. Pretending it can be eliminated (especially here) is not the real world. You are invalidating your stance here by writing this kind of nonsense, and I will not be responding to you further. Jytdog (talk) 17:23, 18 July 2017 (UTC)
Good. You haven't or won't grasp my point, your
WP:BLUDGEONing of the discussion is getting tiresome, and your inflammatory edit summaries gild the lily. Coretheapple (talk
Strong oppose-All paid editing is, by its very nature, biased. And, as Coretheapple said, this would also put Wikipedia in the position of being seen (rightly or wrongly) as supporting those companies that pay these editors. --Khajidha (talk) 12:38, 18 July 2017 (UTC)
Comment I want to make a note here that even if everyone opposed the idea, someone could start the project, which could only be removed for cause, not just because we don't like it. As far as I know, Projects are not vetted beyond having a scope that is within the limits of the greater project, and this clearly is. When it gets started (and it could be a month, a year, a decade, but not "if"), it would best be started by someone that isn't a paid editor but is willing to provide some guidance and written material to keep paid editors out of trouble. In the end, that should be our goal: help any editor follow policy, generate worthwhile content, and avoid sanctions. That which isn't worthwhile, we have AFD for, no different than today. Dennis Brown - 2¢ 13:27, 18 July 2017 (UTC)
Dennis, thanks for your note. My goal in posting here was to make sure that the community was aware of this from the beginning. I am aware that people have strong feelings about paid editing so wanted to communicate clearly and broadly, at an early stage, and get useful feedback so that as this move forward (if it does...) that could be built in. My plan has been to do further planning and then present again, with detail, before launching it. Jytdog (talk) 15:02, 18 July 2017 (UTC)
That WikiProject is not really driven by paid editors. With the lack of that sense of "ownership" in the positive sense, comes neglect. Part of the design of this WikiProject is that paid editors will "invest" in its authentic success in the community - that it would propagate best practices and help us identify paid editors who aren't following PAID much less best practices. Jytdog (talk) 15:02, 18 July 2017 (UTC)
I saw that yesterday and just didn't say anything yet. That WikiProject isn't driven by anything, it is basically a ghost town. Re-purposing defunct projects is allowed. Dennis Brown - 2¢ 15:12, 18 July 2017 (UTC)
i allso wanted to say that this would be "organic" - the next step in the evolution of rhe Statement. Jytdog (talk) 15:16, 18 July 2017 (UTC)
IMO before we will get those involved with paid editing interested in doing it above board, we need to be much more vigorous in policing those involved with undisclosed paid editing. As lots of the articles made by throw away socks of undisclosed paid editors are kept they have no incentive to change. Doc James (talk · contribs · email) 15:21, 18 July 2017 (UTC)
needle-exchange services in Vancouver or the like, and all the issues around that. Jytdog (talk
) 15:37, 18 July 2017 (UTC)
I have seen a handful of disclosed paid editors who consistently use the AfC process. There is nothing stopping us form listing them in a central location right now. Doc James (talk · contribs · email) 16:02, 18 July 2017 (UTC)
In a way, a project would have us picking the winners and losers. Paid editors that followed the rules wouldn't have any problems, so they would be more efficient (from their perspective). Paid editors that didn't, who still socked, who lied about their status, would be subject to having all their work deleted, wasting their time. This creates a financial incentive to play by the rules, and rewards those that do by letting them spend more time writing passable articles and getting new clients, and less time dodging AFD and Checkusers. This may sound simplistic, but people always act in their own self-interest. We just need to provide a better alternative to socking, one where we can easily monitor everything. Dennis Brown - 2¢ 16:41, 18 July 2017 (UTC)
A "project" or a "guild" won't do anything to deal with the cause of so-called black-hat paid editing, which is the demand for articles about non-notable subjects. They'll continue to take money from people who want articles written about them, they'll create their throwaway socks for that purpose. If they don't slip by under the radar they will be blocked. So what? They don't care. They'll create other socks, using VPNs etc. Coretheapple (talk) 17:08, 18 July 2017 (UTC)
I have over 1500 SPI blocks, including a record setting 300 in a single paid editing case. VPNs aren't that hard to catch and rangeblock, and pushing as many as you can into the "good" side means fewer to deal with at SPI. Its a bit more complicated than you are making it out to be. I've had more than a few extended conversations with paid editors offwiki, I know the system quite well. Many would rather do so in a legit fashion but the current rules make it hard. Dennis Brown - 2¢ 01:27, 19 July 2017 (UTC)
This would be a lot more organic if it had happened three years ago, and if there were more involvement from any of the signatories. Right now there are just a couple of statements on the statement's talk page, with only vague details on what kind of work and outreach the parties in question would do. Absent their participation in these discussions, it's hard to tell if they're interested in this initiative or in engaging the non-paid editor community in general. isaacl (talk) 05:55, 19 July 2017 (UTC)
That's true. There is not a single paid editor involved in this discussion one way or the other. They can come here and argue how such a project or guild would benefit them, and complain directly about how supposedly difficult it is to comply with the very few rules regulating paid editing (per Dennis's comment above). I've never heard such complaints, and I've never seen them in public, probably because they would be greeted with ridicule. Coretheapple (talk) 12:59, 19 July 2017 (UTC)
I see WikiProject Cooperation and in particular Wikipedia:WikiProject Cooperation/Paid editor help (the paid editor noticeboard) as a way for the non-paid editor community to provide support to paid editors. For any paid editor support group to be successful, I feel the community needs to reinvigorate a group of non-paid editors to provide assistance, whether it is at the current paid editor noticeboard or somewhere else. isaacl (talk) 00:59, 19 July 2017 (UTC)
Oppose: We don't want all paid editors to create an project, otherwise it can cause problems. KGirlTrucker81huh?what I've been doing 19:17, 18 July 2017 (UTC)
Oppose As stated above, allowing for the formation of a WikiProject/Guild/What have you essentially grants tacit approval. We should be here for the benefit of the project, and not to try to turn a buck or push an agenda. caknuck°needs to be running more often 20:44, 18 July 2017 (UTC)
Oppose this would further legitimise some paid editing, the more we de-legitimise it the more the paid editors have to hide by writing neutrally and including neutral sources. I doubt we can get to the stage where paid editors are telling their clients that they had to mention the scandal but they did keep it out of the lede, but that is the direction I'd prefer us to aim for. ϢereSpielChequers 14:17, 19 July 2017 (UTC)
User:WereSpielChequers the notion of "deligitimizing" is what we have always done, and there is no evidence that the problem of undisclosed paid editing is going away or that the public even understands what that means. The goal here again is to a) influence the market for it (which has grown up despite the message that "paid editing is bad"), which we have never tried to do before, and b) be provide a more well-defined space where paid editors can learn best practices (the real ones, not the worst ones). Jytdog (talk) 00:15, 20 July 2017 (UTC)
That the problem is pretty bad right now doesn't mean it won't get far worse if we stop managing it. I've seen a few nice people who backed out quietly when I pointed out that what they were doing was in conflict with our goals, but the egregious examples of gaming the system and trying to covertly promote their stuff more than make up for that, and if we give the latter a soapbox to stand on, we'll have an even harder time ridding the project of spam. DaßWölf 00:38, 20 July 2017 (UTC)
Well said Wolf. I'd add that we don't want paid editors learning from each other, we want paid editors learning from editors who write neutrally, use reliable sources and who avoid areas where they have a conflict of interest. ϢereSpielChequers 07:07, 20 July 2017 (UTC)
Just fyi, have been thinking about this further, and it might make sense to move that activities around the "Statement" that are already happening, to the WP:WikiProject Cooperation. Might be an easier way to go to accomplish the same thing. Jytdog (talk) 00:00, 20 July 2017 (UTC)
Support - A step in the right direction. There is a difference between white hat and black hat paid editors. Sorting the sheep from the goats is what it's all about... Carrite (talk) 04:29, 20 July 2017 (UTC)
Support, after thinking about it for a while. We're never going to stop paid editing altogether, so having some paid editors who are members of the community in good standing is an absolutely solid idea. Enterprisey (talk!) 06:43, 20 July 2017 (UTC)
Oppose - these guilds generally refer to self-regulatory bodies for desired groups; paid editors are, by our standard, an undesired group. עוד מישהוOd Mishehu 07:58, 20 July 2017 (UTC)
Support I'm opposed to paid editing, but I don't see the harm. Perhaps it's a dog whistle I'm not hearing. As pointed out above, anyone can create a Wikiproject. So what are we arguing about? Whatever happens here it will be done, or not, depending upon whatever the whims of individual Wikipedians. Figureofnine (talk • contribs) 00:15, 21 July 2017 (UTC)
Oppose, mostly per Coretheapple. Double sharp (talk) 08:40, 21 July 2017 (UTC)
Suggestion. Is there milage in encouraging corporate user pages? Let us say that Bodgeit & Scarper want to inform the world that they are "the largest (2017 sales: 35 million) and best manufacturers of spring loaded rodent elimination devices". They, or their agent, can put this on a user:Bodgeit_&_Scarper. An editor can then edit
mouse trap to add the information that "In 2017 Bodgeit & Scarper claimed to be the largest manufacturer with 35 million sold.<ref>Bodgeit & Scarper, ''company page'' [[Bodgeit & Scarper]] accessdate=1 April 2017</ref>". Paid editing of the main encyclopedia can then be banned but "white hats" are able to input traceable information whilst eliminating POV. Just a half-formed thought! Martin of Sheffield (talk
) 09:56, 21 July 2017 (UTC)
Oppose I appreciate Jytdog and others here commenting to advance the conversation. If Wikipedia were to develop infrastructure for supporting paid editors, then I think the start should be for paid editors who are not editing Wikipedia articles on people or organizations. Right now "paid editing" is almost synonymous with "editing for a brand or promotion". Because of that heated discussion, we do not create pathways for benevolent paid editing about general reference topics which do not benefit promotional interests. We have a highly committed model for expert paid editing in Wikipedians in Residence. We do not have a light payment model, like for example, an organization which wants to be less committed in funding a scholar to edit Wikipedia articles in a general field like "sanitation" or "public parks" without promoting a brand. For political debates there are some organizations which would fund neutral discourse and presenting all sides of issues, like for example, listing all major points of view in a discussion on any major policy issue. There are lots of organizations which invest large sums of money in sharing ideas in Facebook and Twitter, when actually, what they would really like is to have neutral information in Wikipedia. If there were a club for "no branding, no promotion paid editors" then I think that could be a workable, positive space for some editors. Once we established a clear path for paid editors who have nothing to do with branding, then perhaps we could address the more controversial talk about branding. So far as I know, 100% of paid editors doing editing for brands have caused problems and made volunteers upset. I see no reason to chase a path with a 15 year, 750,000+ attempt, 100% failure rate. Blue Rasberry (talk) 16:35, 21 July 2017 (UTC)
Limited support Some editors perform absolutely herculean tasks on WP, and it is a travesty that none of them should ever receive any recognition for their labors and the selfless giving of their time and expertise beyond just a few barnstars. This should certainly change, even if it is only a small stipend as a token of appreciation for their prolific efforts. Whether it be done through crowdfunding or some Wiki endowment, I do not know. And no doubt not all editors would even wish to be paid for their work, but those who do should have a means of submitting their editing history for review. A committee of admins could then analyze the value of their contribs and decide what, if any, compensation would be appropriate. Another option might be a PayPal link placed on certain user pages to recognize some of the top contributors, allowing others who wish to subsidize and encourage their efforts to do so. Incentivization of excellent work is certainly in the interest of this site. - JGabbard (talk) 17:37, 21 July 2017 (UTC)
Support with Guild member fees in Bronze, Silver and Gold accounts. Membership cards include exclusive benefits, such as immunity from 3RR and get out of AfD for free (see fine print for disclaimers and limitations). Members earn double and triple points for gratis edits made in a non-paid capacity. Other benefits include free Wikimania scholarships, the private email address of the WMF president and a Wikipedia tote. -- GreenC 18:52, 21 July 2017 (UTC)
Very strong Oppose. Every single paid edit whether it is written neutrally or not, is an attempt to promote a company, a product, a person, or a non-profit. That is not what Wikipedia is for, and it's not what thousands of maintenance workers and bona fide content creators offer their unpaid free time for. The slightest relaxation in our view on paid editing, especially the creation of help/support areas for paid editors will be taken by them as a legitimisation of their activity. We already have plenty who think that by putting a paid editing declaration on their user page means we condone paid editing and give them carte blanche to go ahead and write what is basically blatant spam.
Give these spammers the slightest crack in the plaster and they will soon be chipping away at our rules and guidelines until they've knocked the whole wall down. In collaboration of the community and the WMF a short trial of some new measures is soon going to take place and its analysis will show what kind of effect, if any, it has had on spam (as well as other unwanted content). That, together with the non-indexing of new articles, should go a long way towards negating the SEO advantages for the 'Get me a page on Wikipedia' customers, and reduce the incentive for the 'We'll get you a page on Wikipedia' merchants.
Paid editing is not particularly difficult to detect by experienced
New Page Reviewers, and spam links slipped into articles should be recognised by recent changes patrollers and Pending Changes Reviewers, and a few software enhancement we are asking for (eg. ORES, and better automatic duplication detection) should do the rest. What is increasing now however, is the number of direct offers of money for work being sent by email to admins from professional rings of socks (so it's already going partly underground). We can only rely on the sysops' integrity to refuse. I understand that measures to combat paid editing will drive it underground, but I think we need to stick to our principles and if we don't yet have such strong principles, it's time we did. Kudpung กุดผึ้ง (talk
) 21:42, 21 July 2017 (UTC)
Very strong Oppose. Kudpung has said it all above and I concur.Charles (talk) 21:53, 21 July 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
NFCC #8 and Discographies
Hello, I apologize if this is the incorrect place, or if this has already been discussed ad nauseum. It appears it has been discussed before, but not at the village pump, and afaik, not recently.
But: I recently added album covers to the Bob Dylan discography, and these additions were reverted. [note: at the time I wasn't aware of the policy, btw] This appears to be the general practice on WP, and I certainly don't blame anyone for following general practice. BUT if you look closer at the reasoning behind it, it doesn't make much sense to me.
NFCC #8: Contextual significance. Non-free content is used only if its presence would significantly increase readers' understanding of the article topic, and its omission would be detrimental to that understanding.
The reason I added the pictures is not because I love Bob Dylan and want his cover art everywhere (though that's not totally untrue). It's because I was on the discography page and it really did not help me. It's a bunch of names, a bunch of numbers. Without pictures, Dylan's 38 albums all run together. It's just a wall of text, separate by a table, but still not helpful. The cover art provides context, it DOES significantly aid in understanding of the article. Maybe it doesn't assist when an artist has 4 albums. But for artists like Dylan, or say Paul Simon (he came to mind), or anyone with a large amount of work, I think having pictures DOES help. The pictures help to identify the content. Without it, Blood and the Tracks and Street-Legal might as well be the same album.
I would further like to point out the wording of the WP policy:
The use of non-free media (whether images, audio or video clips) in galleries, discographies, and navigational and user-interface elements generally fails the test for significance (criterion #8).
There it is, GENERALLY FAILS. That is to say, there ARE exceptions.
So again, I bring it to you - should there be leniency on no album art in discographies where the artist has over a certain number of albums? I certainly think it makes sense, and personally it WOULD significantly increase my understanding of discographies. It appears to fall within fair use - and the image size used could be even smaller than the 300px used on the album pages. I don't see how this would go awry with fair use any more than using it in the album page. ‡ Єl Cid, Єl Caɱ̩peadorᐐT₳LKᐬ 13:30, 31 July 2017 (UTC)
What significance is putting album covers in a list helping? I know that for music fans it will rapidly help them find an album (they're likely to remember imagery over names), but we're writing for the general reader that may never have seen these. And just adding the image to the list just to help break up the space visually is absolultely not acceptable. You can use free imagery of Dylan in concert or other aspects to help visually assist the list, for example, but there's no logic to considering an NFCC exception for long discographies. --MASEM (t) 13:34, 31 July 2017 (UTC)
What do you mean? Fair use is not connected to whether the user is a music fan or not. I didn't say the purpose was the break up space - all I meant was that having pictures to go with the extensive text would HELP the understanding. Seeing the name of an album vs seeing the name and a picture of the album would certainly appear to provide more context and help in the understanding. And by your logic, what help is there in having the album art on the album's article? The same argument applies in both places. ‡ Єl Cid, Єl Caɱ̩peadorᐐT₳LKᐬ 13:38, 31 July 2017 (UTC)
Except on a discography, you are not going into any details of the album, just basic facts. Note that we generally do allow cover art on standalone articles about published works even if the cover art is not discussed because we recognize that there is implicit marketing and promotion that comes from the selection of art, but this atop a lot of coverage of the work itself, so it clearly is a reasonable allowance. You don't have the same in the table of albums, and as we are trying to minimize the amount of non-free images used and how many times they are used, we do not allow those in discography tables because these do not go into any significant details about the works. --MASEM (t) 13:43, 31 July 2017 (UTC)
@
puposely more restrcitive than fair use and asks us to try an minimize our use of non-free content as much as possible. This does not mean that a non-free file can only be used once, but it does mean that we should try and use alternatives to non-free content whenever possible. -- Marchjuly (talk
) 13:55, 31 July 2017 (UTC)
List of Nobel laureates affiliated with the University of Pennsylvania
? Surely it's not because we think that our readers are fans of them, or will have any idea what most of them look like. But we still think that including those images is useful and appropriate. I believe that readers learn something from photos – perhaps not much from a whatever photos of mostly old white men we could find, at least from seeing how a musical group's album artwork has changed (or not) over time. For some (perhaps a minority of) discographies, I think it would be perfectly reasonable to show most or all of the artwork along with a written, sourced analysis of the artwork.
I think it is very plausible to claim that someone who is not a fan might scroll through The Beatles discography in search of "The White Album" (a navigational use), and be discouraged to discover that you can't just look for white-colored album art. The educated fan already knows that "The White Album" has a different name. The general reader doesn't. WhatamIdoing (talk) 22:13, 2 August 2017 (UTC)
Wikipedia's non-free content use policy does not allow non-free images to be used in articles such as
WP:OTHERIMAGE. The same goes for File:TheBeatles68LP.jpg; it is not licensed as non-free content which means its use is not subject to Wikipedia's non-free content use policy. If the cover art for The Beatles (album) is not being used in The Beatles discography, then it was probably done for editorial reasons and not non-free content reasons. -- Marchjuly (talk
) 22:24, 2 August 2017 (UTC)
If the person does not known the album but by name and is scanning a discography list here, the album art won't help them. An avid fan might be aided by the art, but is also going to know the name. We consider in-table album art on discographies to be pretty much decorative - it would be nice to have but it is far from essential, and thus fails NFCC#8 and thus why it fails NFLISTS. If the art can be free, then great, we can include it if desired, but it is still serving the same purpose, being decorative. --MASEM (t) 22:45, 2 August 2017 (UTC)
I think you're assuming that the reader has started at Wikipedia, and not started at a web search engine, which will have displayed some images. I believe that recent research shows that assumption would be wrong about 90% of the time. WhatamIdoing (talk) 02:16, 3 August 2017 (UTC)
You're describing a situation regarding ease of navigability for readers already familiar with the album art in question, whereas the policy is concerned with readers' understanding of the topic as written. In your specific example (
But such text could be added (and sourced). The idea that Bob Dylan's album art reveals something about the music is not original to Wikipeida.[2] Does your objection end if analysis of the artwork is added to that page? WhatamIdoing (talk) 22:13, 2 August 2017 (UTC)
Discussing the album art on the page about the album makes sense and in fact should be included to strengthen the reason to show the cover art, but it doesn't make sense to cover it on the discography page at all, since there's nothing that connects the art to the overall discographies. --MASEM (t) 22:45, 2 August 2017 (UTC)
I've seen sources that connect the art to the overall discography. "See how all of the albums by Favorite Band have a similar ____ in the artwork" is not an unusual subject for a magazine article (e.g., [3] or [4]). When the source is talking about all of the albums, and comparing and contrasting the artwork on album #1 with album #2, it doesn't make sense to discuss the analysis in an article that's just about a single album. WhatamIdoing (talk) 02:16, 3 August 2017 (UTC)
Then perhaps an article discussing the artwork of a set of albums might be appropriate if sufficient reliable sources can be found to support it. That wouldn't validate inclusion in a discography. --Hammersoft (talk) 13:39, 3 August 2017 (UTC)
Or here's where an imageframe or a small montage image in the lede or outside the tables would be appropriate to discuss the album art sequence. But it would not be required to show every cover, just a few examples to demonstrate the perceived connectivity of the album coverage; since our goal is to summarize and not be exhaustive, we can use the references provided to give the reader a site to learn more from. But that type of source would not be allowed to justify the inclusion of all album covered in the discography table itself. --MASEM (t) 14:17, 3 August 2017 (UTC)
IFF it's not a user generated montage, and IFF the specific album covers are discussed in the context of reliable source citations. --Hammersoft (talk) 15:37, 3 August 2017 (UTC)
Yes, actually - strike the montage. If we assume we have the individual album art available, then its better to reuse these images (with additional rationales) stuffed into an {{
imageframe}} than make a new non-free montage of the two images. The former is minimizing non-free use. --MASEM (t
) 15:43, 3 August 2017 (UTC)
ANI reform RfC
Hello. You are invited to comment on this ANI reform RfC. Please do not comment in this thread; post all comments on the RfC pages. Thanks, Biblio (talk) 19:29, 5 August 2017 (UTC)
WikiProject Hasbro
I think there should be a WikiProject that oversees the Wikipedia articles about Hasbro's toy, games and multimedia businesses, named Wikipedia:WikiProject Hasbro (just like Wikipedia:WikiProject Lego). A child project of Wikipedia:WikiProject Toys, it would have two WikiProjects - Transformers and G. I. Joe (the latter is believed to be semi-active) - as child projects, and absorb Wikiproject My Little Pony (which is believed to be inactive). It should also oversee other subjects (like Mr. Potato Head, Nerf, Jem, Moon Dreamers, Glo Friends, Hanazuki, FurReal Friends, etc.) previously not overseen by the three individual projects. I'm not sure if I could intensively participate in that project for the long time, but I feel there's a need. JSH-alive/talk/cont/mail 15:31, 6 August 2017 (UTC)
WP:REVIVE Wikipedia:WikiProject Toys, and only split into a narrower group if it gets too busy (which, in my not-inconsiderable experience, requires more than one hundred participants). WhatamIdoing (talk
) 17:59, 7 August 2017 (UTC)
Television channels
I thought there should be new rules regarding articles about television (and, to some extent, radio) channels.
If a regional version of a multinational TV channel business has a fully independent schedule, an article about that particular version can be created, regardless of where the channel is actually transmitted from. (Thus, for example, the articles like
Discovery Kids (Latin America)
, respectively.)
Of course, channels with simple regional advertisement opt-out or minor variation(s) in schedule (like UK's Sky Sports channels in the Republic of Ireland) should not be counted as such.
If, for example, 'Channel H' is simply a rebrand of 'Channel Q', and thus making the former a continuation of the latter, the two should be regarded as a same channel, even if the channel was also reformatted in the process (for example, a documentary channel turned into a sports channel).
licence. Thus, DK Canada and Nick Canada can be regarded as two separate channels.
And finally, article's title (with parenthesis) for disambiguation...
If a channel's name has any word that indicates a broadcast channel (like 'channel', 'television', 'TV', 'network', etc.), a word that strongly implies a media brand, or a name of broadcaster, article's title can simply have a name of country or region in parenthesis.
Cartoon Network (Latin America), TVN (South Korea), Disney Channel (Southeast Asia), Channel 5 (United Kingdom), etc.
Discovery Turbo (UK & Ireland), Cartoonito (Italy), Disney XD (Netherlands), etc.
BBC Entertainment (Southeast Asia), CBS Reality (UK & Ireland), CBC TV (Barbados), etc.
If a channel's name consists of normal word(s), there should be 'TV channel' in parenthesis as well.
Fox (Finnish TV channel), Boing (Spanish TV channel), Pop (Italian TV channel), Boomerang (Latin American TV channel), etc.
I intended to clean up an article marked {Copypaste} from 2016. It was fresh in Oct 2016, a complete article, but with tags that indicated they had been retrieved several years before. It was a mashup of other articles from WP or mirrors.
WP:CWW says a new article like this one needs to have attribution unless WP:NOATT applies or WP:PATT is satisfied. I got into a discussion with another editor who deleted a speedy-delete tag and said the process was fine.
The logical result, over time, is that we end up with a multiplicity of articles describing the same content in different mixtures. There is no harm in that, but if an error is injected into one copy, it can be copied from parent to child indefinitely. Because these pages all come with references, they look legit. Only a review of every line and reference would fix each one. Fixing one leaves the others broken.
WP editors, according to their own desires like to format, correct grammar mistakes, discover new facts and cite them, rearrange old unwieldy articles, or create new ones. That is satisfying work. You can see your results. Asking someone to verify every reference in an article is not very popular, as you can tell from the backlogs. There a million articles (yes 1,000,000) with bad references. Every time one of those articles is copied, the number ratchets up.
In the database world, there is a concept called normality. One such standard is third form normal. In it a fact (datum) occurs only once. It is either correct or false. Fix it once and it is fixed everywhere. We allow wikilinks to whole articles. Why not have another form of wikilink that allows one to build an article from portions of other articles? Instead of copying a paragraph, leaving two separate paragraphs that have to be maintained, there is only one underlying paragraph that is correct in both articles? It would solve so many problems where we now use {main}. The subsidiary article explodes and gets out of sync with the main article.
It's a big step, but it would solve many problems. I posted at the Teahouse, but was recommended here. Rhadow (talk) 13:01, 11 August 2017 (UTC)
I'll start with where I do agree with you. Normalisation is a great goal for basic data. We all should be using it to simplify references and citations. AS an example I have just been looking at one page where one book has its bibliographical information and wikilinks repeated 13 times, a full reference for each change of page number! My task this evening will be to change it to a {{sfn}} system so that there is one bibliography and a series of simple references with the page numbers.
Where I disagree however is when we have "a multiplicity of articles describing the same content in different mixtures" and you say "There is no harm in that". Intelligent use of
WP:MERGE
and hat notes should seriously reduce duplication. This is the 21st century and we do have hypertext! It is reasonable to précis the page "History of XYZ" into a one or two paragraph summary in a section called history within the "XYZ" article. A hat note will lead the reader to the fuller form. What is a waste of time is to copy word for word (and reference for reference) paragraph after paragraph from one page to another. Speaking personally I would not expect a summary to have detailed referencing if there is a full form elsewhere, so the issue of propagating bad references also goes away.
In summary; lets keep normalisation for data and sort out duplication using the existing structures of Wiki. I'm sure there are boundary cases but to create a structure to solve a problem that shouldn't be there in the first place is, IMHO, a waste of time. Regards, Martin of Sheffield (talk) 13:24, 11 August 2017 (UTC)
(
Economic policy of Donald Trump. Copying the content was useful, but keeping them separate was as well. TonyBallioni (talk
) 13:36, 11 August 2017 (UTC)
Hello
WP:MERGE. In the example I described, the editor defended the article to the extent that he or she reverted the Delete tag. Losing the history of the text and its references didn't matter to the editor in the slightest. I pointed out the danger in that, and I think you agree. TonyBallioni gives support for copying and pasting in a specific instance, to disaggregate articles as was done with Trump. What is the solution? Rhadow (talk
) 14:23, 11 August 2017 (UTC)
I do like being in "violent agreement", it's much better than the other! :-) I suspect that the instance you are talking about comes under the "boundary cases" heading. Yes they occur, but are rare and can be dealt with in an ad hoc manner. I just don't see the need for establishing the superstructure of a paragraph database. I may have a poke around and take a look this evening. Martin of Sheffield (talk) 15:03, 11 August 2017 (UTC)
Hello Martin of Sheffield -- Think of the problem another way: Most all of the satisfaction WP gives editors comes from fixing, adding to, or creating content. How about some kind of recognition for merging content, making WP more compact without losing any knowledge? Rhadow (talk) 15:10, 11 August 2017 (UTC)
The issue here is that you are basically talking about a paragraph database. Anyone who is not a data scientest has worked with databases will tell you how difficult they are to maintain: doing it for something as complex as paragraphs within the English Wikipedia (which is already poorly maintained on many of our older articles) would be much more difficult than just doing it on an article-by-article basis. Wikidata exists and tracks some data between the English Wikipedia and her sister projects. It might be something that you might be interested in if you didn't already know about it. TonyBallioni (talk) 15:39, 11 August 2017 (UTC)
Proposal to change the existing displayed title "Ching Hai" to "Supreme Master Ching Hai"
Wrong venue. ―Mandruss☎ 11:33, 15 August 2017 (UTC)
As said in the subject, I suggest the title of the article "Ching Hai" should be changed to "Supreme Master Ching Hai" due the following reasons:
According to the Wikipedia policy for article titles, 1. When the subject of an article is referred to mainly by a single common name, as evidenced through usage in a significant majority of English-language reliable sources, Wikipedia generally follows the sources and uses that name as its article title (subject to the other naming criteria). And "Supreme Master Ching Hai is the name of the subject that is most frequently used to refer to the subject in English-language reliable sources. 2. Ching Hai can be meant to be anyone's name, a name of a place, a name of a thing, and even a phrase of certain meaning in Chinese Language. You will find all different kinds of information related to these two words "Ching Hai" not related to the subject depicted in this article while searching on the internet. And therefore, due to ambiguity in the name "Ching Hai", I suggest "Supreme Master Ching Hai" is the most adequate title name for the article. -- Orwuck (talk) 06:12, 15 August 2017 (UTC)
That is not the purpose of this page. See Wikipedia:Requested moves for information about how to propose a move (title change) of an article. ―Mandruss☎ 06:54, 15 August 2017 (UTC)
Also, that would not be a correct move. We don't even have the page name Emperor Akihito for Akihito. We don't call the queen of the U.K. "Queen" in the title of the article either. RileyBugz会話投稿記録 10:55, 15 August 2017 (UTC)
RfC notice: Remove "adult" as a descriptor from the opening sentence of Family Guy
Template:High-risk) pages. They notify people viewing these templates that changes to them are risky since they are transcluded on so many pages. But, many templates that need the high-use or high-risk templates still don't have them. For example, many of the templates in the lower ranks of the top 3000 most transcluded templates don't have the high-use template, even though most of them are transcluded on 5,000-6,000 pages. To solve this problem, I propose a bot that would look through the templates in Category:Wikipedia templates and see how many transclusions they have. If one had more than 2,500 and less than 100,000 transclusions, the high-use template would be added to its documentation page. However, if it had more than 100,000 transclusions, the high-risk template would be added to its documentation page. PhilrocMy contribs
15:42, 15 August 2017 (UTC)
Allow users in the Account Creator user group to add users to the Confirmed user group
WITHDRAWN
I'm going to withdraw the proposal, as it's clear there is no consensus for it. About 40% of respondents supported the proposal and about 60% opposed it. Most of those opposing it oppose it due to the lack of vetting/qualifications for Account Creators. I'm going to follow-up this proposal with a new proposal to create an "Event Coordinators" user group that includes a vetting process and specific qualifications, as I think that might address the concerns of both the supporters and opposers. Kaldari (talk) 23:03, 15 August 2017 (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.
Some time in the next month or so, the Wikimedia Foundation will be implementing
Confirmed user group, thereby allowing vetted users to create new articles at these events. (Note that these articles will still be added to the reviewing queue at Special:NewPagesFeed.) The purpose of this change is basically to provide a work-around during ACTRIAL, so that disruption to these events can be minimized during the trial. As such, it can either be a temporary or permanent change, depending on what the community prefers. Kaldari (talk
) 21:23, 4 August 2017 (UTC)
Support as a temporary change during
WP:ACTRIAL. Most users who are added to the Account Creator user group are experienced event coordinators who are at least providing some basic guidance on how to create proper articles. Although I'm sure there will still be a fair percentage of low quality new articles from edit-a-thons, this will hopefully keep us from throwing the baby out with the bathwater. We should remember that ACTRIAL is about reducing the volume of spam and COI articles, not 100% eliminating all bad new articles. Overall, I think the contributions from edit-a-thons are a net positive for Wikipedia and we shouldn't cut those contributions off. Kaldari (talk
) 21:23, 4 August 2017 (UTC)
One of the major objectives of ACTRIAL is to reduce the workload for reviewers and other maintenance workers. Last week an editathon in South Africa organised by the SA chapter and the Swedish embassy was publicised during a TV interview and received a high participation. Unfortunately, the facilitator was ill prepared for the unexpected high participation and a number of articles were produced in good faith but were totally unsuitable for an encyclopedia. It's a shame to have to delete these otherwise good faith efforts. Rather than making any changes to the User Group permissions, perhaps it would be more appropriate for editathon facilitators to teach their students how to edit by getting them to create their articles in their sandbox or or in the Draft namespace instead. Facilitators could them move suitable articles to mainspace for them. Kudpung กุดผึ้ง (talk) 00:20, 5 August 2017 (UTC)
Ha! Kaldari, you should know by now that "experienced" has a multitude of meanings. You are aware of the issues relating to the recent Dalit campaign, which involved edit-a-thons and was a disaster. This summary only brushes the surface and is replete with poor decision-making from admins and past/present WMF staff. I can assure you that I am not alone in my estimation that it was a complete mess. I wouldn't trust people like that to make exceptions to whatever the standard operating procedure/policy/guidelines might be. There is no deadline for creating articles but we have a limited number of regulars who actually know what they're talking about, and they're stretched as it is. - Sitush (talk) 00:37, 5 August 2017 (UTC)
Oppose/Needs improvement first as-is, way too many people are getting added to account-creator already that aren't even confirmed themselves! (See this list). I would normally support this, but not unless we put some actual requirements on being an account creator first. — xaosfluxTalk 01:04, 5 August 2017 (UTC)
Xaosflux There are 338 names on that list, probably a lot more than are needed, a very large number of which whose edit count is only double figures. Recently buttons were added to the User Rights Manager to be able to accord rights for a limited period after which they would expire. This was particularly useful for Account Creator. However this feature seems to come and go for various user groups and is again not available for Account Creator. Curiouser and curiouser. Kudpung กุดผึ้ง (talk) 03:37, 5 August 2017 (UTC)
@Kudpung: the expiration should be always available to assign, if you see a case where it's not I'd be happy to check and get a bug open if it is not. Many, many of these were added for "events" and a specific administrator did the majority - I'm following up with them. — xaosfluxTalk 12:34, 5 August 2017 (UTC)
It's a browser problem, Xaosflux. The buttons are not rendering in Firefox on Mac. Kudpung กุดผึ้ง (talk) 16:37, 6 August 2017 (UTC)
Re: needs improvement: To be clear, what I think needs fixing first is qualifications/expiration needs for the account creators themselves. — xaosfluxTalk 20:04, 7 August 2017 (UTC)
Support as useful: as a Lead Trainer for WMUK, I've been running editathons and other training events for the last five or six years and have trained hundreds, perhaps thousands of new editors. As I stated at Wikipedia talk:Autoconfirmed article creation trial #Supporting edit-a-thons and similar events, it would be helpful – but by not means essential – to be able to grant autoconfirmed status to event participants on occasion. Most participants work in their sandboxes, and it is not so often that they want to create a new article, so ACTRIAL won't impact much on most of them. In those cases where an non-autoconfirmed editor has the ability to create a new article on the day, there are work-arounds available. Nevertheless granting autoconfirmed status to someone who is clearly capable of producing a new article that early in their editing career doesn't seem like much of a risk, so I can't see any problem with account-creators being able to do that. Either you trust account-creators to do these sorts of jobs, or you don't; if you don't, then I can understand you opposing the proposal here. --RexxS (talk) 12:12, 5 August 2017 (UTC)
I don't - but I think I could - if we vetted the account creators more (e.g. they had to be extended confirmed to use this). Guidance would be to add confirmed with say a short expiration date, if the people are editing they will end up getting autoconfirmed in a few days anyway. — xaosfluxTalk 12:34, 5 August 2017 (UTC)
So the instructions at the editathon might be: "You've made 10 edits, so now all you have to do is sit around here for a few days and you'll able to move your new article into mainspace." It kinda misses the immediacy I usually hope for. :D --RexxS (talk) 15:10, 5 August 2017 (UTC)
No, assuming this gets supports, I'm saying that attendees would get +confirmed for say a month - if they never come back it just expires, else by the time it expires they would already be autoconfirmed. — xaosfluxTalk 16:15, 5 August 2017 (UTC)
That sounds very reasonable. In practical terms then, what would be the difference between having the right expire after a month and not having the right expire after a month (assuming all participants at an editathon/training event will make at least 10 edits on the day)? --RexxS (talk) 16:24, 5 August 2017 (UTC)
Support per RexxS; and speaking as an equally-active trainer. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:46, 5 August 2017 (UTC)
Support as a temporary change during ACTRIAL: Some newbies go through the ACC process, but during edit-a-thons etc; will be a major disruption to events. KGirl(Wanna chat?) 18:49, 5 August 2017 (UTC)
Support per RexxS, but with the understanding that there will be clear guidelines for granting that would include among other things time limited granting, both of the confirmed status and of account creator status. Note, I don't think ACTRIAL will be a major disruption for editathons per feedback we've received at those discussions. This is, however, a nice plus to make it easier. TonyBallioni (talk) 18:55, 5 August 2017 (UTC)
Support on a temp basis Maybe we can see how this works in the future as well. My name isnotdave (talk/contribs) 08:19, 6 August 2017 (UTC)
Support on a temp basis during the trial, for in person event coordinator use only, due to the time and logistical limitations of such events. Any other use of the ability (in the ACC process, etc) should be treated as misuse and grounds for removal of the bit. – Train2104 (t • c) 12:27, 6 August 2017 (UTC)
Oppose Per the comments below and some review of the list of users with this flag, I have some serious concerns about a relatively large number of users with little to no experience/knowledge of WP policies having this ability. If/when the eligibility requirements for accountcreator are stricter, we can revisit this. See also this apparent
Support during ACTRIAL per above for now. There is no need for having this on a permanent basis. I don't think it should be limited to event coordinators though. Regards SoWhy 16:44, 6 August 2017 (UTC)
Support - both as a temporary change during ACTRIAL and as a permanent change. It would be good to have this on a permanent basis because of the fact that it would help those at Edit-a-thons upload images for the articles they are creating. RileyBugz会話投稿記録 16:52, 6 August 2017 (UTC)
Support during ACTRIAL. Edit-a-thons often involve creating articles. —MRD2014Talk • Edits 00:25, 7 August 2017 (UTC)
Support at least for now until we work out something better. This won't deal with all difficulties in training, but it will help. About 9/10 of the trainees usually do not come back after a month, so there ought to be some expiration date, or they might come back years later and still have the confirmed right (unless this proves to be too difficult to program, it which case we just think of it as a minor problem. However, it is essential that for relatively inexperienced group leaders granted account creator for a particular editahon, that both account creator and this userright expire . DGG ( talk ) 05:26, 7 August 2017 (UTC)
Support for the duration of ACTRIAL, and or if that experiment becomes permanent. Sadads (talk) 17:57, 7 August 2017 (UTC)
Support on an ongoing basis. Enabling edit-a-thons and other events with training and editing on the same way is good for the encyclopedia.--Carwil (talk) 20:34, 7 August 2017 (UTC)
Support Give the userright and let participants make wiki articles. I sympathize with Xaosflux's reasons for opposing but the reality is that at the current pace of conversation, the account creator userright will not be developed sufficiently within the next 3 years. Despite the potential for abuse, there is no public history of problems documented with this userright or with in-person Wikipedia editing events. I do not think that this userright is the origin of the tension, but rather, the tension is between the WMF and Wikimedia communities who are organizing large numbers of in-person wiki events while some of the Wikipedia community are unwilling and uninterested to acknowledge the existence of the events. If the events will happen, then the user right should be granted. If anyone opposes the events, then please take the argument to the WMF which sponsors them and has capacity to host discussions on how they should be managed. Blocking events with private discussions with the lower level, more vulnerable, and well meaning volunteer organizers who do not want to be swept into wiki politics is not the way to develop the Wikimedia community's event policy. Blue Rasberry (talk) 21:15, 7 August 2017 (UTC)
Support confirmed is not a very dangerous user right to have and the threshold for getting it normally is very low. I would support making this permanent. Hut 8.5 21:20, 7 August 2017 (UTC)
Support I think account creators are trustworthy enough to know who should and shouldn't be able to create pages during ACTRIAL, and this seems to be beneficial for letting them create pages without making a given # of minimum edits.
(talk)
22:12, 7 August 2017 (UTC)
Support This seems like an eminently reasonable proposal, and in cases of abuse it seems easy enough to reverse. Ancient Studies major (talk) 22:40, 7 August 2017 (UTC)
Oppose Let these new editors write drafts. I've been to a fair number of edit-a-thons and I don't think most account creators are doing enough to control what the attendees write. Show me that account creators are always being held responsible before I place any trust in their discretion. Chris Troutman (talk) 22:45, 7 August 2017 (UTC)
Support - Sure. Account creators are trusted individuals, and this addition makes sense for their work. -- Ajraddatz (talk) 23:07, 7 August 2017 (UTC)
Support per RexxS. Thanks. Mike Peel (talk) 23:20, 7 August 2017 (UTC)
Oppose until we prune the list of account creators. As of now, I count some 320 account creators, 221 of which have made fewer than 1000 edits (including 50 that have made <10 edits, and another 96 that have between 10 and 99 edits). T. Canens (talk) 23:30, 7 August 2017 (UTC)
Oppose per T. Canens. There are very few editors I'd trust with this tool. Callmemirela🍁talk 23:55, 7 August 2017 (UTC)
Support per Blue Rasberry. Double sharp (talk) 23:59, 7 August 2017 (UTC)
Oppose first per Chris Troutman (I wish all editathon organizers were RexxS but that is not what the incoming pages stream suggests) and then additionally for sake of ACTRIAL's data. I'd rather see what ACTRIAL does when "fully" implemented rather than muddy the data by allowing account creators with potentially widely varying standards to override the limit on new users sending pages straight to mainspace. Innisfree987 (talk) 00:30, 8 August 2017 (UTC)
Oppose. Let's be clear on a few things. There is nothing bad about editors creating drafts as part of edit-a-thons and submitting those drafts through AfC. In fact, that's the whole point of ACTRIAL; new editors submitting to AfC instead of mainspace. Second, keep in mind this opens the door of removals of account creator for cause. If this passes and I see an account creator grant the right to an editor who goes on to create inappropriate articles, that account creator will lose their user right. That's going to affect edit-a-thons more severely than submitting drafts to AfC. ~ Rob13Talk 01:12, 8 August 2017 (UTC)
BU Rob13, from some of the comments here re: account creators, creating clear guidelines for revoking the tool seems like a positive to me, not a reason to oppose. Re: ACTRIAL, we received some pretty vocal feedback from users who cared about editathons and similar programs. We do have some very bad editathon creations, but we also have some very good ones that I think are probably a large part of the 20% of articles by non-AC users that don't get deleted. Your comment did remind me though that I think that if this is implemented, there should be an explicit guideline preventing its use as a part of the education program/WikiEd/school courses: those are the organized events that in my opinion have the most inappropriate creations directly in article space. TonyBallioni (talk) 03:04, 8 August 2017 (UTC)
@TonyBallioni: Here's the scenario I'm worrying about. Account creator grants the confirmed flag during an editathon, and the editor they grant it to creates an article that is immediately speedy deleted as a copyright violation. At this point, the account creator has bypassed ACTRIAL for an editor who doesn't know what they're doing, and the only recourse to prevent this from recurring is to yank the account creator right. Now the account creator is 30 minutes into their edit-a-thon without the ability to help editors create accounts and everyone's worse off. That's surely a concern. ~ Rob13Talk 12:30, 8 August 2017 (UTC)
Rob, thanks for the response. I still see having a fleshed out policy as to when to remove the account creator bit is needed, and think that this conversation has shown that. Your example is a good one, but by giving people clear guidelines, I think it would be rare. As an aside that is probably better for one of our talk pages, the issue of copyvios in new content is really something that we need to work on educating people at NPP/AfC about. So much gets through that isn't caught by EranBot. TonyBallioni (talk) 15:07, 8 August 2017 (UTC)
Oppose mainly for the reasons highlighted in my initial comment above, which Chris Troutman reflects in a more succinct manner.; also per BU Rob13 and Innisfree987. I think T.Canens; figures may be slightly skewed because there are some obvious low-count entries in the results list where it would seem experienced contributors have created "roaming"/"public place" accounts for use at edit-a-thons. Nonetheless, there are enough scary examples in there to make me wonder who has been granting these user rights. - Sitush (talk) 02:57, 8 August 2017 (UTC)
support seems like a good idea. this way, during editathons and such, they can edit semi-protected articles, and create new pages during the ACTRIAL. really, confirmed is not that much of an additional privilege. if there are problems, it can always be rescinded. -- Aunva6talk - contribs 03:22, 8 August 2017 (UTC)
Oppose This sounds like a horrible idea in my opinion. Whispering 03:31, 8 August 2017 (UTC)
Oppose As a recent participant in a Wikipedia Meetup, almost all users were creating articles as drafts or in the sandbox anyway. There is no reason why edit-a-thon contributors cant just submit their drafts for review to AfC as intended, and no reason why these drafts cannot simply be added to a list and edit-a-thon helpers (like myself) can't review their AfC creations themselves, or else move the drafts to mainspace for them (after reviewing them). In the worst case, a draft has to go through a bit of a wait at AfC... what is the problem here? This is the whole point of ACTRIAL, and shouldn't be sidestepped during edit-a-thons or meetups. — InsertCleverPhraseHere 04:05, 8 August 2017 (UTC)
Oppose per Xaosflux, Kudpung, and Sitush. Vanamonde (talk) 04:40, 8 August 2017 (UTC)
Oppose: I fundamentally oppose to all measures increasing any rights of those organizing mass events. This is just WM-agenda, increasing their maneuverable volume, but decreasing WP-quality by under cover agenda pushing. See all further arguments above. Purgy (talk) 06:32, 8 August 2017 (UTC)
Oppose I see no real reason why new editors should be given the ability to easily make pages, they should go through the proper autoconfirm process. or they should create an account before the event like a sensible person would, to learn about Wikipedia, rather than jumping into the deep end of Wikipedia's most difficult task. making bulk new pages does not really help Wikipedia much anymore, since it just 'bungs up' the new page patrol system.
talk
) 07:23, 8 August 2017 (UTC)
Oppose. The most appropriate, manageable, and helpful route to creating new articles during an edit-a-thon is via the draft process. The participants are then being taught the method which they will need to know when the edit-a-thon is over, and there is an encouragement and incentive for participants to get the article right in order for it to go live. It also encourages the attitude that while anyone can edit Wikipedia, what we're after these days is quality contributions. I would rather an edit-a-thon resulted in just one good quality contributor remaining active than have 100 well meaning but less than competent contributors remaining active adding inappropriate unsourced material which then has to be dealt with. SilkTork✔Tea time 08:03, 8 August 2017 (UTC)
Support This should be granted on a long-term basis as it's a hassle if this keeps lapsing. For example, I currently have the account creator right. On Aug 17, I'll be attending an event at the Royal Society of Chemistry. So far as I know, the main organisers are not admins and neither am I. Because it will be on a weekday, participation by volunteers may be limited and so this seems a good example of an event that might be disrupted by over-zealous throttles on account and article creation. The institution and organisers are of impeccable quality and so it's us that will look bad if we can't handle the smooth onboarding of novices at such an event. As another example, I was recently discussing setting up an event at the
policy and is foolish. I was myself checking out Everipedia this morning. I don't know much about it yet but get the impression that it has some momentum because it is more open and welcoming. Wikipedia is not the only game in town. As a further example, I just got an edit conflict posting this. This place really tries one's patience... Andrew D. (talk
) 08:06, 8 August 2017 (UTC)
"Impeccable quality" as scientists, sure. But in terms of Wikipedia knowledge? - Sitush (talk) 08:17, 8 August 2017 (UTC)
The main organisers I'm thinking of are Dr Jess Wade and Dr Alice White. They are bright, energetic and personable. And they are fun to work with – that's why I'm going to take a day's leave to support this event. They exemplify "good faith" and so we should strive to facilitate their work rather than putting obstacles in their way. Andrew D. (talk) 09:44, 8 August 2017 (UTC)
Encouraging users to use the appropriate process should not be viewed as an obstacle. No one here is suggesting putting obstacles in anyone's way; rather, that the due process we have been developing to protect Wikipedia and to enable and encourage positive participation should not be specially put aside. All new articles are over-viewed by the community, be they articles created in someone's home, place of work, university library or an edit-a-thon. The users at the edit-a-thon are no different to any other user - their work will be seen by our new page patrollers and dealt with. If inappropriate articles are rejected by the patrollers this will have a dispiriting effect on the edit-a-thon editors. I'd rather they were shown the right way of editing Wikipedia, so they don't have the experience of their work being speedy deleted, but have it go through AFC where if it gets rejected reasons are given, and the work is still available for the user to work on. Not an obstacle, but an assistance. SilkTork✔Tea time 11:43, 8 August 2017 (UTC)
That sounds like you are suggesting that some people are more equal than others, more deserving of special treatment that is not available to other new contributors. As I said way, way above, it is evident that course organisers etc cannot or do not always vet what goes on and so such special treatment both undermines the trial and doesn't fix the longer-term problem. I realise different edit-a-thons attract different people but the ones I've come across have had pretty universally poor outcomes that have entailed a massive amount of clean up for BLP violations, copyright issues, sourcing and, well, pretty much everything. Being keen is good; being au fait with how Wikipedia works takes time. Edit-a-thons tend to rush through a lot in a short span. Tbh, I'd be quite happy if they didn't exist. - Sitush (talk) 12:03, 8 August 2017 (UTC)
All users are not equal – that's the point of this discussion as we're talking about permissions and privileges.
Confirmed status seems designed mainly as a pure obstacle. The main issue is the four-day wait and that has no functional purpose as nothing much happens during that time; it's just a cooling-off period to discourage people. One consequence of not having confirmed status is that you have to supply CAPTCHAs when adding references. Adding citations is painfully difficult for experienced users; that's why so little of it gets done. When you have to do CAPTCHAs too then it becomes really annoying because they are not easy; I have trouble with them myself. Again, this is another obstacle especially designed to make it difficult for new users rather than encouraging them. Experienced users and admins tend not to appreciate how obnoxious Wikipedia is for a new user because, thanks to their privileged status, they don't have to deal with these obstacles. But all our current experienced users will not exist in due course because we don't live forever. Who will edit Wikipedia in the future if we make it increasingly difficult to get in? Andrew D. (talk
) 17:50, 8 August 2017 (UTC)
All new user are equal. They have no privileged rights unless someone grants them. I don't trust the edit-a-thon environment (plenty of empirical evidence) nor, indeed, quite a few of the account creators to grant rights appropriately and I don't see why a new user should so arbitrarily be able to leapfrog a system that by far the majority of new users have to go through. I'm well aware of the issues of not being autoconfirmed because I've edited occasionally when logged out (one or two edits, in subject areas I never visited before or since). Not having the arbitrary account creatoin process does not make it more difficult to "get in" than it already is. - Sitush (talk) 18:49, 8 August 2017 (UTC)
Empirical evidence? I have attended over 10 events so far this year. They were all of high quality and were typically in partnership with world-class academic and GLAM institutions. They were typically focussed on a new event or on filling in red links, such as missing women. Article creation is a fundamental aspect of such events and it's something that our partners like and can get funding for, because it's productive – an outcome that they can measure and boast about. If you invite people to a one-day event with such a focus it is then ridiculous to tell them that they have to wait four days. That's what ACTRIAL would mean; it would make us look like jobsworths rather than the encyclopedia that anyone can edit. Andrew D. (talk) 06:48, 10 August 2017 (UTC)
I've given you some empirical evidence, Andrew and I've already explained that being an expert in an academic field has no bearing on abilities as a newcomer to Wikipedia. This isn't really about biting the edit-a-thon newcomers, who would be treated just like any other newcomer, but rather the people who grant the rights. Too many, including admins and WMF staffers, demonstrated cluelessness in this area and are so set on their pet "social justice" projects, grant income etc that they can't see the wood for the trees. Sue Gardner's much maligned Indian Education Program was another example. That said, even a select group of newcomers - whom you for some reason think automatically know what they're doing here - would be less likely to be bitten if they went through the usual processes of AfC etc. - Sitush (talk) 07:20, 10 August 2017 (UTC) (Sorry, my "biting" bit makes little sense because you edited your comment while I was writing mine. - Sitush (talk) 08:18, 10 August 2017 (UTC))
Oppose As per SilkTork, while we want to encourage the view that anyone can edit Wikipedia, we also want to encourage the view that creating quality material requires learning about policies and processes, particularly the need for reliable sourcing. Peter coxhead (talk) 08:47, 8 August 2017 (UTC)
Oppose, per Xasoflux. Joefromrandb (talk) 08:51, 8 August 2017 (UTC)
Support while I haven't been involved in many editathons since I left WMUK, I have been involved in quite a few in the past. This userright would be useful in running such events, and it is a reasonable mitigation of ACTRIAL. I have seen attendees at such events not get the importance of having some reliable sources before they hit save, but most attendees create articles that meet our notability threshold, and I've never encountered a commercial spammer or a vandal at an editathon. More to the point, such articles created at editathons are almost always more encyclopaedic than the aspiring not yet professional model, musician or sportsperson who NPP is deluged with. ϢereSpielChequers 10:01, 8 August 2017 (UTC)
Oppose, I agree with Xasoflux and Kudpung, and, this imho is where draft process is for.ronazTalk! 10:18, 8 August 2017 (UTC)
Oppose Until there some kind of vetting policy for Account Creator, I can't see giving that user group that kind of power. Sario528 (talk) 11:59, 8 August 2017 (UTC)
Oppose Edit-a-thons & other wiki-events will be far more productive if they aim to develop new wikipedians who understand why wikipedia is the way it is and happen to have a specialist knowledge rather than incubating COI editors who will abandon the wiki as soon as the event is over and they encounter the real requirements of the wiki. The problem as outlined is more about how the event is conducted rather than about how ACTRIAL and Wikipedia operate.
Encouraging new editors by promoting their articles from userspace/draft rather than setting them up for a bruising review experience the next day will be more likely to encourage them to stay - and that is the purpose of these events, isn't it?
The objectives of the proposal would be better met by:
A template on the draft/article stating that it was produced as part of event, identifying the event's coordinator, categorising the article/draft into a maintenance category for the event, and requesting that during the event (start date & time, end date & time) it would be appreciated if all review action were focussed on helping the author grow as a wikipedian rather than cleanup.
An editnotice onthe draft/article to the same effect, with an expiry set for the event's end.
Getting Twinkle & Huggle to observe the event's template & refuse to add deletion tags during the event. Cabayi (talk) 11:57, 8 August 2017 (UTC)
Oppose - for the reasons stated by Chris Troutman, and BU Rob13. The draft process has a greater control aspect as to the quality of the work proposed. Kierzek (talk) 13:34, 8 August 2017 (UTC)
Oppose, users participating in edit-a-thons should experience the same Wikipedia processes as everyone else. (If my brother goes to an edit-a-thon and then tells me how he created an article, and I then I make an account but can't create an article, I will give up on Wikipedia right away). Also, edit-a-thons and other newbie-sirected activities should probably try to focus on editing existing articles. —Kusma (t·c) 13:38, 8 August 2017 (UTC)
Oppose per those in favor of using the draft space. Bending the rules for new users may have the opposite effect of what the edit-a-thons are trying to accomplish. May as well use the processes your typical new user has to use and adequately prepare them for what Wikipedia is really like.
Oppose Primarily the reason being not all account creators are properly vetted. I do not feel autoconfirmed is a high bar and recommend reaching this bar stay in situ. While necessarily removing a hindrance, this also can be wrongfully abused, accidentally or not. --QEDK (愛) 15:24, 8 August 2017 (UTC)
Support as temporary change during
WP:ACTRIAL. Unless a large portion of the members of the account creator group suddenly decides to join the dark side en masse, I can't see how this can blow up in any meaningful way during a short trial period. I would however suggest combining this with somewhat greater circumspection in handing out the right (500/30 seems like a reasonable bar). --Elmidae (talk · contribs
) 15:32, 8 August 2017 (UTC)
@Elmidae: That isn't possible, because we have people who aren't familiar with Wikipedia running edit-a-thons from an administrative perspective all the time. Do we bar such edit-a-thons from occurring? Moreover, the concern isn't "those evil account creators". I don't doubt our account creators act in good-faith. The concern is that they hand out the "confirmed" right to everyone participating in the edit-a-thon, and the edit-a-thon participants create articles not suited for mainspace. That happens all the time in connection with edit-a-thons. ~ Rob13Talk 15:54, 8 August 2017 (UTC)
@BU Rob13: My thinking is that any edit-a-thon participants of events held during the envisioned ACTRIAL period are unlikely to make much of a blip on the radar, compared to the usual flood of unsuitable creations. a) There wouldn't be all that many of them (don't have any stats - a couple of thousand people? I may be way off); b) as someone noted above, they are well-intentioned and at least somewhat supervised. So, I doubt much potential damage in total, compared to business as usual. Thus an evaluation of the effectiveness of ACTRIAL should still be very possible - and isn't that the main goal?
Regarding experience thresholds of edit-a-thon organizers - I was under the impression these would be somewhat seasoned users. If that's not generally the case, a high threshold for account creation rights wouldn't be sensible, of course. --Elmidae (talk · contribs) 19:04, 8 August 2017 (UTC)
The granting guidelines for ACC seem to be rather permissive at present, perhaps better to instruct coordinators on the process to request confirmed and try to have an administrator or two to keep an eye on the permission page during the event if the participants are expected to require 'confirmed'. –xenotalk 17:12, 8 August 2017 (UTC)
Oppose- it is what, four days and 10 edits? If someone is going to come onto WP, I think 4 days is a logical minimum to understand the ropes of article quality. Further, the 10 edits shouldn't even be an issue, as if the user is creating the article in the sandbox or similar space, they should make at least 10 edits in creating the article there. I don't think edit a thons deserve special treatment (though I'm not wholly familiar with what they are). And being a part of an edit a thon doesn't make someone more trustworthy. Summary - 4 days and 10 edits do not create undue hardship for anyone, and giving power to lift it arbitrarily because someone is part of some organization does not seem rational. Even if we trust the admin more than anything, how can they have any idea if the individual is trustworthy? Leave it be ‡ Єl Cid, Єl Caɱ̩peadorᐐT₳LKᐬ 19:23, 8 August 2017 (UTC)
Support as a temporary change per those above. JTP(talk • contribs) 21:16, 8 August 2017 (UTC)
Support If one of the goals of editathons is to bring in new editors and get them to write articles, making them potentially wait weeks to get their articles reviewed (and possibly shot down by a reviewer with really high standards anyway) is going to be really unsatisfying. The discussions on ACTRIAL happened before article-creation editathons were as frequent as they are now (in particular, WikiProject Women in Red didn't exist back then), and we need a measure like this to account for that change. TheCatalyst31Reaction•Creation 23:50, 8 August 2017 (UTC)
I literally just participated in a women in red editathon meetup and I have to say that there is no need for this. Everyone was working in the draft space anyway, it it was much better to review the articles myself before submitting them to namespace than to let the new users do it themselves (a result of some users working in the mainspace resulted in some articles getting prodded, and another article getting onto mainspace with copyright violations. These problems would have been avoided if these users needed help promoting their articles as the issues would have been flagged when doing so. — InsertCleverPhraseHere 00:02, 9 August 2017 (UTC)
Support during ACTRIAL. --joe deckertalk 01:29, 9 August 2017 (UTC)
Comment I'd be far, far, more amenable to arguments that "let 'em use drafts" if we had a Draft review process that wasn't badly backlogged. --joe deckertalk 03:35, 11 August 2017 (UTC)
Neutral. Assigning any user right should be left in the hands of administrators. But, then again, aren't account creators supposed to have their identities confirmed by the foundation? With that being said, I'm torn on where I stand, given that the requirement to have account creators' identities confirmed by the foundation adds accountability. Steel1943 (talk) —Preceding undated comment added 01:40, 9 August 2017 (UTC)
Account creators who work in the request an account process are identified, but the user right is more commonly handed out to event organizers, who need not be identified. Many of these organizers are new users who have not even reached extendedconfirmed yet. – Train2104 (t • c) 03:51, 9 August 2017 (UTC)
I now oppose this proposal now that I know there is a group besides Administrators that can have the account creation permission other than Account Creators. Steel1943 (talk) 18:49, 9 August 2017 (UTC)
Question - Would implementing this proposal allow account creators to add existing accounts to the confirmed user group, or only allow for assigning this right during the creation of an account? I am inclined to support the latter but quite reserved on the former. Thank you.--
As far as I can tell, it would be the former, just like an admin can assign permissions to any user. – Train2104 (t • c) 03:58, 9 August 2017 (UTC)
Comment - It seems to me that supporting this as a temporary measure to mitigate the effects of ACTRIAL is tantamount with supporting a measure to reduce the value of the statistical data being assessed, and the trail itself. Am I wrong?--
Comment I've been assuming that that the effects of this on the trial results would be insignificant, that new articles from these events do not make up anything like a signficant fraction of incoming articles from new editors. Am I mistaken? --joe deckertalk 15:00, 9 August 2017 (UTC)
Same here. Any numbers available on that? --Elmidae (talk · contribs) 16:54, 9 August 2017 (UTC)
Oppose. With Wikipedia's increasing maturity, the bar for article creation needs to be higher to maintain quality. Editathons seem too often to be a source of low quality article by newbies whose convenors are unwilling to criticize. Xxanthippe (talk) 06:06, 9 August 2017 (UTC).
Oppose Creating them in Draft adds extra work at the beginning for experienced users to review them but I feel that it will also allow to better guide new users and improve the quality of articles in main space. --Crystallizedcarbon (talk) 15:37, 9 August 2017 (UTC)
Oppose per Kudpung, xaosflux, Sitush, and many others above who have observed quite serious problems with the provision of the account creator userright and suitability for mainspace of articles created at these events. Draft space is the way to go for these events. Ivanvector (Talk/Edits) 16:45, 9 August 2017 (UTC)
Oppose. New editors should be encouraged to create drafts, and that's what editing event organizers should have them do anyway. I had people do that at an editing event I worked on and there were no issues with it at all, and a much reduced risk of having to field the question "Why does someone say my article should be deleted?". (Never happened.) Creating an article that's immediately mainspace ready is not something we should encourage new users to try, it's just likely to cause frustration on all sides. SeraphimbladeTalk to me 17:10, 9 August 2017 (UTC)
Oppose Per BU Rob13. This just doesn't make sense. Let me get this straight, the community decided to increase the prerequisite for article creation from "nothing" to "4 days and 10 edits" (addendum, per Kaldari: for a trial run). But the WMF blocked this, and more than 6 years later they're just getting around to testing it? But they want to add the caveat where Account Creators, of all people, can exempt anyone as they see fit? What's even the point then, honestly? It seems like WMF is just trying to add a major loophole to something that they apparently disagree with enough to block a community decision for 6 years. As one of the admins involved at Requests for Permissions, I'll share something that not everyone may realize: Account Creator has fairly high requirements usually, including identification to the foundation, but it's also granted to basically anyone who says they need it for an event. These users may well just barely be autoconfirmed themselves. They're not some well-vetted, highly trusted class. They're literally random people, many of them inexperienced, who claimed they were running an event, and were permanently granted this flag (the ability to grant it temporarily finally exists, but it was only recently implemented). The task of revoking the flag from these users was reinforced by a community consensus, but it has yet be undertaken by admins, due it being a large, tedious and relatively unimportant task in an area where not many admins are involved. Anyway, if you're going to give Account Creators the ability to confirm accounts, you may as well give it to everyone. I just can't see the logic of delegating an administrative responsibility to a ragtag group of users who were rubber stamped. Swarm♠ 18:09, 9 August 2017 (UTC)
@Swarm: I don't think the WMF is seeking this change; it's community members who for some reason think edit-a-thon participants going through AfC would be harmful (how? no clue). The WMF, if anything, would likely oppose this change because it would pollute the statistical results of the trial. ~ Rob13Talk 18:17, 9 August 2017 (UTC)
Rob, my impression is that the WMF has as one of its goals increasing new editors. I don't think @Kaldari and DannyH (WMF): and the Community Tech team have strong opinions either way on this. I believe Sadads who works in another WMF department was one of the first to bring this up as an issue. JMatazzoni (WMF) also probably has thoughts on this as his team more directly deals with editor retention, but I don't know what his thoughts are on it in terms of affecting the trial. The short: my impression is that different parts of the WMF are viewing ACTRIAL in different ways. There is definitely some support for something like this there, but there are likely others who oppose it for the reasons you pointed out. TonyBallioni (talk) 18:24, 9 August 2017 (UTC)
I see what you're saying about WMF not wanting to dilute the data, and that's certainly what you would think they would want. However, after the six-year delay in implementing this, a WMF employee's request for a major exemption for all outreach initiatives certainly does not give the appearance that they are actually supportive of this idea. I'm not saying Kaldari is disingenuously pursuing some sort of hidden agenda, and I think Tony's comment makes sense. I'm just pointing out that the ACTRIAL is such a modest change, and combined with the ridiculousness of this proposal (see my comments on ACCers above), which would gut it, the whole thing seems disingenuous. Swarm♠ 18:57, 9 August 2017 (UTC)
@Swarm: With all due respect, much of what you said above is wrong. First, the community didn't decide to increase the prerequisite for article creation, they decided to request a trial of such a limitation. The WMF is now running that trial. The WMF doesn't want to add a caveat; the community expressed support for a very similar idea at Wikipedia talk:Autoconfirmed article creation trial#Supporting edit-a-thons and similar events. No one at the WMF has any strong opinions on this proposal (that I know of). If you don't want to AGF, that's fine, but I promise there's no conspiracy here. Kaldari (talk) 19:15, 9 August 2017 (UTC)
Again, I was not assuming bad faith, nor alleging some sort of conspiracy, and I expressly clarified that in my previous comment. Thank you, but I don't actually need assurances from WMF staff that there are no nefarious motives at play. I'm sure we can both agree that such a notion is a bit ridiculous. And I'll point out that that aspect of my comment was not even my reason for objecting. It was just an observation on how ridiculous this proposal looks, in the context of my perspective on Account Creators and my perceived significant ramifications for the ACTRIAL. Swarm♠ 20:03, 9 August 2017 (UTC)
The Community Tech team is helping to support ACTRIAL as a research experiment, because it'll give us better information about how all these processes work. It's possible that restricting page creation to autoconfirmed users will drive new people away to an unacceptable extent, and we'll lose good editors and good content. But creating a new page and having it deleted within a couple hours is a terrible experience for new users, so it's possible that if we redirect them to the Article Wizard and Drafts, then they'll be more likely to stick around and learn how to edit. Opinions on both sides are pretty entrenched, and running this trial will help us all have informed discussions about it. So that's why Community Tech is working on this -- you can see the hypotheses and measures that we're working on at Research:ACTRIAL on Meta.
Running this trial has an impact on other people's work, so we want to minimize that if we can. People at the WMF who work with program leaders, like Sadads, want to make sure that people can run events successfully during the trial. We haven't actually looked at the experiment-pollution angle; we should see if we could get an estimate of the number of main namespace articles created in editathons, to see if it would make a difference to the statistical significance.
But this is a community decision; that's why Kaldari proposed this here. Running ACTRIAL isn't dependent on this decision; we've committed to running the experiment. -- DannyH (WMF) (talk) 19:18, 9 August 2017 (UTC)
Those are the events that bring in a bunch of (often conflicted) new contributors who are enabled by people who often don't have much experience themselves (honourable exceptions) or who share similar conflicts and want to steamroller over policy etc in order to get their way (per the link to my talk page right near the top). "More editors" seems to be the overarching mantra and it should not be. - Sitush (talk) 19:29, 9 August 2017 (UTC)
DannyH (WMF), how much research has been done into what type of editing productive long term users do when they first become active on Wikipedia, compared with the type of editing done by short term or single purpose editors whose work is largely unhelpful? Anecdotally, my impression is that the sort of editors on this page commentating on this (representative of the productive heart and core of Wikipedia), would not have started on Wikipedia by attempting to create a new article. While those editors who have started off by creating a new article, have tended to be those who have a vested interest in the subject they are introducing onto Wikipedia (and no real interest in editing on any other subject), and either disappear soon after they have created the article, or simply hang around to feed that article and none other. My anecdotal experience might well be shared by others on this page. We have spent a disproportionate amount of our time over the years, attempting to clean up messes created by users who are not interested in Wikipedia itself, but only in their particular subject appearing on Wikipedia. If WMF wishes to encourage new users, perhaps conduct research into what attracts productive users compared to what attracts disruptive or unhelpful users, and then work on attracting productive users while discouraging unproductive users. It seems to me, again purely anecdotally, that directing new users to go through an approved article creation procedure is likely to attract, develop and retain the sort of editor we want, while discouraging the sort of editor we don't want. SilkTork✔Tea time 08:53, 11 August 2017 (UTC)
I'm not sure that I can agree with the implicit idea that only long-term users are desirable. However,
WP:Build the web
to the linked article) was the most common first edit, and a couple fixed typos or similar small errors. Only two made major changes to an article. Two created their user pages, one moved a page (back then, you didn't have to be autoconfirmed to do that), one warned a spammer, one voted in a discussion, one expressed an opinion about a merge proposal on a talk page, and the other inserted an image to an article. So if you assume that bureaucrats are "productive, long-term users", then the answer seems to be: they did almost everything for their first edit.
There has been some research into the effect of sandboxes and draft space. Someone involved in that project will have more information, but the TLDR seems to be "Draftspace is where articles (and their creators) go do die". WhatamIdoing (talk) 22:11, 11 August 2017 (UTC)
Oppose, Whether via Edit-a-thons or not, articles created by non-autoconfirmed editors should go through AfC, or draft-to-AfC. Softlavender (talk) 22:29, 9 August 2017 (UTC)
Support Trim the list by all means, but this will help the trial not be skewed.L3X1(distænt write))evidence( 22:58, 9 August 2017 (UTC)
Oppose - in my opinion, Edit-a-thons ought to focus on editing instead of article creation, especially if the editors are so inexperienced that they are not even autoconfirmed. And I think the ability to add a user right necessitates the ability to remove that user right, which this proposal does not address.--
Support for a number of reasons - if the purpose of opposing is to force new people into AFC/Draft process thats is nothing but a power trip to many of the reviewers with expectations of content being GA/FP ready. I always encourage new editors to ignore that process, just we did when we started editing its a learning curve becuase its almost certain negative experience. The big issues at editathons isnt so much the creation of new articles but rather that every edit the user gets a captcha thats really unproductive especially as new editors in a workshop are being supervised anyway. There is already a limit on the number of accounts an IP can create so generally need an account creator or an admin, having run workshops for most of the last 10 years as an admin I actually prefer to edit user rights as auto confirmed so that I can capture the new editors usernames and monitor post event whether they return, what issues they run into, review their edits, and generally keep in contact. Gnangarra 00:24, 10 August 2017 (UTC)
The captcha argument is the most convincing argument I've seen here (as it really is very disruptive to new users at meetups). AfC also does sometimes require far too much of new articles. However, the arguments that this change would undermine ACTRIAL, as well as the fact that there are so many users that currently have account creator rights that clearly shouldn't have the ability to do what is proposed here are stopping me from changing my !vote. — InsertCleverPhraseHere(or here) 18:40, 10 August 2017 (UTC)
Oppose On the theory that the current system works reasonably well. If an editor feels that the confirmed right is needed, it can be requested through an admin at
Oppose during ACTRIAL, Support a trial run afterwards if we decide to go forward with ACTRIAL changes. One experiment at a time, please. DaßWölf 01:29, 10 August 2017 (UTC)
Oppose as proposed. Kudpung has presented a number of reasons. In brief, too much chance of trouble that will be hard and/or long to undo. Let them create in draftspace. — No stance on experimenting in a more controlled and limited way. --Thnidu (talk) 04:56, 10 August 2017 (UTC)
Oppose Per Timotheus Canens and Xaosflux. Way too many users with the ACC flag, in my opinion, that list needs to be pruned by about 300 users and a vetting process for the flag needs to be hammered out. - FlightTime (open channel) 07:10, 10 August 2017 (UTC)
Oppose I'm generally uncomfortable with tool unbundling, but this is just a bad idea. As many people above me have stated, giving relatively new editors (and yes, we do hand out Account Creator to almost new accounts who are perhaps running an editathon) the ability to not only bypass ACTRIAL themselves, but to allow the rest of their group to do it too. I also fail to see how articles created at these events are automatically legitimate new article[s] - does being at an editathon just magically make you an experienced editor? There's the implied understanding that perhaps these participants have been given training, but that's entirely down to the organisers. --
to explain
) 07:35, 10 August 2017 (UTC)
Oppose per Xaosflux, Kudpung, Sitush, SilkTork and others. Callanecc (talk • contribs • logs) 08:46, 10 August 2017 (UTC)
Oppose per Swarm and several others. I can add that I took a quick look at the 50 or so first names on the list of users with the "account creator" right, and found a whole bunch of users who aren't even autoconfirmed themselves (several of them have only two or three edits of their own...), but would still be given the right to autoconfirm other users if this proposal passes... - Tom | Thomas.W talk 17:22, 10 August 2017 (UTC)
Worth mentioning that they could autoconfirm themselves and any socks they wanted to create (should they not actually be running an editathon shock horror) --
to explain
) 17:37, 10 August 2017 (UTC)
Oppose As per SilkTork and many others. We must continue to encourage the fact that anyone can edit Wikipedia, but we must be cognizant that not everyone can simply jump in without learning policies and processes. High quality standards have taken years of collaborative effort to create and changing this will undermine a lot of that effort. Spacini (talk) 18:13, 10 August 2017 (UTC)
Oppose per Kudpung amongst others. (((The Quixotic Potato))) (talk) 19:29, 10 August 2017 (UTC)
Oppose I'm not so enthusiastic about the qualities of newly created articles by non-confirmed users. —
talk
) 19:50, 10 August 2017 (UTC)
Oppose per @Train2104: way up above. If anything, this flag needs to be tightened, not loosened in any way. GenQuest"Talk to Me" 21:41, 10 August 2017 (UTC)
Oppose - My reasoning is the same as many of the other editors on this page. All Wikipedians should go through the same processes when joining the website, regardless of the circumstance. The drafting process, in addition to vetting some of the more incomprehensible work that's produced, can serve as an important teaching moment for newer users. Those who are committed to collaborating on Wikipedia will hopefully have the patience to learn from that experience. The only real problem I see here is that new editors unable to directly publish their work might feel discouraged (like they aren't truly editing the encyclopedia "anyone can edit") from the onset and never bother sticking around. But if an editor is committed and goes through with the processes they will almost certainly come out of it more competent than their peers. So I say its worth it if we break a few eggs if that keeps the one-time contributors with their "drive-by" articles under proper supervision. Lastly, I think that this proposal would undermine ACTRIAL and its effects, which would by extension undermine the research that's to be conducted. -Indy beetle (talk) 06:54, 11 August 2017 (UTC)
Oppose. My early thought on this were to support, but I declined to comment for a few days until some of the arguments for and against had been brought up. Now that I read them I'm swayed the other way.
talk
) 09:54, 11 August 2017 (UTC)
Oppose - As per Swarm, I do not think it is a good idea. Adityavagarwal (talk) 12:52, 11 August 2017 (UTC)
Oppose - As per SilkTork, in addition I feel that this proposal would undermine the research that is being conducted with regards to ACTRIAL --Imminent77(talk) 13:45, 11 August 2017 (UTC)
Oppose - Per many others, allowing many new editors to obtain confirmed status is a dangerous prospect. Edithons are a good thing, but they also overload editors like myself that cruise the new page feed. Diverting traffic through our existing system of drafts is the best way to do things. SamHolt6 (talk) 16:54, 11 August 2017 (UTC)
Oppose - encouraging new editors to jump into creation causes more problems than it solves. I am a case in point. Let them cut their teeth on the million plus articles that have problems, so they don't create more. Rhadow (talk) 19:44, 11 August 2017 (UTC)
Oppose per many editors here (too many to name) - If newbies want to create articles we have drafts which is more than sufficient - I see no valid reason as to why we should allow account creators to go on a mass-adding spree especially when most (judging by the link by Xaosflux) shouldn't even be account creators anyway!. –Davey2010Talk 21:43, 11 August 2017 (UTC)
Oppose: it would be a big security risk, especially as many of the account creators are inactive. Esquivalience (talk) 22:34, 12 August 2017 (UTC)
Support as a temporary change during ACTRIAL: This will be a major help during edit-a-thons, which are already guided environments. Sayan rc (talk) 13:57, 13 August 2017 (UTC)
@Sayan rc: The right to auto-confirm other users, and even themselves and whatever socks they might create, isn't a temporary right connected to a certain event, so it wouldn't be limited to just whatever edit-a-thon they were to take part in but would be a "full-time" right that they can use as they want, whenever they want to, and would also be given to several hundred existing user accounts that haven't been screened at all... - Tom | Thomas.W talk 14:16, 13 August 2017 (UTC)
oppose new editors should put articles through AfC - there is no shame in that, and there appears to be an underlying assumption that there is. Doing that does not harm editathons in any way, and actually helps teach new users to respect that they are new and learning and that it takes time to understand the policies and guidelines that allow WP articles to realize the mission of providing high quality articles summarizing accepted knowledge to the public. There is a learning curve. Not impossible to travel up, but there.
On a further note, once permissions are given it is often very hard to take them back, and i do not think it is wise to add this particular permission to this particular class of users.
A better way to manage the trial, if an editathon organizer really wants to give participants the immediate gratification of seeing their work published, would be to recruit independent article reviewers to participate in real time, which also would be helpful in teaching new users how to interact with independent community members. Jytdog (talk) 18:54, 13 August 2017 (UTC)
Oppose: It doesn't help as it can be workaround. I think we can work out a better measure to support edits. Also could be harmful for less developed Wikipedias in other languages take this action.
talk
) 16:06, 14 August 2017 (UTC)
CommentSupport: Does this proposal affect the 500/30 rule? If so, I'm against it because it is not fair to allow some but not all people to circumvent that process. Otherwise, I'm in favor. ImTheIP (talk) 18:14, 14 August 2017 (UTC)
@ImTheIP: no, this would not allow adding "extended confirmed". It would allow bypassing the "10/4" autoconfirmed period only. — xaosfluxTalk 02:23, 15 August 2017 (UTC)
Comment I think all of the opposed (and my currently ambivalent self) would feel better if this "trial period" (as others have suggested) is transparent to confirmed users without account creation rights. Apologies for my prepossession if it already is. :/--Monochrome_Monitor 19:59, 14 August 2017 (UTC)
For reference, here's a histogram of account creators by age and edit count. As stated above, I can't support this right when this chart looks like this. Data as of August 14, 2017 23:15 UTC – Train2104 (t • c) 23:40, 14 August 2017 (UTC)
@Train2104:How do people with less than 100 edits get creation rights? That histogram is very concerning. It's quite the opposite of a normal distribution.--Monochrome_Monitor 01:36, 15 August 2017 (UTC)
@
WP:PERM, and (d) Ad-hoc by any admin, presumably in support of general community standards. If the standards need better definition or a change, a discussion for what works best may be needed. — xaosfluxTalk
10:59, 15 August 2017 (UTC)
Support. This is more than about the drafts process. The purpose of autoconfirmed is to filter out potential abuse from newly registered accounts, mainly socking. Confirmed / autoconfirmed merely means "based on personal acquaintance or track record, we trust that this account is operated by a well-meaning human being". As an admin who regularly grants confirmed status at editathons so new editors can move pages and edit semi-protected pages, I am persuaded that if a user is trusted enough to be given accountcreator rights, they should be trusted enough to give new users confirmed rights. If this opens up the possibility of demoting accountcreators, well, that means the system worked. Deryck C. 11:06, 15 August 2017 (UTC)
Comment The ability to grant confirmed status to a new user during edit-a-thons and similar events could be helpful, if in the right hands. I have been watching this for a while, and Deryck finally convinced me that it could work. My previous main concern was the potential abuse of this privilege by inexperienced users (such as myself) that happen to have been granted this option. The user group in question, that of account creators, is a fairly small one. Yet its impact is quite large, and apparently a large portion of current account creators may not be trustworthy with this proposed ability. I apologise beforehand if the following question has been brought up and turned down before, but why not create a new user group: "account confirmers", with stricter criteria for acceptance? Inatan (talk) 17:51, 15 August 2017 (UTC)
Oppose: Creators of new articles should be experienced Wikipedians. I am suspicious about edithons anyway. Zezen (talk) 22:33, 15 August 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Implement Highlight, Underline, Note, and "share notes" features into Wikipedia.
Implement a highlighting, underlining, and notes feature into Wikipedia.
All changes and uses of these features will be completely unique to every account
unless a "share notes" button was added.
Imagine the possibilities of adding these features.
Usage of Wikipedia will go up
Time management will go up
Literacy will go up
Efficiency will go up
The Learning Curve will dwindle
These 3 features and the "share notes" feature will be great tools for college students
and professors, and essentially everyone because it will make learning that much quicker
My general proposal of this will be the follow;
Add a Highlighting feature
Add a Underlining feature
Add a note/comment feature
Add a "share notes (highlights, underlines, notes)" feature to other users
And if a page gets updated or a pice of information is removed on a page and you highlighted that part, it will give you a prompt saying "This edit has been changed. Will you like you review it?", something of this nature.
I do a ton of reading on Wikipedia and enjoy learning, and this is certainly a feature that is missing in my life and certainly millions of other users as well.— Preceding
The ability to highlight text Template:Highlight already exists but I don't recall it being used often.--76.65.42.75 (talk) 23:07, 13 August 2017 (UTC)
This seems to be more about implementing notetaking features into Wikipedia, rather than strictly text formatting options. I weak support it due to these being cool features that can be potentially helpful in some situations, but I wonder about the overall usefulness of such added features, and how they would even be implemented. I think some more thought needs to be given into how how these features will be implemented, and into the actual, concrete problems and situations this will be useful in. The original proposal seems to be trying to advertise these features, rather than simply proposing them. JaykeBird (talk) 06:57, 14 August 2017 (UTC)
I'd oppose increasing "private storage" areas - how and by who would they be policed? — xaosfluxTalk 02:24, 15 August 2017 (UTC)
Oppose - I see little value in this use of developer's time and system storage space for all the notes that no one will ever read. Beyond My Ken (talk) 01:52, 16 August 2017 (UTC)
Guild of Copy Editors, the number of promotional articles would begin to go down. WikiProject Neutrality could be revived and altered to help solve the problem of promotional articles. Thoughts? CoolieCoolster (talk
) 13:09, 20 August 2017 (UTC)
I'm not sure if it's possible to muster enough manpower to deal with the increasing influx of the marketing material, let alone meaningfully reduce the backlog. I fear that the project may be fighting the windmills in absence of editing restrictions for new accounts or
CAT:PROMO
, which together with borderline notable BLPs seem to dominate the category. Which raises the following questions:
Is it ethical to ask volunteers to work on articles created by paid editors instead of articles about more notable subjects, thus letting the market dictate what they work on? Why should they work for free instead of becoming paid editors themselves?
I was recently approached by a person who wanted to pay me for making their article neutral so as to allow the COI tag to be removed. This is exactly what the proposed WikiProject would be doing for free.
What message does doing their work for free send to paid editors, their clients and their potential clients?
One undisclosed paid editing company used to advertise: Our Wikipedia veterans create or correct it in a way that [...] sticks on the wiki, even gets updated for free by the Wikipedia volunteers later on.
That said, doing something is better than doing nothing. I would be interested in getting involved in such project with two caveats:
It should prioritise the truly notable subjects (as opposed to articles that haven't been deleted only because some editors think that Forbes content farm and the like are reliable sources).
It should focus on removing the promotional content rather than trying to polish the turds that most of these articles are. Many long articles will be
stubified
. Realistically, that's the only way to make a dent in the backlog.
Just as there are people who enjoy fixing typos, copyediting, or stopping vandalism, I believe there must be editors out there who would be interested in helping to remove all of these promotional articles on Wikipedia. The article creation companies may say it is "free editing", but it would be "free editing" just as editors do for any other article. If a company creates an article that is not notable, then it will be taken down. If they create a promotional article, it will be made neutral. Any "free editing" would just be to update notable topics with unbiased information, just so that anyone reading those articles has up to date, neutral information on notable topics. Just like the Guild of Copy Editors has, a WikiProject like this could have events that reward editors with barnstars for significantly reducing the backlog. If we show the writers of these promotional articles and their clients that we are going to start fixing them at an even faster rate, then the clients would see that they are just wasting their money trying to have a company write an advertisement on Wikipedia for them, and some of these editing companies would go out of business. And while it may be more important to focus editing time on articles that are viewed more often and are more important, it is also important to make Wikipedia an even more reliable source by removing biased information and articles that don't belong on Wikipedia. Accepting money for making articles neutral would break the fundamental rules of editing on Wikipedia, so I think if we can come up with other ways of rewarding volunteers for their time spent improving Wikipedia and removing biased information, Wikipedia as an encyclopedia would be greatly improved. Such a project would not be keeping articles on Wikipedia that do not belong on Wikipedia, it would simply delete insufficiently notable promotional articles, and de-advertise articles that are sufficiently notable to be on Wikipedia. These editing companies tell companies that they can write positive articles about them that won't be taken down or edited, so if we can show them that that is not the case, I think it would be a major step in solving paid editing. CoolieCoolster (talk) 00:16, 21 August 2017 (UTC)
Right now you have four main areas that are dealing with these issues:
WP:ACTRIAL will hopefully be a step in that direction that will also provide us with data on other changes that we can make involving new content, much of which is not neutral. TonyBallioni (talk
) 01:04, 21 August 2017 (UTC)
I just think it would be easier for people to coordinate and discuss issues on a WikiProject instead of a noticeboard. There is currently no WikiProject dedicated to removing the backlog of promotional articles. CoolieCoolster (talk) 01:26, 21 August 2017 (UTC)
If you want to create a disincentive for clients to pay someone to create an article for them, then I don't think fixing their articles will help. Reviving WikiProject Requested articles and making the article request process more responsive would provide an incentive to use this process instead. isaacl (talk) 02:06, 21 August 2017 (UTC)
The kinds of companies that hire editors to make them articles don't want actual Wikipedians to be making articles for them, as no regular editor would make an article promotional enough to meet the demands of the company. The companies don't care about improving Wikipedia, they just want a permanent advertisement. And even if some companies would use the Requested Articles WikiProject, I imagine many companies would rather hire editors who professionally make corporate articles than to get one of their employees to have a long discussion with editors that will not approve of everything the company wants. CoolieCoolster (talk) 02:15, 21 August 2017 (UTC)
Sure, but fixing their articles won't discourage them from using paid editors either, because they still get an article, jumping the queue over companies playing by the rules by submitting requests. If you really want to discourage them from hiring editors, then they can't receive an advantage from hiring someone. isaacl (talk) 02:23, 21 August 2017 (UTC)
They will always have the advantage of having the content they want in their article when they hire editors. Fixing more of those articles won't incentivize more companies to do it, as it will simply mean that they will have a promotional article for less time than before. The kinds of companies who hire editors are different from the kinds of companies that follow the rules of Wikipedia. The ones that hire editors have no respect for the rules of Wikipedia and simply want an advertisement, while those who follow the all of the rules, for the most part, simply want their company, if it is notable enough, to be included on Wikipedia. CoolieCoolster (talk) 02:38, 21 August 2017 (UTC)
For an essay on that topic, see Wikipedia:Buy one, get one free. It explains the concept in a fair amount of detail and I think raises a lot of good points. TonyBallioni (talk) 02:33, 21 August 2017 (UTC)
If the article is deleted instead of fixed, the promotional words will be around for even less time and a disincentive for hiring an editor will be given. Why should priority be given to those who engage in a discouraged practice over those who do not? isaacl (talk) 03:23, 21 August 2017 (UTC)
Because sometimes articles created that way are too notable to be deleted. Although for a lot of those articles they end up just becoming stubs anyways, so for most of them it would probably just be better to delete them than fix them, which would leave them as stubs. CoolieCoolster (talk) 12:44, 21 August 2017 (UTC)
Requested articles can be notable too; if the intent is to discourage paid editing, it would be reasonable to give them priority over preserving articles created by paid editors. That being said, I recognize there isn't a perfect answer; if editors are interested enough in fleshing out an article on a notable topic, they should be able to do so, even if the article was started by a paid editor. But if there's nothing to save from the paid editor, the article may as well be deleted and placed on the requested article queue to be dealt with in good time. isaacl (talk) 02:25, 22 August 2017 (UTC)
Lists to include number of pages
Resolved
For certain lists, e.g. people born in a certain month and year, one can repeatedly click on "Next page" to find a specific entry. Would it be possible to have the page number and a little note about how many pages such lists go across, as this may make it easier to find entries?Vorbee (talk) 10:57, 21 August 2017 (UTC)
Could you give a specific example of a page that has this situation? Depending what namespace and how it's formatted, the solution might already be doable vs substantially difficult in different ways. DMacks (talk) 16:31, 21 August 2017 (UTC)
Sorry - my mistake, I think it has already been done. I just went to the category called "1989 births" and I see it does say at the top "The following 200 pages are in this category". Vorbee (talk) 10:10, 22 August 2017 (UTC)
Glad you are able to do what you want. "On Category:... pages" was the key detail I didn't recognize from your original question. DMacks (talk) 13:37, 22 August 2017 (UTC)
Add an option with "Show pages starting with this text" on logs
Hi. I wanted to suggest an option that has "Show pages starting with this text" in the logs because I thought that would be a useful addition. For example, you put "2017" and have that option checked. The log displays every page, deleted or not, that begins with "2017". I would find it difficult to find some log actions without this option, as you have to type in the exact page name, so that's why I'm requesting this feature. Or even better, either that or add the option of "show titles containing this text", so any article with "2017" in its name is listed. I would find this convenient. Rain drops, drop top (talk) 01:37, 21 August 2017 (UTC)
I like this idea; it would also be helpful in finding log entries by namespace (other than mainspace). עוד מישהוOd Mishehu 10:47, 21 August 2017 (UTC)
Would this include categories?Vorbee (talk) 10:52, 21 August 2017 (UTC)
If we can search for anything starting with the text "Category:", then we would get the categories. עוד מישהוOd Mishehu 10:53, 21 August 2017 (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.
Petty impulse vandalism of articles is a common pastime among certain IP visitors, such as bored schoolkids. If IP edits were not visible for the first few minutes, it would discourage a lot of this noise.
Pending changes
achieves something vaguely similar but carries a page-specific admin overhead and has no timeout. I therefore propose that, when an IP user edits an article:
The IP edit will not be updated in the article served to IP visitors until one of:
A fixed time period, say ten minutes, has elapsed, or
A logged-in editor (preferably not all bots though) subsequently updates the article.
The IP edit will continue, as now, to be immediately visible to logged-in editors.
Anybody who edits the article, even an IP editor, will see the IP altered version while editing and not necessarily the displayed version.
The second condition assumes that the logged-in editor has vetted the IP edit, and also allows their user account edit to appear immediately. Most bots cannot vet and their edits do not require visual feedback, so they are best treated the same as IP editors. However a few bots do specifically revert vandalism, so they should be treated the same as logged-in users.
The overall idea is to reduce petty vandalism while affecting genuine editing as little as possible. It will be invisible to logged-in editors. Good faith IP editors would be mildly inconvenienced by not seeing their edits immediately, but not unduly so as they will see the edited version in the page preview and can still make further improvements while waiting.
The use case really only makes much difference in main article space, but there would be little harm in implementing it on all pages, if that were easier and carried a lower processing overhead.
One significant probelm: A good-faith anonymous user who doesn't understand that they sould use the "Preview" button, or doesn't bother to do so, will count on after-the-fact proofreading of the sentence immediately after saving; denying them this right (which you propose to do) will probably increase the amount of mistakes which persist on Wikipedia, as well as some other user, genuinely not understanding the edit, reverting it as vandalism. עוד מישהוOd Mishehu 10:46, 21 August 2017 (UTC)
I am not sure that the immediacy of feedback to the untutored editor is a "right", that is strong language to use. I propose only that it is briefly delayed, not removed. The impact of ignorance could be lessened by adding an info banner explaining that the edit will be displayed shortly. This kind of approach is common on many commentary sites (blogs, etc) elsewhere, sometimes even with logged-in users, so it should not confuse the online citizen unduly. For example I find no problem with it on The Register forums. — Cheers, Steelpillow (Talk) 11:54, 21 August 2017 (UTC)
Oppose vehemently Hells no. Users who have not registered accounts are not to be treated as lesser humans ever. We do not require the creation of an account for normal editing, and should never do so. We already put too many restrictions that require a registered account, and the barrier for entry to Wikipedia gets higher and higher each year, decimating our editor base. The last thing we need is another hoop for new editors to jump through. Let the IP editors fix spelling mistakes, and stop pre-judging them to be vandals, which they by-and-large are not. --Jayron32 14:30, 21 August 2017 (UTC)
Oppose - Wikipedia already doesn't have enough editors to fix all of its problems. We should not make it even more difficult for new people to edit Wikipedia. CoolieCoolster (talk) 14:37, 21 August 2017 (UTC)
Strong oppose-A thousand times no! Amidst all the fanfare with vandal-edits by IPs, we miss their good and sometimes brilliant contributions.The collateral damage exceeds the benefit of such a policy by miles.Winged Blades of GodricOn leave 15:44, 21 August 2017 (UTC)
OK, I get the "death by a thousand cuts" argument. Probably best if it is closed, then. — Cheers, Steelpillow (Talk) 18:14, 21 August 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
In a nutshell, supporters of guideline status state that consensus was already achieved at
WP:VPPRO
, and was buried at the end of a multi-part RfC about "Recent years" trivia of various sorts, where it received very little comment. That RfC was closed by one of its own !voters.
Both viewpoints (and some neutral/other ones) also, of course, have substantive reasons pro and con the page being a formal guideline. I'm "advertising" the discussion here because it's the primary venue for elevation/demotion discussions, and was left out of the original loop. The ongoing discussion is also listed in
WP:CENT, so its location on the project's own talk page (a non-neutral venue, but one with a small number of regulars) is probably not much of an issue in this case. — SMcCandlish ☺☏¢
≽ʌⱷ҅ᴥⱷʌ≼ 23:01, 23 August 2017 (UTC)
Proposal to have the Programs and Events Dashboard have an English Wikipedia interface
Hi, following consultation with course leaders at the University of Edinburgh, we are looking to see if the Programs and Events Dashboard can be brought up to the same level functionality as the Wiki Edu Dashboard. Currently the Wiki Edu Dashboard has the facility where a Course Extension-esque Wikipedia page can be automatically created at the same time as course is created on the Wiki Edu Dashboard. The Programs and Events Dashboard does not offer this and course details are kept firmly within the Programs and Events Dashboard with no in-Wikipedia interface provided. The proposal is for the Programs and Events Dashboard to be able to create a Project Page / Course Extension-like page on English Wikipedia so that any course programme would have this as standard.
In short:I'm proposing to enable edits via Programs & Events Dashboard on this wiki. Once enabled, related activity for courses and other events on Programs & Events Dashboard would be reflected with wiki edits, as currently done on English Wikipedia with the Wiki Ed Dashboard. Here are the types of edits it can potentially make:
Updates to a course page, showing the list of editors and the articles they work on: [5]
Adding templates to user pages when the user joins a course: [6]
Adding templates to article talk pages to show who is working the article: [7]
Strong support – As one of those University of Edinburgh course managers, I would wholeheartedly love to have this facility. It is something that currently exists for educational institutions – but only if in the via the US-institution-only Wiki Edu. It is hard to encourage academic colleagues in the UK to get on board with using Wikipedia in the classroom without the flexibility of such tools to make that happen. Thanks! —Caorongjin (talk) 08:53, 22 August 2017 (UTC)
Support I am a big supporter of the Dashboard. It is an essential tool for any Wikipedian to partner with any external expert organization, such as in a Wikimedian in Residence program. It also is essential for any Wikimedia or chapter group to fulfill its obligation to the Wikimedia Foundation when receiving any grant funding, as anyone getting funded through meta:grants:start has to make a report through meta:Learning and Evaluation/Global metrics and the dashboard is the only way to do this in 5 minutes versus 5+ hours for typical new users in typical programs. As you say, the dashboard is actually designed for schools and does this very well.
I regret to say that the politics around developing the dashboard is tangled. I do see a path forward, and I could use your assistance. Here is my proposal for next steps -
@Caorongjin and Stinglehammer: both of you are in the UK, and I expect that both of you have communication with Wikimedia UK. I request that you both contact that organization and see if you can negotiate organizational support for what you are proposing. Ask Wikimedia UK if it as an organization would be willing to routinely use and recommend the dashboard for all UK school outreach and perhaps all public editing events whatsoever. Please determine how much event coordinators with that group are willing to support what you are proposing.
@Caorongjin and Stinglehammer: as a step two, please have someone at Wiki UK contact me as a member of Wiki NYC. Both NYC and the UK speak English, we share a Wikipedia, and we ought to collaborate. NYC already uses the dashboard for everything.
The Wikimedia Foundation currently has no plans to encourage the use of the dashboard. So far as I understand, the WMF's position is that Wikimetrics is their preferred alternative tool, but I find this advice to be misguided because obviously Wikimetrics is inaccessible and obviously the Dashboard provides the same information except for a non-technical user base. The WMF moves slowly until and unless an organized group of people make a clear demand. I feel that if we could demonstrate a user base, such as commitments from two chapters, then we would be better positioned to make requests which affect the community. Personally I recommend the Dashboard for all languages, for all Wikimedia projects, and to all wiki event organizers.
FYI - the dashboard is going to need funding for development, and probably that money should to to Wiki Education Foundation because they produced the tool. The dashboard works, but there are some situations where the math is inaccurate and especially for university and professional use, I do not want anyone putting research or their reputations on the line over software that gives data which is correct in 90% of cases but is incorrect in some common use cases. The dashboard looks great and provides data which makes people excited but it would cost less to just fix some problems than it would to document and train against its peculiar shortcomings. Perhaps funding could come directly from the WMF, perhaps it could come indirectly from the WMF but through Wiki UK and Wiki NYC, or perhaps it could come from other sources. Either money or a committed developer is required if large group of people make long term plans around this tool. Somehow, users of the tool are going to need to assign a value to the outcomes of the tool to establish a case to request development funding. $100,000 would be good for a year, $25,000 would go a long way and provide some stability and continuity to the tool's development. In my view, thousands of people discuss the data from this tool and I get really anxious about my reputation and Wikipedia's reputation when I know that people expect web applications to only work perfectly, especially in data science.
Critical suggestion: The Wiki Edu Dashboard looks prettier, but appears to provide less utility (or much of it is buried). The Programs & Events Dashboard appears to provide more functionality or at least more immediate access to the features. I would suggest a merger of the approaches, not a binary choice between them. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 16:56, 24 August 2017 (UTC)
Re-ordering 'Interaction' box menu on left-hand side
Background: Noticed over the years that some new editors that hurting to create an article about the company they own or the company they work for or a band that the have just formed or their sister that has just had her first poem published.... have a desire to have the article about 'that' -to appear only. Many (most) show no willingness at all, to read though
Wikipedia:Your first article
but instead go straight to a help-desk. After much guidance and a editors setting them up with a draft space etc, they still came back and say “HELP my submission is about to be deleted!!!” simply because they obviously haven't felt it necessary to read and digest the advice nor follow it – and why should they? When all they have to do is comeback to help-desk every-time when things don't go their way. Thus, requiring more editors to spend more time holding their limp hands. Result is: I don't think any of these proto-articles (of this nature) ever get into main-space due to lack of notability etc., but they absorb at lot of our time and it is a waist of time, when we could be spending it on new 'editors' that may stay if we give them some early help on the specific problems they are still having after reading and digestion WP's written and comprehensive guidance. Proposal: Suggest we move 'Help' down to the bottom of the menu and replace it with 'Howto create an article' at the top. This can be a link to
Wikipedia:Your first article. Not only will it send single purpose accounts there first but if they turn up on 'Help' later, having a problem, of not so much comprehension but having obviously not having bothered to really read it, we can simply refer them back to Howto create an article. It is pretty easy to distinguish newbies who have come here to contribute from those that are just here to promote. So, don't see a deep policy objection here, rather more of a streamlining. HelpDesk is a help-desk not a kindergarten for single purpose accounts who are here to-day and will be gone tomorrow. Aspro (talk
) 17:50, 22 August 2017 (UTC)
Half-support: We should add something like "
How to create an article", but this does not require moving or removing the "Help" link. — SMcCandlish ☺☏¢
Personally, I'd support moving everything, but files and templates don't really need to be. Starting the discussion to see what the support is for this.
I'd support this in full: screen readers have very variable unicode support, and having something closer to plain text would be almost always an improvement in the experience of readers using assistive technology. I've taken the liberty of changing the
pseudo-headings above to real headings in the interest of accessibility. --RexxS (talk
) 20:48, 16 August 2017 (UTC)
Oppose mass bot moves. Only 101 titles are listed above. They can be evaluated manually, and some should have navbox updates if they are moved (to make the bold selflink feature work). DISPLAYTITLE only works on the page itself, not in categories, search results and so on. The mentioned guidelines are about article content and don't consider this limitation in page names. If a sub/superscript is usually ignored in pronunciation then dropping it is usually acceptable, but if a superscript means a power like a square then it's pronounced differently and looks confusing without it. We should consider the common plain text notation "^2", like moving
12m2 Sharpie. The "^" character can be hidden by DISPLAYTITLE with positioning like Kalai's 3^d conjecture at Template:DISPLAYTITLE#Examples. I don't know how screen readers pronounce "^" but I guess their users are used to it meaning a power. There are other special cases like 101² which might be moved to 101 Vol. 2 like some sources call it. 1012 would be strange (and is taken by the year). PrimeHunter (talk
) 22:59, 16 August 2017 (UTC)
Here is where we ought to evaluate them.
b
} 13:44, 17 August 2017 (UTC)
I've gone and done the move to
b
} 22:51, 20 August 2017 (UTC)
Oppose moves by a bot, the number of items involved is quite small per PrimeHunter, and each article/category requires individual review. Templates and files, whose names aren't exactly reader-facing, should definitely not have these characters in them (they have to be typed by editors). FYI, I've sent one of the files to FFD. – Train2104 (t • c) 23:55, 16 August 2017 (UTC)
Why oppose those moves by a bot? Are there any listed above that should not be moved, beyond the few I've already mentionned? If so, we can just exclude those, and let the bot perform these rather tedious things for us.
b
} 02:44, 17 August 2017 (UTC)
Do not use a bot, and do not rename files or templates for this reason. Files or template names will not be read by screen readers. And why can't screen readers be updated to include more unicode characters like this? Superscripts have been there for a long time now. Anyway there may be reasons to rename apart from this. Windows 10 Narrator reads these correctly as "superscript 2" or even "square meters". Windows 10 narrator does not handle the ^2 as well as ² so please don't change this to ^2. So screen readers are not a good reason the alter these. Graeme Bartlett (talk) 00:36, 17 August 2017 (UTC)
The reason mostly is because unicode superscripts/subscripts are pretty much deprecated everywhere, and are an incomplete set. <sup></sup> and <sub></sub> tags support all characters, so that's what people use. There's no effort to improve unicode subscript support, because it's an incomplete character set, and the effort required to improve it would duplicate the existing solution by doubling the unicode character sets, and then somehow develop an alrorithm that could parse ₕₑₗₗₒ as 'subscript hello'. And update thousands of fonts to line up and kern subscripts/superscript characters.
b
} 14:06, 17 August 2017 (UTC)
I support this in principle, as a relatively minor and handy improvement. However, I'm really not in a position to look into this in great detail ... except to reply to the points by Graeme Bartlett that Windows Narrator is not widely used as a screen reader by blind people, screen reader makers have enough trouble updating their products to work with new software versions rather than thinking about Unicode characters, and file names can sometimes be read by screen readers because of the way Wikipedia's image syntax works (as most images are linked and have no alt text). Graham87 02:38, 17 August 2017 (UTC)
Support I don't care what tools you use (bot or manual), end result is what matters. Not sure what the issues are with template and files, but I would support the Articles anyway if had to narrow the choice. -- GreenC 03:11, 17 August 2017 (UTC)
Support, after giving users a reasonable amount of time to review trhese lists and request individual exclusions. עוד מישהוOd Mishehu 19:44, 17 August 2017 (UTC)
Oppose. Use redirects instead. KMF (talk) 22:42, 20 August 2017 (UTC)
I'm not sure you understand what is being proposed here. Moving the pages will create redirects automatically.
b
} 22:48, 20 August 2017 (UTC)
Support getting it done. Neutral leaning oppose on bot method; I tend to trust the objections of the bot-experienced when they say the number of affected articles is too small, and the amount of manual review needed too high, for that method to be practical. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 23:13, 23 August 2017 (UTC)
I am bot-experienced, and the amount of manual review for this is pretty small, and would mostly amount to deciding 'should this page be moved' or not. This would require a series of ~300 edits [150 moves, with 150 follow up maintext updates, with corresponding edit summaries for each]. This cannot easily be easily performed automatically/semi-automatically. If it's worth anything to you, I plan on personally reviewed each of the bot's edit after the fact [probably would take 10 minutes to review it all]. This likely would save me over 4 hours of work.
b
} 03:06, 24 August 2017 (UTC)
I've done AWB runs over more pages than that, in less time than we've been discussing this. :-) — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 03:08, 25 August 2017 (UTC)
Yes, but you can't move pages with AWB.
b
} 14:19, 25 August 2017 (UTC)
Actually, yes you can. There's a working "Move" button on the "Start" screen, right next to the "Watch" button. bd2412T 14:27, 25 August 2017 (UTC)
A button which is disabled and can't be used.
b
} 14:35, 25 August 2017 (UTC)
It may be disabled based on the permission level of the user. I just used it to move all 21 of the lists of political and geographic subdivisions from titles ending in "km²" to titles ending in "square kilometers". bd2412T 14:39, 25 August 2017 (UTC)
Well, if someone's willing to do the work manually, certainly I'm not going to object to it.
b
} 14:52, 25 August 2017 (UTC)
However, you did seem to have forgotten to move the talk pages.
b
} 14:54, 25 August 2017 (UTC)
If you look at my edit history, you will see that all of the talk pages were moved along with the articles. What is left are talk page redirects. bd2412T 14:59, 25 August 2017 (UTC)
I think one was missed. It just so happened to be the one I randomly looked at. Anyway, all fine now.
b
} 15:08, 25 August 2017 (UTC)
Yes, I probably missed one. The interface requires clicking an additional field to also move the talk page. I would prefer to have the talk page moved by default. bd2412T 15:12, 25 August 2017 (UTC)
Attempting infobox merger is a tedious and time consuming process. What adds to the difficulties is the strong opposition faced from Wikipedians with absurd reasons. I liked the
WP:INFOCOL, but it's a mere essay. Can a guideline or policy be framed regarding infobox consolidation listing conditions qualifying for merger or converting to wrappers? -- Pankaj Jain Capankajsmilyo(talk·contribs·count
IP range now blocked. Thanks for the name of the sockmaster, Ajraddatz. I knew I had seen this MO before. ~ Rob13Talk 23:12, 28 August 2017 (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.
Create Logged-in Protection level (), which only allows any registered user to edit. Newly-registered users will be able to edit pages with this level.
If there is high vandalism from IPs, use logged-in protection.
If there is severe vandalism from IPs or any high vandalism from new users, use semi-protection.
However, users can request it if the vandalism came from IPs.
Please do it.
It will use the "Permission=Require registered editor access" text when a page is protected with this level..
For example: "Protected "Page" Persistent vandalism [Edit=Require registered editor access] (indefinite) [Move=Require registered editor access] (indefinite)".
2600:387:9:3:0:0:0:C5 (talk) 10:47, 28 August 2017 (UTC)
Why do you believe semi-protection is insufficient for this case? --Izno (talk) 13:12, 28 August 2017 (UTC)
Oppose. This is the whole point of semi. (As a side note, I vaguely recall a sockpuppetry case where an editor continuously recommended new protection levels, including inserting new padlock color symbols in their proposals. Does anyone else recall that and remember the name?) ~ Rob13Talk 15:23, 28 August 2017 (UTC)
Support. So after creating an account, I won't have to wait until autoconfirmation. Please do not deny. Approve. 2600:387:9:3:0:0:0:B4 (talk) 20:42, 28 August 2017 (UTC)
I can't wait to see what happens after this level is added. But HOW can someone edit the protection interface? 2600:387:9:3:0:0:0:B4 (talk) 20:44, 28 August 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Sorry Button
I say we need a sorry button like the thank button but if you make a mistake you can apologize!
A user talk page post is much more meaningful and more apt to be taken as sincere. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 08:59, 5 September 2017 (UTC)
Automatic R2
I propose that {{
WP:PM/C#6). I don't see the benefit of having others' moves leave redirects that then have to be cleaned up, and as far as I can tell, there are no valid reasons for keeping such redirects. See {{R from move/sandbox}} for a draft implementation. – Train2104 (t • c
) 21:26, 26 August 2017 (UTC)
The template R from move would need to know where a page redirects. If it is placed above the #redirect call, that is not possible. If it is placed below, it might be possible in Lua (but not in Template script), but I'm not sure the MediaWiki API knows where a page redirects on the redirect page. --Izno (talk) 21:30, 26 August 2017 (UTC)
It's placed beneath the redirect by MediaWiki:Move-redirect-text, and Module:Redirect provides the functionality. For testing purposes I changed the conditional to check for userspace and used {{db-g7}} instead of {{db-r2}}, since the latter does not display outside mainspace. Test It works, except that speedy template looks really strange. – Train2104 (t • c) 21:48, 26 August 2017 (UTC)
Can someone familiar with the R-tag templates tell me why the CSD tag looks so strange in there? @Paine Ellsworth: perhaps? – Train2104 (t • c) 23:40, 26 August 2017 (UTC)
Thank you very much for the ping, Train2104! I think the reason some of the text is outside and above the main display has something to do with the fact that the outside text is generated by the meta template used by {{db-g7}}. That template, {{db-meta}}, uses the {{Mbox}} template, which can be interfered with by HTML Tidy when not correctly positioned on a page. In this case, the G7 template should go at the TOP, the very top of a page. Place it anywhere else on a page, as the {{R from move/sandbox}} does, and HTML Tidy may cause the template to appear in an abnormal and unexpected manner when saved.
We should also note that page movers are given the suppress-redirect tool specifically to perform
round-robin page swaps. The redirect is suppressed only to make way to move another page into that title. Page movers are warned that to suppress a redirect under any other circumstances should be done only very carefully and selectively to prevent breaking links both on and off Wikipedia. Paine Ellsworthput'r there
00:48, 27 August 2017 (UTC)
Fixed it by putting it on top of the message. I've seen many cases of CSD buried under redirect and they looked fine, unfortunately we can't automatically place it on top of the page (unless a bot is involved). Thanks for the hint to look into positioning! – Train2104 (t • c) 01:43, 27 August 2017 (UTC)
Yes, I thought about that possibility several hours after I posted the above. The important thing with the Mbox and HTML Tidy is that the template should be at the start of its own line (not necessarily at the TOP of the page). I'm glad you tried that and that it worked. Yet I'm still a bit concerned over the "automatic" addition of any Db template. Seems to me it could quickly grow to be a migraine for admins. Paine Ellsworthput'r there 06:17, 28 August 2017 (UTC)
Support if possible. If it is easy to implement this with existing tools, I don't see how this would not be an improvement. Even in cases where you mean to redirect the page to something else in mainspace afterwards, blanking the R2CSD when doing so is easy enough and doesn't add an extra step. — InsertCleverPhraseHere(or here) 23:09, 26 August 2017 (UTC)
Oppose
WP:RDRAFT says this should not be done and provides a justification. Thincat (talk
) 13:49, 1 September 2017 (UTC)
RDRAFT is about pages that were moved from the Draft: namespace to the main namespace. This proposal is about the reverse. —
Cryptic
16:42, 1 September 2017 (UTC)
My oppose struck, thank you. Thincat (talk) 16:47, 1 September 2017 (UTC)
Comment
WP:R2 says "If the redirect was the result of a page move, consider waiting a day or two before deleting the redirect." so this places the onus for the delay on the admin, not the tagger. Perhaps that is what is meant anyway. Can a warning to the admin be placed in some way? Thincat (talk
) 16:56, 1 September 2017 (UTC)
My comment struck because {{db-r2}} already provides a warning. Thincat (talk) 17:02, 1 September 2017 (UTC)
Oppose. I've decided to oppose this suggestion. This proposal seems unnecessary since admins and page movers are supposed to suppress mainspace redirects to other namespaces. Paine Ellsworthput'r there 09:47, 3 September 2017 (UTC)
Um... I'm pretty sure that this proposal meant to apply specifically to moves made by non page movers and admins (which together make up a very small fraction of total editors). I thought it was implied that moves made by page movers and admins would be suppressed (if checked) and moves made without suppression (i.e. by others) would be tagged for R2 if directed to draft space. Presumably that would also tag redirects created by page movers or admins that forgot to suppress, but that is still better than leaving these cross namespace redirects in place. — InsertCleverPhraseHere(or here) 11:11, 3 September 2017 (UTC)
As you noted, there are a very small number of editors to whom this might apply. And
I think you misunderstand me. this change would affect and improve the experience of all of the other editors (the large group), not admins or page movers (the small group). For page movers and admins, this change would likely have no effect at all, as those users generally suppress redirects anyway (again unless they forget, in which case this change would be a bonus improvement to them as well). The R2 statement about deleting the redirect is about when to delete the redirect after the redirect has been tagged (i.e. it does not say "consider waiting a day or two before tagging the redirect for deletion." it says "before deleting the redirect") This isn't about making up for editorial mistakes, it is about making the lives of normal editors who do not have redirect suppression privileges easier by autotagging redirects from mainspace to draftspace. dbR2 should always be applied to the redirect in these cases, so there is no reason not to make the process automatic and remove a trivial step (none that I am aware of anyway, feel free to enlighten me). — InsertCleverPhraseHere(or here) 23:07, 3 September 2017 (UTC)
First enlighten me. You said "this change would affect and improve the experience of all of the other editors (the large group)". So just how large is this "large group" of editors that move unready mainspace pages to draftspace and cannot suppress the redirect themselves and must add the db-r2 template? Is it large enough to warrant this alteration to a template that is presently used on close to a million redirects with the number growing daily by leaps and bounds? I doubt it, so no, IMAO there is no reason that the "large group" of editors can't continue to apply the SD template manually, which really isn't such a chore, you know. Paine Ellsworthput'r there 23:17, 3 September 2017 (UTC)
PS. I consider your interpretation of the text at db-r2 to prove that it's subject to intepretation. And if we go with your choice, then we just get back to this proposal being a potentially huge migraine for the admins who monitor the db-r2 template application log. PS added by Paine Ellsworthput'r there
Those are fair arguments. It may be that the number of people performing such moves is small (I'd have have a watch of the R2 CSD category for a while to see), but it could also be that many non-pagemover reviewers simply avoid the hassle of draftification because of the need to manually add tags (probably not that likely but possible). In any case the potential number of people that this would apply to (all editors except the 1000 or so Admins and page movers), is a very large group. Per your second point, I guess the real question is if changing the global template makes any noticeable change to any of the existing non-draft pointing redirects, if not, and visible changes are only applied to redirects pointing at draft space, then I would argue that there are only positive benefits. Would this change immediately apply a CSD tag to all existing (but unidentified) cross namespace redirects (potentially inundating that category with many pages creating a temporary backlog)? Even if that is the case, this would only be temporary, and would be preferable to leaving such redirects in place.
As it is, I am surprised that we do not have a bot that automatically tags such inappropriate cross namespace redirects. Perhaps this would be an alternative proposal, a bot that tags all such redirects with a new tag 'cross namespace redirect' which would highlight such articles and put them in a new category so that a user (I'll volunteer) can manually rummage through and tag those that are appropriate for db R2. Would you support this as an alternative? — InsertCleverPhraseHere(or here) 00:30, 4 September 2017 (UTC)
I've done two mass R2 taggings with AWB and a Quarry query. Don't remember how many each were, but someone who can see my deleted contribs could check. – Train2104 (t • c) 13:43, 4 September 2017 (UTC)
in one way or another (probably a section at MOS:BIO), since it is a draft style guideline with almost nothing in it that pertains specifically to article titles (i.e., it is not a naming convention).
Cross-listing at VPPRO because parts of the "naming convention" page date as far back as 2005, and it's been tagged with {{proposal}} for way too long. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 07:48, 11 September 2017 (UTC)
Lint Errors could be enhanced with a short description of each type of error. The nine sub-pages could be enhanced with a short description of their respective type of error. For example, Lint errors: Fostered content should define "Fostered content" with a link to a page where the topic is discussed. (I found that page before but I can't find it now.) Paragraph wrapping bug workaround and Tidy whitespace bug are similarly non-obvious even to experienced editors. Also, these pages seem to list approximately, but not exactly, in order of least-recently to most-recently edited. It would be useful to know the exact rule for how the pages are ordered. One reason this would be useful is, after editing a listed article, the editor may wish to revisit the lint error list page to make sure the error is truly gone. But if editing affects the page ordering, then the user needs to know how to find where the page would be listed after editing.
For that matter, it would be useful to know the rule for how search results in general are ordered. —Anomalocaris (talk) 02:36, 1 September 2017 (UTC)
There is a help page linked in the top right of each error type as well as the general special page. I agree, it is not very discoverable. I have also observed the order as "most-recently edited at the bottom". --Izno (talk) 12:17, 1 September 2017 (UTC)
Regarding order, it's probably in order of "last parsed", which explains why edited articles are lower (as they automatically cause a new parse if the content has changed). But rendering can occur for many reasons, so that explains why the order is not exactly like that. BTW. these are not search results, they are just a list in our databases. Search results are what is returned by Special:Search (these use a completely different storage system, which is optimized for textual and partial matching). —TheDJ (talk • contribs) 09:24, 5 September 2017 (UTC)
Thanks for discussing this. I think Subbu may be able to do something about T162895. But I also have a question about what else it is that we could be doing to solicit more involvement here :) I have posted info a number of times (inrandom order, this obviously doesn't include other venues such as the mailing lists, for example), and we really welcome more ideas about finding other interested people who we could support in fixing pages :) Elitre (WMF) (talk) 16:16, 7 September 2017 (UTC)
While signatures can contain lint errors, there's little chance in reducing the figures significantly. T140606 would need fixing to help with it. -- WOSlinker (talk) 20:23, 7 September 2017 (UTC)
I've been focusing on mainspace content and have filed a couple tasks that would help track the mainspace problems. Signatures being broken is not a significant issue IMO. If people use <font>...</font> and find that they aren't getting the effect they want, they'll ask for help fixing it, at which point the "lint for signatures" issue mostly becomes moot. --Izno (talk) 22:17, 7 September 2017 (UTC)
These messages can all be defined locally, for example in MediaWiki:linter-category-fostered-desc - someone just needs to propose the messages. Feel free to leave edit requests on the talk page of the mediawiki: page. — xaosfluxTalk 03:24, 8 September 2017 (UTC)
… but, as always, please don't do local customisations unless there's a serious need for bespoke information, as it means all future updates are lost to the English Wikipedia unless someone notices and manually copies them across. Jdforrester (WMF) (talk) 15:45, 8 September 2017 (UTC)
But I also have a question about what else it is that we could be doing to solicit more involvement here :)
It is a problem of inefficient tooling. Tasks like this are a) hard to fix b) require an understanding of many technologies (html, css, wikitext, and maybe lua), and then they need to dig and investigate where these errors are coming from. In complicated cases, the lint only gives a hint of where it may come from, this could be a very deeply nested template. Psychology 101, means people only care about things that impact them directly. The pages currently look perfectly fine, and there is seemingly no need to do anything. The situation can be improved by either using the carrot or the stick.
The carrot:
Show errors in preview (https://phabricator.wikimedia.org/T163072)- This should be triaged and prioritized, and is the carrot because it will help all wikitext editors because editors often introduce such errors unknowningly and then spend minutes searching for the cause.
Add an popup whenever people introduce basic errors to pages and try to save (this already happens with the code-editor)
Forcibly activate the parser-migration extension for everyone or show it whenever there are migration errors in the page.
Abusefilter - block new edits (e.g. new editors) from adding such simple (e.g. unclosed tags) lint errors to the template or possibly even the article namespace
The point is that the situation will continue as long as the lint error reports are stuffed in some special page somewhere that only few people even know about and fewer even care. The workboard for editors is the editing tool, putting things elsewhere is a great way to tell them not to care about it. Here's a recent example of this problem (https://en.wikipedia.org/w/index.php?title=Template%3AWFTDA_Division_3&type=revision&diff=799743535&oldid=799729962). A user edited 1 page (template) and immediately brought about 100 high priority lint errors, it could easily have been a template used in thousands or millions of pages, and if someone reverts it they'll simply come back.
The current approach is quite simply insane ... 16:18, 9 September 2017 (UTC)
I don't think that we want to stop new editors from working on templates. Very few of them do, and they're the ones least likely to know how to figure out a problem. IMO it would make more sense to flag this kind of typo to experienced editors. The one responsible for the error you link has more than 10K edits, and even if s/he didn't know how to fix it, the editor would know where to ask for help. Whatamidoing (WMF) (talk) 15:33, 12 September 2017 (UTC)
Meta RfC to try to address one aspect of impersonation
It seems the proposed changes have already come into effect (making the discussion moot) but regardless there is general support for it. Further issues and concerns should be taken up in a new discussion. Primefac (talk) 16:34, 29 August 2017 (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.
Recently it became possible for <references /> to automatically use responsive columns when there are more than 10 references in the generated list. Currently this behaviour is an opt-in mode (<references responsive="1"/>). The opt-in was intentional as throughout Wikimedia, we had many templates that already relied on pre-existing behaviour. Recently I prepared {{Reflist}}, to be able to deal with both situations. As such it would now be possible, to switch the default of <references />, without influencing {{Reflist}}. I think a default column mode is easier for most situations that do not require {{Reflist}} and I want to propose to switch the default of <references /> to automatic responsive columns. So to summarise:
Currently <references /> never has columns
When we switch the default, <references /> will have columns if there are more than 10 references (30em wide, same size as most Reflist usages).
This switch of the default will not influence {{Reflist}}, which can be used for changing column width and a few more advanced features.
It will be possible to disable these columns by using <references responsive="0" />.
Yes please! --Izno (talk) 12:21, 13 July 2017 (UTC)
It would be great! --Jennica✿ / talk 14:52, 13 July 2017 (UTC)
The change reduces the size of the text. This change was not mentioned in the description of this change. I prefer that the type size match the body of the article. Jc3s5h (talk) 15:39, 13 July 2017 (UTC)
@Jc3s5h: I'm not sure how you reached that conclusion, but I cannot confirm it. All references lists have a font-size of 90%. It has been like that since 2011 as far as I can tell. Can you please give examples, and information regarding the skin you use perhaps ?—TheDJ (talk • contribs) 15:55, 13 July 2017 (UTC)
When I tried to reproduce the problem, I realized the article I used as an example has several reference-related subheadings and I had been mixed up about which section I changed (in preview mode only, of course). Jc3s5h (talk) 16:12, 13 July 2017 (UTC)
I agree with this change. The columns seem to be just slightly too wide at the moment, but maybe this is deliberate. Jc86035 (talk) Use {{re|Jc86035}} to reply to me 05:58, 14 July 2017 (UTC)
I support this change. There will no doubt be some minor unintended consequences and some necessary cleanup to a few articles, but that is the price of progress. – Jonesey95 (talk) 16:19, 14 July 2017 (UTC)
Mild oppose. Personally, I prefer the single column style, and think that the change to 2 column that is often made is rarely an improvement. Making it the default will mean this is done with little thought far too widely. If this is to be done, the threshold of 10 is much too low, 30 is about right, at the lowest. DES(talk)DESiegel Contribs 14:44, 15 July 2017 (UTC)
This sounds like a nice improvement. I support making it the default. Kaldari (talk) 18:40, 15 July 2017 (UTC)
I kind of oppose this. As {{reflist}} already does this, changing <references /> too would make creating a single column ref list needlessly complicated. DaßWölf 21:53, 15 July 2017 (UTC)
Oppose. Multiple columns are fine for simple citations, but make it difficult to read long explanatory footnotes. In considering whether to use columns, and of what width, our first consideration should be what makes things easiest for the reader. That has to be done on a case-by-case basis rather than according to an arbitrary standard based on the number of citations. Ammodramus (talk) 16:55, 16 July 2017 (UTC)
@Ammodramus: You consider the case of NOT having columns for lists larger than 10 items to be more common than having columns ? I think we should cater to the largest group of users and to 'safe' defaults. I think that if we can have 90% of the cases right and only need to modify 10%, then that is better than the reverse for the casual editor right ? —TheDJ (talk • contribs) 10:17, 17 July 2017 (UTC)
Would support if the proposal is limited to two columns only. Even long citations / quotes are reasonably easy to read if in a two-column format. Is that what's intended by the proposal. K.e.coffman (talk) 21:20, 16 July 2017 (UTC)
The columns of the responsive column mode of the references tag, are the same as the most common setting for {{Reflist}}: 30em. The amount of columns depends on the width of your screen. —TheDJ (talk • contribs) 12:01, 17 July 2017 (UTC)
OpposeSupportbecause we already have this with {{Reflist|}}. Why re-invent the wheel? What are the benefits of having two paths to get to the same place? Also, with today's screen proportions trending towards wider screens, three ref columns are being used more and more; so if this change were to take place, that capability should be available as well. I'd still oppose this, however, for the same reason as above. It's not a needed universal change, and we already have the way to do it. GenQuest"Talk to Me" 11:16, 17 July 2017 (UTC)
I see several errors in reasoning here. (1) The wheel is already reinvented, it just needs turning on. Our {{reflist}}'s multi-column support was liked so much it got added to the extension itself. (2) This change would use three columns on wide enough screens, it's more or less equivalent to {{reflist|30em}}, not {{reflist|2}}. (3) Two ways to do it already exist. The only thing this change changes is to make the default when "responsive" isn't specified in <references /> be <references responsive=1 /> rather than <references responsive=0 />. Anomie⚔ 12:14, 17 July 2017 (UTC)
Still not clear on there being a need for this. Users of reflist have pretty much moved away from using the column to the width parameters anyway. Doesn't this have the same effect as your #2 above? What, if any, are the differences? GenQuest"Talk to Me" 13:36, 17 July 2017 (UTC)
This form of arguing can also be inverted. Why would you want to keep a difference between two existing methods for the same purposes, now that we have the ability to not have this difference ? Is there a need for columns to begin with ? Well probably not, yet people still like using them. Is there a need to change the default ? Well no one will die if we don't, but if it's already the most common form, then why not align the default with that form and make the exception the more laborious process ? —TheDJ (talk • contribs) 13:52, 17 July 2017 (UTC)
Still doesn't answer the question. Why do we not just deprecate <references> and use the more powerful {{reflist}} ? GenQuest"Talk to Me" 16:05, 23 July 2017 (UTC)
Because {{reflist}} is, at heart, a wrapper for <references />. You can't deprecate the tag as it must be available for reflist to work. DES(talk)DESiegel Contribs 19:29, 23 July 2017 (UTC)
Support People generally like multiple columns, which is why {{reflist}} is so widely used. We may as well make it the default for a bare <references /> too, where it will use what is currently recommended as the multi-column setting in Template:Reflist/doc#Columns. Anomie⚔ 12:14, 17 July 2017 (UTC)
@User:Anomie What is your evidence for this assertion? See my brief inadequate survey (#twelve of 20). --PBS (talk) 09:41, 15 August 2017 (UTC)
Support. There's no harm in doing so since automatically adding columns would actually reduce the amount of space that one has to scroll down. epicgenius (talk) 21:25, 17 July 2017 (UTC)
If we were to remove all paragraph dividers and section headers the one would scroll less but that does not mean that the article would be more readable. -- PBS (talk) 16:57, 12 August 2017 (UTC)
Editors do not have to check and arrange refs in columns when number of refs increases. So one less thing to care about.--Nizil (talk) 06:40, 15 August 2017 (UTC)
Support, especially given that it's only a change to the default. Peter coxhead (talk) 08:14, 31 July 2017 (UTC)
Strong Oppose, at least unless the following issues can be proven not to apply: You're talking about reformatting hundreds of thousands of pages automatically, sight unseen. (I'd say millions, but alas, I think our average article's sourcing may be too scanty) What happens when the multi-column references interact with infoboxes, graphics, tables, elements that editors have customized by hand with HTML and CSS markup? If they break the format, do editors of that page have any way to know that the references behavior was changed? Even if an editor goes back to the history version, will he see the references appear the way they used to or will he see a broken page was always there? (I think the latter). I'm sorry, but as a general rule, please do NOT mess with default behavior. There's not even any obvious reason I can see why two columns are "better" for "more than 10" references but "worse" for less! Personally I've used the simple references / on even stubs with just a few references because it seems easier to read and keep track of a plain list, so I admit some bias against the idea to begin with, but I think the backward/history compatibility and formatting are serious issues. Wnt (talk) 11:39, 4 August 2017 (UTC)
Wnt, can you give a couple of examples of pages that might be affected? The pages you're talking about would have to meet all three of these conditions:
they use <references /> (not {{reflist}} or similar templates),
they have more than ten refs in the group, and
they have hand-customized HTML and CSS markup that affects the list.
I don't ever remember seeing an article that meets all three conditions, and I think that a few examples would help people figure out what you're talking about. This search should give you the list of all articles that meet the first condition (plus maybe an extra 25% that don't), which might help you start your search. If my very quick spot-check is reasonably representative, then something on the order of 100,000 articles meet the first two conditions, but I can't find any that meet all three. I look forward to seeing your examples. Whatamidoing (WMF) (talk) 17:44, 6 August 2017 (UTC)
@Whatamidoing (WMF): Your search isn't working for me - it pulls out things with reflist and references responsive, etc. Also, checking ten more or less totally random articles using that search, as I did, is not checking a hundred thousand. So I did not find the exact thing you mention. But I *did* already find Paladin (Dungeons & Dragons) in that ten, which has a list of twelve footnotes that I think would be less readable when you decide, sight unseen, to put them into columns. If you want, you're welcome to go put a reflist|2 or references responsive into that section and see how the local editors respond. But if it seems pointless or counterproductive to make that change to one article, how can it be OK to do it to all of them? Wnt (talk) 18:02, 6 August 2017 (UTC)
The search pulls out pages using the reflist template, because the proposed change here is "to switch the default of <references />, without influencing {{Reflist}}" (emphasis added), so those pages are irrelevant.
Your written objection above is about "elements that editors have customized by hand with HTML and CSS markup". If nobody can find any examples of such elements actually existing in articles that will actually be affected by this, then perhaps you'd like to withdraw your objection?
User research demonstrates that splitting long (but not short) lists of refs into responsive columns (NB that'd be {{reflist|30em}}, not {{reflist|exactly two fixed columns no matter what, because that's what looks pretty on my screen}}) makes it easier/faster to find what you're looking for in the refs. So, yes, I do think changing that article to use columns for the refs would be a pointful and productive change. Is it (IMO) hugely important for 12 brief refs to use columns on wider screens? Probably not. The longer the list (and the wider the screen), the greater the benefits. Readers will get some benefits at this length, and they will get more benefits with longer lists. Whatamidoing (WMF) (talk) 17:52, 7 August 2017 (UTC)
We have had this discussion. In my opinion it's worth it to break a few rare exceptions if we improve behavior for the far larger majority. For almost any change it is possible to find a small downside and if we give that undue weight, then we will never move forward on anything. Besides if editors have expectations about article content never changing in either format or contents, then they are misguide, per
WP:OWN. Styling should never be relied upon when writing. We are not typesetting a book or a newspaper, we are using HTML, to deliver to each and every person a page that is optimized for his or her usage of the content. And before we get wound up about backwards compatibility, let us not forget that we regularly delete entire templates, even though they have been used in articles. Everything is relative. —TheDJ (talk • contribs
) 15:38, 9 August 2017 (UTC)
Support – The majority of articles use, with good reason, {{Reflist}}, {{Reflist|30em}}, and some other variations that display responsive columns. Making <references /> behave the same way will improve consistency across Wikipedia. A 1-column display for >10 references can still be done. No downside. -- Michael Bednarek (talk) 13:20, 8 August 2017 (UTC)
@User:Michael Bednarek what is you evidence for this even if the template {{Reflist}} is used it is usually used without any column formatting and until User:TheDJ changed it recently it too displayed one column by default. -- PBS (talk) 16:57, 12 August 2017 (UTC)
Support - this is something novice editors can almost never understand, and I don't believe new article creators should have to worry about it. There are few articles for which a multi-column reference list would be inappropriate, and it shouldn't be necessary to manually recode the reflist to be multi-column once it swells up - it should certainly be an automatic thing. Blythwood (talk) 22:17, 9 August 2017 (UTC)
Support - thanks for taking this hard work on. I'm glad to see this proposal come to fruition - as editors we really shouldn't have to manually set how many columns a reference list has. Legoktm (talk) 03:39, 10 August 2017 (UTC)
Support. As I understand it, the facilities to produce other column widths and numbers will remain for those rare occasions where they may be useful, so I see no real down side, only imaginary/hypothetical ones. • • • Peter (Southwood)(talk): 10:08, 10 August 2017 (UTC)
Support. Where {{reflist}} section 2.1, bullet 3 applies it can be overridden (see for example Edith Cavell). The only problem is if someone lets loose a bot or goes off on a spree removing all reflist parameters without reading and thinking. Martin of Sheffield (talk) 11:13, 10 August 2017 (UTC)
Why do you think this isn't an RFC? Anomie⚔ 12:57, 10 August 2017 (UTC)
This is not an RfC because it has not RfC banner at the top! -- PBS (talk) 16:57, 12 August 2017 (UTC)
Support, so long as the behaviour can be turned off by code. While this would work with the vast majority of pages, some will be better off with refs in a flat list rather than columns. Ivanvector (Talk/Edits) 19:26, 10 August 2017 (UTC)
Comment I first saw this earlier today, and was at first in the negative camp wrt a new default for {{
Great Officer of State is the current canonical exhibit A, but even one such reference tightly wrapped into multiple lines in a column is plain ugly. Fortunately, it's the nature of such articles dependent on old PD sources that this citation is often the only one, and having more than ten is a small minority. I don't know of a good solution for these cases; manually forcing some to one column on the basis of visual style is way down the totem poles of priority for me. I am aware that using {{sfn
}} with a single "source" notation is an alternative, but have other issues with that approach.
Some have suggested that we use {{reflist|1}} as an override. But I thought the unnamed parameter was deprecated, so that confuses me.
I'm also in agreement with whoever said that the XML element looks like the old Wikipedia, as opposed to the more concise reflist, especially with LDRs. But, if it's going to be used, I hope we don't literally mean people should write <references responsive /> (an attribute without a value) because it's invalid XML. David Brooks (talk) 21:12, 10 August 2017 (UTC)
ETA: I realize I'm not being constructive above. Does the implementation have the ability to increase the column width if it detects that there are footnotes with more than a certain number of characters?
Great Officer of State
looks much better at 48em, and slightly better at 40em, than the default (I realize that would often just end up in a single column). Also, now that I understand the syntax I see that my comment about LDRs above is backwards, so I withdraw it.
To Mike Christie's comment below - may be true for new articles, so long as the editor is up to date on the responsive feature, but for existing articles requires first finding candidates, which would take some deep analysis. Not so simple. David Brooks (talk) 01:45, 11 August 2017 (UTC)
Support. This should be the default behaviour; it can be over-ridden if needed so I see no issue with the rare articles that don't want this. Mike Christie (talk - contribs - library) 22:53, 10 August 2017 (UTC)
Support Seems like a sensible change that would improve article readability. AlasdairEdits (talk) 14:24, 11 August 2017 (UTC)
Support, currently we let article editors to decide on the number of columns, which means that articles have whatever looks best on particular peoples' screens. We can serve our readers better by adapting to everybody's screens. Max Semenik (talk) 20:22, 11 August 2017 (UTC)
Commment @user:Winged Blades of Godric I have re-open this as I created an RfC two days ago about this issue and my questions there were not addressed. There is no reason for closing this so quickly particularly as it was not well advertised. It is a very big change that affects a lot of pages so I think that there needs to much more widely advertised, than it has been so far. -- PBS (talk) 16:57, 12 August 2017 (UTC)
Oppose keeping default as 1 column. It was the change to the template {{
Great Officer of State that alerted me to this change. While I agree that short citations are better displayed with multiple columns, the majority of pages I have looked at, if they have inline citations, they are full citations and I do not think that full citations are better wrapped into narrow columns because it makes them harder to read. -- PBS (talk
) 16:57, 12 August 2017 (UTC)
Comment @User:TheDJ, I think your comments at VP show a misunderstanding of why people use {{reflist}}. They may use it to display multiple columns, but they may also use it for its other attributes of making the text smaller, or simply use it because it is used elsewhere. It would be interesting to see a proper search done, but using insource:/\{\{[Rr]eflist/ (which times out), and the small sample returned on the first page of results: twelve of the 20 have no parameter, two use "2" as the parameter five use "em30" and one uses "em35".-- PBS (talk) 16:57, 12 August 2017 (UTC)
(1) what makes you think that "Proposal to default references element to column mode" would be a very significant header or that "I have started a proposal to switch the default behaviour of to automatic column mode" would be understood by most people that you intended to change the behaviour of the default setting? (2) why did you make changes to the default behaviour of {{reflist}}before there was a general consensus for such a change? -- PBS (talk) 16:57, 12 August 2017 (UTC)
For your kind information, this was listed at Centralized discussion for an entire month.Your RFC was already closed.Now, move on or take this to AN.Winged Blades Godric 17:04, 12 August 2017 (UTC)
@User:Winged Blades of Godric This was not an RfC so there was no reason to close it after a month. Besides people are clearly still posting the section so why close it? Are you in favour of the proposition or against it? -- PBS (talk) 17:22, 12 August 2017 (UTC)
Comment Since this thread is still active but it seems the feature is now established, I want to reiterate a request I made above that may have been overlooked. PBS (and I) make a valid point: the impact on long references is deleterious to readability. There are probably thousands of articles with long refs in their footnotes (and I may be underestimating by a ten-factor or more). Finding and editing the subset of such articles that have 10+ footnotes in order to widen the columns may be beyond my abilities to automate. So the request is: can the "references responsive" code be enhanced to detect long lines in the footnotes, and substitute a column width of 48em? For some definition of "long", and some tweaking of "48", of course. David Brooks (talk) 17:31, 12 August 2017 (UTC)
I created some long text at User:Whatamidoing (WMF)/sandbox#Columns in those two sizes, and I'm not convinced that the wide columns is actually easier to read (on my screen, etc.). What do you think? Whatamidoing (WMF) (talk) 23:11, 12 August 2017 (UTC)
That's because your text isn't like footnotes, with its mixture of very short and moderately short lines. Using our admittedly extreme example of
Great Officer of State, compare the default setting with one I forced to 42em width (not even the 48 I mentioned) at different window sizes. I think wider is better in this case, although 30 is probably OK for the typical footnote. Now consider the pages many where the full footnote is generated by {{EB1911}} with inline parameter, like "One or more of the preceding sentences incorporates text from a publication now in the public domain: Chisholm, Hugh, ed. (1911). "Antithesis". Encyclopædia Britannica. 2 (11th ed.). Cambridge University Press. pp. 146–147." (see Antithesis, where I experimented with 40em) for the more extreme effect. Or consider editors who put a fully-populated {{Cite book}} in an inline ref. David Brooks (talk
) 00:02, 14 August 2017 (UTC)
In both examples you give, I like the two-column approach better than the one-column approach. (Those widths work out to that number of columns on my screen; it may be different on yours.) Whatamidoing (WMF) (talk) 00:40, 14 August 2017 (UTC)
What we are talking about here is a style preference. As most editors who have subsituted {{
WP:CITEVAR. A change such as this that affects 100,000s of pages ought not to be made by about a score of editors in a discussion that is not even an RfC. -- PBS (talk
) 09:41, 15 August 2017 (UTC)
PBS, while I agree with you in this particular debate, I don't see support for your assertion that "most editors who have subsituted {{reflist}} for <references/> have presumably chosen the number of columns they want". I make the substitution in any case, often through an AWB template, because I remember reading some time (years?) ago that the template is preferred to the xml - in part because it does allow for parameters, but also because raw XML in a document seems so 20th century. Yes, it's more transclusion work for the backend, but that's what servers are for. David Brooks (talk) 16:41, 15 August 2017 (UTC)
@DB surly if you replace <references/> with {{reflist}} then you choose how many columns you want. Personally I often use {{reflist|30em}} but that is because I expect there to be 2 columns on a typical computer display (more or less depending on the width of the window). If I set it to {{reflist}} then I have deliberately chosen to one column. -- PBS (talk) 17:38, 15 August 2017 (UTC)
I took a look at 10 pages currently using the <references /> tag. I found two added before {{reflist}} was created, and another just days after its initial creation (in late 2006). Two were added by editors who primarily edited at wikis that don't use that template. One was added in 2007, three by experienced editors in 2008, and the last by a logged-out editor in 2009. I found no examples of editors removing the template in favor of the native code (although I've personally done that, because the visual editor does live updates for the native code, but not the template, while you're editing).
Another way of stating this is that some of these were added before the reflist template was an available option, and all of these were added before {{reflist}} was used by the Article Creation Wizard or otherwise recommended as the "normal" way to add refs (which, if memory serves, had much more to do with the size of the font than anything else, but now the two methods use the same font, so that distinction no longer exists).
None of this suggests that a deliberate choice against having columns in the article. PBS, if you have evidence that the use of <references /> is a deliberate request for a single column, then please share it. (Remember, the change under discussion has no effect whatsoever on what happens to any article that is using {{reflist}}. It's only about what happens to pages such as Original video animation, where <references /> was added before the {{reflist}} template even existed, and has never been replaced. So if anyone changed an article from <references /> to {{reflist}}, then that article will not be affected by this. It's only if you changed it the other way around that the article could be affected – and I found no examples of people doing that.) Whatamidoing (WMF) (talk) 18:28, 15 August 2017 (UTC)
It is not an issue of <references/> because that has always been one column. However in anticipation of a change to <references /> {{reflist}} has been changed to emulate it. As the majority of the {{reflist}} I surveyed in a crude search were single column, it seems reasonable to assume that it is a reasonable proxy for the preferred number of columns among those editors who have exercised a choice. -- PBS (talk) 14:41, 18 August 2017 (UTC)
It looks like {{reflist}} has been changed to explicitly specify either responsive=1 or responsive=0 on every page, but this proposal is unrelated to that. Supporting or opposing this change will not have any effect on {{reflist}} or any page that is using that template.
Given that the Article Wizard puts plain {{reflist}} in all articles, and given that plain {{reflist}} seems to have been put by bot/AWB into more than a million articles during the last five years, I am not convinced by your assertion that the use of the plain template indicates an intentional use of one column. Perhaps a better measure would be the use of columns in GAs and FAs, since those generally include long lists of references, and are generally written by editors who know how to change the default.
But even if I were convinced by your argument that not changing the template indicates intentionality, it's pretty much irrelevant, because this change will not have any effect whatsoever on the reflist template, or on any page that is using the reflist template. This change amounts to "When the responsive status is not specified (e.g., when the responsive-status-specifying reflist template is not used), then it should produce two or maybe three columns, on long lists of references, if your screen is wide enough."
This change will likely affect ≤2% of articles. Whatamidoing (WMF) (talk) 16:36, 18 August 2017 (UTC)
Great Officer of State, has quite short references compared to fully expanded references for books, institutional web pages, and journal articles used in many areas of Wikipedia. To have reflist detect such short references and use overly wide columns would completely undo the point of responsive references for much of the English Wikipedia. StarryGrandma (talk
) 21:00, 14 August 2017 (UTC)
That PBS and a few others feel that more disc. is needed, I would like to request the discussants to re-post this thread at Cent and make some fresh advertisements at related notice-boards.Otherwise, from the mini-post-closure discussion that is taking place, I fear, that it may be the same set of faces arguing/discusing broadly on the same set of themes.Esp. in an area where perceptions (rel. to readability et al) matter considerably, new faces would be welcome for sure.Winged Blades Godric 10:02, 14 August 2017 (UTC)
George Ho, a watchlist or site notice for this would be inappropriate. This a minor formatting change, not a major policy issue. TonyBallioni (talk) 13:03, 15 August 2017 (UTC)
Rescinded consideration. --George Ho (talk) 13:04, 15 August 2017 (UTC)
Comment@ StarryGrandma I agree with you, but the problem I have finding a really good example is that most of the pages I edit tend to use short citations and separate references section, and I think that columns are preferable for short citations. I tend to come across articles with 100 of large inline references only when I am running AWB scripts to fix something else, and as this is not an issue that has come up before I have not kept a record of such articles. Perhaps someone else has a few examples which can be used so that others view them and made an informed decision. -- PBS (talk) 09:24, 15 August 2017 (UTC)
Try Pythagoreanism and Birecik, both of which contain two of the "long" version of the EB1911 template. Now I look at those, with some other long citations, I'm even more against the idea of forcing a width without reference to the line lengths. There are many other pages with multiline references due to book citations etc. But I am sensitive to the problem that choosing a bigger width (42 or 48) would result in just one column anyway, on most displays that aren't fullscreen on a PC. David Brooks (talk) 16:41, 15 August 2017 (UTC)
Support - Since it's re-opened, I then add my full support. Making <references /> adopt to different screen sizes is always a plus to readers, this can be easily overridden with {{Relist|1}}(with this version) or <references responsive="0" /> for editors who prefer a single column, the latter can also be added to charinsert gadget for an even easier access. --Lam-ang (talk) 15:15, 16 August 2017 (UTC)
Support
b
} 15:53, 16 August 2017 (UTC)
Support all the supporting arguments above. — Stanning (talk) 17:24, 16 August 2017 (UTC)
Weak support as the general preference among editors, though I don't prefer the format myself, and I'm skeptical we have any real data on reader preferences. As long as we have a means of overriding it when it's not helpful, which is any time it's done with extensive footnotes rather than just short reference citations. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 23:31, 23 August 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Changing the color of DELETION TEMPLATES from from red to light green/light blue
WP:BITE, if Prod, csd templates and "notifying page creator templates" don't have red color. Red is warning/danger sign. If these Twinkle "article deletion" messages are light green, it won't scare new editors. --MarvellousSpider-Man
05:34, 2 September 2017 (UTC)
Humm well it might scare them a little less. I'm ok with a change. Legacypac (talk) 05:53, 2 September 2017 (UTC)
I admit, green and blue seem a little incongruous on a "ATTENTION THIS PAGE MAY BE DELETED" template. Deletion is deletion, irregardless of whether the template is red, blue or green. Jo-Jo Eumerus (talk, contributions) 08:46, 2 September 2017 (UTC)
They will know that their article might be deleted. Red is a color of warning, which should be used only to warn vandals, or block templates. Creating article about non-notable actors, musicians, bands, politicians is not vandalism. They should not see red colored template on their article page and talk page. MarvellousSpider-Man 09:10, 2 September 2017 (UTC)
While I appreciate the intent here, red is the appropriate color for "THIS NEEDS URGENT ATTENTION". Alsee (talk) 17:52, 2 September 2017 (UTC)
Split the difference and use yellow or orange. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 09:01, 5 September 2017 (UTC)
Yellow seems right--or orange -- red is overused on WP. Are there any problems about accessibility? DGG ( talk ) 20:27, 6 September 2017 (UTC)
No more so than Red.
People with deuteranomaly and protanomaly are collectively known as red-green colour blind and they generally have difficulty distinguishing between reds, greens, browns and oranges. They also commonly confuse different types of blue and purple hues. People with reduced blue sensitivity have difficulty identifying differences between blue and yellow, violet and red and blue and green. To these people the world appears as generally red, pink, black, white, grey and turquoise.
So to color blind people it will look the same. (probably)
Oppose. The Ambox color scheme was decided 10 years ago, and most changes since then have been minor. This is not minor at all. KMF (talk) 16:39, 16 September 2017 (UTC)
Readers of this proposal may be interested to know that "Change the colour of redlinks" appears on Wikipedia: Perennial proposals. Vorbee (talk) 19:52, 16 September 2017 (UTC)
Oppose. Solution in search of a problem. Kudpung กุดผึ้ง (talk) 21:14, 16 September 2017 (UTC)
Resolved
.jpg&action=edit&redlink=1){kind=link}
), which only allows any registered user to edit. Newly-registered users will be able to edit pages with this level.
If there is high vandalism from IPs, use logged-in protection.
If there is severe vandalism from IPs or any high vandalism from new users, use semi-protection.
However, users can request it if the vandalism came from IPs.
Please do it.
It will use the "Permission=Require registered editor access" text when a page is protected with this level..
For example: "Protected "Page" Persistent vandalism [Edit=Require registered editor access] (indefinite) [Move=Require registered editor access] (indefinite)".
2600:387:9:3:0:0:0:C5 (talk) 10:47, 28 August 2017 (UTC)