Knowledge:Village pump (proposals)/Archive 198

5704:- 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 Knowledge 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. 6196:. 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. -- 3166: 5669:

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,

5880:

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. Knowledge 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

5305:. 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 6555:- continuing this discussion on the effectiveness of Knowledge'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: - in comparison, multiple studies have praised Knowledge's community-based approach - caveat that many of them focus more on content, because that's what we're famous for, but: Generally speaking, sources that discuss Knowledge, Twitter, and Facebook's handling of content moderation together describe Knowledge 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 7675:. 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. 6602:: 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. 6021:- 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. 36220:), 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. 6559:, 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 Knowledge, 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 6430:. 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. 5777:. 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. 4806:- 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.- 2928:. So long as there is some ability for individual WikiProjects to maintain individual quality assessments that are uncommon but nonetheless useful (such as A-Class), then I would support this. I do not support giving MilHistBot a veto power over global quality assessments; global quality assessments should be given by the global criteria, and MilHist should be free to separately list its own rating if the WikiProject dissents from the quality assessment performed by the community. That being said, this will save editor time, and I look forward to the implementation of this across EnWiki. — 5369:. 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. 5543:. 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 Knowledge 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. 6154:

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. --

4947: 1637:, right now there's generally no difference between different project's ratings, so it's superfluous to mark it in each template. I hope, though, that the technical implementation allows for easy per-project overrides; the video games project, for example, stopped using A-class 8 years ago, so it would be convenient if the template would put those articles into the GA-class video games articles category automatically instead of the deleted A-class one if another project wants to mark an article as A-class. -- 8020:

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).

5260:

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.

36682:

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. —

6136:

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 Knowledge movement as a whole and probably largely irrelevant to the English Knowledge specifically. I echo what Barkeep and Levivich have said.

4935: 35961:: 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. 1845:– This proposal does a lot in an elegant way! I firmly believe this consolidation opens up an easier learning curve for newer editors: We can get comfortable with "the standard" in an incremental way, without always being pulled by multiple (competing? hard to understand?) WikiProjects. Further, as a mobile view reader and editor, I appreciate anything that 1) means less code overall for my thumbs to screw up and 2) clears up space on my tiny screen. Happy, happy all around. — 4941: 36497:

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.

37114: 36060:

collection (not like every village in Turkey), and it's not just scraping a database and copy/pasting it to Knowledge. 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

3746:", and now I'm going to have to start using that? I've got about all I can handle dealing with US, UK, OZ, NZ, Canadian, and Oxford English, and I'm willing to go out on a limb once in a while for a worthy article in Caribbean or maybe Nigerian English. But as for articles in Ghanaian English and Liberian English and Pitcairn English and all the rest, count me out; someone else can go edit those articles in that case; it's more effort than I'm willing to offer. 7349: 35692:

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

7985:

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

37105: 6528:

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

4859:, 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. 6584:

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.

36001:, 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. 37132: 37123: 3476:). A bot was suggested to carry out this purpose, however I believe that the nature of these tags, i.e. garnering context from the article itself, requires a human edit. Neither of us see anything undesirable about adding this maintenance template per se, however we both paused our efforts until some sort of discussion had been had. Any comments on this would be most welcome. Thank you and best wishes. 3742:". Now, I'm not surprised that Ghana has its own variety of English, but honestly, that notice on the page does only one thing wrt my editing at the article: it discourages it, and waves me off, since I haven't a clue about Ghanian English, and even if it's pretty close to Commonwealth or some other English, as soon as I have it under my belt, then the next article that hits my list is going to say, " 7912:, 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 9104: 3894:

they will be converted to "colour" and "truck" with no documentation needed; there's probably also enough Kiwis around that instances fjord will be converted to fiord without us needing to document that peculiarity of NZ English anywhere. On the other hand I'd be surprised if we had even a handful of regular Ghanian editors so without documentation changes will happen only slowly.

6564:

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.) --

1521:. The current quality assessment structure is an overly-complicated mess; the fact that there are individual assessments given for each project is just one of many ways. The vast majority of projects just copy-paste the generic criteria into their project space, which adds no value. Those with legitimate reason to continue to maintain their own criteria (for example: 35886:

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.

6406:. 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. 7531:

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.

4113:, although the templates can be useful on a case-by-case basis. Like Mathglot above, if I see "Ghanaian English" I would be quite reticent about touching the article. And FWIW, our Indian articles are generally dreadful, not just for lack of sourcing, but because of the abysmal strings of characters which I understand are supposed to pass for "Indian English". I 6214:

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 Knowledge 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.

3898:

trying to replace all transclsuions of the Irish template with the British one, or the Pakistani one with the Indian one far outweighs any benefit. As a practical matter tools can be instructed to treat the two identically, and it's actually easier for new editors to manually tag correctly per TIES when tag names directly match country names anyway.

6037:- 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. 4157:, but this is a second language to most users, and exists in several registers. Academic Indian prose is virtually the same as British, or intended to be so, but most of our Indian editors aren't academics, and lean towards the colourful Indian form of journalese, just as huge numbers of American editors do towards their local version. 4710:

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.)

5310:

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

3669:) in which you could set the format in which dates would be shown in your preferences. It required that all dates be wikilinked in a specific pattern. It was deprecated because it was clumsy, and only worked if you were logged in. Remember, users who are not logged in (most of our readers) do not have preferences available. 6383: 5907:

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 Knowledge more of a

5127:. 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. — 36523:

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.

36099:. I generally don't like what bots do on Swedish and Cebuano wiki etc but I'm of the opinion that English Knowledge 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. ♦ 6580:

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 Knowledge will continue to be handled by English Knowledge's policies and enforcement procedures.

36522:

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 Knowledge's history has been earned. I'd rather not speak

36059:

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

35691:

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

8153:

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

8126:

needed is broader enforcement of Knowledge 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.

8078:

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"

7534:

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

6923:

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 Knowledge. It appears that there will be a consensus of some kind

6610:

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

5949:

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

5003:

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

4505:

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

4466:

The reason copyrighted media cannot be uploaded cross-wiki, is that their use is subject to local laws, not American law. For example, "fair-use" provisions don't exist in many countries. On the French Knowledge, copyrighted logos can be used, but copyrighted screenshots are illegal with no exception

3897:

It's also best to remember that some national varieties of English are tagged separately solely to be polite. There's no functional difference between British and Irish English when written in an encyclopedic register; Likewise for Indian and Pakistani English, but the shitstorm that would ensue from

36263:

I am writing to request the promotion of the WikiShootMe.js user script as a Gadget on Knowledge. The WikiShootMe.js user script is a useful tool that allows users to quickly access the Wikishoot tool page, which displays Wikidata items, Knowledge articles, and Commons images with coordinates on the

36072:

encourages me to support; we have articles about every abandoned train stop and dirt road in the US; because Knowledge 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

35654:

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

7984:

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

7934:

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

7884:

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

7788:

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

7540:

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

7530:

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

7447:

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

6463:

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

5995:

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

5254:

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

3999:

does apply, it's useful to have had someone else go through the article history before me and figure out what the stable usage was at the beginning or has been up till now, so I don't have to figure it out for myself for every article. I wonder if those templates, in articles where there's consensus

3893:

The issue is that documenting all of the differences would be tedious and no one is interested in doing the work (true for documentation in general). Most of the time this probably isn't a big deal if someone puts "color" or "lorry" into an Australian article there are enough Australian editors that

3284:

Some boxes like notifications that an article may be merged or split might not be something a passing user would want to know. Perhaps having those contained within a pre collapsed box would be better. Or maybe a generic notification that there are administrative (or something) things to be aware of

2335:

Some editors just unify the quality assessments across wikiprojects... so that isn't a proper indication of individual topic-area-specific quality (as opposed to general article quality) on Knowledge right now; unless it's a few missing classes (ie bottom/low/C/A) that some projects have that others

2041:

While I've for a while been a member of the "assessments don't matter" school of philosophy, I feel compelled to point out that an article can be fully sourced without meeting other B class requirements such as comprehensiveness, and that doesn't disqualify an article from DYK eligibility. Trying to

2024:

True, but note that DYK already has certain requirements: A1 requires a 1,500 character minimum, and D7 requires and article "to be complete and not some sort of work in progress". It is likely that if this proposal for project-wide classification is accepted, there will be a proposal to set the bar

37266:

I'm sure you're not proposing to use them on English Knowledge. Just that something is done on many other Wikipedias doesn't make it right for us. Voting seems to be more common on other Wikipedias too. What I would love is for more editors to discuss things first before coming to a conclusion that

36681:

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

36496:

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

36090:

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 Knowledge to have near start class articles

6213:

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

6056:

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

5812:

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

5741:

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

4709:

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 Knowledge. I'm happy to engage in discussion, but don't blow us off by referring elsewhere as if this project does not

4052:

Deciding on a variant of English to use, and harmonizing a whole article onto it, is good practice when you're trying to bring an article to GA or FA class, but I don't see the point of doing it en-masse. As a side note, while I have no interest in telling anyone what to do, I just don't understand

3491:

I would tend to agree that these edits are unnecessary, and making thousands of unnecessary edits is undesirable. Unless there has been some kind of editing history on a particular article that would suggest this template is needed, then it is probably better not to add it. PS, I note that it seems

36385:

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

35490:

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

7519:

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.

6622:

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

6579:

I don't feel that Facebook and Twitter are good comparisons to Knowledge, because whereas they are explicitly for chatter about anything, Knowledge discussions must be related to Knowledge editing and thus ultimately to improve Knowledge. This provides a central guiding purpose that can be used to

6527:

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

6135:

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 Knowledge is run. Their influence is likely to be stronger on smaller Wikis, giving the WMF more tools to fight institutional capture by

4501:

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

4036:

I think these are mostly make-work edits and aren't helping editors. Unless a page has had a recurring issue that has since been resolved about dialects this isn't helping editors - and may actively discourage casual editors who should be most concerned with adding relevant verifiable content, not

2658:

without requiring changes to individual banners templates afaik, except if a project opts-out. Ofcourse, there's no rush. If/when the proposal succeeds, every WikiProject should be given ample time to discuss (de)merits of opting-out and making a decision. I have a proposal on how to move forward,

2486:

An interesting question, including the issue of what is "correct". I think the default should probably be that articles are in the "unassessed" categories if the main banner doesn't have an assessment. It shouldn't be too hard to code a category for articles that have a global assessment but not a

35964:

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

7980:

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

7965:

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

7418:

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

7178:

Yes, the same function that allows editors on Knowledge to use prefixes such as commons:, meta:, and w: (for Knowledge) 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

7082:

While the Wikimedia Foundation does not offer web hosting services, it does provide free and open source software, including the MediaWiki platform, which powers Knowledge and many other wikis. Anyone can download and install MediaWiki on their own web server or hosting provider, allowing them to

6583:

On a side note, the problem with English Knowledge'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

5668:

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

5577:

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

5259:

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

3859:

That's just carelessness. Can someone help me set up an AWB run, so I can place one Trout on Ser Amantio's Talk page for each incorrect edit summary, and a big, golden mega-trout for starting this without consensus? That could be eight thousand trouts, but it's healthy protein, and could help the

3648:

Because of things like torch/flaming torch/flashlight, or truck/bogie, it's difficult to do an automated straight substitution without additional markup in the source text in some fashion. Variations like "licence/license" are tricky too, since the spelling depends on whether or not the word is a

3519:

article containing "color" (not "colour") are automatically identified, but I'm not convinced that this is worth the wikitext it takes up at the top of the page. There must be a better way to do this. I can't really fault the editors here for adding a tag to applicable articles, but I don't think

3013:

It may make wikiprojects with their own quality assessment criteria a bit more visible, so an editor making a change to the general assessment may leave it to a project member to change the project assessment. Not sure if that is good or bad. A bot could perhaps be developed to flag articles with

2708:

to have a parameter for last assessment date, which in my opinion should be introduced more globally at the article-level, to have a rough idea of what articles among the millions may have improved/degraded in quality over periods of time. This one probably requires separate discussion, but if it

1948:

I can see the advantages on this, with articles rated B or better being the minimum acceptable standard for DYK and ITN. The criteria do differ slightly from those that the MilHist Project is currently using. The main differences are criterion 5, where we require an infobox or images (not hard to

36962:

I think this is a good idea. It's a well-defined and limited set of redirects, all of which will be plausible search terms (pretty sure I've searched some myself). Where clashes exist, it may even be worth turning those clashes into disambiguation pages, although this will presumably be a manual

35885:

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

6563:

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

6171:

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 Knowledge's current mechanisms, and beyond that the fact that it was foisted upon the community and we're doing all

5879:

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 Knowledge, 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

3383:

from which backlinks should be added. I still use the tool anyway, but the default result set is always zero results, and I have to manually delete the 'Draft' prefix in two places. That shouldn't be necessary, and may leave some editors persuaded that there really are no useful article backlink

2973:

echoing almost entirely the comment above, it's fine as long as Wikiprojects such as Military History can still set their own classes for only their WP where they disagree e.g. they want A-class, which isn't commonly used, and therefore the general rating should never be A-class. It will benefit

7693:

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

5906:

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 Knowledge, 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

5448:

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

4881:

tried and failed doesn't = push through anyway. I understand the idea of the perfect is the enemy of the good - Knowledge 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."

4840:

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 Knowledge. Learning how to thread

2060:

Start-class articles that are fully sourced but not broad enough in their content coverage are allowed to run at DYK. I think this is a good thing; DYK isn't a mini-GA review, nor should it be. People who produce a good number of well-referenced C-class articles that fail B-class only for their

1702:, generating significant additional work for essentially no benefit. I would further support an opt-out implementation, in which projects are assumed to be okay with the project-independent assessment unless they specifically request to have their own system. I have mixed feelings about whether 35820:

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

7899:

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

7587:

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

5726:

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

4186:

being added to 5-10 articles I started (as I usually add them myself), I don't see a general need to add them, particularly when it's not clear to the majority of people what the differences between some of these are. E.g. Despite being English, I'm not really sure what the differences between

1442:

It is a way to put a general assessment of an article quality at the top of the article talk page, and let the project banners "inherit" that assessment. It saves space on the page, and makes it easier to update the general assessment. Projects can opt out and use specialized ways of assessing

1226:

Importance assessments are project-specific, showing how important the article is in providing complete coverage of the project subject area. An article may be high importance for one project, low importance for another, and irrelevant to most projects. This proposal does not affect importance

8019:

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

7698:

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 Knowledge editors. You're going to need better examples than that. If nothing else, your examples have served to show places where it

6153:

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

5345:

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.

5309:

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

3678:

If the only downside is that "it doesn't work for IP users", then I think that's not a major problem. IP users already miss out on all sorts of benefits, and it's by their own choice. If they are "forced" to view articles in whatever the default English is, I would say that is extremely minor

35979:

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

9014:, 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. 2547:

know how many and what articles are covered by the project and what their classifications are. Unless we have a volunteer to preform a great deal of work, I strongly recommend that this be "opt-in" and not "opt-out", as someone from each project will have to work on the template. Start with

35655:

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.

6605:

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

7789:

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.

5004:

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.

3876:

I've long wished that the people who have the idea that every country in the world needs to be flagged for its own variety of English would include in these templates' documentation an explanation as to how exactly those varieties actually do vary from American or Commonwealth English

5827:

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.

6481:

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

1794:– This seems like a sensible simplification, and a reflection of how (in my experience) assessments work. I don't think any project I'm involved in uses project-specific criteria, but it's good to keep the opt-out (which, as I read it, is there in the proposal) for projects that do. 4067:

Exactly. Ppl seem very busy 'standardizing' things to a level that is never achievable (for long) in a public editing model by thousands of (imperfect and untrained) people. It is better to accept certain imperfections and mistakes of the users. It is part of what makes it a wiki.

1284:

has the value "custom", the project class will be displayed and used to create categories as at present. The project class will be displayed even if it is the same as the article class. Projects will be canvassed to set this parameter if they want to use custom quality assessment

35767:

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,

7846:

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.

36981:, if you can provide a complete list, I can provide you with a list of the ones that clash with existing redirects, and the ones that clash with existing articles (if any). I agree with CMD that disambiguation pages would likely be appropriate for all clashes with redirects. 6265:. 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. 1486:

project specific (with a handful of notable exceptions). I especially like the fact that MILHIST can continue using its own assessment standards. I'll also note that this approach has been done on French Knowledge for more than a decade, and always felt more "modern" to me.

4634:

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

35942:

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.

4398:

Since these logos are the best logos for each of these companies and are with the highest quality and when an user of a different Wiki wants to create an article about these car manufacturers, which is missing on that Wiki and wants to use these logos, can't use them.

35517:

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. —

5807:

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

7179:

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

36620:

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.

36271:

The WikiShootMe.js user script has been developed and tested by myself and other users, and we believe it meets the criteria for promotion as a Gadget on Knowledge. I have provided a link to the script below, along with an installation guide for interested users:

6395: 5481:

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

5630:

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

4333:

the templates run a risk of deterring editors who feel they can't write Pakistani English, so their use should be kept to an absolute minimum. They should only be used to relay the result of discussion where there has been disagreement and it's been resolved.

5719:

It's long past time for English Knowledge 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

36201:: 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. – 8103:

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

5484:

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.

2261:, yes please. Some projects will probably also want to simplify their criteria (WikiProject Germany has a B-Class checklist but doesn't have the manpower to use it properly); I guess projects should explicitly opt out of using the standard rating scale. — 5727:

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,

6464:

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.

1949:

do), and 6, which we rejected years ago. I trust that everyone understands that classification up to B is handled by our MilHistBot, so that if this proposal passes, then the MilHistBot will assign a global assessment whenever the article falls under

36267:

The user script takes latitude and longitude coordinates from a Knowledge page and redirects the user to the Wikishoot tool page. This can be very useful for editors who need to quickly locate images and other media related to a particular location.

5754:

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

3881:. I see no need to care about varieties that differ only in slang, or in colloquial registers, or in spoken pronunciation (at least until "SpeakGPT" exists to make natural-sounding spoken versions of articles in an appropriate accent), or the like. 9278:, 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 6968:

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?

37251:

different, which is a good thing. Trying to achieve technical compatibility would merely mask existing social incompatibilities and make things worse. (And I say this despite being active on 3 different multilingual wikis, and an admin on one).

2741: 8127:

At some point, I suspect Knowledge 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.

7039: 3633:

Not a bad idea, but only if it could be done via some widget or script in your browser, and not if it's visible in the Wikicode, which would pollute the code in a way making it harder to maintain, and likely would have other knock-on effects.

4603:

that have been give the distinction of being "Featured Lists". This is a step in the direction of what I am proposing, but I wondered whether other lists should also be ranked. This might help WikiProjects see which lists require more work.

4349: 8060:: 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 6176:

the thing treated as a fait accompli is beyond insulting, and against the pillars Knowledge 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

4656:

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. —

4557:

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.

35576:

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

5472: 7861:

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

7086:

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.

4885:

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. -

4053:

why so much of Knowledge has turned into menial busywork. Why is it that the vast majority of articles I come across are substantially unchanged from ~2010-2013, save from Wikignoming? Surely article expansion is more rewarding?

2501:

For projects that opt out, presumably including military history, the article will be categorized as unassessed if the project banner does not have an assessment. For other projects, if there is also no article-level assessment.

36562:

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

6280: 4873:

I appreciate all that. I do. But all I need do is look at the default signature for editors to see that Knowledge sees the value of a talk page link. (And yes, I'm aware that mine isn't there - user pages are important too :

3421:

Oh my gosh, you're right; I've had that script installed for so long, I completely forgot, and thought it was part of the standard mw installation (it ought to be!). I'll move this request to her TP; thanks for the heads-up!

5899:

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

2275:

I wouldn't shy from opposing this if I felt it deserved it just because 20-odd users all voted 'support' before me, but there's a good reason for that; this is a very sensible improvement, and it does deserve it. It's got my

35676:

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.

5360: 1811:– I think this is a good change per above, and WikiProject-specific ratings could still be kept. Additionally, it solves the issue of topics that do not fall under the scope of any WikiProject not having a class assessment. 35491:

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) —

9201:

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

35822: 9188:

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.

6030:

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

8241:

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 Knowledge articles, see

37051:

Sorry, I don't. However, I would suggest saving the excel document as a CSV file, opening it in notepad, and copying and pasting the contents - probably to another page. It won't be formatted, but that isn't important.

36781:

Personally, I prefer to defer to search engines to figure out the best destination for a search term, and not try to make every reasonable search term a redirect. I appreciate, though, that others have different views.

4117:

the weird capitalisations are mistakes, but they're so predominantly "wrong" (to my USian eyes), that I wonder if there's not actually a system. The grammar, meanwhile, just seems sloppy. Summary: templates are useful,

3102:

No. If there had been solid opposition there would be no point wasting time. But a weekend editor may identify a roadblock. I would be surprised, but this has waited more than 15 years so a few more days will not hurt.

6075:

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.

5198:: 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. 3292: 1323:, or if it supplies a value the same as the (non-blank) article-level class, the class will not be shown in the project template, since that would be redundant. The article class will be used to form categories like 7743:

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):

6181:

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?

5338:

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.

3147:

with a question: how will this affect the situation of articles that are currently asssed for inactive Wikiprojects only? Will those assessments be automatically restored and piped to the general assessment scheme?

1329:

If the wikiproject banner supplies a class value that differs from the (non-blank) article class value, the talk page will be placed in a tracking category and the project class will be used to form categories like

3204:. If all projects assign same class, that class will be made the global-class by a bot. If projects differ among themselves, they will be categorised for human review, and a human will decide what happens with it. 36762:

With respect to the problem it would solve, it would allow users to type in the ISO code in the search bar and then be taken to the article on the corresponding geographic entity. Users currently can't do this. —

5335: 4877:

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

2158:, I can say that B1 is enforced at DYK (DYK's rules are possibly a bit more strict). The similarities do kind of end there, though: bolded articles regularly fail B2 and B5. B3, B4, and B6 are... not requirements 36635:

IMO, the key point for C-Class is content (B2). Format (B4) and supporting materials (B5) are really immaterial for C-Class. I am glad to pass an article for C-Class if it meets B2 but fails all of B4 and B5 and

9232:

Hi, thanks. I have checked logs of 149 and found they are focused on article namespace, however, most spams are coming from user namespace and subpages of that. Could we expand this filter? Or shall I request on

35613:

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

3296: 36216:"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 ( 6909: 5275: 3679:

inconvenience. Specifically: implementing Fred's idea would not make any IP user's viewing experience worse than it is now; it would only improve the experience of other users. I don't see a downside to this.

5793:, 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. 3550:

isn't), especially if the article has had to be actively cleaned up from multiple varieties. I think bots can (or at least would have the capability to) standardise in some cases, e.g. adding or removing the

2099:

Agree (with everyone except Hawkeye7); this will never fly. Except for the GA ones, very very few DYK articles are assessed as B (although I think we have a general problem of under-rating in assessments).

7010: 7004: 5315: 2595:

being replaced by the MILHIST criteria, rather than the opposite, but would support MILHIST opting-out if that isn't done. Perhaps a discussion on the enWiki-wide criteria should precede the MILHIST vote?

2162:, but there are a lot of cases where a reviewer rightfully wants the nominator to take the article vaguely in that direction if it's too far away, and DYK will generally uphold those requests. I mean, you 1181:

Quality assessments define how close we are to a distribution-quality article in terms of completeness, organization, prose quality, sourcing, wikilinks etc. Most projects follow the general guidelines at

35502:

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.

5327: 4841:

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. -

5848:

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.

1599:

the ability of certain WikiProjects to choose their own assessment is retained if they so desire. But there are many that don't seem to care and there's no need to make those projects assess everything.

6498: 7353: 7156:

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 Knowledge (if it's compatible with PAG). --

2244:

for the topic area of each wikiproject, which generally would not be the same until it reaches A-class or FA-class, where all assessments would need to reach A-class or FA-class to meet that level. --

2995:

I don't understand why there's a dozen or so comments which assume that there's any doubt as to whether MILHIST can keep its own grading criteria, when that's a fundamental part of this proposal. The

7803:

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:

7541:

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.

3609:, etc. were templated to conform to your ENGVAR regardless of the topic's ENGVAR. Number templates could default to lakh and crore instead of thousands and millions for our Indian readers. To me, 1236: 7315:

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. --

4411: 1740:

are reasons for allowing projects to have custom assessments, not because this is how you'd design a system from scratch but because there are active communities that find these ratings helpful. —

7197:

When I wrote "or Knowledge (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. --

7062: 6403: 4268: 3754:) 01:54, 7 February 2023 (UTC) Clarifying: agreeing with the STOP sign from the admin; disagreeing with placing any more of these. Place the bot in reverse, and have it undo all the ones it did. 2427:

This will make things so much easier. And some wikiprojects seem to not have some levels of criteria, leading to articles being rated as, for example, Start Class and C class at the same time. ―

35625:- 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. 7107: 2805:

That is a generous offer. This would need to be carefully tested in the sandbox; the number of articles is large, and the template is complicated. A Bot run may be needed to aid the conversion.

2487:

local one (if the banner says B-Class but the checklist hasn't been filled out, perhaps you would prefer to be in an "unassessed" (or perhaps "half-assed" or something) category for MILHIST). —

2443:

A better example is that some projects still don't have Redirect-class or Disambig-class, which are shockingly still considered "Non-standard grades" (I'll propose standardization posthaste on

1346: 1145: 1338:

A future project may consider bulk change to remove |class= values from wikiproject banners where the value is the same as the article level class, and where the wikiproject uses the general

5355: 3188:

in principle, Will there be any way to see what changes are made relating to a specific project?, like which B-classes get downgraded to C or start and which C or start end up as B? · · ·

5977:. I don't think that this sort of top-down approach is workable on a site as large as Knowledge is. We function, to the extent that we do, because of our collaborative culture, and while 5951: 5424: 3279: 8079:

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

7866:

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

5212:

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. —

3912:

I'm not sure that even that isn't a solution in search of a problem. Surely it's better to have sourced content with Us and Zs in incongruous places than to not have the content at all?

36428:

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

36734:, et cetera. I think that this is a reasonable search term; I've had to type the codes into google to figure out what they've referred to when looking at datasets in the past. We have 8083:. 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." 2061:

breadth of coverage provide substantial value to the encyclopedia, and we need some system to reward creators while evaluating that sort of work (which is what DYK functionally is). —

7341: 6334:

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,

35916:. 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. 36833: 5314:, 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 1677:

with an opt-out for projects that have their own criteria. I also propose integrating things better with tools like Rater.js, which makes assessment and proper tagging much easier.

1544:. I think this is a great improvement. Updating assessments will be quicker for editors (change once, rather than for each project). The banner looks good and communicates clearly. 35931: 5954:(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. – 4764:

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).

4496: 1828:

I don't see how article quality would vary like importance does, so this seems like a pure upgrade to me. I've never really seen an instance of quality differing across projects.

7597:

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?

7367: 5722:

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

35629:

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:

7627:

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? --

4646: 4624: 4618: 3371:

The 'Possible backlinks' link (left sidebar under 'Tools') is very useful for helping to integrate new articles into the encyclopedia, as is recommended by the lead sentence at

35599:

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.

36695: 36541:, 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. 36068:) 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, 8376:

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.

6114:(WMF VP, Global Advocacy) is deliberately attempting to interfere in UK legislation that would (potentially) hold tech executives liable for their organisation's misdeeds by 36995:

I would be happy to. Do you know of any script that converts a Microsoft Excel document into a Wikitable? I'd be happy to post one here if I can get the formatting fixed. —

5384: 4550:

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

3288: 36115:

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.

36073:

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.

7957:. 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 7486: 5164: 5068: 4613: 4518: 1732:: this aligns with common practice, where an article is rated the same class across each project banner, even if the editor who makes this assessment is only a member of a 36113:

I'm of the opinion that English Knowledge would benefit massively for a bot to create missing populated settlements which are near start class upon creation and consistent

5301:

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

4467:(even low-resolution). There may be jurisdictions where the use of copyrighted logos is illegal too. That's why these files are local to each language-specific Knowledge. 4219:, the idea being (correct me if I'm wrong) that an Indian reader will still understand "100 million" but a non-Indian reader is unlikely to be familiar with "10 crore". — 7142:, 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? 6001: 5790: 4095:, per Xaosflux. I can sympathise with the intent, but mass changes can very easily become disruptive and there's no pressing need that justifies it in this circumstance. 37014: 36091:

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

6407: 6399: 2297:

Absolutely. I've same reply InfiniteNexus as above. Articles and individual projects can have their own requirements if need be, but a general guideline would suffice —

2118:

I may have misled you. Our B5 criterion requires that an article "contains appropriate supporting materials, such as an infobox, images, or diagrams." My own article on

4527:

has something like this already. The reason it's not more widely adopted is probably because other WikiProjects don't see the need and/or there's not enough interest. —

2584:

Opt-in poses a problem since so many WikiProjects are inactive. Couldn't a bot deal with this effectively, avoiding the need for manual intervention? I also agree that

5950:

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

5569: 3311: 35540:(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. 5663: 3485: 2520:, I am not presuming that at all; discussion is ongoing, and if the proposal passes, I will put it to the project for a vote. But this is a make-or-break criterion. 36330: 6419: 6127: 4897:

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.

3259: 36307: 35881:

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 "

6491: 6274: 5535: 3236: 36379: 6188: 6046: 5604: 5458: 4572:

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.

3061: 1576: 1360: 36302: 9291: 6573: 6205: 6145: 3973:, not seeing what the value of these templates is. The dmy and mdy templates actually have purpose, interacting with the citation templates. The documentation of 36668: 6918: 5990: 5678: 5640: 5589: 4431:

What you are proposing would be a violation of copyright laws. We are not about to leave ourselves open to lawsuits like that for cross-platform convenience. As

50: 6102: 6085: 5713: 5625: 5499: 36364: 6379: 6230: 6163: 6066: 5414: 4357:

I am a car fanatic and I have a request. Please can you make some car manufacturer logos available for use on different Wiki languages when creating articles:

3447: 3393: 36031:

The articles are covered by GEOLAND, and having checked a dozen or so I'm not seeing issues. They appear better than many such stub location articles. -- LCU

6473: 6439: 6324: 6257: 6013: 5925:

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

5552: 3693:

It works perfectly on the Chinese Knowledge, where you do not need to log in to switch between simplified and traditional Chinese (and a few sub-varieties). —

3224: 37319:. There are userscripts that do this automatically (visually only, not actually in source) for those who want it. Just use those - no need to poke the bear. 35863:

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

7373: 5378: 1175: 7981:

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.

5342:

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?

4730: 6375: 5981:

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. --

5036: 3344: 3257: 37017:

for a couple of Toolforge tools that will convert tab-separated text into wikitext tables, so you can try copying and pasting the cells into those tools.

6348:

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. –

3977:

says that all it does is add a category, in which case all it does is duplicate the talkpage notices (themselves not always a great use of screen space).

1157: 37053: 36982: 36116: 35917: 35868: 35826: 35789: 35588:

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.)

9265: 9156: 9087: 9015: 8979: 8363: 8282: 8247: 8213: 6266: 5241: 3929:

Agree, in fact I suspect most pages are not fully MoS compliant, and in general MoS issues are pretty far down the priority list of editorial standards.

2517: 7513: 7026: 4821:, 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? 2974:

articles with many WPs listed, and only half of the WPs have been assessed for quality rating, even though generally it should be the same for all WPs.

6924:

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 Knowledge. Best,

4144: 3492:

to be classified as a maintenance template, but it really is not a maintenance template because no maintenance is required on these articles. — Martin

36972: 2920: 2051: 37061: 37008: 36990: 36744:

for language codes, and the plan would be to do a similar thing for subdivision codes—so long as there isn't any conflict with existing redirects. —

36173:

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

8993: 8168: 8136: 7905: 7550: 4417: 4403: 1737: 8246:. 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. 4986: 3986: 36905: 36859: 7569:

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.

7090:

It would be nice if Wikimedia Foundation had a commercial web hosting division that allowed one-way direct wikilinking to Knowledge's articles. --

4965: 4686: 4335: 4018:

There is some value some of the time, but that is already provided for by the talkpage templates (which are indeed sometimes put in edit notices).

3538:

I see the value in having an explicit statement that a given variety of English is used on an article when it is not obvious which should be used (

1482:. This is a long-overdue simplification. There's no need for article-class to be project specific, when the assessment criteria are overwhelmingly 36776: 36757: 36713: 8371: 8255: 8236: 7606: 4321: 3955: 3938: 3924: 3601:

If only there were a way to make everyone happy. There could be a setting in your preferences asking what your preferred ENGVAR is and words like

37242: 37079: 36612:. The proposal is incomprehensible jargon because even an experienced editor like myself has no idea what those various B numbers are. And, as 36258: 36124: 8117: 7726: 7684: 7640: 5526:. It would be grossly improper for the en.Knowledge community to in any way endorse a 'code' being imposed without consensus by an outside body. 5022: 4203: 4166: 2963: 2943: 2862: 2447:). But newbies who don't use the Rater tool would never know it, and would be confused why 3 projects say "Redirect", and one project says "NA". 2179: 2092: 2076: 2042:

require all DYK submissions to be B class is also a non-starter when different projects have very different requirements for what B class means.

1588: 1390: 37276: 37206: 36796:

I tend to use Knowledge where possible since it's ad-free and respects users' privacy, hence I'm in favour of creating redirects such as these.

9195: 7572:

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

6541: 4919: 4892: 4868: 4343: 4248:

may actively discourage casual editors who should be most concerned with adding relevant verifiable content, not which spelling their prose used

3353: 2379: 37325: 37044: 37026: 36955: 36937: 36889: 36845: 36791: 36051: 35784:

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,

4426: 4306: 4285: 4047: 4027: 4013: 3763: 3688: 3673: 3265: 3042: 2345: 2253: 2224: 1883: 1127: 1123: 1119: 1115: 1111: 1107: 1103: 1099: 1095: 1091: 1087: 1083: 1079: 1075: 1071: 1063: 1059: 1055: 1051: 1047: 1043: 1039: 1035: 1031: 1027: 1023: 1019: 1015: 1011: 1007: 1003: 999: 995: 991: 987: 983: 979: 975: 971: 967: 963: 959: 955: 951: 947: 943: 939: 935: 931: 927: 923: 919: 915: 911: 907: 903: 899: 895: 891: 887: 883: 879: 875: 871: 867: 863: 859: 855: 851: 847: 843: 839: 835: 831: 827: 823: 819: 815: 811: 807: 803: 799: 795: 791: 787: 783: 779: 775: 771: 767: 763: 759: 755: 751: 747: 743: 739: 735: 731: 727: 723: 719: 715: 711: 707: 703: 699: 695: 691: 687: 683: 679: 675: 37152:. There is a long-established consensus against templates for marking votes, in particular because they encourage voting over discussion. See 36651:

B2, and dropping the rest, to echo your and Andrew's comments (or dropping the B-jargon and saying "citations" and "coverage" or equivalents.

36630: 36452:

I hate to ask this, but does anyone outside of MILHIST and I guess the 1.0 Editorial Team actually care about the non GA/FA article criteria?

36441: 36423: 36409: 36395: 9164: 9146: 9116: 9095: 9078: 9023: 9005: 8987: 8385: 8290: 8272: 8092: 8073: 8029: 8014: 7975: 7944: 7929: 7894: 7879: 7856: 7841: 7798: 4490: 4447: 4105: 2843: 2419: 1851: 1690: 37018: 36963:

process. Might be worth including some tracker for codes where the target page doesn't exist, or is itself a redirect, for manual follow up.

36811: 36783: 36475: 36142: 35952: 35876: 35858: 35504: 7703:

a problem; it's clear evidence against needing any ECR sanctions, since so little of those discussions is taken up with any such people. --

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

it's called) would reduce abusive reporting by allowing another level of review, one of the things I like about the enforcement guidelines.

6520: 5694: 5516: 5504:

I see that an abolitionist's words on fighting against racial inequality are being compared and applied to a code of conduct that prohibits

5230: 4663: 4062: 3702: 3213: 3023: 2990: 2870:

and hopefully this would include a new tracking category for globally unassessed articles, whether they have a Wikiproject attached or not.

2438: 2396: 1940: 1803: 1612: 1468: 1452: 1437: 37228: 37168: 36461: 35925: 35895: 35834: 35815: 7327: 6933: 6632: 5938: 5920: 5893: 5768: 5736: 4795: 4773: 4420:

Non-free images cannot be used cross-wiki, but nothing is stopping you from uploading a local copy if the home wiki allows non-free media.

3504: 3380: 3178: 2314: 1923: 1786: 311: 307: 303: 299: 295: 291: 287: 283: 279: 201: 197: 193: 189: 185: 181: 177: 173: 169: 165: 161: 157: 153: 149: 145: 141: 137: 133: 129: 125: 121: 117: 113: 109: 105: 101: 37309: 37261: 36508: 36234: 35999:

all mass-created articles (except those not required to meet WP:GNG) must cite at least one source which would plausibly contribute to GNG

35549: 35497: 9279: 9255: 9242: 9223: 7738: 7716: 6996: 6982: 6961: 5173: 4678: 4567: 4232: 3869: 3811: 3643: 3336: 3139: 3112: 3097: 3083: 2903: 2887: 2757: 2579: 2481: 2330: 2289: 2166:

make the case that all DYK articles are B-class if you stretch them broadly enough, just because of how much hedging this guideline does.

2036: 2019: 2007: 1984: 1964: 1866: 1559: 1536: 1383: 36660: 36642: 36557: 36491: 36276: 36046: 36010: 35989: 35974: 35728: 35667: 6593: 5965: 5837: 5822: 4545: 4476: 3574: 3509:

To be frank, I think the problem is with the template. What purpose does the template serve? Perhaps the idea is so discrepancies like a

3384:

candidates. Can we get this useful tool updated to drop the prefix, so users can more easily prepare their backlink article set? Thanks,

3160: 3008: 2718: 2456: 2149: 2133: 2113: 1837: 1761:- I think this is a good idea as long as WikiProjects with their own more specific assessment scales are allowed to retain them, such as 36942:

As specified above, I wouldn't touch anything with a name clash during a mass creation. I agree that those are best handled manually. —

36819: 36805: 36248: 35524: 35512: 35458: 7584: 7306: 7281: 6454: 6343: 5784: 5438: 4461: 3888: 3658: 3596: 3431: 3416: 2610:

The opt-in projects do not have to do anything. As pointed out above, a bot could at some point run through the articles taking out the

1753: 1629: 36810:

Sure; I think it's better to improve Knowledge's search capability, though, without requiring editors to create innumerable redirects.

35565: 7214: 7192: 7173: 7134: 5388: 5091: 5077: 3628: 2816: 2776: 2690:

If banners differ between their quality ratings, categorise them for human review, and assign them a proper class at the article-level.

2641: 2605: 2511: 2496: 2270: 1650: 1496: 1133: 36871: 36532: 35797: 9301:

Table of articles created by Semsûrî on villages and municipalities in Turkey, between December 2022 and February 2023 (2010 articles)

7694:

experienced editors. I have spent 5+ minutes paging through them, and while I'm sure a small number of comments in those discussions

6359: 6073:

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.

5856: 5802: 5184: 5150: 4847: 4834: 4812: 4581: 3379:, but it doesn't work while an article is still in Draft space. I often develop in Draft space, and one part of my launch plan is the 3247: 1724: 1513: 1419: 1405: 1223:

parameter, can continue to record these assessments on their project banners and link to their specialized quality assessment scales.

37295: 36107: 7563: 5249: 4717:

is the issue argued, then swap them. Or maybe combine "alerts" and "notices" to save space. Or whatever other ideas people may have.

4713:

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

4004:, than as a inline template in the article? We don't really need to know what version of English it is, unless we decide to edit it. 1522: 1144:

Strong support and no objections, so the project to implement it will proceed. Discussion on technical implementation has started at

37173:

I will echo what The Earwig says in that there's been longstanding hesitation around making those templates. There already exists a

36600: 36580: 36357:

Grades provide "gamification" that incentivise article expansion, so the more precise they are, the more effective the incentive is.

35231: 4085: 3943:

I like my articles to look pretty and be neatly formatted and consistent throughout. But most of all I like them to be informative.

36208: 36165: 35779: 35703: 11987: 7419:

area is among those most capable of causing real world harm. For these reasons, I'm proposing the creation of community-authorized

5560:

as it is inappropriate to enforce something that is not approved. Current codes and practice handles inappropriate behaviour here.

4735: 4631: 4254: 1667: 36082: 35802:

I believe the Lugnuts problem involved mass-use of unreliable sources (as opposed to here, government sources), and violations of

35714: 35686: 35608: 35485: 27678: 11948: 5998:

UCoC violations that happen on a single wiki: Handled by existing enforcement structures according to their existing guidelines...

5118: 4852:

Most newcomers are using the Reply button, so they don't have to count colons any longer. The learning curve is essentially flat.

2672:

If all banners (of the WPs that didn't opt-out) show same quality rating, run a bot to introduce it directly at the article-level.

36727: 36719: 36360:

These criteria provide clearer guidance for editors wishing to improve Start-class articles, who may be unsure of where to start.

35748: 24259: 8221: 7125:

for details). This doesn't guarantee, of course, that any given MediaWiki installation will choose to keep this default enabled.

6388:

oth the UCoC and the enforcement guidelines (after ratified), will also be open for review and voter-endorsed amendments annually

5133: 4758: 2306: 2081:

Theoretically yes, but in practice articles that are fully referenced but fail one of the other B-class criteria are quite rare.

36587:

Should I turn this into an RFC? Would be nice to get wider community participation ruling on this one way or another, before we

33866: 8174: 5207: 35762: 7289:, does it allow wikilinks to work between your website and Knowledge? If so, do red wikilinks work in the same way as here? -- 7051:. Questions about what features a particular third-party hosting provider has are best directed to that provider, for example 4139: 2175: 67: 37031:

I'm getting a terrible error when I try to copy-paste into VE. I'll take a look at those tools. Thank you for the pointers! —

35934:) 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 34217: 19189: 5054: 36925: 35788:). If Semsûrî limits themselves to the more expansive articles that would be fine, but the majority of the articles are not. 18968: 17044: 13950: 12000: 6867: 5509: 5269: 3991:

Playing Devil's advocate here a bit: there is a legit value, imho, in having some of them, some of the time: for cases where

2732: 2562: 1331: 1324: 37213:

These are in widespread use on other language Wikipedias, so their absence on en.wiki often surprises multilingual editors!—

14457: 7443:

that limits all editors to a single revert in 24 hours (unless it's to enforce the previous point or remove clear vandalism)

4435:

points out, different language Wikipedias have different rules about non-free media use in certain limited circumstances. --

87: 36154:

Conditional on them having the amount of content and sourcing in the first three of the 4 listed examples, or close to it.

29745: 24246: 12988: 7074: