Undid revision 1142835579 by BilledMammal (talk) first off, that's arguably sigcov and secondly, I'm not sure if its the exact thing or not, but it says "Citation: Biographical Dictionary of Czech Countries p. 341" - being in a national biographical dictionary gives automatic notability under ANYBIO
Approval of Enforcement Guidelines without first approving a Code of Conduct
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
Let me start by saying there is recognition that this RFC is primarily advisory, as there has been a community ratification vote and the enforcement guidelines fall under WP:CONEXEMPT. As such I will be providing a summary of the discussion.It is clear that the strong majority of users who took part in this RFC do not support the UCoC enforcement guidelines. There were many reasons for the opposition, and a few points that were raised in many of the responses. First and foremost, there was a strong resistance to ratifying enforcement guidelines for a code of conduct that has not been vetted by the community and does not enjoy explicit consensus. This has led many to many feeling this was foisted onto the community in a top-down manner. There are also serious concerns about the vague and overbroad language, as well as the poorly defined scope of the guidelines which could allow the application of the UCoC in almost any situation. Additionally, it was brought up that there are no protections for an accused party, or any provisions for evidentiary access. The combination of these issues gave some editors reservations, having seen WP:FRAMBAN and other actions taken by the foundation against community consensus. Lastly, and the most obviously true thing stated in the RFC, the first time the enforcement guidelines are invoked in a high profile situation to sanction an editor for a violation of the UCoC it will cause "a huge pissing contest," as the UCoC does not have explicit community consensus.Other responses have said that ratification of the guidelines will likely not have that much of an effect, as en.wiki already has policies and processes in place that broadly cover the same area as the UCoC. It has also been brought up that these guidelines are WP:CONEXEMPT, and that the foundation has held multiple community ratification votes and responded to community concerns about the enforcement guidelines.It looks like this closure is probably a few weeks too late, but I hope that some of those in the foundation have read and taken on board the criticism above. ScottishFinnishRadish (talk) 16:23, 24 February 2023 (UTC)[reply]
The Wikimedia Foundation has announced that January 17 begins voting on a second attempt to obtain approval of Enforcement Guidelines for the Universal Code of Conduct. There has been no such voting on the content of the Universal Code of Conduct itself.
Does the community Endorse or Oppose approval of Enforcement Guidelines prior to, or in the absence of, any community approval of a Code of Conduct itself?
This RFC is intended to determine and communicate a consensus position. Editors may consider this during current or future Enforcement Guideline votes, and the Wikimedia Foundation may consider it when evaluating how to proceed if the second Guideline vote turns out worse than the first vote. Alsee (talk) 07:53, 14 January 2023 (UTC)[reply]
Responses: Approval of Enforcement Guidelines
Oppose. I will never approve Enforcement without approval of a code itself. The current Code of Conduct is botched, and without consensus the Code has no legitimacy. Consensus is especially NECESSARY as the Code is almost entirely worthless and ineffectual without active community support for it. Repeated attempts by the WMF to "improve" and re-vote the Enforcement Guidelines can never fix those fatal flaws. The WMF needs to stop trying to steamroll forwards, it is necessary to back up and let the community develop a new Code which actually gets consensus approval. Alsee (talk) 08:07, 14 January 2023 (UTC)[reply]
This RfC seems founded on a rather narrow understanding of "approval". The UCoC was approved by the WMF Board of Trustees, the legal custodians of this project, who we play a part in selecting. Not all decisions are subject to consensus of editors and local policy specifically recognises acts of the WMF Board as one of those exceptions. The UCoC isn't the first policy to come via this route and we can enforce it with or without guidelines, just like we enforce the Terms of Use, for example. – Joe (talk) 10:12, 13 January 2023 (UTC)[reply]
Oppose I didn't participate in this before and I haven't really looked into it all in any depth but it seems to me that if the foundation position is that they must have the code whether community approved or not, then they can impose the enforcement as well and see what occurs. I would not personally approve the enforcement guidelines since by doing so that is in fact approving the code of conduct retrospectively. Selfstudier (talk) 08:18, 14 January 2023 (UTC)[reply]
Oppose. I agree with everything Barkeep49said earlier, except the conclusion. If it was a mistake and you don't want the mistake repeated you have to speak up. Frederick Douglass expressed it like this: If there is no struggle there is no progress … Power concedes nothing without a demand. It never did and it never will. Find out just what any people will quietly submit to and you have found out the exact measure of injustice and wrong which will be imposed upon them. Following his crystal-clear logic, there is no choice but to oppose. There is another reason to oppose as well: subject the UCoC to community vetting, and it will become a more robust, less ambiguous document. It will become better, more fit for purpose. --AndreasJN46609:21, 14 January 2023 (UTC)[reply]
Oppose. It would be grossly improper for the en.Wikipedia community to in any way endorse a 'code' being imposed without consensus by an outside body. AndyTheGrump (talk) 10:02, 14 January 2023 (UTC)[reply]
Oppose. The UCoC is well intentioned and contains many sensible rules. However, a similar and more tailored set of rules is already approved and enforced by the English Wikipedia community. The UCoC provides a model which smaller communities may choose to adopt, perhaps even by default, but neither the code nor the new police force that comes with it would be helpful to enwp. The WMF will impose UCoC anyway, but they need to understand that this is a power grab without consensus which conflicts with the community's needs rather than satisfying them. Certes (talk) 10:59, 14 January 2023 (UTC)[reply]
Oppose Graeme Bartlett said it perfectly. it is inappropriate to enforce something that is not approved. Current codes and practice handles inappropriate behavior here. Adding to that, if WMF insists on pushing guidelines invented by them without community approval, its time to fire WMF and replace them with an organization that has not gone astray and revised the bylaws that allowed that to happen. North8000 (talk) 22:05, 14 January 2023 (UTC)[reply]
Alternative - drop the facade of this being something was in any way “approved” by the community, and admit that it is something imposed by the WMF. Let them figure out how to “enforce” it. Blueboar (talk) 22:38, 14 January 2023 (UTC)[reply]
I am not sure what this vote is about, but I am personally going to vote on Meta to adopt the enforcement. I opposed it last time and raised a specific concern. From what I see, the problematic part was eliminated, and I do not see any further issues with the enforcement.--Ymblanter (talk) 23:39, 14 January 2023 (UTC)[reply]
I voted against the first enforcement guidelines as I thought there were enough flaws that nothing was better than those. I will be supporting the enforcement guidelines when they come up for a vote again, as enough has changed to tip me over. One concern noted above is something we don't have to worry about. No one is going to be compelled to enforce the UCoC, in the same way no one is compelled to enforce UPOL, BLP, Harassment, or any other policy (or guideline) now. In fact this removes a requirement for admin to agree to the UCoC at risk of losing their adminship and that change is one of the reasons I can support the revision. In the end this is a non-neutrally worded advisory RfC about a Wikimedia wide advisory vote to the Board who will make an actual vote. I suspect that this RfC will attract the people who are most opposed to the UCoC and I think it is important for their voices to be heard, in particular their frustration (which I share) about the lack of community ratification of the original guidelines. I also suspect this RfC will be less likely to attract the people who are mildly supportive of the guidelines but who might vote to approve them in the final vote. So I hope everyone takes note of whatever consensus is reached here - because if a consensus is reached it's worth taking very seriously - but at the same time those participating realize the limitations of what that consensus will mean. Best, Barkeep49 (talk) 05:16, 15 January 2023 (UTC)[reply]
Support - I might be the only editor on this project who voted for the enforcement guidelines last time and is looking forward to voting for it again. Yeah, it would have been better for the UCOC to be put to a community ratification vote, but that doesn't bother me so much because that decision was made by different WMF leadership than the one that is handling (well, IMO) the enforcement roll-out (cf. it passed with like 55% or so but they didn't implement it, sort of the opposite of how the UCOC itself was handled). The other reason it doesn't bother me is because the UCOC is such a vanilla document--like, it's beyond me what objections anyone could have to those provisions that aren't nitpicky--other than that it's way longer than it needs to be. But overall, put me down for being glad that there's a UCOC and hopeful that enforcement provisions will be put in place soon. That's been long overdue on this website, which has a terrible, terrible record of self-regulating user conduct over the past two decades. It's long past time for English Wikipedia to grow up and start behaving like the rest of the world and not like the wild west... which means a UCOC, and at least some method of UCOC enforcement by impartial professionals rather than volunteer members of the community. Cf. Twitter, which was improved significantly when they started being more serious about regulating user conduct on that website, and has backslid since those regulations were recently relaxed. Cf. all other social media. Levivich (talk) 20:19, 15 January 2023 (UTC)[reply]
It's long past time for English Wikipedia to grow up and start behaving like the rest of the world and not like the wild west... which means a UCOC, and at least some method of UCOC enforcement by impartial professionals rather than volunteer members of the community. this is going to come off like snark, but I mean this sincerely: if you believe this you should vote against the UCoC Enforcement Guidelines. The Enforcement Guidelines have the Principle of subsidiarity as a major tenet which means that nearly all enforcement, including all new enforcement enabled on other projects that don't have policies and guidelines that already cover the tenets of the UCoC (unlike us), will continue to be done by volunteers (both in the sense that it's people willing to enforce the UCoC and that they are not impartial professionals). There's a path not taken where professional enforcement of the UCoC is what happens but that was not what either of the committees that drafted the UCoC Enforcement Guidelines chose. Best, Barkeep49 (talk) 02:21, 16 January 2023 (UTC)[reply]
Oh I know, but I disagree that one should vote against the UCOC Enforcement Guidelines if one believes in professional enforcement... I see UCOC and the Enforcement Guidelines as incremental steps. My prediction: both the UCOC and the Enforcement Guidelines will work, and work well. I think we will perceive no change on enwiki (for the reasons you point out: it's set up to not 'mess' with our developed self-government), and that in and of itself will be a big deal, as the enwiki community will come to realize that this is not a "power grab" or anything like that. I think, give it a few years, but it will help develop trust between enwiki and the WMF, and I hope that trust makes enwiki more comfortable with the idea of professional enforcement, which, btw, I pitched today at the idea lab in case anyone is interested (don't forget to hit that like and subscribe button). Levivich (talk) 04:32, 16 January 2023 (UTC)[reply]
My own expectation is that there will mostly be "no change" until someone decides to try for another WP:FRAMBAN. And then the UCoC will be used to counter the opposition that ultimately resulted in the WMF's attempted ban being overturned. They've got the overbroad language that can be selectively interpreted, they've got the "protect the victim" language to justify not giving any details, they've got the language allowing them to override local processes if they think local processes "refuse to enforce the UCoC" or "lack will to address issues", they've got language mandating the committee be "diverse" in a bunch of ways (but not viewpoints) that could allow for disqualifying troublesome candidates for not being "diverse" enough, etc. Anomie⚔00:05, 17 January 2023 (UTC)[reply]
In the current proposed enforcement guidelines, there is no requirement that the Universal Code of Conduct Coordinating Committee be diverse. That being said, the process for electing this committee is still to be determined by a yet-to-be formed group. isaacl (talk) 00:40, 17 January 2023 (UTC)[reply]
There is a requirement that the building committee reflect the diversity of the movement and there is a requirement that the work of the building committee be ratified by vote. So while it's true that there is no requirement for the U4C to be diverse, but I would be amazed if there isn't a requirement by the time the U4C comes into existence. To give a peek behind the scenes, the way that the U4C building committee came to be was because I proposed some diversity requirements for the U4C and the original Enforcement Guidelines drafting committee quickly realized just how much time it would take to hammer those and other fundamental U4C questions out. Best, Barkeep49 (talk) 00:45, 17 January 2023 (UTC)[reply]
Yes, for brevity I omitted discussion of the building committee. If the entire coordinating committee membership is elected, I can only imagine mandated diversity that covers certain broad characteristics, like geographical region. We'll see what the building committee comes up with. isaacl (talk) 00:56, 17 January 2023 (UTC)[reply]
It says The U4C’s membership shall be reflective of the global and diverse makeup of our global community. True, the current "such as but not limited to" list is only in connection with the building committee, but I'd be surprised if they didn't wind up with basically the same thing for the committee itself. Anomie⚔10:17, 17 January 2023 (UTC)[reply]
I don't broadly disagree with the intent of creating a UCoC, but I think that it's important to observe that the rest of the internet is (on the whole) even worse at this than Wikipedia, at least aside from smaller communities that are easier to moderate in a hands-on manner. Compared to eg. Facebook or Twitter we are vastly better at handling issues even on talk - I definitely don't agree that (even prior to their current issues) they were doing better than we are. Twitter and Facebook, for the most part, still allow, and have always allowed, things like the aggressive promotion of fringe theories or even "dogwhistle" racism, sexism, transphobia, blatant trolling and so on as long as it doesn't trip one of the few red lines they've set; similarly, aggressive harassment occurs on those platforms quite regularly as long as it doesn't cross one of their few red lines. Wikipedia isn't perfect but I feel that it has generally done better than those, and part of the reason is because of the limitations that come from trying to solve complex social issues via a set of rigid rules established from above with no input or buy-in from the community. I absolutely do not think we should be looking at Facebook or Twitter as the model for how to handle anything, ever, and I'm baffled that anyone would say otherwise - they are examples of what not to do. --Aquillion (talk) 04:24, 16 January 2023 (UTC)[reply]
allow, and have always allowed, things like the aggressive promotion of fringe theories or even "dogwhistle" racism, sexism, transphobia, blatant trolling and so on as long as it doesn't trip one of the few red lines they've set is how I'd describe Wikipedia ¯\_(ツ)_/¯ I don't really think that Twitter or Facebook (or any other social media, or reddit, or 4chan, etc.) is any better or worse than Wikipedia, especially not Wikimedia as a whole. I don't have any statistics or way of measuring it, but in my admittedly anecdotal experience, I just don't perceive a difference between the people here, the people on any other social media I've used, and the people out there in "the real world". It's all filled with racism, sexism, -phobias, etc. If anything, I think we're a little bit worse, because we let people vote other people off the website, which gives Wikipedia more of a Lord of the Flies vibe than other sites, IMO...and I say that as a participant in many such votes. It's a YMMV situation I think. Levivich (talk) 04:36, 16 January 2023 (UTC)[reply]
I suspect we're better than those other sites you name. One reason I suspect this is that none of them have published how many of its users feel safe, unlike us. Best, Barkeep49 (talk) 00:48, 17 January 2023 (UTC)[reply]
You're not the only one. One of the (many) problems of us only discussing the UCOC in negative RfCs like this one is that we tend not to hear from people who think the UCOC sounds like an okay idea and/or aren't into playing power games with the WMF. That in turn gives the impression that the UCOC is being imposed an an enwiki community that largely opposes it (seemingly taken as writ by many above), which we don't actually have any evidence of. The results of the last vote on the enforcement guidelines (57% in favour) would suggest that a majority are supportive – unless you think enwiki is out of step with the rest of the movement on this, which again we have no evidence of. – Joe (talk) 07:59, 16 January 2023 (UTC)[reply]
Oppose. I don't think that this sort of top-down approach is workable on a site as large as Wikipedia is. We function, to the extent that we do, because of our collaborative culture, and while a UCoC is something we could benefit from, it is completely unworkable to try and impose or enforce one from above without the consensus of the community. --Aquillion (talk) 04:24, 16 January 2023 (UTC)[reply]
Regardless of the provenance of the code of conduct, I agree with giving the community the opportunity to support or oppose the enforcement guidelines. Those who wish to oppose based on who approved the code of conduct are free to do so. Those who want to ensure that the enforcement guidelines defer to existing enforcement structures and existing guidelines (as per UCoC violations that happen on a single wiki: Handled by existing enforcement structures according to their existing guidelines..., from the revised enforcement guidelines) have a way to influence the process. isaacl (talk) 04:40, 16 January 2023 (UTC)[reply]
Oppose acting on them, neutral on actual voting on the EGs - I will join the gang in saying that I don't plan on ever (at least, in my role as an en-wiki admin - and I'm not planning on running for any other position in the next few years!) executing a sanction based on the UCOC here. I opposed the last set of enforcement guidelines, but am probably a weak support for the new set - although they *still* lack sufficient bits on the two aspects of right to be heard (evidentiary access and actually being heard). But while the EGs are much improved (and presumably passed by vote) the reasoning everyone else has given for the original UCOC holds true. I don't accept as a reasoning "you could always oppose the EGs if you don't like the UCOC", because that splits the reasoning with everyone who thinks it's already in place.
The base policy text is unacceptably vague at multiple aspects, unacceptably blurs necessary and desired actions, and imposes a scope that covers every action any of us will take on this planet. It also lacks a sufficiently codified amendment structure. Per Barkeep49 - this technically is a just a community position RfC, with the issues he raises. I suppose we could do another one that would prohibit any on-en-wiki UCOC-based action that doesn't have an underlying (overlying?) en-wiki PAG as well, which could reasonably be viewed as causing quite a lot of conflict for not much practical difference. Nosebagbear (talk) 14:30, 16 January 2023 (UTC)[reply]
Oppose per all the above. Just because the WMF is intent on imposing this, there is no reason we have to approve it. As has been pointed out, it's so vague anything we do could be an offence, or not, or it could be different based on how we identify, and they could call it anything they want and deal with it however they want. After all, they own the servers. It wasn't meant to be this way.--Wehwalt (talk) 16:46, 16 January 2023 (UTC)[reply]
I think Barkeep49 has put it in a much better way than I could (see above): In the end this is a non-neutrally worded advisory RfC about a Wikimedia wide advisory vote to the Board who will make an actual vote. Also I'm somewhat skeptic about how to interpret whatever result comes out of this RFC, given there is a community consultation about EG approval via vote, which I'd expect to have higher participation than this RFC. MarioGom (talk) 20:11, 16 January 2023 (UTC)[reply]
Support I don't find anything strongly objectionable in the UCOC or the Enforcement Guidelines, nor do I think they will have a significant impact on the way the English Wikipedia is run. Their influence is likely to be stronger on smaller Wikis, giving the WMF more tools to fight institutional capture by bad faith actors. The process was and is imperfect. However, the WMF is holding multiple community-wide ratification votes on these guidelines and has given many clear opportunities for us to be heard over a period of years. They have responded seriously to feedback and made changes as a result. Simply put, I think this is a net benefit for the Wikipedia movement as a whole and probably largely irrelevant to the English Wikipedia specifically. I echo what Barkeep and Levivich have said. —Ganesha811 (talk) 13:32, 18 January 2023 (UTC)[reply]
Oppose I've seen little effort by the Foundation -- & especially the employees who were driving its adoption -- to discussing why their draft of the UCoC was a good thing. Instead, they engaged in patting themselves on the back for getting the board to adopt it (whom I doubt fully understood the document or how it would be implemented) & how it would be such a good thing. Considering the hostile acts the Foundation have taken against the volunteer communities in the past, I can't support this document without serious reservations & doubts about how it will be applied. One of the features about ruling by consensus is that one has to engage in dialogue with all parties so they know their concerns are heard, & hopefully addressed; there has been little effort by the Foundation to do exactly that. -- llywrch (talk) 21:24, 18 January 2023 (UTC)[reply]
Oppose even being on the Arbitration Committee and hearing WMF talk about the early parts of the UCOC, I still don't really understand how it is particularly an improvement on the English Wikipedia's current mechanisms, and beyond that the fact that it was foisted upon the community and we're doing all these quasi-democratic showpieces around the thing treated as a fait accompli is beyond insulting, and against the pillars Wikipedia is supposed to operate on. The reality is regardless of what "votes" say about the UCOC, the first high-profile time someone tries to actually sanction someone based on it, we're going to get into a huge pissing contest the likes of the Fram debacle or similar WMF overreach showdowns. If they're so confident in their product, how about the community gets to decide? Der Wohltemperierte Fuchstalk20:06, 19 January 2023 (UTC)[reply]
Comment. I have very mixed feelings, and will make a "comment" instead of a support or oppose. It's very clear that the UCoC is going to be implemented and enforced regardless of what editors say here. The UCoC actually has been approved, just not by us. I will also say that I am actually pleased that the enforcement proposal being voted on now has removed, in response to community feedback, the implied requirement that all admins here would have to sign some sort of loyalty oath. So, on the one hand, I, like many other editors above, would like my opinion here to be heard as finding it offensive that the UCoC is being put into effect without clear community support, and that, as such, it feels wrong to ask us to approve its enforcement. But, on the other hand, I think that the proposed enforcement guidelines are as good as we are going to get, and could have been a lot worse. I'm going to say those two things, hope that both messages are heard, and accept that this RfC will be treated as advisory no matter what. And, more likely than not, en-wiki will adjudicate disputes as we choose to do, and when the day comes that we and the WMF disagree, we will have to fight that out regardless of what the WMF will have done with the input they are getting from us here. --Tryptofish (talk) 20:55, 19 January 2023 (UTC)[reply]
Oppose I think it is quite evident how little regard WMF has for the community, and pushing though the CoC without community vote and then trying to add the associated enforcement guideline only goes to continue the pattern of disregard. It is not clear to me how another layer of rules changes or improves the situation for the enwiki community. We already have plenty of policy, rules, ToS, consensus and enforcement mechanisms as it is, and the complexity of engaging with Wikipedia already drives people away. I have never seen a serious case of disregard for community standards from any established editor, and the community has plenty of ways to police itself. Melmann20:37, 20 January 2023 (UTC)[reply]
Oppose. Nonsensical to discuss how to enforce a policy without first deciding if the policy should be enforced. I plan to propose that we hold an enwiki-only securepoll vote or RfC to determine whether there is a consensus here for either the policy or the enforcement guidelines. BilledMammal (talk) 07:35, 2 February 2023 (UTC)[reply]
@Alsee you should have a single neutral RfC question followed by a signature. But right now this RfC has neither. You could after the question then have background and then responses. Best, Barkeep49 (talk) 15:57, 14 January 2023 (UTC)[reply]
I think it was poor form to simply discard the responses you received so far and start again. The question posed here is essentially the same as above. – Joe (talk) 07:32, 16 January 2023 (UTC)[reply]
I am going to copy my statement from above, given I feel it is still applicable despite the improved RfC format:
As of late, the relationship between the WMF and "the community" has improved drastically (see Wikipedia:Fundraising/2022 banners and Wikipedia:Page Curation/2023 Moderator Tools project). We had the first vote on the enforcement guidelines because we made a politely-worded request. This prompted a detailed response from the BoT, including a commitment that [b]oth the UCoC and the enforcement guidelines (after ratified), will also be open for review and voter-endorsed amendments annually. When we voted last year on the enforcement guidelines, it passed. The board responded by convening a revisions committee to address the concerns of the minority of people who opposed the guidelines, and they changed the UCoC itself based off of similar concerns. They have already shown plenty of good faith. I think an open letter requesting the promised amendment process on the UCoC itself followed by a ratification vote on the entire document is the most productive way forward. One final note: one of the recommendations from the Enforcement Guidelines Revisions Committee was that the UCoC be added to the Terms of Use. A consultation with legal about this (and some other modifications) is scheduled to begin on February 21.
I am not sure what this vote is about - Ymblanter. I'll try to clarify for anyone unsure what this is about. The issues are (1) the Code of Conduct itself has not been approved by the community, with the predictable result that (2) many people have issues with the contents of the Code of Conduct. It is impossible to "fix" either of those issues by revising the Enforcement Guidelines. The contents of the Enforcement Guidelines are irrelevant here. An "Oppose" vote here presumably indicates an intent to vote against any version of Enforcement Guidelines unless&until we have an approved Code of Conduct. That essentially says to the Foundation that it needs to back up and get an approvable and actually-approved Code first. Alsee (talk) 01:19, 15 January 2023 (UTC)[reply]
Chris_troutman I suspect your confusion/misunderstanding may be sarcasm, but in case it wasn't: The WMF took charge of producing the Code, the Board accepted it, and neither the WMF nor Board felt there was any need for community approval. I believe(?) it was pressure from various ArbComs that persuaded the WMF to graciously grant us permission to vote on the Enforcement Guidelines. They weren't originally planning on that. Praised-be the WMF, for they have so vastly improved relations and respect for the community as a partner. Oops, I think I just sarcasmed. Alsee (talk) 04:17, 15 January 2023 (UTC)[reply]
this removes a requirement for admin to agree to the UCoC at risk of losing their adminship Again with the proviso that I have not looked at this in any real depth, that something like this was included to begin with is, I think, concerning, and makes me even less disposed to approve the guidelines. If anyone thinks that not approving them is misguided because of a lack of understanding/appreciation for the situation, I would appreciate a pointer to the relevant material.Selfstudier (talk) 13:58, 15 January 2023 (UTC)[reply]
The first version of the enforcement guidelines included a section stating that all advanced rights holders should be required to affirm [that] they will acknowledge and adhere to the Universal Code of Conduct. There's nothing in there about what would happen if someone refused to affirm it. – Joe (talk) 07:40, 16 January 2023 (UTC)[reply]
Houseblaster correctly notes that the WMF and the BOT has shown genuine, highly positive steps with their ultimate actions in the fundraising banner dispute. The UCOC issues however, rather significantly predate those. When the WMF finally started discussing ratification for EGs (and they at least were quite clear in those meetings it was the cross-arbcom letter that drove those), they seemed to feel that no-one had raised the desire for ratification on the policy text. When I provided the diff of I and another asking for it during the phase 1 consultations, that particular staffer seemed to ghost me for the remaining discussions - before the WMF just decided to opt for 50%+1 as a ratification margin. No adequate reason has ever been given for why, say, the policy text couldn't undergo ratification attempt alongside the EG's. Nosebagbear (talk) 14:37, 16 January 2023 (UTC)[reply]
@Levivich: - continuing this discussion on the effectiveness of Wikipedia's community-based moderation vs. Facebook and Twitter's from-above, since it seems central. Maybe we (or the WMF) should focus on producing those statistics, since we need to understand the problem we're trying to solve. But there's definitely massive volumes of studies on the problems Facebook and (even pre-Musk) Twitter have: [1][2][3] - in comparison, multiple studies have praised Wikipedia's community-based approach - caveat that many of them focus more on content, because that's what we're famous for, but: [4][5][6] Generally speaking, sources that discuss Wikipedia, Twitter, and Facebook's handling of content moderation together describe Wikipedia as a model for getting it right. I think the reason why it feels, anecdotally, like we don't is partially because our community-based system (the "Lord of the Flies" process you mentioned) tends to be loud, especially when dealing with longstanding editors - we just had that a massive incident with Athaenara, say. But that's partially because we do these things out in the open, which IMHO is necessary to catch things that more top-down systems don't and for the moderation system to scale in a way that keeps up with our size. I also think that, as "power-users" who are deep within Wikipedia, we're more familiar with the details of the places where it does fail. My concern is that if we shift to relying more on top-down rules, we'll have less big discussions like that, yes, but that will be because a lot of things slip through the cracks - I think that top-down approaches don't actually work at the scale we operate on. The sometimes riotous discussion is actually necessary for us to consider context and nuance and handle edge-cases that eg. a list of forbidden words wouldn't capture. It's also easier for a blunt top-down system to be abused - yes, sometimes we have issues here where someone is harassed and then snaps and gets in trouble themselves, but at least our processes give us some leeway to observe and understand that context; boomerangs are not uncommon. A more blunt and rigid code of conduct won't necessarily allow for that, leading to victims getting reported and banned by the very people abusing them (not uncommon on Facebook and Twitter.) --Aquillion (talk) 20:09, 16 January 2023 (UTC)[reply]
I don't feel that Facebook and Twitter are good comparisons to Wikipedia, because whereas they are explicitly for chatter about anything, Wikipedia discussions must be related to Wikipedia editing and thus ultimately to improve Wikipedia. This provides a central guiding purpose that can be used to filter unrelated discussion. De-centralized enforcement of process can allow for more consideration of context, and that is what the code of conduct enforcement guidelines are proposing: disruption on English Wikipedia will continue to be handled by English Wikipedia's policies and enforcement procedures.
On a side note, the problem with English Wikipedia's decision-making process is that it's a mass, unmoderated conversation amongst everyone, and that doesn't scale well to more than a small number of people. As a result, we don't necessarily get full consideration of context, as a small number of people can dominate discussion and drown out others, leading to attrition in participants. With no bar to participation, it's easy for anyone to chime in without taking time to become familiar with all aspects of the situation. It's also inefficient, taking up the time of a lot of people, and inconsistent, relying on whoever shows up on a given day. Without refinement, it's not a model for social networks to follow. isaacl (talk) 21:46, 16 January 2023 (UTC)[reply]
@Aquillion: Yeah, I think as you say because I'm a "power user", I'm more familiar with inner workings, and that's why I beleive "the last great place on the internet" media narrative is more myth than reality--plus, as you mention, they (the studies, the media) focus on content dispute resolution (where I agree we are better than social media), but I'm talking exclusively about conduct dispute resolution (subject of the enforcement guidelines). I don't think there have been many (any?) studies of how well ANI has worked (or AE, or Arbcom, etc.). I freely concede that much of this is very subjective. In the recent massive RFA incident you mention, whether one sees that as a failure or success depends very much on one viewpoint: a block, and an unblock, and a reblock, but not a siteban. It's a glass-half-full-or-half-empty situation.
The thing is, I don't see UCOC and UCOC enforcement as a "top-down" situation, mostly because I see us (the community) as being on top. I fully and always will support the community being the ultimate decider of policy, even though I think we should delegate some day-to-day stuff to paid professionals since we have the money. The enforcement guidleines are coming from the community: multiple votes, plus the drafting committee has community members on it, and the trustees who ultimately approve it are elected by the community. It's our document, written by our people, approved by our people. The UCOC was essentially the same except for the community ratification part. To me, neither document are "top-down" (imposed on us by the WMF).
While I believe professional first-line-of-enforcement would reduce abusive reporting, the UCOC/enforcement guidelines don't do that, and they leave first-line-of-enforcement to enwiki, so in that sense, it's not changing, which means I don't believe that it'll have an effect on abusive reporting. However, I think the possibility for appeal to the U4C (or whatever it's called) would reduce abusive reporting by allowing another level of review, one of the things I like about the enforcement guidelines. Levivich (talk) 22:14, 16 January 2023 (UTC)[reply]
After 3 days this RfC has, at the time I write this, attracted 22 participants who've given a topline comment in "responses". After less than 1 day of voting, the official ratification has had 151 participants whose homewiki is English Wikipedia. It appears that there will be a consensus of some kind reached here and it should be respected for what it is. But what it is not is a consensus of people interested in the UCoC on English Wikipedia. Best, Barkeep49 (talk) 15:50, 17 January 2023 (UTC)[reply]
I agree completely. I still tend to think this RfC was created to serve as a fait accompli, and struggle to see how this could be interpreted by WMF in any way other than "micro-consensus". 🌈WaltCip-(talk)13:33, 19 January 2023 (UTC)[reply]
Quick question: Isn't there already a mechanism for users to vote on the enforcement guidelines? Why this second vote? Surely, anyone can go vote in the SecurePoll vote and have their voice heard that way. Why are we having a second vote here? --Jayron3218:43, 19 January 2023 (UTC)[reply]
The results of the vote across all projects has been posted on meta. 76% of editors voted in favor with 3097 editors participating in this second vote. In terms of enwiki participation While 1007 voters had their homewiki registration set to English Wikipedia, only 803 voters had their most edits there. Best, Barkeep49 (talk) 19:32, 13 February 2023 (UTC)[reply]
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.
RFC - restore "talk" from drop down
Ok, so for me, there's a lot not to like about the new layout.
But someone else can start that eventual RfC : )
I just want to focus on one very specific thing: the talk link being moved to a drop down.
Hiding the talk link is a very very bad idea.
We operate on the consensus model here.
Hiding the talk link just reinforces that edit-warring is the way to go.
And no, I really don't care what some off-site discussion was - so I don't need to hear an WMF employee breezily tell me that a talk page link was determined to not be important on Wikipedia. I'm happy to engage in discussion, but don't blow us off by referring elsewhere as if this project does not matter please. (As an aside, and this goes far beyond this simple RfC - But just thought I'd mention that while I respect the WMF in general - I think it's very important - but I'm really not happy about how things seem to be being pushed through, with fewer and fewer discussions being allowed to be "open" for anyone to participate.)
Anyway, if we weigh importance, I think it's easy to agree that the talk link is more important than the watchlist link. So if space really is the issue argued, then swap them. Or maybe combine "alerts" and "notices" to save space. Or whatever other ideas people may have.
I think they mean the link to their own user talk page, which is indeed now in a dropdown (unless you have new talk page messages, in which case it's more prominent like before). Matma Rextalk21:13, 19 January 2023 (UTC)[reply]
anything - anything that reduces the visibility and/or ease of accessing the talk page is a bad idea. We want people to discuss. We want people to respond to talk page concerns about their editing. Not to get frustrated because they can't find the link, and thus not engage. There are innumerable reasons that hiding the talk page link is really bad. Even just from the optics of suggesting that talk pages are uninportant. I understand that this may seem an innocuous change for some, but when I consider years - decades - worth of dispute resolution, among many other things, this just really really seems an incredibly bad idea.- jc3721:46, 19 January 2023 (UTC)[reply]
@Jc37, so your problem is that people might get talk page message, dismiss that notification, and then not know how to find their user talk page and respond? — Qwerfjkltalk21:59, 19 January 2023 (UTC)[reply]
One, of several. Anything we can do to get people using talk pages, the better. We've repeatedly seen that initial talk page usage helps bridge the learning curve gap for people to turn into regular editors. It's part of why we encourage the community aspect of Wikipedia. Learning how to thread discussions on a talk page can lead to being confortable to add to lists, to add references, and just merely feeling comfortable to edit a paragraph on a page. These are called "gateways" for a reason. - jc3722:14, 19 January 2023 (UTC)[reply]
Most newcomers are using the Reply button, so they don't have to count colons any longer. The learning curve is essentially flat.
The Editing team, as a result of mw:Talk pages consultation 2019, considered ways to make talk pages more visible, but it's tricky, and I don't think that they got very far. You don't want the "Talk" tab at the top to be more prominent than the article tab. You also don't want it to be more prominent than the Edit button. So at best, it's in third place. In terms of your own User_talk: page specifically, I think that Growth's Newcomer homepage work has made some difference there. Whatamidoing (WMF) (talk) 23:37, 19 January 2023 (UTC)[reply]
I appreciate all that. I do. But all I need do is look at the default signature for editors to see that Wikipedia sees the value of a talk page link. (And yes, I'm aware that mine isn't there - user pages are important too : )
But anyway, if it's in third place, then watchlists decidedly aren't. And while I may have done some looking around to find out the difference between notices and alerts, I doubt the average person would know, or care.
tried and failed doesn't = push through anyway. I understand the idea of the perfect is the enemy of the good - Wikipedia is a work in progress after all. but something like this is different, we're being asked to swallow the watermelon whole, with no changebacks allwed due to fait accompli." what's done is done" and all that.
I'm not merely complaining to the air, I've actually proposed some suggestions and welcome others. (not adding "support/oppose" sections was intentional). So if you have any ideas for a way forward, I'd be happy to hear them. - jc3723:54, 19 January 2023 (UTC)[reply]
I don't think that I want to get in the middle of whether the talk page or the watchlist is the more important thing to show. I imagine that most editors want both.
But now I'm not sure that we're talking about the same thing. At the top of an article, volunteer-me sees these options:
Article – Talk – Read – Edit – Edit source – View history – Watchlist star – More menu – Twinkle menu
I think that in the end, anything that improves or makes more efficient the talk page in a non-obnoxious manner should be implemented. In particular, I believe that the talk page is one of the biggest catalysts for recruiting new editors, and if they see a place where not only their voice matters but they can participate in a discussion with consequences they can see, I think we've done a good job at recruiting a new editor. Put another way, to know that the change you helped to support 10 years ago can still be found on the website is, for lack of a better term, a magical feeling. InvadingInvader (userpage, talk) 21:46, 31 January 2023 (UTC)[reply]
This RFC is a bit misleading in the title, "Talk" in general is not in any menu, this is only about the link to someone's own usertalk page. This is also something that is skin-wide, so would really need to be changed upstream. I don't see this as severely breaking the consensus building model, as most consensus building discussions don't take place on personal user talks, but on article talks or project pages, both of which are already accessible. — xaosfluxTalk12:32, 21 January 2023 (UTC)[reply]
The title is: "restore "talk" from drop down" - that is exactly what this is about. the talk link in the drop down. Nothing there misleading at all. - jc3708:32, 22 January 2023 (UTC)[reply]
Support: There is a huge gap between search box and "CX Zoom" at the top, which could've been utilised in better ways. Talk pages should absolutely be visible on up there in order to assist new editors find a link to there. —CX Zoom[he/him](let's talk • {C•X})16:17, 21 January 2023 (UTC)[reply]
This is exactly what I was saying about the "log in" button for unregistered users. Whether logged in or not, the WMF seems intent on wasting that space and forcing us to live with it. —pythoncoder (talk | contribs) 17:56, 1 February 2023 (UTC)[reply]
As someone who has been using Timeless, I can say that having the user links in a dropdown does not cause me any issue today, and it's second nature to click these links through a dropdown. (I'll move to Vector22 on desktop probably Soon, just have to get off my preferences butt, and mobile Whenever it actually supports mobile.) Oppose accordingly. "Supports" and "opposes" aren't really valuable here. Discussing why you want a link in X or Y position might be, but is still squarely in the realm of design, especially (as I'm sure they will) as they start turning to making the skin friendly(er) for mobile. It might be valuable to decide on what the most valuable links are in the dropdown, rather than having RFCs for this that and the other thing, and see if there can't be some thought put into displaying certain links at certain widths (perhaps as icons, though I know the group that hates the dropdown is probably a concentric set with the group that hates icons). In general though, this dropdown is provided for the set of people who already do have access to scripts, so they always have a workaround to what is/isn't displayed. Izno (talk) 21:08, 4 February 2023 (UTC)[reply]
Make "Always give me the visual editor if possible" default for new editors
Yesterday I helped someone to start editing in Wikipedia. Creating an account is a breeze, but when he started editing he is presented with the text editor, instead of the Visual Editor. Text Editor is good and have its uses, but for newer editor it is better to present them with Visual Editor, as it is created to be user friendly and really show changes that you intended. Editing through Text Editor for newer editor may be off putting, as many may just want to do minor changes (maybe add a single line in a table, change the number of things, etc.) and "learning" the wiki markup may be too much for them.
I understand that changing it in Preferences is trivial for many of us, but for many new editors this can be quite hard. This can be changed easily by making "Always give me the visual editor if possible" default. ✠ SunDawn ✠(contact)03:03, 31 January 2023 (UTC)[reply]
Strong support, as in "this could be one of the most important changes Wikipedia makes" support. To a new user, the wikitext editor is terrifying and bloated. To an experienced user, it can still be bloated. I'm fairly competent with wikitext, but I still use the visual editor for most purposes simply because the wikitext editor is too much to wade through unless you're making a really technical edit. I genuinely think Wikipedia would have a much larger user base contributing if the visual editor was the default. Thebiguglyalien (talk) 03:56, 31 January 2023 (UTC)[reply]
For an IP editor, the default is the wikitext editor, but it gives a pop up asking if you want to switch to the visual editor, which I imagine is meaningless to most users. I suppose it's not quite the same thing as a new account (and SunDawn might want to look into it to see where the discrepancy is), but visual editor definitely needs to be more accessible. Thebiguglyalien (talk) 05:20, 31 January 2023 (UTC)[reply]
Strong oppose. The WMF has been persistently and attempting to force this, despite the fact that they have data showing that defaulting into VisualEditor is harmful. There of course are some people who prefer VE, but the objective data shows the overal impact is negative. The WMF has been resistant to collecting good data on this, but I can report what we do have. If you examine the graph at the right, you'll find that the Desktop Wikitext Editor has approximately DOUBLE the retention rate as Desktop Visual Editor, and that Mobile Wikitext also has about DOUBLE the retention rate as Mobile Visual Editor. That is a pretty staggering difference. From the published graph we cannot tell whether Visual Editor is causing half of editors to quit editing entirely, or whether users given VE-by-default merely abandon VE to use the Wikitext editor instead, or more likely some mix of both. Regardless, the data is extremely damning.
Nearly 4 years ago they started work on a mobile-default test. They still have not released any results, however if you dig through the comments of various related tasks it is clear that the results were a disaster for VE. A VE-default on mobile was clearly driving away a significant percentage of edits, and possibly driving away editors. They have been working off-and-on repeatedly shifting the goalposts on that project, trying to get better results. Nearly 4 years, and they still haven't released actual data.
Important final note: Never believe any claimed "Edit Completion Rate" data. The raw data for VE is so bad that the WMF concocted this specific term and defined it in such a way as to inflate the apparent success of VE. The "Edit Completion Rate" is defined such that every Wikitext-activation that does not result in a saved edit counts as a "failed edit", but a substantial portion of equivalent VE "failed edits" are simply discarded from the dataset and ignored. That artificially inflates the claimed "VE-success" percentage.
When the VE project was first conceived the WMF internally hyped it as so insanely-awesome that pur biggest problem would be handling the overwhelming flood of new users. The WMF diverted an absolutely excessive percentage of all development time&dollars on this agenda (VE itself, Flow, replacing the translation-editor, attempting to eliminate our wikitext editor in favor of a wikitext mode inside VE, ongoing work to replace our wikitext engine, and various other work). People's paycheck was literally dependent on producing positive results. It resulted in an almost cult-like level of confirmation bias, internally cheerleading and wildly hyping anything that could remotely be interpreted as positive for VE while all unfavorable information and data vanishes down the Memory hole. Nearly 4 years researching VE-on-mobile and we still don't have any published results. I have asked the WMF to preform equivalent research getting solid data on the effect of a VE-default on desktop, but no-go. The retention graph I posted is the best we've got, and that's ambiguous whether VE actively drives new users away or whether it "merely" drives users to flee to Wikitext instead. Alsee (talk) 12:34, 31 January 2023 (UTC) (Some vote timestamps are out of order due to auto-resolved edit conflict.)[reply]
I don't agree with your assessment of the data shown in the graph. The caption reads, emphasis added: This includes all logged-in users who made an edit at any time, on any wiki, between October 2017 and March 2018, regardless of the number of edits made before the study started. This graph does not show overall retention rates for new accounts. Edits in four editing environments were measured: the 2010 WikiEditor, VisualEditor's visual mode, the MobileFrontEnd wikitext editor, and the MobileFrontEnd visual editor. It excludes all edits using VisualEditor's 2017 wikitext mode, [...] All manual "Undo" actions are counted as "using" the 2010 WikiEditor. Users who used multiple editing environments are counted separately for each editing environment. Therefore, each user can appear up to four times in this graph. If a primary user of VisualEditor uses the undo button frequently, then they are counted as a "retained" user of the 2010 WikiEditor. 0xDeadbeef→∞ (talk to me) 12:44, 31 January 2023 (UTC)[reply]
I agree that the available data isn't exactly the data we need. I said it's the best available data, and that it's pretty damning. The result was disastrous when they tried collecting data for VE-on-mobile. How about we agree that we shouldn't be making such a critical change like this unless-and-until we actually do collect data on what effect changing the desktop default has? I have requested the WMF collect this data, and they declined. I'm all for a formal community request that the WMF do a proper test on this. Alsee (talk) 12:55, 31 January 2023 (UTC)[reply]
"How about we agree that we shouldn't be making such a critical change like this unless-and-until we actually do collect data" If the situation we're complaining about wasn't justified with data, why should a change to it require that justification? Is the current situation (that in effect, new editors get locked into VE or wikitext almost at random) even the result of a consensus? MartinPoulter (talk) 13:13, 31 January 2023 (UTC)[reply]
I just realized - this isn't even a proposal to change the default editor. This is vastly worse. This is actually a proposal to move away from the "remember my last editor". People who actively choose to use the Wikitext editor would get screwed waiting for VE-to-load and then switch to wikitext on EVERY edit, unless/until the locate preference item to fix this. I likely would have quit editing before I discovered there was a way to fix it. Alsee (talk) 13:07, 31 January 2023 (UTC)[reply]
The problem is not for prominent editors like you or me - but for newer editors. Experienced editors have the knowledge and the time to go to their own Preferences (which took less than a minute) but newer editor, in my opinion, will immediately be confused by the text editor and stopped contributing. They don't know that Wikipedia have a very user-friendly UI at VisualEditor. They will think that the only way to edit is through this confusing text editor. ✠ SunDawn ✠(contact)15:45, 31 January 2023 (UTC)[reply]
Support. I'm not sure why, but during a recent edit-a-thon at least one new logged-in editor was unable to use VisualEditor, and it us 5 minutes in Preferences to show both editing tabs. VE is easier for beginners. Femke (alt) (talk) 12:18, 31 January 2023 (UTC)[reply]
Support Despite some long-term attempts to continue forcing wikitext on new editors, it is extremely clear that VE is the more welcoming and easy to understand editing environment. I use it more often than wikitext when editing articles, and have not once in recent years considered wikitext an improvement when trying to explain how to edit to a new editor. Sam Walton (talk) 12:47, 31 January 2023 (UTC)[reply]
Strong Support I also have been recently running training events for new editors and am having the same problem that it is very easy for them to get locked into the wikitext editor without realising that the visual editor is an option. Fixing that involves taking them to their preferences and is a speed-bump on the whole training process. That's with in-person training; it's exponentially harder to fix this when training remotely. It shouldn't be so hard for new users to access something which has been created to make the experience easier for them. MartinPoulter (talk) 13:04, 31 January 2023 (UTC)[reply]
Whoa. Why not give them VA as the editor on their first edit, but "Remember my last editor" as the default? Why force them back to VE even after they have switched to edit with wikitext? If they found the switch once, they will find it in the opposite direction as well if and when they want it. Fram (talk) 13:34, 31 January 2023 (UTC)[reply]
Strong oppose: Alsee has articulated this much better than I could've, so there's that, but I'll add extra. Ever wondered why we teach young kids do addition/subtraction when we all have calculators today (smartphone ones included)? The problem with Visual editor is that it is not univerally compatible to all pages, try editing the tables at United States congressional delegations from New York, for example. To edit them, you need advanced knowledge of wikitext. And to gain that advanced knowledge, you need to gain basic knowledge first, which is gained by editing normal prose. And that isn't hard. My first Wikipedia edit was made when I was in 1st grade (≈6 year old) as an IP. I could understand the wikitext logic and implement it to write prose and construct wikilinks. Is the next generation going to be dumber? No one is taught wikitext syntax in schools or colleges, people learnt it as they edited Wikipedia and that has kept the site running smoothly for about two decades. When we default to VE, and people may start using it for basic editing, they fail to acquaint themselves with the wikitext logic, which will hurt them make complicated edits where visual editor fails. Even today, most complicated templates/modules are maintained by a few old guards who familiarised themselves with wikitext/lua, a level of familiarisation which the newer generation of editors has probably not achieved. No one here will be here forever, and newer editors should be encouraged to use wikitext, rather than be served with VE on a silver platter. I know this is a controversial opinion of mine and will probable lose at the end, but I genuinely consider it to be detrimental to the future of the project. —CX Zoom[he/him](let's talk • {C•X})13:48, 31 January 2023 (UTC)[reply]
The way I see it, if editors didn't understand wikitext, that is still fine by me - as long as they are able to edit constructively. In my case, my friend just want to add a single information. Forcing him to "learn" wikitext took time, as he will have to read about how to cite properly in wikitext, find the "location" he wanted to edit in the middle of the jumbled things he didn't understand, and so on. While if he got VE, he could just see it, use the cite button, let Wikipedia handle the citing, and he is finished. There are many other scenario. Someone stumbling into a typo on an article can fix it easily if he use VE, while if he see the complexity of text editor, he may be afraid that he broke something then he did nothing. In short, for most editors, I didn't think the knowledge of text editor is necessary. If they are interesting in doing more for Wikipedia, they will learn that text editor offered more, and learn. But if they just want to fix small mistakes and add small bits of information, that should be fine as well. ✠ SunDawn ✠(contact)15:54, 31 January 2023 (UTC)[reply]
Conditional Oppose if this is going to end up breaking the "remember my last editor" option - users should get a consistent experience. — xaosfluxTalk14:50, 31 January 2023 (UTC)[reply]
Let's say we use Fram's input - keep the "remember last editor" while change the default editor for newer editor to VE, would you reconsider your position? My objective is not break the current "remember last editor", but to make VE default for newer editor. ✠ SunDawn ✠(contact)15:59, 31 January 2023 (UTC)[reply]
@SunDawn: I marked that as conditional. I haven't created a brand-new account just to test this, but if I recall correctly the the current default is "Ask me what I want to use" with a big pop up box, isn't it? — xaosfluxTalk16:55, 31 January 2023 (UTC)[reply]
Good question. Does anyone know the current default? I assumed it was wikitext. If it's a pop-up box then I'll change to oppose because a choice is better for editors who can handle wikitext and raises awareness of the "real" editor for newbies. Certes (talk) 17:24, 31 January 2023 (UTC)[reply]
The current default for IPs appears to be the wikitext editor covered by a large "Welcome to Wikipedia" banner which has a "Switch to the visual editor" button and a "Start editing" button. If this is also the case for new editors, then Wikipedia:VisualEditor is wrong and this list is misleading or bugged. CMD (talk) 17:58, 31 January 2023 (UTC)[reply]
That's what I recall seeing when making my first logged-in edit on other wikis. If it's also true for enwp, perhaps all we need do is reword the buttons to something more equal like "Edit using Visual Editor" and "Edit as wikitext". One of the buttons is highlighted by default; we may want that to be VE rather than Wikitext. Certes (talk) 18:35, 31 January 2023 (UTC)[reply]
The way I recall it (when assisting someone new editing) is that they are immediately represented by text editor. The "edit" beside the heading is "edit source", and he is immediately taken to to the text editor. I didn't recall him given the option between VE and text editor. Of course, the sure way to know is to create another account to test it by ourselves. ✠ SunDawn ✠(contact)04:49, 1 February 2023 (UTC)[reply]
Conditional support, only if editors are prominently offered a simple and persistent way to opt out of VE. Certes (talk) 16:19, 31 January 2023 (UTC) It's complicated: see my comment above. Certes (talk) 18:38, 31 January 2023 (UTC)[reply]
Comment By adding an obscuring layer which is obscure itself, I suspect that visual editor does more harm than good for about 90% of editors. But it might be a good default for the 10% which is those who are just starting.North8000 (talk) 17:58, 31 January 2023 (UTC)[reply]
Strong oppose. Even on fast machines, the visual editor has a very perceptible lag. If you want to encourage people to continue editing, that is going to be a negative. --Trovatore (talk) 18:01, 31 January 2023 (UTC)[reply]
@Trovatore Realtime preview is a niche feature that new editors probably won't use, and it has to be laggy by design, as I understand it. Rendering wikitext into a preview takes time so it can't happen instantly. There needs to be some delay between the preview updates. VE itself, in terms of actually editing articles, is almost completely lag-free for me. Sam Walton (talk) 18:32, 31 January 2023 (UTC)[reply]
Generally support - But this thread is already a bit confusing. It would help to revise the top part to state clearly what the current situation is and what specifically would change. VE is already the default for new users AFAIK, as it should be. As I understand it, this would address a specific issue: people switching to the wikicode editor and not understanding how to get back. If my understanding is correct, I definitely support it. Alternatively, we could replace the unclear toggle button that nobody ever thinks to click with a bright line that says "GET ME BACK TO VISUAL EDITING MODE" unless you disable that in prefs. My engagement with new users has largely been through edit-a-thons and university classes. When I started with those activities, wikicode was still the standard. VE existed, but wasn't very good yet, and I had everyone working in wikicode. It was fine, and I still use wikicode most of the time. At some point some years back, though, VE got good. Using VE during events/classes was -- and I don't like using this term -- a game-changer. It presented a learning curve that took time to get over, and people used to just run away from editing and/or never really got comfortable. Using VE means newbies can get right into editing and spent their learning time focused on things like wikipolicy, citations, style, etc. rather than syntax. Sure, we still talk about wikicode for talk pages, but with the reply tool, even that's less needed. In short, moving newbies away from wikicode has been an incredible boon for new user engagement in my experience, and now one of the most frequent questions I get is "I think I did something wrong; how do I get back to what we used before" when people accidentally find themselves in the wikicode editor. — Rhododendritestalk \\ 18:02, 31 January 2023 (UTC)[reply]
Last I checked, when an IP makes their first edit, they are taken to the source editor and then get a dialog box asking if they want to switch to the visual editor. Has this changed? —pythoncoder (talk | contribs) 18:00, 1 February 2023 (UTC)[reply]
. Comment I would support a far clearer way of switching between the two. When I first started I found VE couldn't do what I was try to do, switch to wikicode and never looked back. However a couple of times I mistakenly switched back to VE, and had to spend 10 minutes trying to work out how to switch back. Hiding the option behind a very unclear toggle is bad UI design. Having a large "back to VE" would be a bad idea, as any IP editor using wikicode wouldn't be able to get rid of it using preferences. -- LCU ActivelyDisinterested∆transmissions∆ °co-ords° 18:36, 31 January 2023 (UTC)[reply]
Support making VisualEditor default. Now that it works well and reliably I tend to use it over source editing unless I'm adding an infobox template or something like that, an activity that new editors are unlikely to be doing. VisualEditor is much more accessible and is capable of performing most edits nowadays. There's quite a few tables across wikipedia that should be altered to make them easier to edit with VisualEditor.Garuda3 (talk) 22:27, 31 January 2023 (UTC)[reply]
Oppose When you start users on the VE as the default, they will basically never learn to edit the source in proper wikitext. I'd rather have users who come in and get familiar with wikimarkup from the get-go, and then once they get some experience, they can later decide to activate the VE. I'd rather not create a breed of new editors who don't know how to manually add a template or an infobox or troubleshoot a badly formatted table, or whatever. There's value in learning to work in the markup, and if we start people on the VE, we basically create an artificial barrier to advancement in Wikipedia to true competence, which is likely to be as, if not more, frustrating than learning to write in wikimarkup from the start. --Jayron3216:31, 2 February 2023 (UTC)[reply]
Oppose until VE is significantly improved. You almost need to have a better understanding of wikitext for using VE than for SE if you want to avoid breaking links and removing semantic templates. Syntax highlighting should definitely be made default though, as without it reference and template bloat can get in the way of the content of the article. – small jarstc10:47, 5 February 2023 (UTC)[reply]
Support. I don't believe that markup is inherently off-putting to 'ordinary users'. It wasn't ten years ago when BBCode was everywhere and it isn't now when Markdown is everywhere. But wikitext was never the cleanest markup language to begin with and now that the average article starts with a wall of templates and long embedded references, it clearly is off-putting. This isn't 2013: VisualEditor works fine, offers a kind of distraction-free writing interface that lets you focus on prose, makes it easier to add and format references, and if they find its limits new users can easily switch to source editing. It would be nice to have some hard (and up to date) data on how the switch might impact editor retention before making a permanent change, though. – Joe (talk) 16:38, 5 February 2023 (UTC)[reply]
I sorta see your point, and I remember ten years ago BBCode was used on forums etc, but even those have some technical barrier. On sites used by 'very ordinary users' like Facebook, I think there were still WYSIWYG editors. I use Markdown on sites like GitHub but on 'normal sites' not geared at technically proficient people I don't recall using Markdown or any other language, it's usually either plaintext editors with no syntax support, or WYSIWYG editors. (with the caveat that my memory might be selectively omitting normal sites using BBCode/markdown!) ProcrastinatingReader (talk) 12:49, 6 February 2023 (UTC)[reply]
on 'normal sites' not geared at technically proficient people I don't recall using Markdown or any other language – I don't share this experience. I thought the asterisks and underscores used in youtube comments where pretty well known. Discord also has rich text markup and escape codes. They even have little codes for creating emojis in comments on Scratch, a website used mainly by children. [1]. None of this is quite as complex as wikitext, but I don’t think that very ordinary users are yet so dependent on WYSIWYG that the difference is going to be deterring. small jarstc18:58, 6 February 2023 (UTC)[reply]
I suppose asterisks and underscores are well known, yes. I guess they're in WhatsApp also. Though IME most people do not use them, I think because they aren't aware how they work. I think Discord does target itself at a relatively technical audience, certainly more-so than Wikipedia. ProcrastinatingReader (talk) 11:57, 8 February 2023 (UTC)[reply]
Strong support - I didn't even realise VE isn't the default for unregistered users. It should be IMO; in 2023 the average user does not want to write wikitext/raw syntax, is not used to doing so (think the avg site a normal person uses), and even techy users who don't use WYSISYG editors tend to use markup languages that are much simpler than wikitext (e.g. Markdown). As for preferences, it'd be ideal if the choice persisted, and maybe that will happen (n.b. the persisting of fixed/full width opening the door on that), but even without that I think it's better to have VE as the default. Even I use VE to write articles, and not the wikitext editors, and I'd consider myself more technically proficient and used to wikitext than the average person. ProcrastinatingReader (talk) 12:49, 6 February 2023 (UTC)[reply]
Can we make showing both editing tabs the default for new editors instead? I don't see any reason that this would harm people, and it would give a nice easy button to choose which editing mode you want to use. — Red-tailed hawk(nest)00:08, 9 February 2023 (UTC)[reply]
Going back to two edit tabs, one for each editor, is a very reasonable solution. Note that the WMF imposed the change to a single edit tab without consensus or consulting the community. Here's the MWF's announcement. They unilaterally declared that they are going to drop from two edit links to just one. Alsee (talk) 12:05, 10 February 2023 (UTC)[reply]
@Red-tailed hawk @SunDawn I can explain the mess of wikis with random edit tab configurations. I'll try to keep this shortish. The WMF manager who came up with the single edit tab idea has been pushing an agenda to force everyone into VE. I spotted the single-tab project when he first started work on it. He assured me he wouldn't try to impose a VE-default without asking the community first. He then deployed an effectively stealth VE default - not visible to the existing community. He failed to respond to messages and Notifications in multiple places - for weeks. I had to escalate the issue to the Executive Director, she had to summoned him to answer to me. He claimed it was a "bug" and, to the Executive-director's-face, he assured us he'd fix it. He again disappeared, silently didn't fix it, when pressed later he admitted the "bug" was his plan all along, and declared he would not fix it. ANI ruled it's not uncivil to say a manager "lies" when the charge is supported by evidence. Three wikis rebelled with EnWiki and another Wiki writing hacks to the sitewide javascript to override his code. We came one step short of a second superprotect incident. Instead he relented and those three wikis were changed. He then abandoned the project part way through his attempted global-deployment, leaving the global wikis with randomly differing configurations. Alsee (talk) 05:36, 16 February 2023 (UTC)[reply]
So, if there was never consensus to implement it here, and the code exists for other wikis why not just open an RfC to ask the WMF to add the second tab here? This seems like a relatively simple configuration to enable, and I don't see the phab task getting rejected if an RfC were to close in favor of this—especially at this point in time. — Red-tailed hawk(nest)05:40, 16 February 2023 (UTC)[reply]
Strong support - VisualEditor is much much easier to use for casual editing than doing it via wikitext (atleast on Wikipedia, on other projects it is a different discourse). Learning an arcane markup language should not be one of the side-quests to writing an encylopedia. -- Sohom Datta (talk) 00:30, 14 February 2023 (UTC)[reply]
Strong support with a but. Look, I run educational programs and each year I introduce dozens of newbies (students) to en wiki. And of course they ignore the choice prompt and half of them gets old code and they are unhappy/confused, and I have to manually help them with adjusting their preferences. This should've been the default years ago. However, I think that an even better choice is to give them "both edit tabs", so they can experiment with two modes. That's actually is what I try to get my students to have, interface wise. B/c let's face it, VE is good but editing anything template related is still a mess. (Tables suck in either version). --Piotr Konieczny aka Prokonsul Piotrus| reply here04:15, 16 February 2023 (UTC)[reply]
Support There's a lot of bad history with the visual editor, but it has made a lot of strides and is definitely a lot friendlier for a non-technical editor. Galobtter (pingó mió) 08:00, 16 February 2023 (UTC)[reply]
Support but still with the change option, oppose pure change - currently we appear to have wikitext as the default, with a big overlay asking which option people would like. I'd change that to Visual with the overlay. Options beat pure Visual, but this covers people who click out, not knowing which to go for. I don't see any reason this would involve it forgetting last selection, which obviously is more key, but the current system doesn't have any issues with it. Nosebagbear (talk) 23:10, 1 March 2023 (UTC)[reply]
Give both edit tabs as described in my comments above. This will allow users to decide which editing style that they would like to use, while harming nobody. It's the best of both worlds, and it seems more sensible than trying to address this issue by tweaking the default option. — Red-tailed hawk(nest)19:43, 3 March 2023 (UTC)[reply]
Support as proposer. The year articles are very long (e.g. 2022 is 206k, 2021 is 227k, 2020 is 360k, 2019 is 316k, 2018 is a comparatively lean 153k). The Births and Deaths sections take up half the pages or more by my eye. Moving them to sub-pages (e.g. Deaths in 2022) is the fastest and easiest way to cut year articles down by about half and finally comply with WP:SIZE, while still having a place to put the content. Note we already have List of deaths by year, Deaths in December 2022 and so forth. (If a death itself was a significant event and not just "old person dies", e.g., an assassination of a world leader, it would still be listed in the "events" sections.) Levivich (talk) 18:27, 1 February 2023 (UTC)[reply]
I support splitting them out from the main year articles. I don't really have a strong opinion about how the sub-articles are organized (e.g. by year or month). Levivich (talk) 18:39, 1 February 2023 (UTC)[reply]
Monthly articles are for all deaths of internationally notable people. Those on main year articles are only for those who have substantial international notability. Jim Michael 2 (talk) 18:42, 1 February 2023 (UTC)[reply]
International notability as it has been practiced on year articles is already being questioned as a criteria, as it has been both too arbitrary in what it means and is the subject for all these content disputes. InvadingInvader (userpage, talk) 07:17, 6 February 2023 (UTC)[reply]
Correct. As a frequent contributor to US Years articles, this has been hugely beneficial as we have had more time to add in events without having to be worried about article size due to these deaths. InvadingInvader (userpage, talk) 01:27, 6 February 2023 (UTC)[reply]
Support. This has been my position for a while. Beyond size considerations, most births and deaths are not notable in their own right. Births and deaths are a WP:MINORASPECT of each given year, and they do not warrant such massive coverage in the year's article. The inclusion of births and deaths is a relic of before Wikipedia was standardized, and the year articles are late to catch up. Thebiguglyalien (talk) 18:50, 1 February 2023 (UTC)[reply]
Oppose we shouldn't be having discussions about major changes to layout & inclusion criteria of main year articles when their best editor is absent. Jim Michael 2 (talk) 19:20, 1 February 2023 (UTC)[reply]
Deb's input is valuable and I hope we have a chance to hear it, and I hope she's having fun while on wikibreak, but I can't imagine Deb ever suggesting we not have an RFC while she is on a wikibreak that's lasted three weeks and will continue for an unknown duration. Levivich (talk) 19:42, 1 February 2023 (UTC)[reply]
Of course I would not suggest that :-) I was away for 4 weeks but for obvious reasons I didn't give out that information on my user page. I am fairly neutral on this proposal, but I have to say I am not sure it will have much effect. Year articles should undoubtedly be shorter. I also don't object in principle to summaries. Unfortunately I can't see anyone willing to put in the work to ensure that the global picture is what we get, as opposed to duplication of what's in the article on the United States. I see some people (below) already suggesting that the articles should include everything that is "newsworthy", which may just mean relocating the problem. Deb (talk) 17:52, 7 February 2023 (UTC)[reply]
Welcome back! We've written several novels about year articles in your absence, apologies for all the reading to catch up on :-) Levivich (talk) 18:11, 7 February 2023 (UTC)[reply]
If their birth or death is newsworthy, it should be included in the article. Otherwise, we're picking and choosing who gets to qualify, which is what we've already done by having articles on them in the first place. I propose removing all lists of births and deaths and relying on categories. Otherwise, what even are categories for? --Golbez (talk) 21:14, 1 February 2023 (UTC)[reply]
Dying in office. New heir apparent born. First [x] born in [y]. Last person killed by [z]. That kind of thing. And you say there's a higher bar, I say there should be no bar. They should only be included in the year article if they were somehow significant to that year, right? So either their birth is notable, their death is notable, or their actions in life are notable. Everything else, that's (at risk of repeating myself) what we have categories for. --Golbez (talk) 22:38, 1 February 2023 (UTC)[reply]
You really don't think the assassination of Shinzo Abe wouldn't be mentioned? You seem to still think I'm arguing for a discrete "here are the important people who died" list. No, I'm saying, include them in the actual list of events, if their birth or death was actually notable. I'm pretty sure Abe's is. --Golbez (talk) 23:07, 1 February 2023 (UTC)[reply]
Their deaths, in themselves? Sure. Looks like Pele's funeral was a major event though, so that would probably be included. You do realize that all I'm suggesting is that, if people want to find out who died in 2022, they look at the category of people who died in 2022. That's all. There's no need to duplicate efforts in a year article, especially since then it just becomes a popularity contest of who gets included. --Golbez (talk) 23:58, 1 February 2023 (UTC)[reply]
That cat has multiple times more people in it. The deaths in main year articles are only of those that have substantial international notability. You're implying that thousands of editors have pointlessly made those lists on main year articles during the last two decades. Jim Michael 2 (talk) 00:31, 2 February 2023 (UTC)[reply]
Why? Why do they go to the list? I'm not being facetious. If they want to know who died in the year, that's what the category is for. If they want to know who famous died in the year, well, first of all, if they're on Wikipedia they've already passed notability. Secondly, they aren't going to find the famous people - they're going to find what a tiny subset of a subset of Wikipedia decided were the people worth mentioning. I know this isn't going to change, and I'm not about to right some great wrong with this argument. But I will defend it. --Golbez (talk) 16:19, 2 February 2023 (UTC)[reply]
Those cats include a huge number of people. The deaths lists in main year articles are those who have substantial international notability. The criteria have been discussed at length. Jim Michael 2 (talk) 18:09, 2 February 2023 (UTC)[reply]
Very weak support I think that this is an axe being asked to do a scalpel's job. Yes, if the article is too long per WP:ARTICLESIZE, than births and deaths make a good target for spinning out into their own articles. However, to say that we need to do so for all year articles is a bridge too far. I'd be okay with guidance that says "If a year article is too long, then it should be considered to split the birth and death sections as their own articles" however, this wouldn't be even necessary for most year articles. Picking a few random years 175 (not needed), 1211 (not needed), 1472 (not needed), 1811 (a bit of a longer article than the rest, but probably still not needed), 1877 (getting longer still. Probably not needed, but reaching the edge-case territory), 1922 (needed, being overwhelmed by births and deaths, and reaching the "probably a bit too long" area), 1988, (likely needed). Given that data, I'd be fine with setting a cutoff of 1900 or later, but even still, we should be careful about how we do this. The current proposal is far too broad. We need to tailor it to actually fix the problem at hand. --Jayron3212:08, 2 February 2023 (UTC)[reply]
Support, the WP:SIZE argument applicability gets tricky as this mixes prose and lists, but perhaps that is another argument for a WP:STANDALONE list. Most of the year articles are just lists of course, but they could be much more! Even without that step, I suspect any prose would develop from the events sections, not the births and deaths, so spinning off the undue elements makes sense. (As mentioned above but to clarify, births and deaths that would make the event section are of course fine in the main articles.) CMD (talk) 12:30, 2 February 2023 (UTC)[reply]
Comment If births & deaths are to be split off main year articles, for which years would this be done? Recent year articles have the most deaths in them, but far fewer births. Jim Michael 2 (talk) 12:35, 2 February 2023 (UTC)[reply]
I'm not saying it doesn't, but there isn't an exact size at which we should split, so how many main year articles should the births be split off from? How many for the deaths? Jim Michael 2 (talk) 15:49, 2 February 2023 (UTC)[reply]
I'm not convinced that it's not. The way the discussion seems to be heading, we're in danger of creating two articles of unmanageable length in place of the existing ones, with the same debate over "international notability" having to continue. Deb (talk) 13:29, 9 February 2023 (UTC)[reply]
Support removal, this is what categories are for. No need to split. Just delete. If categories aren't up to the task, then we need to improve how categories work. (can't help but wonder if this is where my 20 year old Semantic Wikipedia proposal would have come in handy...)[citation needed] --Golbez (talk) 16:37, 2 February 2023 (UTC)[reply]
That seems like the kind of editorializing other websites, like news sites, might excel at. Maybe if we had a better category system, we wouldn't need to maintain a list like this. --Golbez (talk) 22:48, 6 February 2023 (UTC)[reply]
Support as long as readers could easily navigate to "Deaths in year X" from "Year X". It is getting too long and too unwieldy. Ancient years where there are no long list of births and deaths should not be changed.✠ SunDawn ✠(contact)16:04, 4 February 2023 (UTC)[reply]
I think that how [[[2022 in the United States]] handled it is the best way. We have a level 2 header with a hatnote. InvadingInvader (userpage, talk) 01:29, 6 February 2023 (UTC)[reply]
Partial Support, as it fixes the usability issue of having multiple long timelines per page (which makes it harder to use scroll bars to judge which point in the timeline you are looking at). Partial because articles like Deaths in February 2022 appear to include all notable deaths, so are very likely to already include the more selective subset of deaths from the main year articles, so in practice we are talking about deletion of those sections rather than splitting. I support that too, but I’m not sure this is laid out clearly enough in the proposal. Barnards.tar.gz (talk) 22:22, 4 February 2023 (UTC)[reply]
Barnards.tar.gz: Just to clarify, situations like this would be the exception. There are preexisting standalone lists of deaths for 1990-2023, so it would be effectively be a deletion in those cases since the content already exists at the destination. But all the years before that don't have dedicated lists of deaths, and to my knowledge there aren't any preexisting standalone lists of births by year. Thebiguglyalien (talk) 22:50, 4 February 2023 (UTC)[reply]
Support per Useight. Good suggestion. This would also have the benefit of preventing some of the horrendously long and mind-numbing disputes recently seen. Happy days ~ LindsayHello16:18, 5 February 2023 (UTC)[reply]
Support as it would drastically reduce the amount of content disputes, though I would prefer to see some mention of notable funerals under events, as well as hatnoting these. I would also not be a big fan of splitting these contents if it would end up creating mini stubs, but in general, especially for years 1900+, this is a good idea. InvadingInvader (userpage, talk) 01:25, 6 February 2023 (UTC)[reply]
Support The articles are moderated pretty well, but the pattern right now is every time someone disagrees it goes to RfC and it basically becomes a popularity contest with no regard for how the article has been managed. Since there's no consensus on a way forward it makes sense to just remove the deaths altogether. Nemov (talk) 16:52, 6 February 2023 (UTC)[reply]
Support. I agree that births & deaths are minor aspects of a yaer. The freed-up space could be used to turn the lists into prose, which would make these articles far better. DFlhb (talk) 18:13, 6 February 2023 (UTC)[reply]
Support, so there is no more discussion about who is "internationally" noteworthy enough to be included in the main year article which really comes down to editor opinion. Right now, people are arguing to include Viktor Mazin or Josef Panáček due to winning gold in the Olympics despite a lack of potential WP:DUEWEIGHT in sources (Josef's bio has two sentences, but he's included over someone like Ash Carter). If you list them all on their own page and remove them from the parent, that solves the problem. Of course, deaths like Shinzo Abe and Queen Elizabeth can still be included in the "events" section, as there is related news to that beside just their act of dying (e.g., the assassination; the new king). Why? I Ask (talk) 02:19, 8 February 2023 (UTC)[reply]
Support Births and Deaths sections are the reason why recent years articles are cluttered. A split would be a good idea, as it would make most discussions regarding death of notable figures moot, and not just that, it would do away the possibility of another discussions regarding these - which always fills up the talk pages of year articles because of debates after debates about THESE deaths. MarioJump83 (talk) 09:01, 8 February 2023 (UTC)[reply]
Not only that, but these sometimes ridiculous deaths discussions have been draining my mental health. I feel confident in assuming that some other people can relate. I'm glad that we've finally gotten rid of the old "International notability" standard in general, but deaths at this point are best if they face a Morgenthau Plan-like fate. InvadingInvader (userpage, talk) 21:28, 11 February 2023 (UTC)[reply]
Oppose. Neatly trimmed sections that contain births and deaths should be included, per summary style. That we have a hard time doing this might be part of the task, but merely splitting it out without providing some summary overview in the article seems contrary to that style. — Red-tailed hawk(nest)19:16, 8 February 2023 (UTC)[reply]
Support only for those that satisfy the conditions of WP:SPLIT. If the articles are way too long, then it's a good idea, but for e.g. earlier centuries, most of the year articles are short enough that the list of comparatively smaller births and deaths of people with articles is unobtrusive. Joseph2302 (talk) 13:35, 9 February 2023 (UTC)[reply]
Support - Where the year article is over-long, and the birth/death is not a major historical event in itself (like, e.g., the birth of Jesus or the death of Stalin). If there is any dispute about where a birth/death should be included as a major event, typically I would expect an article about the birth/death as an event for it to qualify. FOARP (talk) 14:46, 9 February 2023 (UTC)[reply]
so you're saying that we should include a list of very significant events, births and deaths in the year articles, and have a separate set of articles of 'all deaths' in those years? This is already the case. JeffUK12:50, 10 February 2023 (UTC)[reply]
Oppose - We already have articles listing all (notable) births and deaths in each year. This is supposed to be a curated list of very significant events in each year; If the problem is that the article is too long, we need an RFC to agree the inclusion criteria for Births and Deaths that would drastically raise the bar for inclusion. I think the same is true of 'Events' as well. JeffUK12:50, 10 February 2023 (UTC)[reply]
This is supposed to be a curated list of very significant events in each year. You're right, which is why a deaths and births sections is unneeded in the parent page. It's not a big event that Coolio died. Other deaths, such as Shinzo Abe or the Queen, are notable events themselves with their own pages. But that can be added to the events section as special mentions. There is not need for the random duplication of content across pages, and currently the inclusion criteria is vague and handled by only a small subset of editors. Why? I Ask (talk) 13:13, 10 February 2023 (UTC)[reply]
My view comes from 'look at what other similar sources tend to include', and a 'year in review' type resource will often include a list of 'important' deaths which is separate from 'events'. There's a difference between a death with is significant (Joe Nobody killed by aliens) which is an 'Event', and the death of someone who is significant, but who's death was otherwise not (Rich old formerly important man dies at home). I think readers expect a listing of significant deaths in the year in some easy-to-consume format, without having to read through all the other events. Looking at the newly formatted 2001 article, I think having a section on 'Deaths' would fit perfectly. I like the idea I saw on one of these myriad discussions about having a guideline/soft limit of X deaths on the main article. JeffUK19:23, 10 February 2023 (UTC)[reply]
"My view comes from 'look at what other similar sources tend to include', and a 'year in review' type resource will often include a list of 'important' deaths which is separate from 'events'."
What "similar" sources do that? Most WP:RS that might publish a 'year in review' editorial would be WP:Secondary sources with functions and policies which allow for editorial discretion in making such a list. This project is a WP:tertiary source, an encyclopedia, meant to summarize the positions of primary and secondary sources, with neutrality policies that greater constrain our ability to pick favourites, so to speak, from among topics, on the basis of personal judgment of what is an "important" topic. There seems to be a problem understanding that point of policy and community consensus so far at WikiProject Years, and thus no suggestion (that I have seen presented anyway, from my indirect view of the project and the recent related VP and ANI discussions) that is based in WP:WEIGHT has been advanced out of that project. If there was, I for one should be happy to consider it, as I think there's at least an argument for keeping a summary section in the main article. And yes, a soft limit might make sense there as well. But inclusion criteria has to somehow be rendered out of source-based/NPOV/WEIGHT processes. None of this !voting the opinions of our individual editors as to what we think is important, and then reverse-engineer policy-like language such as "international notability" to rationalize those idiosyncratic preferences after-the-fact nonsense that seems to have become quite common practice on some the years articles in recent years, from the look of the talk pages.
In the meantime, until such a RS-based standard and process is proposed and endorsed by the community at large, the current proposal is a reasonable middle ground solution that addresses the main concern that arises out of the WP:YEARS crowd--which is doubtlessly exaggerated but nevertheless a cognizable issue--that the years articles are too large, but balances that concern against broader, more central, and more critical content policies that the community expects other more localized standards to generally conform to. SnowRise let's rap02:31, 11 February 2023 (UTC)[reply]
A deaths section on paper would look nice, but it's like premium gasoline for an engine which produces the lamest edit wars and most unnecessary discussions. I feel like I need ten extra cups of coffee whenever I'm entering Talk:2022 to argue in favor of or opposing deaths. It's become mentally draining for me, and the removal of the section is not only in the interest of the project for reducing these wars, but by extension also in my self interest. No one can agree on a criteria, and given the about of opposition to "International notability" as previously implemented, unless we remove deaths altogether, we're going to be stuck in a gridlock because it seems like no one is willing to concede disputes until an RFC closes or outside admin intervention occurs. InvadingInvader (userpage, talk) 21:24, 11 February 2023 (UTC)[reply]
Support. I actually think that the need to curtail content on these articles may be at least somewhat exaggerated, in the WP:NOTPAPER sense. But if the choice is going to be between 1) allowing users to run around applying thinly-veiled WP:OR criteria as to the "importance" of this or that person based on nothing nothing remotely tethered to WP:WEIGHT or, 2) simply sequestering the content into separate articles to reduce the perceived need to constantly be asserting policy non-compliant personal calls as an excuse to "prune" the article to personal taste of importance, and then rationalize it by page byte size, then I have to choose the latter. That's unlikely to stop the arguments based on subjective calls in the Years articles altogether, nor completely forestall debates in the death/birth offshoot articles, but it is a start. If the Year regulars come up with a WEIGHT-centered test for inclusion of a summary section in the main years articles that the community can get behind, we can then make that adjustment as well. For the meantime, a clear break moving all death/birth entries to a separate list seems like a workable system. SnowRise let's rap02:31, 11 February 2023 (UTC)[reply]
I personally doubt that such a measure can be agreed upon. When I try to propose criteria myself, I feel that too many people follow an "all or nothing" approach, either restricting ourselves to the old "international notability" standards or including everybody. Frequently, I remember seeing Jim Michael 2 before his TBAN and 4me689 make a lot of these arguments, like "by including Robbie Coltrane we must include Anne Heche" or "we must include Takeoff because we included Coolio". I also remember Scrubby making a lot of anti-Americentric arguments, but there came a point where it at least seemed his position was less anti-Americentric and more so exclude because they're American, which is worse. My attempts to persuade editors into a more consensus-based system not rooted in a standard have all but failed. I think that my support of the removal of deaths, as much as it is rooted in article size, is even more intended to prevent chronic and energy-draining debates. As dumb as the following sounds, it's come to the point where I felt I've been losing my Monday and Friday chess games partly because I used most or all of my brain energy to argue in favor of including Barbara Walters. InvadingInvader (userpage, talk) 21:18, 11 February 2023 (UTC)[reply]
Strong oppose - We'd need to be consistent with every single year to do this. It would be strange to have some years with sections for births and deaths and others not. In practice, this would create hundreds of new articles. Tim O'Doherty (talk) 17:58, 18 February 2023 (UTC)[reply]
Make quality ratings of list pages in Wikipedia more specific
I wonder whether it is worth making a proposal for WikiProjects to make their assessments of list articles more specific? If one goes to the article "List of pastries", one can see it was rated "List class" by WikiProject Food and Drink. This tells us WHAT this article is, but does not tell us its quality. My proposal is to introduce the following ranking for Wikipedia lists:
Q. Contains Questionable Entries
Start class. Needs to be more comprehensive
C. Reasonably comprehensive and accurate, but still requires more work
B. A very good list
A. Contains accurate information, covers a good range of entries and
provides parameters for information that would not normally be accessible
from categories or articles.
I'd strongly support adopting the MILHIST List ratings wholesale (and frankly, that's more likely to obtain consensus than this proposal; I wish this had been brought up at WP:VPI first, to obtain consensus on which list-ratings to propose).
MILHIST's approach just makes far more sense: lists and articles are both subject to the same flaws (sourcing, completeness, comprehensiveness, writing quality), so there's little reason to only have two assessment grades for lists. DFlhb (talk) 22:20, 16 February 2023 (UTC)[reply]
I can second this proposal. Now that we are working on globalising ratings, we should definitely consider ways to standardise as many quality ratings as possible. —CX Zoom[he/him](let's talk • {C•X})11:26, 19 February 2023 (UTC)[reply]
I agree that the line between Start and C is blurry. But as someone who edits in topics that have some overlap with MILHIST, I've found that particular assessment system and the B-checklist tool to be more of a mild annoyance than anything. I suspect you could come up with an article that's only a few sentences long but would technically meet this set of C-class criteria. Thebiguglyalien (talk) 15:30, 17 February 2023 (UTC)[reply]
I see. I've noticed that even short MILHIST articles tend to be far better sourced than for other WikiProjects. Maybe that has at least a little to do with their criteria incentivising either completeness or sourcing, while our current criteria just incentivises completeness? Seems like a bad incentive. DFlhb (talk) 16:57, 18 February 2023 (UTC)[reply]
Very much so. C class did not originate at MILHIST. It was brought in by other projects and adopted by MILHIST for conformity only after some debate. I argued against it; I did not think creating an additional class between Start and B was worthwhile, given that B is the minimum acceptable standard for any article. The outcome was not what the advocates expected. It resulted in the criteria for B class being hardened. Where once an article could have an unreferenced sentence or two and still be waved through as B class, now such articles were now graded C. Over time the role of C class has become that of identifying candidates for elevation to B class through a small amount of work. Currently MILHIST has about 20,000 articles rated B class and 60,000 as C class. Hawkeye7(discuss)18:40, 18 February 2023 (UTC)[reply]
WP:MILHIST has some advantages because of long continuity among the project's ranks. Hawkeye7 has been among those leading the project for many, many years and the respect I feel for his experience, competence, dedication and long first-hand knowledge of Wikipedia's history has been earned. I'd rather not speak for other wikiprojects but C-class can be, as Hawkeye7 points out, a useful flag that moderate diligence has been exercised in review and that only comparatively small effort needs be made to get the work to B-class thresholds. The required effort to promote between start and B-class reviews is substantial. BusterD (talk) 19:44, 18 February 2023 (UTC)[reply]
At WP:HWY, this means that there are at least all the required sections (Route description, History, and Junction list]], but that they are not necessarily complete or fully sourced. WP:HWY/A. --Rschen775419:55, 18 February 2023 (UTC)[reply]
I just thought of another potential benefit: with this change, all assessment grades will have clear, specific criteria (except of course Stub). It doesn't just clarify C; it also defines Start-class as any article that fails both B1 and B2, or fails any of B3, B4, B5. DFlhb (talk) 18:34, 19 February 2023 (UTC)[reply]
Oppose per WP:BURO. The proposal is incomprehensible jargon because even an experienced editor like myself has no idea what those various B numbers are. And, as Sideswipe9th says, what's the point of these fine distinctions? For example, I attend discussions at WP:ITN/C where article quality is an important consideration for every nomination. Project ratings get no respect there. I have suggested that they be used but most editors use their own assessment based upon the number of citations, the amount of prose and little else. Andrew🐉(talk) 10:28, 4 March 2023 (UTC)[reply]
Donations for Wikipedia editors
Preface: I want to address administrators, bureaucrats, and other contributors to Wikipedia. I am not advertising anything in this message, it is just important for me to try to improve the project, to attract participants, to improve conditions for editors.
"Hello everyone. I would like to address all members of Wikipedia. It's good to see everyone in this project. I believe that each of you love Wikipedia and like to spend as much time in it as you want, because doing what you love can be endless. However, you would hardly refuse financial support, a kind of "tip" for working in your favorite project. I joined the project about 5 years ago myself, and over the years I have noticed several things: once successful and energetic participants leave Wikipedia: sometimes because of burnout and other reasons, but in most cases it is due to the need to plan their lives, and not everyone has the strength, resources, time, or desire to stay. Sometimes the desire is there, but the opportunity is simply not there. This is just the tip of the iceberg. I love people who are willing to help pro bono, but I want those people to get feedback. I think editors also want "tips."
I appeal to the Wikimedia Foundation and its staff: add the ability to donate financially to Wikipedia editors. Henry Ford used to pay employees for their vacations - and they worked much more efficiently. There's just one important point - donations need to be added in all language sections. Why can YouTube, Ticktock bloggers get donations from fans of their work and creativity, but not less talented Wikipedia contributors can't? All you need to do is add another button next to the "Thank you" button (the participant for the edit) - "Donate" to the participant for the edit. If you want to support me, speak up below, I've also created a Change.org petition that you can sign and help distribute (https://chng.it/CKYRQK4G). Love you all. Have a nice day.
As a Wikipedia editor, I don't want readers to swell my personal bank account. What I would love is for them to have a way to donate to Wikipedia – to have their money used to fund projects editors vote for, such as addressing the huge backlog of MediaWiki bugs and enhancement requests, rather than disappear into a general WMF fund which sponsors a Ruritanian equality workshop or creates another post for an ethical diversity advisor. Certes (talk) 21:56, 17 February 2023 (UTC)[reply]
I'm afraid I may have been misunderstood, so I'll correct myself a bit. I was not referring to replacing donations to the Foundation with donations to participants. It is necessary to have both. If any participant doesn't need the funds, they can redirect them to the Wikimedia Foundation. Алексей Старовойтов (talk) 22:14, 17 February 2023 (UTC)[reply]
What you are saying is that you want the Foundation to employ editors, paid for by donations. Even if that's a good idea, it would be a logistical nightmare to set up(which would also be costly) and likely there would be privacy issues. 331dot (talk) 22:30, 17 February 2023 (UTC)[reply]
I'd support having a system that provided some relevant material reward to highly productive editors (counting myself in that cohort). I would guess that many of us who provide value to the project could benefit from upgrades to the equipment we use to edit, and access to sources beyond those available through the Wikipedia Library. I personally have in the past purchased reference works useful to the improvement of specific sets of articles, and have worn out several computer mouses fixing large tranches of disambiguation links (I think New York alone took about 70,000 mouse clicks). BD2412T23:15, 17 February 2023 (UTC)[reply]
How would you define 'highly productive'? Judging by the number of high-edit-count contributors who have found themselves sanctioned or blocked/banned by the project in recent years, I'd have to suggest that a raw edit count would be a highly inappropriate metric, and I can't think of any alternative off the top of my head that wouldn't be inherently subjective. AndyTheGrump (talk) 23:28, 17 February 2023 (UTC)[reply]
Raw edit count isn't irrelevant though. I would also look at contribution to GAs/FAs (an area in which I am admittedly somewhat lacking), DYKs, creation and expansion of non-stub new articles. Certainly I would put the burden on anyone seeking support to show their work beyond merely "I have a high edit count", but we can set up smart enough measures of evidence. BD2412T04:55, 18 February 2023 (UTC)[reply]
Blocking results from bad edits, and someone with a million edits has probably made more bad choices than someone with a hundred. However, despite the occasional error, they've also added vastly more net value to Wikipedia. That's the important metric and, although it can be hard to measure, it seems strongly correlated with edit count. Certes (talk) 11:53, 18 February 2023 (UTC)[reply]
I'd like to echo a few things raised by other editors: 1) for obvious reasons, it might be wise if WMF was attempting to help LT contributors maintain appropriate equipment, connection, and data security, 2) purely to assist with our costs of volunteering, it would be useful for a wider array of library-like local sources like current newspapers be made available by Foundation allies, 3) the WMF might consider a wider program of grants and scholarships towards improving and encouraging the volunteer pool. My highest priority is the sustainability and survival of the program, and substantial foundation liquidity is essential to protect the mission. We also need to see Internet Archive well managed and liquid. I've raised my concerns below, but I believe opening this floodgate could be a pandora's box for Wikipedia. BusterD (talk) 17:04, 18 February 2023 (UTC)[reply]
Oppose. Money, even small amounts of money, attracts bad actors and system-gamers. No issue with individual editors putting donation links on their user pages though. Barnards.tar.gz (talk) 20:26, 21 February 2023 (UTC)[reply]
We have a stop-gap half-measure, which are grants. Some of them are small. Pl wiki offers mini grants/reimbursements for stuff like buying a book or even a camera (for folks who upload photos). See meta:Grants for a start. Note that I personally think micro grants are good but I have serious concerns about abuse in large grants (TL;DR, I fear some larger grantees are inflating costs to profit while producing next to no benefit for us). But, to reiterate, I think small grants, refunding books, library access, etc. are a good thing to pursue. --Piotr Konieczny aka Prokonsul Piotrus| reply here04:04, 18 February 2023 (UTC)[reply]
Having carefully studied all the arguments, I propose possible solutions to these issues:
I mean to add the ability to donate to regular editors, but not to remove the ability to donate to the Foundation. In my opinion, donations to participants will not interfere with donations to the Foundation itself. That is, readers will have a choice: to send money to the Fund or any editor, whose contribution they like. An important point: I propose that it is not the Foundation that gives donations to participants, but the readers of the project (although I do not exclude the help of the Foundation, if necessary). If some of the participants do not want to receive donations - we need to add a function that allows to refuse donations. If anyone doesn't want donations and thinks the Foundation needs the money more, we need to add a feature that allows the editor to redirect the donations to the Foundation. If some participants have money, they will have the opportunity to spend it on technical means (equipment, literature, media subscriptions, etc.) and therefore the Foundation will no longer have to spend money on grants to participants, but concentrate its attention and finances on more global and important issues. If anyone is intimidated by large amounts of donations or by turning Wikipedia into a place where many people will want to make money or will want to use donations as a payment system, it is reasonable to put a limit on the maximum amount of donations that can be sent to the editor per payment, for example about $1-$10.
If by confidentiality problem you mean payment data of participants, this problem is solvable too, for example on YouTube, when you sponsor authors, you don't see their payment data, a good example.
How do I know which authors should be allowed to accept donations and which should not? After all, there are authors who are detrimental and not very competent. For example, you could make it so that authors can only receive donations if they have been on the project long enough (although this measure would not solve the problem). Or it would be a special page where editors could apply for permission to accept donations. Or the ability to accept donations would be assigned at the same time as flags (e.g. "Patroller", "Administrator", "Bureaucrat"). Since these flags are not just assigned, nor are they assigned to everyone they meet, this could solve the problem.
As for grants, I've already made my point, if readers can donate to participants, then participants can cover equipment costs themselves, and the Foundation would not have to spend its own money on such programs, or at least it would at least reduce the Foundation's costs for these items. And besides, my proposed donations should, in my idea, increase the number of editors who can receive financial support, since the Foundation cannot satisfy absolutely all participants with grants. Алексей Старовойтов (talk) 07:11, 18 February 2023 (UTC)[reply]
This is scary material for discussion. I'd be interested in links to previous discussions on this inevitable subject. In the hypothetical, a request for "donations" reminds me of the run of '89 (without insult all to disenfranchised First Nations people, of course, but with all of the unintended consequences). I can't be the only wikipedian who has a view of how the pedia might one day die. I'm going to take a liberty to describe my thoughts. The WMF seems to be applying pressure on editors to subscribe to a UCC as volunteers, not paid employees. As a sysop, I feel strongly I'm here by and for the community, not the foundation. From another view, many longtime regular contributors perform important work without which an online encyclopedia truly still in infancy might not survive, and many of those editors are senior human beings who could utilize the stipend. What is true is that none of us will last forever, some of us may be corrupted or co-opted (by money or pressure), and as Larry Lessig once said in a Wikimania keynote, text is becoming the new Latin. My grandchild is no longer taught to read my handwriting. It is an amazing time, and how the world's largest online experiment for getting along reacts to these forces will make for a social experiment worthy of Hari Seldon. The foundation wants to give admins, functionaries and twenty-year contributors a stipend, that's one thing. Creating a way to donate to individual editors may turn us all into paid editors, and transform Wikipedia into Twitter or Facebook, neither fully functional nor socially relevant. BusterD (talk) 07:31, 18 February 2023 (UTC)[reply]
Adding a paypal me link for editors down the side of talk pages wouldn't be technically difficult if people were willing to give their email addresses and source for payment, but very few of our readers check the history of an article, and given the collaborative nature of the project singling out one editor for writing something can be difficult, particularly on core topics. I think you'd find next to nobody would send editors money individually and it would be a waste of time. ♦ Dr. Blofeld17:25, 18 February 2023 (UTC)[reply]
Considering the proliferation of UPE the last few years, I'm sure there are dozens of reputation protection and pr firms who'd love to legally pay editors for popular contributions. Am I the only person to see this? The "how" isn't relevant before the "if" or "why." BusterD (talk) 18:18, 18 February 2023 (UTC)[reply]
No. you're not the only person to see that this is an incredibly bad idea. I can just imagine an editor saying in a discussion about what to include, "but five people paid me for this edit". No, just no. Phil Bridger (talk) 18:41, 18 February 2023 (UTC)[reply]
Yes, I just wanted to add the rebuttal of - this would encourage both functional paid editing "do editing in this area, where your odds of working on content that aids my business is higher" as well as irrevocably breaking our reputation for such. If the WMF wants to directly handle acquisition of sources and such, perhaps through the Wikimedia Library, that's always good.
I found a quarter once at a Wikipedia conference. My new pay grade. But I do wish the Foundation greatly funded full conferences, offered room and board to editors traveling to cover a topic (when one editor, okay, I'll name him, Another Believer, goes into a city he photographs and writes articles for most of the statues in that city - a wonderful use of travel time. I say fund a few trips for editors who have shown their proficiency on things like this). And, yes, full funding of events and participants in a gala VivaWikiVegas for a North American Conference, well-earned party and meet-up occasion using Foundation money saved during the covid years. The Foundation really should be funding more Wikipedia editors and projects, to the tune of 10-20 million a year for a few years. Randy Kryn (talk) 13:36, 20 February 2023 (UTC)[reply]
If editors could be paid for edits then some of them would abuse it. For example, delete a large part of an article with an alternative account and restore it while claiming credit. Or make an unattributed copy to another article. Or make edits you think are popular with somebody willing and able to pay, e.g. removing negative well-sourced material about a company. Imagine articles where it becomes known or just rumored that certain types of edits are likely to get paid. I think there would be too few donors who are both willing to pay and properly judge who actually deserves pay for improving Wikipedia. "What is the chance somebody will pay for this?" should not be a thought when you make an edit. PrimeHunter (talk) 16:54, 20 February 2023 (UTC)[reply]
Strong oppose as it's open to abuse. We already have Wikimedia editathons with prizes that just encourage users to make tons of poor quality edits rather than helping the encyclopedia (e.g. an annual spam as many poor quality pictures into article challenge). Don't see how paying people to do more edits would have an actual benefit to the encyclopedia, as it would change motivation of some editors from being useful to doing as much small junk things as they can to make money. Joseph2302 (talk) 17:01, 20 February 2023 (UTC)[reply]
I would support the WMF hiring people or otherwise subsidizing them to edit and/or mediate neutrally on contentious topics, subject to extensive oversight by the community itself. But I think that the model proposed here of donating directly to editors in a decentralized fashion is unlikely to work for the various reasons identified by other editors above. signed, Rosguilltalk17:54, 20 February 2023 (UTC)[reply]
If so many people can come together and contribute to a shared goal, then is paid editing ever needed? I think not. As others have said, I believe it will lead to people joining for the money, rather than joining for what we are truly here for: to create a free encyclopedia. Anything that could detract from that ultimate goal is a bad idea. Schminnte (talk • contribs)02:53, 22 February 2023 (UTC)[reply]
If people want to donate in support of the project, but don't want to donate to the Foundation, then donate to the Internet Archive or any other project that provides free access to reliable sources. I just "checked out" a book for an hour from the Internet Archive yesterday to use as a source in an article I'm working on. I also use the Wayback Machine a lot, and periodically contribute to the Internet Archive. - Donald Albury13:34, 22 February 2023 (UTC)[reply]
Confession I've actually been soliciting donations to further my own editing. After all, obtaining sources costs money, an increasing amount of money since I started editing, & I figure I could get money in a way that did not influence the POV of what I wrote. (Examples: I've found that some of the books I need for Ethiopian & Classical History have set me back over $100, while most of the rest are at least $50 a volume. I've encountered more & more a charge for ILL materials, such as Duke University charging me $15 for me to borrow one of their books.) So far, opening accounts at Go Fund Me, & Buy Me a Coffee have netted me exactly $1 in total. To be good at raising money in these ways, one has to be good at self-promotion, & if I were good at self-promotion I'd probably have been writing & publishing books & making a living that way. Instead I write articles on Wikipedia.
One proposal I have been promoting is for the Foundation to set up a process for awarding research moneys. (Yes, the Foundation offers grants, but nowhere is it explained if, when or how it will provide grants for research. At least no where that I've looked. Maybe that's changing.) Providing grants of $50 to $100, maybe $500, is not going to ruin the seriousness of any established editor, but it might be an incentive to keep an experienced editor from drifting away. In my case, receiving a modest grant -- say $100 to $250, which is not enough money for me to live on, unless I live in a developing country where the minimum wage is $2 a day -- would have provide an incentive to improve some of the articles I've worked on to GA or FA class. -- llywrch (talk) 07:10, 24 February 2023 (UTC)[reply]
I think you are optimistic that that wouldn't have any impact on the individuals writing (including the risk that editors who might indeed have taken something to FA without it, decide to take it to a good level and then ask for the research grant - and not progressing if they don't receive it). Perhaps more significantly, it would give the WMF a means to push content they wanted to see more of - indirect Editor status, and the WMF has public, established, social and political positions that (for example) en-wiki has !voted and confirmed a neutrality on. Nosebagbear (talk) 23:06, 1 March 2023 (UTC)[reply]
Community-authorized sanctions for gender identity
There are currently ARBCOM sanctions on topics related to gender and sexuality as described at WP:GENSEX. This allows uninvolved administrators to apply and enforce restrictions on related articles and editors in this topic area. Unfortunately, it seems that this is not sufficient to prevent widespread disruption in the topic area. Gender identity is highly contentious and causes significant disruption, and that's unlikely to change any time soon. Furthermore, this topic area is among those most capable of causing real world harm. For these reasons, I'm proposing the creation of community-authorized WP:ARBPIA-equivalent restrictions for this subject. This would entail:
Standard contentious topics sanctions as previously established
One revert restriction that limits all editors to a single revert in 24 hours (unless it's to enforce the previous point or remove clear vandalism)
It would not replace or change the ARBCOM GENSEX sanction, but it would supplement it in this specific area with ECR and 1RR. To my understanding, this is the highest level of restriction in use under general sanctions, and it currently applies to Palestine–Israel, the Syrian Civil War and ISIL, and cryptocurrency. Before any RfC is created, I'm posting this proposal here to determine:
Whether support for this exists
If so, at what scope; whether a more limited scope such as transgender BLPs, or more broadly into LGBT topics
If there are any stipulations or other considerations that would need to be addressed in a hypothetical RfC
That I didn't completely misinterpret how all of this works
Note, saw this before the notification went out, though I am active in that WikiProject. I'm a pretty active editor across many GENSEX articles, if I'm not patrolling recent changes for any sort of vandalism or disruptive editing, you'll likely find me on a talk page somewhere hashing out content. I've some remarks on each of the three proposals:
This seems largely redundant. GENSEX is already a CTOP area through the past ArbCom cases and motions listed on WP:GENSEX.
On the surface this isn't a bad idea. As you've alluded to, it would prevent drive-by article space disruption by both IP editors and new accounts, which would certainly cut down on certain types of disruption like inserting deadnames or mass pronoun changes of BLPs, or spurious accusations based on typical anti-LGBT+ canards. However I'm not sure it would actually solve the current overall problems in the content area. From my perspective, one of the biggest problems is that we have a set of established behaviourally problematic editors in this content area, all of whom to my knowledge are extended confirmed, that this restriction would not directly affect.
A blanket 1RR seems overly draconian to me. As a tool to prevent disruption, it has its uses on a targeted per-article basis, but as a blanket "all articles are now subject to 1RR". 1RR has by its nature a stabilising effect on articles sure, but that also has the effect of making rewrites, and major additions or removals significantly harder for all involved.
In terms of actually fixing what's currently broken in GENSEX, I don't think that this would have the desired effect. I'd also be concerned at the unintentional side effect of scaring off good faith new editors from this area. Maybe I'm wrong though, and I'd be interested to hear from editors in the other content areas you've identified that have these restrictions if they find that those restrictions have actually helped that content area, or if they've just moved the trouble spots elsewhere. Sideswipe9th (talk) 00:17, 23 February 2023 (UTC)[reply]
@Thebiguglyalien, here's how I'm understanding your proposal.
99.75% of all registered editors should be banned from joining this discussion, or any discussion like it, because it's not in the Talk: namespace.
If a celebrity reveals a different gender identity today, then only the top 0.25% of editors should be allowed to make our articles comply with MOS:GENDERID. The other 99.75% of editors should be warned and blocked if they try to help out.
Editors attending edit-a-thons (such as Art+Feminism) and students in organized classes (there are more 4000 students in more than 300 classes running right now) should be banned from editing anything even remotely related to gender. We should definitely cancel any groups that want to write about women's health or women's politics, because someone might have to decide whether to write "the woman's uterus" or "the uterus", and that's gender-related.
And the justification for this is: People who have already achieved not only ECR, but Wikipedia:Unblockable status, can and do perpetuate gender-related disputes for years, while an IP can be blocked out of hand and pages can be protected to prevent them from editing entirely. Right? WhatamIdoing (talk) 18:55, 27 February 2023 (UTC)[reply]
The OP has asserted that WP:GENSEX restrictions are inadequate to stop disruption, but there are no diffs or links to anything to back up that assertion. If we're going to supercede the existing ArbCom sanctions scheme, shouldn't we at least have evidence that the current sanctions are not working? --Jayron3219:26, 27 February 2023 (UTC)[reply]
I'd support adding WP:ARBECR to WP:GENSEX. ARBECR has helped in the WP:PIA and WP:APL and the community recently authorized it for WP:RUSUKR, WP:KURDS, and WP:ARBAA. GENSEX has the same problem with socking/drive-by/inexperienced editors as the other topic areas. For examples of current sanctions not working, just look at the two ANI threads in the GENSEX topic areas right now (which, in my view, have been disrupted by non-ECR editors, on both "sides" of the issue). I think the "99.75%" figure is a lark; most registered accounts never edit; we have 40 million registered accounts; half of them (20 million) never made any edits; only 2 million made 10 edits; only 450k made 100 edits; only 100k hit ECR. And yes, I think it's a good idea to not allow new editors to edit in our most-contentious contentious topics. I'm much less sure about 1RR being effective or necessary; I think I'd only be in favor of that upon a showing that there is so much edit-warring in this topic area that the usual 3RR isn't working. Levivich (talk) 19:34, 27 February 2023 (UTC)[reply]
Looking at both discussions at ANI (One involving Newimpartial and one involving Tranarchist), and neither has significant disruption from anyone that wouldn't already qualify for ECR. Well over 90% (and possibly vanishingly close to 100%) of the text in those two ANI discussions, involve well experienced editors. I have spent 5+ minutes paging through them, and while I'm sure a small number of comments in those discussions may be from new or "drive-by" editors, I can't at first glance identify any obvious ones, the vast bulk of the text in those discussions is from very experienced Wikipedia editors. You're going to need better examples than that. If nothing else, your examples have served to show places where it isn't a problem; it's clear evidence against needing any ECR sanctions, since so little of those discussions is taken up with any such people. --Jayron3220:22, 27 February 2023 (UTC)[reply]
Here's a complete list of the edit counts for every person who's ever edited that talk page, in order by the number of edits made to that page (which, BTW, they would all still be allowed to do under this proposal):
22K edits + 14 years
350 edits + 6 years
1300 edits + 1 year
19K edits + 4 years
7K edits + 15 years
250 edits + 1.75 years
(sock)
31K + 5 years
(IP) 1 edit
300 edits + 2 years
3800 edits, 7 years
95K + 13 years
5K edits + 1 year
That's 13 editors. Ignoring the sock, there are only three registered accounts and one IP that would be banned from editing, and all of them could reach extended-confirmed by spending a couple of hours doing some kind of trivial high-volume editing mindless, like removing dead links from ==External links== sections. Also, the IP and one registered account has made just one edit to the talk page, and another has made only three, so if your goal is to reduce the number of comments, I suggest that excluding the people who don't post much anyway is not going to make much difference. WhatamIdoing (talk) 23:55, 27 February 2023 (UTC)[reply]
That's missing the forest for the trees. The edits by the non-XC editors on your list prompted the edits by the XC editors on your list, and wasted their time. There are 8 threads on that talk page:
Started by a sock with 14 edits who argues with several editors before getting blocked
different non-XC 1AM with poor understanding of sourcing
same
same
productive thread by XC editors
different non-XC with poor understanding of sourcing
Unless I'm missing something, if ARBECR was applied to the GENSEX content area we'd still have to respond to those threads on article talk pages in some way. ARBECR would only prevent article space disruption, and to a lesser extent related discussions in the project namespace. Sideswipe9th (talk) 00:07, 28 February 2023 (UTC)[reply]
Yes, this is true. ARBECR would not actually prevent this particular type of disruption (unproductive talk page discussions). I'm just pointing to this as an example of disruption in the topic area by non-XC editors. But look at the article history and you see non-XC editors also having to be reverted there (even by you in some cases, lol), which seems like most of the last six months of edits to that page. I think they're wasting your time Sideswipe but I would take your word for it (and that of other regulars in the topic area) if you thought different. Levivich (talk) 00:13, 28 February 2023 (UTC)[reply]
I've already put forward my thoughts on the initial proposal above. ARBECR is not a bad suggestion per say, we do get a lot of disruptive drive-by article space edits that need some sort of cleanup and this would put an instant stop to that. But for actually fixing what I see as broken in the GENSEX content area, I don't think it would actually address any of the root problems. Sideswipe9th (talk) 00:20, 28 February 2023 (UTC)[reply]
You're right, that it doesn't stop all, maybe not even most, disruption. But I see the success of ARBECR in, for example, the Holocaust topic area right now. This controversial high-profile paper comes out, it's all over Twitter and such, it should be bringing in a bunch of new editors and IPs POV-pushing from all angles, but it's not, because all those pages are ECP'd. So if you look, for example, here, here, or here, you still see editors arguing about stuff, maybe disruptively maybe not, but it's experienced editors. What you don't see is the non-XC wasting people's time on talk pages, even though the talk pages aren't ECP'd, but the articles are, and that makes the difference. I think ARBECR is noticeably reducing the amount of disruption there otherwise would be in that topic area right now. Compare with Seymour Hersh or Killing of Tyre Nichols--both high profile but not ECP'd--and you see a lot more disruption there. Levivich (talk) 00:38, 28 February 2023 (UTC)[reply]
Maybe it's because I'm too tired right now, but it seems like you're saying that ECPing all of the mainspace pages in a contentious content area also has a measurable decrease in disruption in the related talk space? Is this something specific to the examples you've provided, or is it also reflected in other ARBECR areas? Sideswipe9th (talk) 00:44, 28 February 2023 (UTC)[reply]
Yeah you've got me right: mainspace ECP reduces talk page disruption. I've also seen it in WP:ARBPIA, like Israel. There you see the same thing as in the Holocaust articles: a long, often quite contentious, content dispute on the talk page amongst a number of experienced editors, but not really any disruption by non-XC editors. The article is protected, the talk page is not, and there has been a major escalation in violence in that conflict in the real world in the past month or two, and you'd expect this big influx of new editors, but it's just not there. Which lets the experience editors focus. To my eyes, when I look at Holocaust or Israel/Palestine talk pages, they look very different from gensex talk pages, it's a more focused and productive form of disruption :-D Levivich (talk) 00:48, 28 February 2023 (UTC)[reply]
Interesting! In that case, I would be open to at least trailing it for 6 to 12 months to see what sort of effect it has. If it does result in the same lessening of disruption on talk pages as well as in articles, I wonder if perhaps it might bring some of the other behavioural problems from other long term editors into sharper focus. As if it does, then it would also indirectly help solve what I see to be one of the root problems in the content area.
There's a few procedural niggles that I and probably a few other editors would need some clarification on. Because GENSEX deals with identities, the delineation between when an article is or is not covered under it is a bit more fluid than other content areas. For example how do we handle BLPs where notable person John/Jane Doe comes out as trans or non-binary and changes their name? Sure I can now slap a GENSEX alert onto the talk page, but would I also be able to go to RFPP and say "BLP subject, came out as trans, article now covered under GENSEX ARBECR" and straightforwardly get the page protected? And how would we handle articles that contain or could contain GENSEX content, but where GENSEX isn't the primary topic? For example man, woman, pregnancy, vaginoplasty, phalloplasty. Sideswipe9th (talk) 01:03, 28 February 2023 (UTC)[reply]
Articles that are in, or that enter, the topic area scope can be tagged. I don't think ECP is applied just as a matter of course, but if/when there is disruption, the RFPP request will get approved as a no-brainer, and often will be indef instead of temporary so you only have to ask once. For articles that aren't mostly in-scope but have some in-scope content, those I don't think usually get indef ECP'd, sometimes temporary ECP, but reverting a non-XC editor is a 3RRNO, so it's still very easy to enforce. Similarly, non-XCs can post "constructive comments and make edit requests" on article talk pages, but they can't vote in RFCs, RMs, AFD, RSN, BLPN or any other project discussion. It also stops non-XCs from creating new articles in scope (in theory, NPP catches it, but if not, it can be CSD'd). Levivich (talk) 01:14, 28 February 2023 (UTC)[reply]
In re "I think the "99.75%" figure is a lark; most registered accounts never edit" for @Levivich: If you want to count only registered editors who have successfully completed an edit (a number that is smaller than the number who tried), then extended-confirmed excludes about 99.2% of all registered editors. That still excludes a lot of editors. WhatamIdoing (talk) 00:00, 28 February 2023 (UTC)[reply]
That's no more convincing than pointing out the pool of XC editors is over 64,000. There are lots of editors. Most are not extended confirmed. Even more are not autoconfirmed. Even more have never made an edit. That doesn't mean anything, and portraying it in terms of "percentage of editors excluded" is rhetoric, not logic. The logic is to exclude inexperienced editors; that fact that 99% of registered accounts are inexperienced is besides the point, since 87% of registered accounts don't currently edit anyway. We have like 50k active editors out of 40+ million accounts, so that's 87.5% (I think) of editors do not currently edit. It's just an example of "lies, damned lies, and statistics." Levivich (talk) 00:16, 28 February 2023 (UTC)[reply]
I have to agree with Levivich… the proposal is overkill, and would result in many editors (who are not editing disruptively) being restricted from contributing. I see no evidence that our current restrictions and cautions are not working. Therefor, I must Oppose. Blueboar (talk) 20:16, 27 February 2023 (UTC)[reply]
Yup, overkill. What is actually needed is broader enforcement of Wikipedia policies (e.g. WP:NPOV, WP:RS etc) in BLPs generally, and firmer action against those who use such articles as political battlegrounds. Picking out specific topics to police such content over misses the point - we shouldn't be allowing it to happen anywhere. At some point, I suspect Wikipedia will be obliged to implement restrictions on editing biographies of living persons generally, but until that happens, we should be enforcing existing policy consistently, which this proposal clearly won't do. AndyTheGrump (talk) 01:18, 28 February 2023 (UTC)[reply]
Everything GENSEX-related reminds me of the hand-wringing that occurred around 2007 over intelligent design (which seemed to take over the entire 'pedia), and then a few years later, the hand-wringing that occurred over climate change, a content area brought well under control by the dedication of Femke and Co. The problematic editors make the headlines (ANI), but we have a bevy of very experienced editors holding down the fort. Editing in this area is no better and no worse than in any other areas. Deal with problematic editors as they come up; don't paint the entire topic area with too broad of a brush. No need to freak out because we happened to have two threads at once at ANI. SandyGeorgia (Talk) 01:46, 28 February 2023 (UTC)[reply]
To compare it to BLP's I either need a template or category that marks them as those; unfortunately, I haven't been able to find one. If you know one then I can get those figures for you. For all Wikipedia articles, see this query. It hasn't returned yet, and note that it doesn't cover as long a period of time as the LGBT studies one in order to keep the run time reasonable. BilledMammal (talk) 01:58, 28 February 2023 (UTC)[reply]
Are you still taking requests? Could I interest you in running that for articles that are tagged as specific CT topics, like maybe AP2? I'm curious how other CT topics look. Levivich (talk) 03:17, 28 February 2023 (UTC)[reply]
I don't know a category that would allow me to determine AP2, but I've done:
I've run one for that category, but I wouldn't consider it a reliable baseline because that template isn't used consistently; it is more likely to be included on contentious articles within the topic than less contentious ones, and because of this the results will overestimate how contentious these topics as a whole are. BilledMammal (talk) 05:39, 28 February 2023 (UTC)[reply]
(60% of Pakistan edits reverted??) Thanks for this. If I'm summarizing all of the above correctly:
For all articles on Wikipedia, edits by WP:XC editors (>500 edits) are reverted ~4% of the time, editors between WP:AUTOC and WP:XC (10-500 edits) 14%, non-AUTOC (<10 edits) 38%
For WP:BLPs, that breakdown is XC 4%, AUTOC-XC 15%, non-AUTOC 40%
For (some but not all) WP:CTs, XC 8%, AUTOC-XC 28%, non-AUTOC 59%
For Kashmir, Kurds, Afghanistan, Pakistan, and India, XC 5-9%, AUTOC-XC 23-34%, non-AUTOC 40-57%
For WikiProject LGBT studies, XC 5%, AUTOC-XC 19%, non-AUTOC 38%
Creating a preference for skipping to the top/bottom buttons
Earlier this year, I opened up a discussion at the Idea Lab to create buttons that would automatically skip to the top or bottom of a page if you pressed them. It seemed that it should be made into a preference based on the discussion, and I think that this should now be made into a formal proposal, and that is to create a preference for skipping to the top/bottom buttons. Should this be made into a preference? Helloheart 01:37, 23 February 2023 (UTC)[reply]
@Helloheart we can't just "create a preference". We can make an opt-in gadget, but step one is writing it. Good news: you (or anyone) can start on that now as a userscript. Once it is ready, we can look in to making a test gadget run with it. — xaosfluxTalk01:55, 23 February 2023 (UTC)[reply]
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.
While the Wikimedia Foundation does not offer web hosting services, it does provide free and open source software, including the MediaWiki platform, which powers Wikipedia and many other wikis. Anyone can download and install MediaWiki on their own web server or hosting provider, allowing them to create their own wiki.
Additionally, there are many web hosting companies that specialize in hosting MediaWiki and other wiki software. These hosting providers often offer one-click installs and other tools to make it easy to set up and manage a wiki.
It would be nice if Wikimedia Foundation had a commercial web hosting division that allowed one-way direct wikilinking to Wikipedia's articles. -- Valjean (talk) (PING me) 17:43, 25 February 2023 (UTC)[reply]
isaacl, if I understand you correctly, it sounds like there is already a wikilinking function that works from a private installation of the MediaWiki software. Is that correct?
It's many years since I had my own free website hosted at Yahoo! GeoCities (yes, I'm that old!). I'd like to start one up again, now that I'm retired. That would be an outward-facing effort visible to the public.
I also wonder if it's possible to download the MediaWiki software to one's own PC and just develop content there, then later copy it to one's own website or Wikipedia (if it's compatible with PAG). -- Valjean (talk) (PING me) 19:08, 25 February 2023 (UTC)[reply]
Yes, the same function that allows editors on Wikipedia to use prefixes such as commons:, meta:, and w: (for Wikipedia) is part of the default MediaWiki software, and there is a default interwiki link configuration. Not sure what policy and guidelines you are thinking of? No one can stop you from writing your own web pages, whether or not you are using MediaWiki software. (If you copy text from anywhere or are deriving your work from someone else's, of course, you are subject to copyright considerations and the licenses offered by the sources.) You can see mw:Manual:Installing MediaWiki for information on installing MediaWiki. isaacl (talk) 19:15, 25 February 2023 (UTC)[reply]
When I wrote "or Wikipedia (if it's compatible with PAG)", I was referring to content that would go into any article here. They are of course governed by PAG. Thanks so much for the good info. -- Valjean (talk) (PING me) 20:45, 25 February 2023 (UTC)[reply]
There is no legitimate excuse for the Wikimedia Foundation, a not-for-profit educational corporation, to run such an operation. It has no relationship to the corporation's purpose for existence. --Orange Mike | Talk01:02, 26 February 2023 (UTC)[reply]
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.
Requesting permission to engage in mass-creation
Per MASSCREATION and WP:SEMIAUTOMATED, I request permission to mass-create articles pertaining to villages and municipalities in Turkey, including templates and categories. After creating many articles, was advised to seek permission for such semi-automated creations. Discussion here here. Semsûrî (talk) 17:40, 28 February 2023 (UTC)[reply]
Table of articles created by Semsûrî on villages and municipalities in Turkey, between December 2022 and February 2023 (2010 articles)
It is sort of a chicken/egg scenario. Yes, this will need a BRFA - but the BRFA will want to see that there is community support for the activity. That can occur beforehand (such as here), as part of the BRFA, or separately prior to the BRFA closing. The BRFA will primarily focus on the technical aspects, but will also be looking to see that there is consensus for the activity at all. If this is a completely inappropriate activity for a bot, the proposed operator could just stop now. 18:59, 28 February 2023 (UTC) — xaosfluxTalk18:59, 28 February 2023 (UTC)[reply]
Based on the discussion on their talk page, I don't think they want to use a bot; they're using a boilerplate template to create new articles. Thus discussion at the village pump may be more appropriate. isaacl (talk) 19:04, 28 February 2023 (UTC)[reply]
Gotcha, so unless a bot-flagged account is going to be used to make "likely good" edits that are autopatrolled, etc - no BRFA will be involved. "Mass-creation" is certainly subjective, if it is going to flood recent changes - bot is the way, else may not be needed. — xaosfluxTalk19:15, 28 February 2023 (UTC)[reply]
WP:MASSCREATE says Any large-scale automated or semi-automated content page creation task must be approved at Wikipedia:Bots/Requests for approval. (emphasis added) Maybe we should update that to say that non-bot semi-automated mass creation should be approved at VPR, if BAG doesn't want semi-auto to go to BRFA. Levivich (talk) 20:58, 1 March 2023 (UTC)[reply]
Semsuri, can you expand a little bit about the proposed creations, like how many are you planning to make, based on what sources, and give a few examples of what they look like when done? I assume we're talking about articles like Altınbaşak, Üzümlü and Gökçe, Artuklu, in the same form, using the same sources?
Also, how is this related to your earlier effort to redirect existing village articles, if it's related at all? (I saw the discussion on your talk page.)
I would support either redirecting villages to other articles (that can contain the information about villages), or creating new village stubs (if redirecting is not desirable), I'm just not sure what is the best way, and maybe it's redirecting some and having stand-alone pages for others. Levivich (talk) 19:31, 28 February 2023 (UTC)[reply]
I can give a very specific estimate by counting the number of villages and towns in the provinces that I haven't gotten around to yet (I'm not planning on creating an article for every notable settlement in the country!).
The two primary sources that are recurring in all of the pages are TUIK and e-icisleri - the former gives me info on population history from 2007 to 2022 while the other gives me info on the administrative status of the entity and whether there are hamlets attached to the entity. Ofis, Kızıltepe is an example of an article with the bare minimum. In many cases, however, I have secondary references that allows me to expand the pages to various degrees as seen with these:
The issues with the articles that I redirected last year were plenty including lack of primary references that confirmed their status (some quarters in a town had their own article claiming to be villages), no coordinates, no population, and so on, so I just believed that the easiest thing to do was to redirect them (which was also very cathartic for me). Since then (and having in mind that I had plenty of secondary and reliable references in my library), I believed I could create better articles — even the stubs that I have created are of better quality than the ones we were used to.
My advice… take your time. Go slowly. Do say 5 articles… wait to see if there are any problems… if none, then do 10 and wait… If after a few iterations of this no one is stating a problem, you can ramp up the pace further. Blueboar (talk) 19:36, 28 February 2023 (UTC)[reply]
You didn't say much about the amount of content within the articles. The worst case scenario that is covered by your request would be a zillion content free stubs with just an "it exists" statement with one reference which supports "it exists" I took a look at 2 of your articles and they have a lot more content and sourcing than that. Looking at that and you saying SEMI-automated, you have real articles each with a few sources and a few sections and text covering a few areas and a moderate amount of time invested in each one. . If so, we're talking about a moderate amount of real articles, not a zillion geostubs. If so, perhaps you could describe that in a few sentences and then I think it would receive affirmation / support here. Sincerely North8000 (talk) 20:13, 28 February 2023 (UTC)[reply]
The first three articles on that list have 5+ references and material derived from them, multiple sections and represent at least a moderate investment of time on each one. I support continuation of that (or even articles a bit skimpier) and thank you for your work. Sincerely, North8000 (talk) 21:19, 28 February 2023 (UTC)[reply]
Looking at the table some of these are appropriate, but the majority appear to be the sort of stub that got Lugnuts into trouble (for example, 100. Yıl, Adıyaman). If Semsûrî limits themselves to the more expansive articles that would be fine, but the majority of the articles are not. BilledMammal (talk) 03:28, 1 March 2023 (UTC)[reply]
I believe the Lugnuts problem involved mass-use of unreliable sources (as opposed to here, government sources), and violations of WP:GEOLAND; but the article you link above seems to suffer from neither problem. DFlhb (talk) 03:59, 1 March 2023 (UTC)[reply]
I was referring to the broader Lugnuts problem, that resulted in him being topic banned from creating articles of less than 500 words; the articles listed above are the same sort that resulted in that sanction, and the rate of creation is very similar. I think you are referring to the narrower Lugnuts Turkish village problem, that resulted in him losing autopatrolled and having all the relevant articles deleted. BilledMammal (talk) 04:06, 1 March 2023 (UTC)[reply]
In some ways that is better, but it makes other things worse; when an article consists of little but a table showing population growth by year it introduces WP:NOTDATABASE issues. What is needed is additional prose, giving information on the history, geography, economy, etc of the location. BilledMammal (talk) 09:12, 1 March 2023 (UTC)[reply]
I don't disagree that additional prose would make the article better, but the addition of the population chart does not make anything worse, nor does it introduce "WP:NOTDATABASE issues." That guideline is concerned with "excessive listings of unexplained statistics" that "lack context or explanation can reduce readability" and further suggests that "statistics should be placed in tables to enhance readability, and articles with statistics should include explanatory text providing context." In the case of 100. Yil, the population statistics are not excessive and do not reduce readability. Moreover, they are placed in a table (as the guideline suggests), and the article includes explanatory text explaining that there has been a recent decline in population due to climate issues. This seems to be exactly what NOTDATABASE suggests. Cbl62 (talk) 12:29, 1 March 2023 (UTC)[reply]
The explanatory text providing context and rectifying the WP:NOTDATABASE issues was added after my comment. I would still prefer additional prose and a second source providing WP:SIGCOV, but considering the locations are currently covered by WP:GEOLAND I wouldn't object to Semsûrî's creations if they were all like the current status of 100. Yıl, Adıyaman. For the moment, they aren't, but I understand Semsûrî intends to bring them up to that status; once they do so for the current 2000 I would support the creation of the final 3000. BilledMammal (talk) 13:17, 1 March 2023 (UTC)[reply]
Yes, I've created a database for myself (User:Semsûrî/Turkeyplaces) where I can keep track on my work. There are many articles that are at the same level or more voluminous than 100. Yıl like Kayalık, Çukurca and Anadağ, Derecik but it would be great to have clear criterias so I don't have to guess whether I've reached a sufficient volume at each article. I'm planning on adding the historical population template to all of the articles and moreover expand the prose based on secondary references. Semsûrî (talk) 19:48, 1 March 2023 (UTC)[reply]
@Semsûrî: Thanks for answering all these questions. If I understand correctly, for every article you have created (about 2000 so far) and plan to create (about another 2700), there is at least one secondary source (in addition to the databases TUIK and Icisleri). I understand that creation of the stubs with the database sources can be done semi-automatically (with a template), but expansion of those stubs with the secondary source cannot, that requires manual work, and so will take longer.
Assuming I understand correctly, here is my question: can you create these articles so that when they are created, the secondary source is listed in a "Further reading" section (even if it hasn't yet been worked into the article as a source)? That way, every article created will have at least one secondary source in the Further reading. Is it possible/reasonable to do? Levivich (talk) 20:00, 1 March 2023 (UTC)[reply]
Sometimes a secondary reference is used in multiple articles where I change the prose + page in the citation template. So, at times a secondary reference is included in my boilerplate template. I see the point in adding a 'Further reading-section' if there are none utilized as sources and it shouldn't be an issue. Semsûrî (talk) 20:38, 1 March 2023 (UTC)[reply]
WP:MASSCREATE says all mass-created articles (except those not required to meet WP:GNG) must cite at least one source which would plausibly contribute to GNG, so I think if you are including the secondary source in "Further reading" then that's good enough (even if the source isn't yet cited for prose). That way, anyone looking at the article knows the village has at least one GNG source (the one in Further reading), plus anyone else who wants to expand the article will have at least one source listed they can use to expand it, so I think it would encourage expansion. Levivich (talk) 21:02, 1 March 2023 (UTC)[reply]
Support after the discussion above. It isn't a ridiculous amount (2k created, 2.7k to go, <5k total), it's not like 100k of villages in Turkey. Each article would be supported by at least one non-database source (included at least in Further reading, as I understand it), so it's not like an indiscriminate collection (not like every village in Turkey), and it's not just scraping a database and copy/pasting it to Wikipedia. Because of the secondary source, I think it's reasonable to believe the articles will be expanded (at least there exists one source that can be used for expansion, which is more than we can say about other mass-created articles from other users in the past). I don't think redirects would be a good alternative; I think it would make articles like Üzümlü District unwieldy if we merged every village (e.g. Altınbaşak, Üzümlü) into the district article. I'm generally more inclined to see the value in populated, legally-recognized place stubs than other types of stubs (obscure athletes). Finally, WP:SYSTEMICBIAS encourages me to support; we have articles about every abandoned train stop and dirt road in the US; because Wikipedia is so heavily Western, we don't have as many editors who are going to manually create articles about populated/legally-recognized villages in Turkey, as compared to editors who will write about places in the US, so I'm more inclined to say yeah, let's do some mass-creation of expandable stubs about non-Western notable topics to even out systemic bias. Levivich (talk) 21:18, 1 March 2023 (UTC)[reply]
Conditional Support I would strongly suggest asking a bot coder to include more information upon creation than just population. I would also support the deletion and recreation of ones I started over 10 years ago without much information. It would be much more beneficial for Wikipedia to have near start class articles on these villages than short stubs sitting around which nobody is working on. Much better to do this than redirect to districts as the proposer did in the past. I would oppose a proposal to mass create one or two line stubs like Gökçe, Artuklu. I generally don't like what bots do on Swedish and Cebuano wiki etc but I'm of the opinion that English Wikipedia would benefit massively for a bot to create missing populated settlements which are near start class upon creation and consistent. I did propose something back in 2008 in fact with Fritz. ♦ Dr. Blofeld14:31, 2 March 2023 (UTC)[reply]
I'm of the opinion that English Wikipedia would benefit massively for a bot to create missing populated settlements which are near start class upon creation and consistent In theory I would support this; I suspect it can be done well, and if it is the result would be both the creation of new articles and the improvement of existing articles. BilledMammal (talk) 14:43, 2 March 2023 (UTC)[reply]
In the case of Turkey, I would even include depopulated settlements due to the violent history of the Kurdish region. Kovankaya, Beytüşşebap is unpopulated but still notable enough to have its own article. Semsûrî (talk) 18:33, 2 March 2023 (UTC)[reply]
CONDITIONAL support Conditional on them having the amount of content and sourcing in the first three of the 4 listed examples, or close to it. North8000 (talk) 14:50, 2 March 2023 (UTC)[reply]
Conditional support per North8000. I had many of these watchlisted and up until now, it looks like the vast majority have been based purely on lists and statistics like Saray, Nizip, Kilis, Sason and Kulaksız, Sason. Any further creations would ideally include in-depth secondary sources like Gelinkaya, Midyat, Ayranlı, Şemdinli and Bağlar, Şemdinli. Question for Semsûrî: As someone who doesn't read the language, could you explain the political status of these villages? Are they self-governing municipalities, census tracts or something else? I just want to make sure we don't make the same mistakes as past mass creators. –dlthewave☎00:05, 4 March 2023 (UTC)[reply]
On the village politically, I think Jongerden explains it best:
"The center-village model is best understood against an administrative background. Administration in Turkey is strong in centers, but weak in peripheries. The villages are formally headed by the village-chief (muhtar), who is supposed to implement the law in village affairs and act upon directives of the governor and district officer. In practice, the governor and district officer do not take much notice of village affairs (as long there is no urgent need), and the village headman does not take much notice of the law (so long as he is not forced to), particularly if village custom already provides an accepted alternative method of dealing with a problem". The administrative status of the hamlets, which outnumber villages by almost a third, is unclear. In some occassions the muhtar of a neighboring village has authority over a hamlet, but at other times a formal administration is absent, and administration takes place through customary law.
When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
Should the following biographical microstubs, which were mass-created by Lugnuts and cover non-medalling Olympians who competed between 1896 and 1912, be moved out of article space? 08:15, 2 March 2023 (UTC)
List of microstubs
Article
Initial size
Current size
Growth
Date created
Page views in 2022
# of extant articles created by Lugnuts on same day
Selection criteria: Generated using a Quarry query, these 960 articles meet the following criteria and are a subset of the articles created by Lugnuts:
Athletes who competed in the 1896, 1900, 1904, 1908, or 1912 Olympics
No significant contributions from editors other than Lugnuts[b]
If this proposal is successful: All articles on the list will be draftified, subject to the provisions below:
Draftified articles will be autodeleted after 5 years (instead of the usual 6 months)
Any editor may userfy any draft (which will prevent autodeletion)
Any WikiProject may move a draft to their WikiProject space (which will also prevent autodeletion)
Any draft (whether in draftspace, userspace, or WikiProject space) can be returned to mainspace when it contains sources that plausibly meet WP:GNG[c]
Editors may return drafts to mainspace for the sole purpose of redirecting/merging them to an appropriate article, if they believe that doing so is in the best interest of the encyclopedia[d]
Background
In the 2022 Deletion ArbCom case, ArbCom found (Finding #6) that User:Lugnuts had created over 93,000 articles, "the most articles of any editor ... Most of these were stubs, and relatively few have been expanded to longer articles", which led to sanctions from the community and to Lugnuts being indefinitely sitebanned by Arbcom.
Arbcom also mandated an RfC on mass deletion. A mass creation RfC took place but the mass deletion RfC did not, and the RFC mandate was rescinded, leaving the question of how to handle mass-created microstubs such as these unresolved. This proposal suggests a method for resolving this question, with a group of articles that can be used to test the proposed resolution.
Survey (Olympian draftification)
Support. The alternative to this proposal is bringing hundreds or thousands of articles through AfD each month[e] and that alternative is not practical. These are articles that took minutes, sometimes seconds, to create; each AfD consumes hours of community time and it would be a waste to spend more collective time assessing each of them individually than was spent on their creation. Further, editors who support keeping these articles object on the grounds that the workload is too high; that it is impossible to search for sources with the diligence required in the time available and as a consequence articles on notable topics are deleted.
This proposal resolves both of those issues; editors will have time to search for sources, and considerable amounts of our most limited resource, editor time, will be saved.
We also cannot leave the articles as are; we have a responsibility to curate the encyclopedia, to remove articles that do not belong on it due to failing to meet our notability criteria or due to violating our policies on what Wikipedia is not. Failing to do so is also harmful to the project; it reinforces the perception among the public that Wikipedia is mostly empty around the edges and that anything is notable, and it reinforces the perception among editors that creating large numbers of microstubs that do not inform the reader is as good or better than creating smaller numbers of informative articles.
These are articles that all violate the fifth basic sports notability criteria, on topics that usually lack notability, that no one edits, that almost no one looks at, and that are so bereft of information that they are of no benefit to the reader. Removing the group will improve the quality of the encyclopedia, and by doing it in this manner we provide the best hope of the articles on notable topics being identified, improved, and returned to mainspace. BilledMammal (talk) 08:15, 2 March 2023 (UTC)[reply]
Disagreed on pretty much all points. These articles improve the scope and quality of the encyclopedia, they are often useful for every day users, and have little to no impact on how others view Wikipedia in my opinion. Ortizesp (talk) 05:30, 4 March 2023 (UTC)[reply]
Support I'm generally suspicious of mass action, but this feels like a reasonable first step to solving a difficult situation. For one, it's clear that some kind of cleanup is required, and increasing AfD workload by something like half for literal years simply cannot be the only solution. The proposed extremely extended draftification seems like a suitably conservative approach (to the point that I'm not sure five years is truly required), giving editors plenty of time rescue any articles that warrant rescuing while ensuring that (most of) those which do not warrant retaining are eventually (even if after an extensive wait) removed. The set of articles identified here (or rather, the criteria used to identify it) seems like a very "safe" subset with high accuracy to the point of sacrificing recall.I'm sure that this type of mass action will not be sufficient to solve this situation completely: there will inevitably be literally thousands of articles that will need to be checked by hand and discussed individually. But filtering out some of the "worst" ones out for a start should conserve everyone's energy for the less clear-cut cases.I'd also support an alternative where these would be redirected to "Country at year season Olympics" as suggested by Curbon7 in § Discussion, below. -Ljleppan (talk) 12:34, 2 March 2023 (UTC)[reply]
Articles can't be judged on new standards, as those can always change. Just as someone had 5 years to edit this, people here had years to mark this as a draft or to delete it.KatoKungLee (talk) 01:59, 4 March 2023 (UTC)[reply]
Your response is farcical. You added literally nothing to that article that would get it to pass this project's notability threshold. That is not debatable. Zaathras (talk) 02:40, 4 March 2023 (UTC)[reply]
I prefer draftification as I believe it makes the articles easier to work on but I would support redirection as a second choice, with the requirements to restore the article being the same in regards to sourcing.
As it appears there is some support for this alternative I've created a list of proposed targets to allow it to be properly discussed. Note that some articles have multiple targets; a way to resolve that issue would be required.
I assume the editors in support of this proposal would support this alternative, at least as a second choice, as this proposal already includes that possibility; Rhododendrites, Black Kite, Pawnkingthree, would you support this alternative as your first choice rather than opposing entirely? BilledMammal (talk) 17:29, 2 March 2023 (UTC)[reply]
Support These have not been shown to meet the basic notability requirements of NSPORTS including "A person is presumed to be notable if they have been the subject of significant coverage" and "Sports biographies must include at least one reference to a source providing significant coverage of the subject, excluding database sources." Draftification is the best solution to prevent these mass-created stubs from being any more of a time sink, while giving folks the opportunity to work on any that can be proven notable. I think this RfC format will be the best way forward to deal with these mass creations. –dlthewave☎13:52, 2 March 2023 (UTC)[reply]
Support For the reasons given. IMO the ideal final result would be to have each of these end up as one line in a table in a broader article. This proposal is a good framework handle that possibility if the 5 year thing is doable. If not, then we have 6 months for somebody to take that on. North8000 (talk) 14:13, 2 March 2023 (UTC)[reply]
Oppose - Draftification when the author of the page is blocked is just delayed deletion. Contrary to what BilledMammal says, creating a glut of AfDs is not actually the only alternative. There are three other options: (1) redirect them all to the relevant team/event articles. Articlespace pages for people mentioned in other articles should redirect to those articles anyway, even if the articles are draftified. If redirects are reverted, choose another from this list or send to AfD at that time. Further, for those whose efforts at redirecting have been thwarted, I'd even support a proposal to redirect them all, putting the burden on anyone recreating the article to demonstrate notability. (2) Rather than assume all 960 people are exactly the same, with exactly the same available sourcing, help figure out which are actually notable and improve those. (3) Anything else. There's zero exigency here. I certainly wouldn't say these stubs do anyone any good (and am opposed to the creation of stubs based on databases), but these stubs weren't created illicitly, and they don't harm the project in any way except for the drama that has grown around them. There's no obligation to deal with them. Personally, I prefer #1, but including the others because the threat of "otherwise we'll have to tank AfD" is silliness. — Rhododendritestalk \\ 14:31, 2 March 2023 (UTC)[reply]
Oppose, deleting a thousand pages (which is what this amounts to) for drama-based reasons doesn't build the encyclopedia but seeks to tear out a major part of its Olympic collection. Voices of reason needed please, thanks. Randy Kryn (talk) 15:01, 2 March 2023 (UTC)[reply]
Support redirection, Oppose draftification Even as something of a deletionist, I am somewhat perplexed as to why these need to be draftified. If they're not good enough, why not simply redirect them to the relevant event, event group or Games article? At least that might help someone searching for them. Black Kite (talk)15:18, 2 March 2023 (UTC)[reply]
Support as Lugnuts created so many thousands of Olympian biographies that comprehensively fail WP:SPORTCRIT that it is not realistic to expect that editors can address them all within the next several years using our standard processes (i.e., finding and adding WP:SIGCOV, which if it exists most of it is stored in difficult-to-access, non-English-language archives, identifying appropriate redirects, proposing and nominating for deletion) without completing overwhelming AfD. This moves these biographies out of mainspace for 5 years, so there is sufficient time for interested editors to address them. As the query shows, on a given day, Lugnuts was often creating 50+ of these biographies. I think that Lugnuts' highly unusual article creation justifies the movement of so many of those articles out of mainspace at once. Jogurney (talk) 15:37, 2 March 2023 (UTC)[reply]
Articles should not be judged under rules that didn't exist when they were created. And we know this is happening, because if those rules existed, those articles wouldn't have existed. If someone tomorrow makes a rule that all articles have to mention "jello" or be deleted, we would lose almost all of the site overnight.KatoKungLee (talk) 17:31, 3 March 2023 (UTC)[reply]
Even if that nonsensical approach was used, the rule that all athletes must meet GNG was in place at the time Lugnuts created these articles. JoelleJay (talk) 01:27, 4 March 2023 (UTC)[reply]
That is not true, GNG coverage was always presumed to exist for Olympians but it was never an automatic notability pass. Editors were just more reluctant to challenge Olympians because that presumption was considered strong. JoelleJay (talk) 01:43, 4 March 2023 (UTC)[reply]
Support - When someone copies a database and pastes it into Wikipedia by the thousands, creating tiny stubs on subjects that don't meet WP:GNG or any WP:SNG, and then never touches the articles again, and no one else reads or edits the articles, for years, even over a decade... the articles are not worth keeping in mainspace (WP:NOT). We will never be able to get through these at AFD, there are too many. Some say redirect them all, some say expand them, some say delete... this procedure is flexible and allows editors plenty of time (five more years) to deal with these titles as they see fit (redirect, merge, draft, expand, userfy, WikiProject). It's better than an WP:XCSD, and it's better than leaving them in mainspace, unedited and unviewed, forever. Levivich (talk) 15:44, 2 March 2023 (UTC)[reply]
Oppose (now support redirection) I don't see any reason why every single one of them cannot just be redirected to the relevant Olympic article.-- Pawnkingthree (talk) 15:47, 2 March 2023 (UTC)[reply]
If this proposal passes, they can still all be redirected, by any editor at any time. If this proposal fails, they won't be redirected. So why oppose? Levivich (talk) 15:57, 2 March 2023 (UTC)[reply]
Draftification of a stub is only useful if there's someone immediately available and interested in working on it. Instead of having them sit for five years in draftspace, the title should be in mainspace redirecting to a useful article if a reader searches for it.-- Pawnkingthree (talk) 16:29, 2 March 2023 (UTC)[reply]
I understand your point -- in fact, I agree with it. But right now, we can't turn them into redirects (when editors try, it gets reverted). We can't have 1,000+ discussions about "should this be a redirect". If this proposal passes, then we can redirect these titles. If this proposal doesn't pass, then we're back to the status quo: can't redirect, would need a second RFC just about redirect, which we can't have for a while after this RFC ends (for the usual reasons). So if you believe these should be redirected, I urge you to support this proposal, so that anyone who wants to turn these into redirects can do so for whatever articles on this list they think should be redirected (and of course the articles could still get expanded into real articles by anyone who wants to do so). Proposal Provision #5, about redirects, was written specifically for editors who believe these should be redirects. #5 (redirect) is an option on the menu of this proposal; I don't think it would help improve the encyclopedia to oppose this proposal because #5 isn't the only option on the menu: that would be letting the perfect become the enemy of the good. I'd ask you to consider "support #5 only" rather than opposing. Levivich (talk) 16:46, 2 March 2023 (UTC)[reply]
So if you believe these should be redirected, I urge you to support this proposal - (Here and elsewhere) your argument that redirect is compatible with this proposal is bizarre. By the same logic, it would also be compatible with absolutely any other mass action that's not redirecting, because you can always redirect them afterwards. For anyone who thinks they should be redirected, draftification is just an unnecessary additional step that adds a countdown clock to the redirection process. — Rhododendritestalk \\ 16:51, 2 March 2023 (UTC)[reply]
No because if you go and redirect the articles now, someone will revert you, and then you have to WP:BRD that stuff, meaning 1,000 discussions. If this proposal passes, then someone can redirect these articles, and no one could revert that unless they added a GNG source per #4 and #5 of this proposal. This proposal fundamentally is about getting consensus that these microstubs should not remain as they are, and then allowing a wide variety of options for how to deal with them. IMO no one should be opposing unless they think the stubs are fine to be left alone the way they are (which some people do, reasonable minds can disagree). Levivich (talk) 17:06, 2 March 2023 (UTC)[reply]
Support: When articles ammount to little more than a name, birth date, death date, nationality and a sport they have competed in, they should not be kept as articles. And with 960 of these articles it is unrealistic to keep them in the article space and add more references and information for each in a timley manner, so draftifying these articles is the appropriate action. Terasail[✉️]15:53, 2 March 2023 (UTC)[reply]
This will result in the mass deletion of boatloads of notable articles: As said above, many of these are notable. That being said, what this is basically is just the delayed removal of the majority of them under the nice-sounding tone "you can just move it back if its notable – and everything works out" – if this is approved here's what will happen: all these articles get moved to draftspace, only a couple get worked on (I doubt that there's going to be a ton of eager editors who want to help out in writing articles on 1900/10s Olympians), and then eventually just about all of them get deleted. Additionally the proposer has made it clear he plans on going after the rest if this passes, which will result in not just the initial 1,000, but then the rest of the 90,000 also being put there. We do not have the time, energy or resources to expand 90,000 articles in a short period of time with deletion the consequence if we do not. And I'll bet that BM and his deletionist buddies will go after other sports if they get rid of the Olympians, and then the rest of stubs until this place becomes a perfect deletionist paradise. But back to the consequences of just this being passed: many many notable articles will get deleted in the end, and a few improved. Does that help the encyclopedia? NO.
There is no harm in keeping these. The only harm that could possibly be done would be if this is passed, which will (as said above) result in many notable articles being deleted, and a few improved. That is not an improvement to Wikipedia at all And it would especially not be an improvement if this passes because then it would possibly lead to absolute loads more being proposed to be removed and likely removed. 1,000 short articles provides much more overall value than a few nicer-looking ones in my opinion.
There are other ways in dealing with them. As Rhododendrites said above, there are several different ways that these could be dealt with than mass draftification. The proposers are stressing that "oh its way too hard to have these at AFD" – AFD is not the only option. Of the numerous different ways these could be dealt with, my personal favorite – expand them.
So in conclusion, mass draftifying nearly a thousand Olympians would have a terrible effect on the encyclopedia, and is completely unnecessary. Signed, BeanieFan11 (talk) 16:38, 2 March 2023 (UTC)[reply]
Oppose So, there are several problems with this discussion. First, and only tangentially related to my vote, but still bears mentioning, is the statement "which led to sanctions from the community and to Lugnuts being indefinitely sitebanned by Arbcom. The initial ban was for "Canvassing, incivility, bludgeoning, spamming" (quote taken from the initial ban proposal); it was not the creation of stubs per se that led to the ban. Furthermore, the Arbcom ban does not explicitly state that it was merely for creating the stub articles in the first place. Indeed, the ban was enacted under a variety of problem, including "making personal attacks, engaging in battleground behavior in deletion discussions, and other disruptive deletion behavior." and notes things like "been blocked for conduct at AfD" (both quotes from the ArbCom page). The OP makes the disingenuous post hoc ergo propter hoc assertion that they were banned because they created the above article stubs. They were banned for things like being disruptive to the AFD process and battleground behavior, making personal attacks. All of that is sanctionable offenses. Creating stub articles is not. I can go create a stub article right now and no one would be proposing to ban me. So the very premise that the ban was enacted merely because some stubs were created is a non-starter for me. That being said, what do we do with all of these stubs? Nothing at all. If the article meets the standards to be an allowable stub article if it hadn't been created by Lugnuts, like if it was just a stub created by someone else, then there's no reason to do anything special to it because it was created by Lugnuts. They're perfectly fine in the mainspace. If you find one of the stubs you want to expand, do so. If you find one of the stubs should be deleted, WP:AFD is thataway. If you don't want to do either of those things, doing nothing is perfectly fine too. Even if the OP's initial statement wasn't fraught with the errors I already noted, I would still oppose treating these stubs any differently than any other random stub someone might happen to trip over. --Jayron3216:55, 2 March 2023 (UTC)[reply]
Preliminary question. I am open to a proposal to delete many of the early Olympic participants, but this appears a proposal to delete hundreds of articles without even providing a list of the articles to be deleted. Maybe I'm wrong. Is there a list of the proposed deletions? Before casting a vote, I would like to see a list and have an opportunity to peruse it. Cbl62 (talk) 16:57, 2 March 2023 (UTC)[reply]
Support either this or mass redirecting. Pre-WW1 Olympians are usually not notable, and so most of these can never become full articles. —Kusma (talk) 17:28, 2 March 2023 (UTC)[reply]
Also, I propose removing from the list those who competed in the Olympics after 1912 – this is supposed to be from 1896 to 1912, not after as well. BeanieFan11 (talk) 17:30, 2 March 2023 (UTC)[reply]
Support, and I would add that we need to review more than 960 articles at a time; at such a low rate, cleaning up after Lugnuts will take about 8 years.—S MarshallT/C18:05, 2 March 2023 (UTC)[reply]
Oppose. Per Wikipedia's deletion policy, draftification must not be used as a "backdoor to deletion". Because abandoned drafts are deleted after six months, moving articles to draft space should generally be done only for newly created articles... or as the result of a deletion discussion.[1] Older articles should not be draftified without an AfD consensus, with 90 days a rule of thumb.[2] This proposal is an extremely clear attempt to mass draftify articles as a backdoor to deletion. The nominator writes that the alternative is not practical but there is another alternative not considered in the OP's arguments—using the articles for deletion process to make decisions with respect to a single mass AfD of these sorts of things. Also, WP:DRAFTOBJECT is pretty clear that literally anyone can object to the draftification of a particular article and revert it to the mainspace, so I'm not sure that this would actually achieve the resolution that the proposer of this RfC desires (all it would take is a few editors to restore one article to mainspace per day over the next six months for this mass draftification to end up back where we started, and that seems to just be delaying sending these to AfD). — Red-tailed hawk(nest)18:10, 2 March 2023 (UTC)[reply]
By extending the autodeletion period to five years the specifics of this proposal are intended to prevent this being a backdoor to deletion, and the various options around article adoption and article redirection are also intended to prevent that. It will also prevent improper restorations; if there is a consensus for this proposal editors will only be permitted to restore these articles to mainspace after adding sources containing significant coverage. BilledMammal (talk) 18:23, 2 March 2023 (UTC)[reply]
Will this apply to all draftified articles, or just to the 960? My understanding is that we have an adminbot delete old drafts if they are more than 6 months untouched. — Red-tailed hawk(nest)19:53, 2 March 2023 (UTC)[reply]
Only to the 960. The specifics of this need to be determined, but there are plenty of options and the required bot modifications will be minor. BilledMammal (talk) 00:41, 3 March 2023 (UTC)[reply]
Support. The proposal is unprecedented, and I am generally opposed to mass actions of this type. Despite my reservations, I do support this proposal limited to early Olympians. My rationale is as follows:
No reasonable expectation of notability. The past year of dozens and dozens AfD discussions has clearly demonstrated that mere participation in the Olympics in the early years of the games is in no way a basis to presume or expect that the individual is notable under our WP:GNG standard.
Mass creation. The articles at issue were the product of a well-documented mass process in which thousands of articles were created at the rate of approximately a minute per article.
Lack of substance. The articles are microstubs that contain limited narrative text simply reciting that the person was an athlete in a particular sport who competed in the Olympics X year. If the articles are ultimately deleted, nothing of real substance is lost. If SIGCOV is later uncovered and brought forth, and given the fact that only a minute or so was devoted to the original effort, the articles can be re-created without any meaningful loss of prior effort.
Violation of SPORTBASIC. The articles violate prong 5 of WP:SPORTBASIC which provides: "Sports biographies must include at least one reference to a source providing significant coverage of the subject, excluding database sources." The articles here are sourced only to database sources and do not include SIGCOV.
In sum, I support draftification in this narrow situation. In less clear circumstances, I would expect normal AfD or redirect procedures to be followed and would likely oppose such a proposal. Cbl62 (talk) 18:13, 2 March 2023 (UTC)[reply]
Strong Oppose This is a backdoor attempt at deletion of articles via the Village Pump, and as such is an obvious violation of deletion policy. Take them to AFD if you want them deleted or demoted to drafts. Steven Walling • talk19:59, 2 March 2023 (UTC)[reply]
Lugnuts is Wikipedia's most prolific article starter, ever. He started rather more than 90,000 articles, most of which were biographies, and he's told us he put deliberate inaccuracies in them. If we nominated 10 of them at AfD every day, it would take nearly thirty years to process them all. I'm afraid that it's simply unfeasible and unrealistic to use AfD to clean up after Lugnuts. It would also be profoundly unfair on other editors to swamp our normal deletion processes with the quantities of articles involved.—S MarshallT/C23:36, 2 March 2023 (UTC)[reply]
Nominating a group of articles like hoaxes is explicitly called out as allowed in our deletion policy, per WP:BUNDLE. In addition to this being the wrong venue, the stated intent of the proposal is to test the waters for establishing a precedent for mass deletion, which is bad faith and not clearly about removing demonstrably bad articles that violate notability or verifiability policy. Steven Walling • talk04:59, 3 March 2023 (UTC)[reply]
Of course it's proven. Lugnuts claims he introduced deliberate inaccuracies into his stubs in this edit. Some don't believe him on that point, because he was ragequitting Wikipedia when he wrote that. Others might suspect that someone who often started upwards of 20 articles a day wasn't checking his facts carefully in the first place. Whichever side you take, it's my view that we have reasonable grounds to doubt the accuracy of this content.—S MarshallT/C11:02, 3 March 2023 (UTC)[reply]
Deleting 960 articles on the chance that there might be inaccuracies is a bit of a stretch. There might be inaccuracies in basically everything that isn't a GA or FA article, but there is no deadline for fixing work in progress, and perfection isn't required. These aren't BLPs, either. Steven Walling • talk23:44, 3 March 2023 (UTC)[reply]
When the article author admits they've put deliberate inaccuracies and obfuscated copyvios in biographical articles, I'd normally expect a more active response than this from a sysop. I do hope you'll reconsider your position here.—S MarshallT/C23:55, 3 March 2023 (UTC)[reply]
Like you said, he was ragequitting. I wouldn't be surprised if he said that in order to make people delete all his articles as a "f*ck you" to the project. Steven Walling • talk01:04, 4 March 2023 (UTC)[reply]
Either way, the argument that we should mass delete a series of articles via a straw poll at the Village Pump is utter nonsense. These articles met notability requirements when they were created and many, if not most, of them probably still do. There's no way of knowing, when you nominate 960 at once based on a hunch, rather than an actual review of the articles and research into all the possible source material. Steven Walling • talk05:37, 4 March 2023 (UTC)[reply]
Have we gotten any proof aside from Lugnuts statements, that he has introduced deliberate inaccuracies? It's better to have no articles rather than a faulty article. ✠ SunDawn ✠(contact)03:42, 4 March 2023 (UTC)[reply]
@SunDawn: Plenty of inaccuracies have been found; whether or not they are deliberate is impossible to say for certain. One example has already been given in this thread by CMD. I just checked another random article myself; literally the first one I clicked on, Fyodor Zabelin, has the wrong birth date in the infobox. Since Lugnuts specifically mentioned birth dates in his claim that he had introduced deliberate errors, one might wonder whether this gives some ground for believing him. Sojourner in the earth (talk) 05:36, 4 March 2023 (UTC)[reply]
Strong oppose as Village Pump is not the place to mass delete articles, as is effectively beimg proposed here. No need for a mass decision on all of these articles, they should be checked according to relevant AFD policies individually as some will definitely be notable. Speedy redirecting should be used when there is clearly no notability. This range of dates is also completely arbitrary, with no justification for why the specific dates were chosen and why these people's notability should be assessed differently to Olympians of different years. Joseph2302 (talk) 20:12, 2 March 2023 (UTC)[reply]
Strong Oppose unless there is a guarantee that the sources already in each article have been examined and any even marginally close calls removed. For example, I would have concerns about the inclusion of Alf Davies (swimmer) on this link - the sources suggest that there's a decent chance that there's more there in newspapers and so on. This isn't the first time lists like this have been put forward - I think we found a knight of the realm on one list... At that point I would still oppose in favour of redirecting where even remotely possible per WP:ATD (which is a policy not a guidelines) - draftifying like this is an utter waste of resources for everyone concerned, whereas a redirect preserves the page history and attribution and enables an article to be returned to if sources emerge and someone has the time and motivation to do so. Finding those initial sources, especially when some are archived, isn't as simple as some of the views here might suggest. We have alternatives to deletion; these are flat out more efficient and we should use them. Blue Square Thing (talk) 20:16, 2 March 2023 (UTC)[reply]
Support. I made a similar proposal at one of the many RfCs this past year, so of course I support this. I don't understand the "backdoor to deletion" hand-wringing or complaints about the possibility of inclusion of maybe notable athletes in this list. If there are people in there who you think might meet GNG, guess what!! You can personally take them out of draft space and work on them in your user space, thereby avoiding the extremely overly-lenient 5-year deadline. Or you could redirect them. Or put them in project space. These are all better for people who want to keep articles than leaving them in mainspace where they will likely be athlete #22 taken to AfD on any given day and you'll only have a week to find all those difficult-to-access sources that surely exist. JoelleJay (talk) 22:25, 2 March 2023 (UTC)[reply]
Support, the proposal is for a very targeted list, and the way these articles have been generated seems problematic. The first one I clicked on was Alexander Martin (Canadian sport shooter). That article, in its entirety: "Alexander Martin (28 December 1864 – 26 October 1951) was a Canadian sports shooter. He competed in the 1000 yard free rifle event at the 1908 Summer Olympics." I checked the Olympedia source and was immediately struck by "Born: Glasgow, Died: Woking". These are clearly not Canadian locations. Olympedia also lists two family member Olympians, both of whom apparently competed for the GBR NOC. So while Alexander Martin may have competed for the Canada NOC, there seems a lot of evidence that describing them as primarily Canadian is a mistake. If somehow the first article I clicked on was the only problematic one, then I suppose I'd have to revise, but that seems unlikely. I would strongly support mass redirection to the relevant Olympic page (if available), and of course would also support people expanding these where possible to be useful and accurate. Both these actions are possible with or without the passing of this proposal though, so I don't understand how they are coming up as oppose rationales. CMD (talk) 00:05, 3 March 2023 (UTC)[reply]
Oppose I find no reason to delete them. There could be a reader looking for information on the topic; we are an encyclopedia; why do we feel the need to delete information? I this context, I think the stub-quality of the articles is irrelevant. Perhaps the content would be better served as part of a larger article, but I wouldn't know where to begin. Further, it would be a fallacy to assume that an "oppose" vote would necessarily lead to mass AfDs — it is a false assumption that the articles involved need to be deleted at all. JuxtaposedJacob (talk) 01:48, 3 March 2023 (UTC)[reply]
WP:NOTEVERYTHING and WP:N; just because there is verifiable information on a topic doesn't mean it belongs in Wikipedia. These are also why failing to deal with these articles through a process other than AfD will lead to mass AfD's; leaving non-notable topics in mainspace makes Wikipedia worse, and it is against policy to do so. BilledMammal (talk) 02:08, 3 March 2023 (UTC)[reply]
Support If someone spends a few seconds doing something mildly disruptive, we should have no qualms about undoing that thing. If anyone wants to create a well-sourced article on one of these individuals, these stubs will be of no help at all. The community has found Lugnuts' mass creations to be disruptive, why immortalize his inappropriate creations? In fact, I'd support deleting all of them that haven't attracted major content contributions from others. No prejudice towards decent articles on the same topics being re-created in the future. Ajpolino (talk) 04:30, 3 March 2023 (UTC)[reply]
Support Although they should really be deleted after the normal 6-month period. Also rather disappointing to see the same cheerleaders from the non-notable NFL player debate weighting this discussion down. Zaathras (talk) 04:45, 3 March 2023 (UTC)[reply]
Support draftification as first choice. Aside from the problem of notability, many of Lugnuts' articles have been shown to have serious verifiability issues (almost inevitable with articles created at speed). If it's true that Lugnuts has admitted to introducing deliberate inaccuracies (@S Marshall: do you have a diff for that?), that's all the more reason to remove these articles from the mainspace as soon as possible. I came into this expecting to support redirection over draftification, but I've explained below why I don't think this is practical. Sojourner in the earth (talk) 08:50, 3 March 2023 (UTC)[reply]
Strong Support - And yes this should be rolled out to Lugnut's 19th-century cricketer articles, his 19th/early 20th century footballer articles, and to sub-sets of the mass-created articles of other historical mass creators (e.g., Carlossuarez46, Dr. Blofeld). WP:PROVEIT is pretty clear on what happens to content the notability of which isn't supported - either the people who want it kept find support for it, or it gets deleted. Any other position is allowing editors to establish a fait accompli of mass-created articles that will never be improved to meet notability standards, and most of which cannot be improved. WP:FAIT is clear that we should not allow that.
This cannot be handled one-by-one by the normal AFD process as it would jam it permanently. Mass deletion through AFD is possible but this discussion is frankly just as valid as any AFD discussion and probably will engage with more editors which, frankly, is needed, as AFD discussions are often dominated by people heavily invested in the deletion/keeping of article-sets such as this one.
Some argue that the fact that some of these articles may be notable is a reason to keep all of them. It simply isn't. What that is is a reason for people who want them kept to go and establish the notability of those articles and bring them back to mainspace. Anything else is accepting a WP:FAIT situation.
Finally, this is not personal. I would also support the same measure be used against other articles sets that were created in violation of WP:MASSCREATE, even by editors I generally like. FOARP (talk) 09:21, 3 March 2023 (UTC)[reply]
Support per nom, 5 years is ample time for any interested editor to expand on any of the articles. Redirect to the relevant pages would also be fine in my opinion. BogLogs (talk) 09:26, 3 March 2023 (UTC)[reply]
Oppose as the solution to the problem is needlessly complicated. Seems to me that the simple(st) solution is to delete all relevant stubs created in this way immediately. WP editors who are interested in writing about any Olympian who is truly notable could presumably get the same starting information from the same sources that the current stubs used, so there's nothing to be gained by draftifying. JMWt (talk) 10:26, 3 March 2023 (UTC)[reply]
@BilledMammal: well I don't know. Firstly I don't know how automated the process would be or whether it would need considerable manual editing time. Second it seems to me that there is quite a high risk of good-faith errors creeping in when trying to do this with so many pages (for example an Olympian being accidentally attached to the wrong team). This in turn could lead to even more circular referencing and the errors being repeated in off-wiki sources. For me the most accurate solution is delete. The databases still exist, there's no presumption that any of the Olympians in these stubs are not notable - so recreation if RS become available for particular people shouldn't be an issue. I accept that it looks like a sledgehammer solution, but for me the main overwhelming issue is the integrity of WP as a usable encyclopedia. If we routinely do anything which adds to the risks of spreading errors, that's bad. I'd rather keep the stubs that simply reflect the content of off-wiki databases than do anything else that introduces errors. JMWt (talk) 13:53, 3 March 2023 (UTC)[reply]
@JMWt: It would be easy to automate, and no new errors would be introduced; it might continue to include existing errors, but in that case we are no worse off than we currently are. BilledMammal (talk) 14:03, 3 March 2023 (UTC)[reply]
Oppose. per BeanieFan, my comments at the previous discussion about olympian stubs and most of the other opposers here. The way to deal with a mass creation of notable topics is not mass deletion or mass draftification - there is no deadline, and it is much better to get the right answer slowly than the wrong answer quickly. Thryduulf (talk) 10:47, 3 March 2023 (UTC)[reply]
This assumes we have a good interim position right now, which given the lack of attention that seems to have been paid to these articles I am not convinced of. There's no deadline by which redlinks have to be turned into tenuous blue links either. CMD (talk) 14:56, 3 March 2023 (UTC)[reply]
The past is prologue... There's not anything we can do about the fact that they have already been created, but as Thryduulf notes, now that they exist, we might as well deal with each thoughtfully. You are correct as the best action was probably not to have created these so rapidly, but we can't go back in time and make that unhappen. --Jayron3219:20, 3 March 2023 (UTC)[reply]
Comment in addition to my note above and discussion below in the redirect section, there seem to be quite a few of these which have a reasonable claim to notability. We really need to read the sources and not rely on a machine query. Philip Plater, for example, seems well worth looking in to and if we delete this via drafting it'd be a massive mistake. A number of the British ones seem to have details that would be worth looking in to. Blue Square Thing (talk) 14:39, 3 March 2023 (UTC)[reply]
The Olympedia source, when you look at it, does in a way suggest that GNG coverage exists – I've found that when they give decent bios, the Olympians usually have a much higher GNG rate than when they don't. BeanieFan11 (talk) 15:01, 3 March 2023 (UTC)[reply]
I would agree! Maybe someday someone will be able to look into such cases and write some articles with more than a database pull, that could do basic things like not make slightly misleading nationality claims and include links to the events the athletes participated in. As noted above, there is no deadline for this. CMD (talk) 15:11, 3 March 2023 (UTC)[reply]
Perhaps this was missed, but we should have articles "that could do basic things like not make slightly misleading nationality claims and include links to the events the athletes participated in". CMD (talk) 15:51, 3 March 2023 (UTC)[reply]
The articles do link the events that the athletes participated in – and I haven't seen very many with the wrong nationality – just about all of them seem fine to me. BeanieFan11 (talk) 16:03, 3 March 2023 (UTC)[reply]
No they don't, Philip Plater which you linked just before didn't until I made the relevant edit. As for "very many", maybe not very many, but how many? We don't know, because these are procedurally generated sentence pairs. CMD (talk) 16:18, 3 March 2023 (UTC)[reply]
Lets see, I'm going to pick ten random people on this list and see if they have the link or not: Francesco Pietrasanta, no; Arthur Maranda, yes; Arthur Seward, yes; James Cowan (sport shooter), no; John McKenzie (wrestler), yes; Orazio Santelli, no; Yrjö Vuolio, yes; Jules Roffe, yes; Pierre Saintongey, yes; and Ödön Toldi, yes. That's 7/10 have it. And even if they were missing it, that's still no reason to mass get rid of them by the thousands. As for the nationality, to check, you can just click on the Olympedia link and it will tell you – I have only seen a handful with any issue, and in most of those cases it was half-right, i.e. they were born in e.g. Switzerland, and then became U.S. citizens and competed for the U.S., and the article referred to them as American. BeanieFan11 (talk) 16:34, 3 March 2023 (UTC)[reply]
It says he "competed at three events at the 1912 Olympics" and links "Athletics at the 1912 Summer Olympics" in the words "three events." BeanieFan11 (talk) 16:54, 3 March 2023 (UTC)[reply]
I agree, Blue Squared Thing, many of these are likely notable. I've checked a bunch and for some I've seen Olympedia bios describing them as having been the best of the era, among the most famous, etc. For example, when I chose a random one in Lou Scholes and did a quick search, I found articles describing him as "the best oarsman the world has ever produced" (not surprising, though, considering this is the Olympics). And then for Albert Bechestobill, I was able to locate full-page long articles in major newspapers. When I looked for Arthur Burn, he was given headlines for his life and death. And another one I think would probably have good potential: Carlo Bonfanti – Olympedia mentions how the way Italy viewed diving was changed all because of him – there has got to be coverage on figures like that. And many Olympedia references have enough coverage that I'd consider them a SIGCOV source all by itself. BeanieFan11 (talk) 15:14, 3 March 2023 (UTC)[reply]
It was a really, really, really bad idea to mass create these articles without any effort made to see whether they are notable. This proposal is what is required to correct that error. BilledMammal (talk) 17:31, 3 March 2023 (UTC)[reply]
When these articles were created, they were considered notable. Later modifications to the notability guidelines removed their automatic notability (but many are still notable). BeanieFan11 (talk) 17:34, 3 March 2023 (UTC)[reply]
They were presumed notable (under some interpretations of WP:NSPORT), and it was a really, really, really bad idea to mass create these articles without any effort to see whether they are are notable and thus ensure that this presumption was correct. BilledMammal (talk) 17:43, 3 March 2023 (UTC)[reply]
Another interesting one: George Retzer. He lived to be 96 and was still regularly working out into his mid-90s (50 situps, 50 pushups every day, wow), and received UPI and LA Times feature stories for it, in addition to having more coverage for being the Pacific Coast wrestling champ. Clearly notable. Just like many others here. Mass throwing them out without any attempt to see if they're notable is an absolutely horrendous idea. BeanieFan11 (talk) 23:17, 3 March 2023 (UTC)[reply]
Yet another that seems highly likely to be notable: Iraklis Sakellaropoulos - the Greek wiki has a much more detailed article on him, he competed at three olympics, was a champion runner in Greek in the 1910s and 20s, and there seems to be a bunch of mentions of him online and in books using his name in Greek (unfortunately I do not speak Greek, so can't tell if its sigcov - but even if those aren't, I'm 99.999% sure the newspapers of the day would have covered him). BeanieFan11 (talk) 00:47, 4 March 2023 (UTC)[reply]
Oppose - This has nothing to do with articles and is just a continued harassment campaign against Lugnuts. How can you possibly judge Article A based on Article B and Article C? These articles and the people who they are written about have nothing to do with each other. Why would they ever be judged together? And this idea of an article not only having to pass current rules but also needing to pass future rules that didn't even exist is horrifying. This is not in good faith and this goes against everything this website should be. I'm absolutely disgusted by this.KatoKungLee (talk) 16:13, 3 March 2023 (UTC)[reply]
Strongest possible oppose tremendous waste of time and resources, and as I've reiterated times, there's nothing wrong with stubs. Many of these could be fleshed out and pass GNG, and many of these are useful to users. If you want to merge them to a list one by one, I wouldn't necessarily be opposed.--Ortizesp (talk) 05:28, 4 March 2023 (UTC)[reply]
The good news on the merge front is they all appear to have been included in relevant lists since 2006 to 2007. CMD (talk) 08:36, 4 March 2023 (UTC)[reply]
Support either draftification or redirection per BilledMammal. These articles can always be recreated if anyone can find sources showing their notability. (t · c) buidhe05:43, 4 March 2023 (UTC)[reply]
Oppose. The only thing the subjects of these articles have in common are 1) they competed in the Olympics during a certain time frame 2) they were created by a certain editor. If you believe that mere documentation that someone competed in the Olympics is not sufficient to confer notability, then neither of the things these articles have in common have any bearing on the article subject's notability. That means the responsible thing to do would be to go through and determine notability for each article on an individual basis. Dealing with them in bulk is inappropriate, and would make it inevitable that some babies will be disposed of with the bathwater. —Scott5114↗[EXACT CHANGE ONLY]06:21, 4 March 2023 (UTC)[reply]
@Scott5114: The contents of the bathwater aren't being thrown out here; they will still be available, whether in the form of a draft or a redirect.
In addition, one of the issues with dealing with them individually is that it will overload AfD. Do you, and other editors opposing this proposal on that basis, have no objection to 25, 50, or 100 of Lugnut's articles being taken through AfD each day (a process that will take between 5, 2.5, or 1.25 years, respectively, if we conservatively assume that only half of Lugnuts articles have notability issues)? BilledMammal (talk) 06:38, 4 March 2023 (UTC)[reply]
Putting them in draft space makes it less likely that anyone will ever actually improve them. I haven't the foggiest idea what's in draft space right now. And when I am using the site as a user, if I come across a redlink and think "gee, I expected Wikipedia to have an article on this," my first inclination isn't to check draft space to see if there's something that just needs to spruced up a bit. I would be very surprised if that is actually part of anyone's workflow.
If it is a long and painful process to put them through AFD then so be it; that is the pain that the nominators choose to endure themselves, and inflict on others in the process. Presumably should they choose to do so, it's because they've examined an individual article and found that it is in fact not notable, and can prove that at AFD. Circumventing the process simply because it will take more effort than some people care to do is simply cheaping out. —Scott5114↗[EXACT CHANGE ONLY]11:31, 4 March 2023 (UTC)[reply]
Most of the proponents of dealing with these articles individually also oppose sending them en masse to AfD, since the seven-day deadline gives too little time to find sources. This is a proposal to extend that deadline by 4 years and 358 days. Those who wish to examine these articles one-by-one will have plenty of time to do so. I'd also note that all the articles covered by the proposal are extremely scanty; even if they were deleted, any one of them could be recreated with better sources in a matter of minutes. Sojourner in the earth (talk) 11:52, 4 March 2023 (UTC)[reply]
Presumably should they choose to do so, it's because they've examined an individual article and found that it is in fact not notable, and can prove that at AFD. They would be able to prove that the individual article doesn't demonstrate notability; there is no consensus that they are required to do more than this when nominating mass created articles. BilledMammal (talk) 12:05, 4 March 2023 (UTC)[reply]
Oppose. Draftspace is an invisible graveyard. It wouldn't matter if the auto-delete period was set to 50 years; approximately nobody beyond the original author ever stumbles upon a draft. Articles get improved by attracting editors, and editors get attracted as a consequence of visibility, which drafts simply do not enjoy. Therefore the practical eventual outcome of draftification would be deletion.
However, I also do not support deletion. Several editors have proposed redirection instead, and I agree that this would be better. Regardless of the possibility of (potentially deliberate) errors within the articles, I don't think anyone is doubting that these people existed and had a verifiable association with a particular event - therefore it should be possible to identify an appropriate redirection target.
Support as deliberate errors had been introduced, per the evidence by Chipmunkdavis. There is no time to check it all, and it is better to have no articles than hundreds of faulty articles. I would agree that draftification would be a better option, but there is no way we should have thousands of articles that have deliberate errors on them. ✠ SunDawn ✠(contact)12:55, 4 March 2023 (UTC)[reply]
Support, with a preference for redirection over draftification. Either way, the article histories will be preserved, and can be used if someone can find reliable sources that establish notability. (IMO, notability is a necessary, but not a sufficient, condition for an article, i.e., just because a subject is notable does not mean that Wikipedia has to have an article about the subject.) - Donald Albury15:10, 4 March 2023 (UTC)[reply]
Support, many of these articles could be improved to pass notability, but they should not be in mainspace until this has been done. However, to increase the chances of editors improving them I suggest adding a note about drafts to the tasks/to-do lists of the relevant wikiprojects (olympics/fencing/swimming…) with a link to the "other" section in their article assessment page. EdwardUK (talk) 15:49, 4 March 2023 (UTC)[reply]
Comment I think the better WP:ATD is to simply redirect them to "Country at year season Olympics", as mass-draftification has been routinely rejected as being against the purpose of WP:DRAFTIFY, which clearly states that the process is not intended as a backdoor route to deletion. Curbon7 (talk) 08:32, 2 March 2023 (UTC)[reply]
Such redirects are often reverted. This specifics of this proposal are also intended to ensure that it is not being used as a backdoor route to deletion, by extending the auto-deletion period to five years, and by allowing the articles to be returned to mainspace without improvement for the purpose of redirecting them. BilledMammal (talk) 08:39, 2 March 2023 (UTC)[reply]
That discussion seems to relate to American football players, which is a topic-area with very fervent advocates. As far as I'm aware, no one is disputing the illegitimacy of Lugnuts Olympian sub-stubs. Thank you for the correction of the 5 years, I had missed that point. Curbon7 (talk) 08:45, 2 March 2023 (UTC)[reply]
It should be, there must be a bug with the query. I'll resolve it and remove any articles that don't meet the criteria from the list; thank you for bringing it to my attention. BilledMammal (talk) 09:09, 2 March 2023 (UTC)[reply]
There were two issues; the query was excluding articles with contributions <-200 bytes, and including those with >200 bytes, and the query was not considering edits made immediately before an edit by Lugnuts. I've fixed both; for the first, I've decided to continuing excluding contributions <-200 bytes rather than adding articles to the list after the RfC has been opened.
Thanks, I think I found that one at the same time, on Adolf Davids. I've fixed it now; the issue there was that it wasn't properly including edits with a change tag other than reverts or undo; that diff was tagged with 616, or wikieditor. This has reduced the number of articles listed to 960. BilledMammal (talk) 11:25, 2 March 2023 (UTC)[reply]
The delete after 5 years seems like it might be annoying to do (since the drafts would have to excluded from any bots and automation that assumes drafts are G13 after 6 months), and I don't know if it's necessary unless some editors argue that there's something to be saved. Galobtter (pingó mió) 09:29, 2 March 2023 (UTC)[reply]
The other issue with the 5 year rule as currently written is what should an admin do if a human updates one of these pages 4 years 9 months after draftification but hasn't moved it in to mainspace yet? We can solve this problem by clarifying that this 5 year timer is a one time extension of WP:G13's 6 month timer and human edits after 4 years 6 months extend the timer in the normal manner. This also lets admins simply delete using WP:G13 (instead of having to cite this RFC) once the 5 year clock runs out. Iffy★Chat -- 14:47, 2 March 2023 (UTC)[reply]
My thought is that doing this subversion of G13 might be trying to square peg the round hole. Would it be worth creating a psuedo-namespace for this, similar to UBXspace? casualdejekyll16:29, 2 March 2023 (UTC)[reply]
Objections to a separate proposal to go along with it, asking if we should mass redirect these articles? Does anyone actually object to redirecting them all (i.e. would only be satisfied if the articles were deleted)? — Rhododendritestalk \\ 16:53, 2 March 2023 (UTC)[reply]
I object to any proposal that has the concept of "them all". If you find that one of them is best dealt with by redirecting it, do that. Some may be best handled by expanding them (or leaving them for someone else with more interest in doing so to expand). Some of them may be best handled by deleting the article outright. Let PROD or AFD handle that. Some of them may be best handled via a redirect. Wikipedia has millions of stub articles. The handwringing over these is primarily about the personality that created them, not about the quality or potential of each one assessed on its own. Yes, these thousands of stubs are a lot, but far less than 1% of all stubs we have at Wikipedia, and proportionally are not that big of a deal. We don't have to do anything with the full set of them, other than approach each one as though it were any other stub we came across. --Jayron3217:01, 2 March 2023 (UTC)[reply]
Reframing my meaning: is there anyone who supports draftification who would object to them being mass redirected? There are clearly at least a few who oppose draftification but would support redirecting. I don't doubt there are still some who would oppose either one, but redirecting seems obviously preferable to draftification. All of the arguments about redirection above assume "someone will revert". Well, if the proposal is to redirect, that becomes moot. — Rhododendritestalk \\ 17:17, 2 March 2023 (UTC)[reply]
Well, I for one wouldn't object, but I think it saves a whole lot more time to say, in this RFC, "Support #5 only", and see if that carries the day. Levivich (talk) 17:23, 2 March 2023 (UTC)[reply]
So, while I certainly don't fit in the camp you're targeting, I am going to push back on a couple of things. Each proposed alternative to deletion has its own unique problems, and none of them really satisfy all possible issues. Some people may support draftification because it preserves, in the currently viewable state, the article itself in a way that allows for people to more easily expand it. Redirection makes the initial text harder to recover. I mean, only a little if one is an experienced Wikipedia editor, but undoing a redirect and turning it back into an article does involve some rather arcane moves (available to any editor, but tricky nonetheless) that draftification does not. For many purposes, redirecting is tantamount to deletion and salting. Indeed, even deleting and leaving redlinks behind is a better solution, as a redlink at least says "here's an article that you might want to create if you can get the sources together" whereas a redirect basically says "Don't even bother". --Jayron3217:26, 2 March 2023 (UTC)[reply]
undoing a redirect and turning it back into an article does involve some rather arcane moves (and BilledMammal's I believe it makes the articles easier to work on) - When was the last time either of you saw a newbie find a draft and improve it? Apart from the drafts that get outside attention (high-profile controversial article, canvassing, etc.), I'm not so sure I've ever seen it happen. Not in browsing on-wiki; not the new users I've worked with off-wiki. It's part of the failure of draftspace (or rather, why it failed as a collaborative space and turned into a trap for bad content): on the chance that someone goes to create a new article at the exact page name of the draft, nobody sees the notice that there's a draft, and the processes to discover drafts apart from seeing that notice are far more arcane. Way back in the early days of draftspace, I loved the idea and created a few thinking it would spark collaboration, but nobody ever edited them; to the contrary, people (experienced users, not newbies) just went ahead and started the article anew. With extremely rare exceptions, people don't discover and improve drafts. I agree it's also unlikely that someone will look in the history of an article to see the material, but it's not less likely. And really, if we're being honest, what is the value of what's there in the first place? There are two reasons I'm opposing the proposal above, and neither is because Lugnuts created a treasure trove of quality material for the ages: one is it's frustrating to see deletion-via-draftification, even with a 5-year countdown. It just doesn't do anything other than delete with a veneer of preservation. The other is the article titles should redirect, so why not keep the piddly bit of content that's there per WP:PRESERVE yada yada. — Rhododendritestalk \\ 17:57, 2 March 2023 (UTC)[reply]
When was the last time either of you saw a newbie find a draft and improve it? MY POINT EXACTLY. We shouldn't do anything with these stubs outside of the normal things we would do with a stub when we come across it during our own random wanderings through Wikipedia. Sometimes, when I find a stub, I don't do anything with it, and leave it for someone else to handle. Sometimes, I'll be like "I know enough about this, and I think this is a worthwhile project to handle" and I'll expand it. Sometimes, I'll be like "I'm not entirely sure there's enough source material to justify an article about this" and I'll search, and find out there isn't, and I'll nominate it for AFD. My entire point here is that every person in this discussion should be handling these stubs in this manner, and not fretting about what to do with them all. They'll get handled. Or maybe they won't. But we don't need to do anything special. Stubs exist. They existed before Lugnuts created this relatively small set of them here. The will continue to exist and new ones created tomorrow as well. There's no need to do anything special. Ignore them. Expand them. Delete them. Whatever you would do if you found a stub that had nothing to do with Lugnuts, you should do with each one of these. --Jayron3218:28, 2 March 2023 (UTC)[reply]
This comment, and the discussion in general, seems to be full of people who believe that draftification = deletion. This proposal is explicitly NOT that and I'm not sure why people are so convinced that it is. casualdejekyll15:01, 3 March 2023 (UTC)[reply]
why people are so convinced that it is - For the reasons I wrote above (and below, and elsewhere). The usefulness of draftspace, to the extent there ever was any, was eroded through a series of RfCs maybe 5-6 years ago which turned it into a bad content trap. Even before then, it was very rarely used for collaboration or article discovery, at least in part because it was never adequately integrated into our technical systems and editing norms. It had potential, but now it's limited to trapping spam/cruft/attack pages/nonsense. It may be useful for that, but I wouldn't support any proposal based on the idea of people somehow finding drafts and improving them, because that just doesn't really happen outside of token cases. This is unhelpful busywork with a veneer of "preserving content" when the goal is really just to delete them (which I wouldn't support, but have more sympathy for than draftification). It's even stranger because there's not really anything to collaborate on or salvage. What we're talking about here is the preservation of 960 instances of Lugnuts creating a placeholder, yelling "first!", adding it to a running tally, and moving on to the next one, leaving the hard part for someone else. Some people say stub creation inspires passersby to develop articles, but in my experience those who want to write a decent article are more likely to do so if they also get to create it (and/or don't have to work within someone else's structure), for better or worse. Not that I think stub creation should be disallowed; let's just not pretend like there's a lot of value here. I digress... Extending 6 months to 5 years doesn't transform draftspace into a useful collaborative space and doesn't create something valuable out of these stubs. It's a way for those who think the stubs shouldn't exist to functionally delete them where a mass deletion proposal wouldn't succeed. I get that some folks are opposing because they see some value in these drafts, but I'm opposing because (a) moving to draftspace is pointless because of the nature of draftspace and because they're not particularly valuable, (b) I don't support their mass deletion, and (c) redirection is just obviously preferable. With that, I'll take some time away from this thread, as I'm writing a disproportionate amount. — Rhododendritestalk \\ 16:49, 3 March 2023 (UTC)[reply]
Is there a reason that we cannot enact this proposal, but then, instead of R2ing the redirects, retarget them to the associated "Country at the year Olympics" article? We would then be able to slap on a {{R with possibilities}}, which would automatically include a handy note that says "This is a redirect from a title that is in draft namespace at Draft:(name of page), so please do not create an article from this redirect (unless moving a ready draft here). You are welcome to improve the draft article while it is being considered for inclusion in article namespace. If the draft link is also a redirect, then you may boldly turn that redirect into a draft article."HouseBlastertalk18:20, 2 March 2023 (UTC)[reply]
One hurdle appears to be that Someone™ needs to figure out what to do about the cases where the subject participated in multiple Olympics. See bolded entries in the collapsed list in § Alternative: Redirection targets below. Ljleppan (talk) 18:49, 2 March 2023 (UTC)[reply]
How is #1 ("Draftified articles will be autodeleted after 5 years (instead of the usual 6 months)") going to be enforced? A lot of G13 deletions are done by bots, the ones that aren't done by bots may be done by people unfamiliar with this unending saga, and I don't envy the person who would have to babysit hundreds of drafts every six months for five years. Gnomingstuff (talk) 18:35, 2 March 2023 (UTC)[reply]
With something like a template or a category. In theory a faux-namespace could be used, but that has some disadvantages, although those disadvantages could be overcome with a redirect from draftspace to the faux-namespace, but that also has some disadvantages. I think the details of implementation should be left until after we see if there is consensus for the idea. If there is consensus for the idea, figuring out the implementation would be a next step, and then we would probably try nominating other batches of articles for the same process (with the implementation figured out). Levivich (talk) 18:44, 2 March 2023 (UTC)[reply]
I wish people wouldn't use terms such as "microstub" or "sub-stub", especially in supposedly neutral places such as RFC statements. Our shortest articles are simply stubs, and the use of other terms serves to frame a debate against such articles before it has even begun. Phil Bridger (talk) 21:05, 2 March 2023 (UTC)[reply]
Request if the motion passes, could a page be created with the articles listed so that people can try to expand them within the 5 years. I know I might try to expand some of them but will have no time until at least July and without a page/list/something like that, I know I'll forget. Red Fiona (talk) 00:21, 3 March 2023 (UTC)[reply]
I intend to; this list will still exist, but I plan to create another one with all current categories listed. If you have any recommendations for where the list should be placed, please let me know. BilledMammal (talk) 00:35, 3 March 2023 (UTC)[reply]
I went through and added sources for a few so that they no longer met the criteria listed (no sources other than Olympedia/Sports-Reference), and BilledMammal has reverted me SIX times (clear violation of WP:3RR) – yet he's accusing me of being disruptive (I have only reverted three times)! BeanieFan11 (talk) 01:42, 3 March 2023 (UTC)[reply]
I support editors removing items from this list if they meet the criteria defined for the restoration of articles if this proposal passes. This was not done for the articles I restored the list; for most of them only a single source was added, which is not enough to plausibly demonstrate WP:GNG, and for one no sources were added, only text. BilledMammal (talk) 02:03, 3 March 2023 (UTC)[reply]
By making those edits you're making your entire proposal false, as its no longer just a list of articles containing only Olympedia/Sports-Reference with no significant edits. And any explanation for why doubling the revert rule is acceptable? BeanieFan11 (talk) 02:06, 3 March 2023 (UTC)[reply]
The criteria for how these articles could be restored is clear; it doesn't make sense to apply different criteria during the RfC than after it. Regarding the reverts, I believe editors are allowed, with some exceptions, to prevent alterations to proposals they make. I also note that you have done more reverts than I, but we already have a discussion about that on your talk page so I won't comment further on it here. BilledMammal (talk) 02:16, 3 March 2023 (UTC)[reply]
No, I have not made more reverts than you (unless three is greater than six somehow) – I do not see anything allowing what you did at WP:3RR – and again, by reverting, all you're doing is making your proposal a bunch of lies. BeanieFan11 (talk) 02:19, 3 March 2023 (UTC)[reply]
This is troubling. I supported this extraordinary proposal only on specific conditions, including the absence of any SIGCOV. If SIGCOV have even arguably been added to some small portion of the articles, those articles should be stricken from the list. Otherwise, the grounds underlying the "support" votes (including mine) have changed. Cbl62 (talk) 02:54, 3 March 2023 (UTC)[reply]
I note the WP:SIGCOV was added after the RfC was opened; I don't believe it makes sense to have different criteria to remove list items during the proposal (one WP:SIGCOV) than after the proposal (WP:GNG). However, if you or other !support editors disagree, I won't object to their removal. BilledMammal (talk) 02:57, 3 March 2023 (UTC)[reply]
I checked one and it was removed due to the presence of a plaintext reference to the 1911 UK Census and a later death registry, so no sigcov issues there (assuming the references were accurate, they were plain text and even then hard to tell if it's the same person). CMD (talk) 02:58, 3 March 2023 (UTC)[reply]
(edit conflict) BeanieFan11 has removed articles under four different categories:
Articles that included plaintext references like the 1911 UK Census and so were missed when establishing the list; for example, Wilfred Bleaden
Articles where, after the RfC had started, they added no sources but made an edit of greater than 200 bytes; for example, Carlo Bonfanti
Articles where, after the RfC had started, they added one sources that could plausibly be WP:SIGCOV; for example, Arthur Burn
Articles where, after the RfC had started, they added sources that could plausibly demonstrate WP:GNG; for example, Richard Genserowski
I consider removals under the fourth category to be appropriate, as that matches the criteria for restoring the articles defined in this proposal, but I reinstated the articles that were removed under the first three categories as those would be insufficient to restore the article if the proposal passes. If !support editors disagree with any of reinstations, then please remove the articles, or let me know and I will remove them. BilledMammal (talk) 03:11, 3 March 2023 (UTC)[reply]
Adding full-page long articles (such as Bechestobill's case) would not pass your criteria for bringing it back? That is ridiculous. BeanieFan11 (talk) 03:16, 3 March 2023 (UTC)[reply]
I removed Behestobil. That article now has a full page article from a major newspaper, a clear example of SIGCOV. This extraordinary proposal to bypass normal AfD processe was to be limited to microstubs lacking any SIGCOV and received my Support vote on that basis. Cbl62 (talk) 03:26, 3 March 2023 (UTC)[reply]
If you have already found multiple sources then it would be easy to add a second reference. Why don't you just do that, demonstrate that WP:GNG is plausibly met, and uncontroversially remove the article from the list? BilledMammal (talk) 03:30, 3 March 2023 (UTC)[reply]
Ok, no, this proposal is about stubs with zero sigcov references. Not stubs with one reference. Zero. Considering you're the most vocal advocate of the proposal, I was hoping you would already know that, @BilledMammal. casualdejekyll15:03, 3 March 2023 (UTC)[reply]
@Casualdejekyll: All of these stubs had zero sigcov references when this RfC started. I'm of the opinion that items should only be removed when the criteria for restoration is met (Any draft (whether in draftspace, userspace, or WikiProject space) can be returned to mainspace when it contains sources that plausibly meet WP:GNG) as I don't think we should set lower requirements while the discussion is ongoing than we will set if there is a consensus for this proposal. BilledMammal (talk) 15:35, 3 March 2023 (UTC)[reply]
Your proposal is just going to be a lie then, as its not a list containing only "Sports Reference or Olympedia" with "no significant edits other than Lugnuts." BeanieFan11 (talk) 15:58, 3 March 2023 (UTC)[reply]
Then there is a grey area that needs to be somehow addressed. I think that generally your position on this is plausible, but the other hand of it is that the proposal hasn't actually been enacted yet - i.e. nothing's been moved into draftspace, so requiring the articles to meet requirements to move out of draftspace when they haven't even entered draftspace yet seems a little silly. I'd say that once the move is done, that's when we restrict it to only your "fourth category removals". casualdejekyll16:42, 3 March 2023 (UTC)[reply]
My concern is that will be gamed, and as the criteria for inclusion is the list is so conservative gaming it will be easy to do.
I don't believe there will be any harm caused by requiring that the restoration criteria is met to remove articles from the list, but I think there will be disruption if we allow the selection criteria to be used to remove articles from the list. BilledMammal (talk) 17:04, 3 March 2023 (UTC)[reply]
Alternative: Redirection targets
This list is to allow discussion of the proposed alternative of redirecting articles to the relevant country and year article rather than draftifying them; the requirements to convert the redirect to an article would be the same as the proposed requirements to move an article out of draft space. Note that some of these articles have multiple possible targets; those are marked in bold.
Support redirects. For reasons outlined in my comments above, I support both creation of redirects and draftification. The two proposals are not mutually exclusive. Cbl62 (talk) 18:47, 2 March 2023 (UTC)[reply]
Support redirects on general principle, everyone agrees that in normal circumstances BLAR-ing articles with no discussion is allowed, whereas draftifying or deleting them is not. There's no need for unprecendented procedure breaks when the problem can be dealt with while still following procedure. I also see some errors in the table: you listed the same article twice for Frank Ihrcke and George Stapf, and George Patching and George Pinchard are bolded despite not conflicting. * Pppery *it has begun...23:48, 2 March 2023 (UTC)[reply]
These really should be discussed individually – some are very clearly notable, some may not be. We should not be getting rid of them all at once when its been shown that many are notable, especially considering that no harm at all is done by leaving them as they are. I think its more harmful to mass get rid of articles, some of which may not be notable, but at the expense of many very clearly notable ones than leaving them as they are and discussing them by their own merits – as they should be. BeanieFan11 (talk) 00:42, 3 March 2023 (UTC)[reply]
Strong support, send the readers somewhere with information that has hopefully been looked at with some due diligence and might have wider context. No objection to drafting still happening, although I don't think it has much purpose at that point. CMD (talk) 03:02, 3 March 2023 (UTC)[reply]
Strong support per my comments in the above section. BLARing is much more reasonable as it maintains page history, while also being semi-useful. Curbon7 (talk) 03:35, 3 March 2023 (UTC)[reply]
Weak support [only choice], per what I wrote in a couple places above. Opposed to draftification; very weakly preferred to just leaving them alone. — Rhododendritestalk \\ 04:13, 3 March 2023 (UTC)[reply]
Support I am not sure exactly what problem the OP is trying to solve. Stubs, per se, are not a problem. I do not think we are dealing with the additional considerations of living people with this list. So, while many of these articles may not meet WP:GNG in their current state, I struggle to see the harm to the project if these articles are left alone and nominated for deletion through normal channels. --Enos733 (talk) 05:52, 3 March 2023 (UTC)[reply]
@Enos733: Are you supporting or opposing this proposal to redirect all the Olympians? You said "support" but your comments (stubs ... are not a problem ... I do not think we are dealing with the additional considerations of living people ... while many of these articles may not meet WP:GNG, I struggle to see the harm to the project if these articles are left alone) seem to say the opposite. BeanieFan11 (talk) 18:29, 3 March 2023 (UTC)[reply]
Strong Oppose - Per Harry Oppenheim, which is shining example of where the urge to redirect everything in all cases rather than delete "to preserve the edit history" is misguided. These redirects simply serve to cast in stone the erroneous methodology and bad sourcing used to mass-create these articles in the first place. Harry Oppenheim was someone who literally didn't exist under that name, the real name of the non-notable Austrian footballer was Heinrich Oppenheim, but we already have an article about a different Heinrich Oppenheim who is actually notable. There are also multiple other real Harry Oppenheims which a searcher is just as likely to be looking for (a news paper owner, and art-collector, a South African magnate etc.) because they are equally as (non) notable as the Austrian footballer, but for bizarre reasons we redirect searchers to a list of Austrian footballers who played a tiny number of games for the Austrian national team, with no real explanation as to why they land there, rather than just giving them the search results they would get for all the other Harry Oppenheims mentioned on Wikipedia which would obviously be of more interest to them. FOARP (talk) 09:50, 3 March 2023 (UTC)[reply]
Oppose per FOARP. The solution to disruptive mass creation is to simply delete the whole batch without looking twice (or if that's not possible, draftify it). The redirects can be recreated from scratch when appropriate, and the ones that are not should certainly not be kept around for sake of preserving trivial edit histories full of low-effort useless information and cosmetic edits. Avilich (talk) 22:14, 3 March 2023 (UTC)[reply]
It's complicated, but redirection is so obviously a better option than creating a tonne of drafts - and is way more efficient technically. I would want, as per my comments below, to be sure that the sources already in the article have been checked for significant detail by a human being - this takes 20 seconds each article and in a 30 minute sample period threw up around 38% of articles as having prose sources already present and which suggest (strongly in around 20% of cases) other sources exist. We need a balance between throwing out everything and reducing the number of stand alone articles. That can be done. Blue Square Thing (talk) 13:09, 4 March 2023 (UTC)[reply]
One solution would be to redirect to the first (or last, or even random) Olympics they participated in, and then let normal editing processes handle it from there. Another would be to say "there is no obvious redirect target, so let's draftify for now" and let normal editing procedures figure it out from here. Both are far from perfect, but perfect is the enemy of good. Ljleppan (talk) 09:45, 3 March 2023 (UTC)[reply]
Draftify first. Unintentionally, I'm sure, this issue of having to redirect has simply acted as a barrier on anything being done at all. FOARP (talk) 11:38, 3 March 2023 (UTC)[reply]
Someone above made the explicit suggestion of COUNTRY at the YEAR SEASON Olympics as the most logical option. I'd be happy with that and it's clear and easy to use - see my point below for which one we use where someone has been to more than one games. Blue Square Thing (talk) 14:33, 3 March 2023 (UTC)[reply]
Agree with Sojourner in the earth above - And yes, this is a problem generally for nearly all these redirects of non-notable sportspeople: there is a multitude of possible redirects, each as bad as the other. Returning to the "Harry" Oppenheim case discussed in my !vote above, Heinrich Oppenheim played two games for the Austrian national team but he also played at club level in Austria so why are we highlighting their very brief career on the Austrian national squad. Indeed, why are we highlighting them with a redirect at all when other Harry/Heinrich Oppenheims existed? FOARP (talk) 11:36, 3 March 2023 (UTC)[reply]
That's a good point about other people with the same name. If we didn't have an article on the Olympian Alfred Keene, then the painter Alfred John Keene would be the primary topic, and should therefore be the target of the redirect. Sojourner in the earth (talk) 18:55, 3 March 2023 (UTC)[reply]
Firstly I'm not even sure I'd be trying to do anything with Alfred Keene before doing a quite intensive search of The Times and the London Gazette - the notes on his Olympedia page suggest strongly to me that there's very likely to be something to allow us to develop a decent article about him.
In terms of where to redirect - in some cases it'll be obvious because someone will have had one relatively successful games, in which case the redirect should probably go there (Sidney Domville for example, although again the notes in Olympedia suggest he's worth a look as a keeper). In other cases it won't be so clear - I'd probably suggest their first games in that situation, but I could live with the last. It's just slightly easier for modern people to use the first (and bear in mind that stuff like shooting means people can have really quite long Olympics careers. Blue Square Thing (talk) 14:30, 3 March 2023 (UTC)[reply]
My plan, if there is a consensus to create redirects, to redirect to the country article for the first Olympics they played in. I'll also provide a list of the articles covering sportspeople who played in multiple years to WikiProject Olympics, so that interested editors may easily alter the target if desired. BilledMammal (talk) 16:22, 3 March 2023 (UTC)[reply]
BilledMammal - but then why redirect at all? With the redirect the user is taken to a single page. Without it, the user sees all mentions of that name on Wikipedia in their search results, including all the events and teams on which that name is listed, but also all the other people of that name who are equally as likely to be of interest - isn’t that better? FOARP (talk) 06:02, 4 March 2023 (UTC)[reply]
I agree, and have argued extensively for that position in the past, but I believe a few inconvenient redirects are an improvement over leaving these articles in mainspace, and if there is a consensus for the proposal only on the basis of redirection I don't believe it would be appropriate to omit a few. However, I would be happy to provide you with a list of articles with multiple appropriate targets, and can probably generate a partial list of clashes with other articles - you can then bring them as a group to RfD? BilledMammal (talk) 06:12, 4 March 2023 (UTC)[reply]
That seems very arbitrary and potentially unhelpful, eg. if someone is reading about the 1912 Olympics, searches an athlete's name and is taken to an article on the 1908 Olympics, with no indication of where they can find the information they're looking for. It might do as a stop-gap measure, but if consensus is to make these articles into redirects, my preferred solution would be to merge them all into List of Olympic athletes (1896–1912). That would be a lot more work, obviously. Sojourner in the earth (talk) 12:00, 4 March 2023 (UTC)[reply]
That would be a lot more work, obviously. Depending on what information you believe should be included in that list, it might not be. What information do you believe should be included in it?
My concern would be that the list would be very long (WP:LSC), and that it wouldn't fully resolve the issue as some athletes who competed between 1896 and 1912 also competed after 1912; I think that can be corrected by creating "List of Olympic athletes: A", "List of Olympic athletes: B", etc. BilledMammal (talk) 12:20, 4 March 2023 (UTC)[reply]
What information do you believe should be included in it? For the list to be useful, I think at a minimum it would have to contain birth and death dates, Olympic years and events participated in. This information would have to be checked against the sources, though, to make sure we're not propagating errors. Sojourner in the earth (talk) 14:48, 4 March 2023 (UTC)[reply]
We can check against the sports-reference source automatically; would that be sufficient?
If we are going to do this I think it will need further and separate discussion; both to determine what information to include, and to determine whether such a creation would be appropriate. BilledMammal (talk) 15:30, 4 March 2023 (UTC)[reply]
Discussion (other article-sets which need addressing)
If this motion passes some serious thought should be given to sub-sets of other extreme-low-quality articles mass-created on Wikipedia. Off the top of my head:
The 19th-century and early-20th-century cricketer/footballer articles made by Lugnuts.
Dr. Blofeld's mass-created Bangladesh/Burmese "village" articles created using only GEOnet Names Server (GNS), a deprecated source for this purpose. Dr. Blofeld has indicated that they are OK with these articles being dealt with in some way in the past.
The Antarctic geological feature articles created based only on GNIS, a deprecated source for this purpose.
Carlossuarez46's Iranian/Azeri "village" articles, created based on GNS/the Iranian census (both deprecated for this purpose - the Iranian Census because it includes wells/pumps/farms/houses etc. as "villages").
Of course the process would be the same as here, and the search used to highlight it having similarly very low criteria for escaping draftification. FOARP (talk) 10:00, 3 March 2023 (UTC)[reply]
Yes, the problem for me is permastubs which can't be expanded or ever become a useful start class article. I think you'll find most stubs created by me can be expanded, but the "xx is a village" approach using a database, even with a population figure in many of them was a poor way to approach it. I'd be happy to delete all database type stubs from the site which can't be significantly expanded, or merge them into lists were appropriate. Carlos's Iranian stubs for instance, I think we'd be better off merging a lot of the smaller settlements into lists by district. ♦ Dr. Blofeld14:32, 3 March 2023 (UTC)[reply]
I think this discussion will need to be split off, but I've created two lists of articles created by Carlossuarez46 on locations in Iran and Azerbaijan. These lists attempt to include every article they have created, so they will include articles that would not be considered for draftification like Hadrut; filtering can be done later, if there is a consensus for this proposal and when we decide how we want to filter the articles. They also may not be complete; I am not certain yet what article or talk page categories are best suited to generating a complete list, and suggestions are welcome.
I am wondering, though, if these creations were fully automated; I'm seeing several articles with identical names disambiguated only by coordinates, and I don't believe that even an inattentive human using a semi-automated process would not realize that those are probably the same location. BilledMammal (talk) 17:17, 3 March 2023 (UTC)[reply]
Discussion (general)
Perfection is the enemy of progress. We're talking about an immense amount of stubs that the creator spent perhaps 1 minute each creating. Any plan which requires a special discussion and decision-making process for each one (perhaps 1 hour of volunteer time for each) will not actually get implemented and would be an insult to volunteer time. Some way of efficiently moving forward on this is needed, even if imperfect. The potential downside of an efficient system potentially having non-optimal handling of some exceptions is easily fixed and not big. North8000 (talk) 16:17, 3 March 2023 (UTC)[reply]
Frankly my preference is for straight-deletion of failing articles that were created en masse, and the recreation of that part of them which may be notable as actual articles. The proposed process does at least eventually achieve that result so I am in favour of it.
Opponents are essentially admitting that even given years of lead-time, they are not going to fix these articles, in large part because many/most of them cannot be fixed. FOARP (talk) 05:54, 4 March 2023 (UTC)[reply]
Well, I"m not sure that that's necessarily true.
I just took a strict 30 minutes - timed - and clicked through the first 163 articles on the list of 960 above (17%) - working in the order they were presented, i.e. alphabetically by forename. For each one I checked the Olympedia article to see if it had anything substantial to say about the person. If there was anything relatively in depth that made me think there might well be further sources available I recorded it as "Definitely worth a look"; if there were a few personal details or details about their career I recorded "Possibly worth looking at"; if there were only passing details, such as the club they represented or their performance just in the Olympics I didn't record anything. On average it took less than 20 seconds per article, including recording.
Of those 163 articles, I recorded "Definitely worth a look" 31 times and "Possibly worth looking at" 32 times - so, 63 of the 163 had something on the Olympedia article which gave me significant pause for thought (38.7% - with 19% clearly, in my view, worth a proper look).
That's a much higher proportion than I was expecting.
This might be because the majority of those with detail on were British or American - more likely British fwiw. The 1908 London and 1904 St Louis games almost certainly mean that there are more of those articles - if the set had been 1912 to 1928 then I imagine the proportions would have been lower.
Obviously this is partially subjective. I tried to be as clear as possible and only record when there was clearly something that caught my eye, but at the same time was working quickly and there may be some blurring. I was focussing on the likelihood, in my experience of using newspaper reports from this sort of era, of other sources existing - after all, that's almost certainly where the Olympedia writers got their information from. In some cases there wasn't much in the way of information but hints that there must surely be more (Daniel McMahon (sport shooter), for example), whilst another cases there is already a significant amount of information (Daniel Flynn (cyclist), for example).
The set I looked at is here along with my notes. I took out most of BilledMammal's columns for simplicity.
Why is this "important"? It's reasonable to make the assertion that stubs can act as seeds for articles. I think it's also reasonable to assert that stubs in mainspace are more likely to be developed than redirects or drafts. I have absolutely no quantifiable evidence to back up that assertion, but I'm sure I've seen other people make it in the past and I don't think it's an unreasonable thing to say.
So what? The query is good at identifying possible articles that might be dealt with. And by my book, 60-odd percent of these could probably be dealt with somehow. But my only request is that we look at the sources actually present first. For the list of 960 that's, what, less than four-person hours (20 seconds per article is easily doable over 30 minute bursts). Think how much time has been wasted on this process of discussing alone over the last couple of years. At least part of that - and a substantial amount of the opposition to the proposals - is people pointing out that some of the articles on lists which have been presented as clearly notable (Bill Huddleston was on one list for example, yet already contains a substantial prose source because the methodology assumes, as with these lists, that the sources included in the article are only databases). The discussions above have already thrown up plenty of other examples beyond the first 163.
I think it's also reasonable to assert that stubs in mainspace are more likely to be developed than redirects or drafts. I have absolutely no quantifiable evidence to back up that assertion, but I'm sure I've seen other people make it in the past and I don't think it's an unreasonable thing to say. I have quantifiable evidence to say the opposite; see my essay Wikipedia:Abandoned stubs. Articles are much more likely to be expanded by their creator than by anyone else. BilledMammal (talk) 11:38, 4 March 2023 (UTC)[reply]
I don't think that's quite the same thing though, is it? And, interestingly, your 35% figure having been developed is quite close to my 39% figure for items on that list where there's a fairly significant flag that I can raise that says, hang on a minute, we need to look at this properly. Which is my main request here. Blue Square Thing (talk) 13:03, 4 March 2023 (UTC)[reply]
the methodology assumes, as with these lists, that the sources included in the article are only databases This isn't accurate. The method assumes the source has been used as a database, which is not the same thing. (And apparently used in a way that generates the wrong birth dates in some instances, somehow.) CMD (talk) 13:22, 4 March 2023 (UTC)[reply]
I take the specifics of your point, but my point is that the way that the list that Huddleston was on was created using a query to produce a set of articles that are presumed to be inadequately sourced, which is often taken to mean sourced only to databases (see any number of discussion around the sourcing of articles about sports people).
The assumption behind that is that the sources, in that case CricketArchive, are assumed to be purely a database source. In the case of Huddleston that source contained a decent sized prose article about him as well as the standard data tables and so on. The same is sometimes true of articles sourced only to CricInfo - a point I've made a number of times elsewhere.
In the case of the list of 960 articles presented here, the assumption seems to be that articles sourced to Olympedia will simply have data tables rather than any reasonable prose that could act as a seed for article development. In around 40% of the 163 cases I've looked at so far I don't think that assumption is reasonable to make. Of course, identifying the 60% that don't have that and doing something with them would make the task of figuring out exactly what to do with the 40% much easier, and, with caveats, I support that. Blue Square Thing (talk) 15:26, 4 March 2023 (UTC)[reply]
I don't see where that assumption is being made; I don't even think anyone has suggested Olympedia is a poor source. Whatever it (and Cricinfo) could be used for, it has instead been used to procedurally generate two sentences on each subject. Whatever is done to those sentences, Olympedia and its seed information would remain for those interested in the 40%. CMD (talk) 15:44, 4 March 2023 (UTC)[reply]
Notes
^This excludes many mass-created microstubs, but it keeps the number of false positives extremely low
^"Significant contributions" is defined as "larger than 200 bytes, excluding edits that are reverts or were reverted"
^This does not mean that the article is guaranteed to be kept at AfD on the basis of the sources contained within it, just that it is possible to make a good faith argument at AfD that WP:GNG is met on the basis of those sources.
^This option is provided to support editors who may determine that some of the articles on this list would be more useful as redirects than drafts.
^Nominating 500 articles a month would increase by a third the number of articles going through AfD, and conservatively assuming that only half of Lugnut's creations have notability issues would take almost eight years
A better way for dealing spam
Hello everyone, I have dealt with spams on newly created pages for a while. I believe they are in the likely patterns,
a new user registered
shortly added spam links, email address and something like that on their user pages, user sandboxes or user talk pages.
Could we add a filter for tagging them with specific edit summary? For example, new users adding links contain their own usernames or new users adding links on their subpages. It will be better for us to deal with spams. -Lemonaka18:24, 3 March 2023 (UTC)[reply]
We already do this sort of stuff. Edit filter 80 is a spam throttle for adding the same link over and over, Edit filter 149 flags edits where the link matches the username. If you have a specific type of spamlink that a regex-based filter may catch that these aren't, Wikipedia:Edit filter/Requested is the place to go. --Jayron3219:32, 3 March 2023 (UTC)[reply]
ok so i think that vote "options" (idk what's it called in enwiki) such as Support, Oppose, Comment should have a little icon that represents the options. so like Support ; Oppose; Comment and Meh. tynjee02:58, 4 March 2023 (UTC)[reply]
I will echo what The Earwig says in that there's been longstanding hesitation around making those templates. There already exists a {{comment}} template, and a {{meh}} template (though the current meh template is slightly different from what you're proposing). — Red-tailed hawk(nest)17:01, 4 March 2023 (UTC)[reply]
Request to mass create ISO 3166-2 codes as redirects
Hi all! I'm planning to undertake a task that would involve creating a large number of redirects to point the ISO 3166-2 country subdivision codes to the relevant articles on that country's subdivisions. Unless an page with a title matching a country subdivision code already exists, this process would create a redirect at that title to point the relevant subdivision. Some of these already exist as redirects (e.g. the subdivision codes for Argentina), but that set of redirects is currently incomplete. I realize that I could probably do this manually without issue, but it would take quite a while. I would hope to eventually semi-automate the process of creating these, since creating 5000 redirects and adding tags can be tedious if done manually. For that reason, I am asking for consensus around whether this sort of redirect creation is looked upon favorably by the community before I go ahead with mass creation. — Red-tailed hawk(nest)16:59, 4 March 2023 (UTC)[reply]
), which is in the dropdown menu for 
, rather than a page's talk page (
). —Tenryuu 🐲 ( 💬 • 📝 ) 22:30, 20 January 2023 (UTC)
Levivich (talk) 07:07, 28 February 2023 (UTC)
Moved to Wikipedia:Village pump (policy)#Make Wikipedia:Requested moves/Closing instructions a guideline
Support ; 
Oppose; 
Comment and 
Meh. tynjee 02:58, 4 March 2023 (UTC)
