User:Barkeep49/U4C
This is a blog reflecting on work that the U4C has done and/or things that I've learned about how other communities go about their work that I want to share with English Wikipedia. I'm going to write it largely expecting my audience to have no idea what I am talking about because they're not really following the U4C (and sometimes because I'll be talking publicly about another wiki where the underlying request itself is private). My plan is to update this approximately every 3-4 weeks with something, with additional updates if something really strikes my fancy.
Disclaimer: This is written solely by me and without consultation of any other member of the U4C. I try to be clear where I am giving my own opinion and where I am summarizing U4C positions but where there's any ambiguity assume it's only my opinion and doesn't necessarily represent the thinking of any other U4C member.
Glossary
|
|---|
|
January 2025: Building the plane while flying it
[edit]A smaller update this month. One reason I wanted to be on the U4C was to build the systems that I knew would likely guide the committee long after I left it. During the time when several of us were elected but we didn't have quorum we did a little work with this. But for the most part we have been building out or processes as requests have required it. There are some benefits to this and some drawbacks. Benefits include less having to worry about the abstract, as the specific issue helps focus not only that but also gives shape to other ways it might happen. We aren't, in other words, getting lost in "what ifs". The negatives are a reason this months' entry is so short: it really slows down our decision making. I'd hoped to be able to write about a particular decision. But that decision isn't ready yet, despite broad agreement among u4c members about the problem and the solution, because we're still having to work out the how we're going to structure and announce certain decisions. For a taste of what I'm referring to, see my comments in the current Swahili Wikipedia case where I have a whole bunch of questions and limited answers. The good news is that we do seem to speed up our decision making after we've made decisions. So as we work these out, I hope we can become a better and better commiteee. 18:15, 13 January 2025 (UTC)
In reflecting a little about this entry I realized I missed out an important element of what I hope to do with this blog: bring ideas to enwiki that we might benefit from. In this case, it's really "things ArbCom can maybe benefit from". There are two things. First, the U4C is much less burdened by procedure and far more willing to try something new. Both are mainly because we have to. But I also see a real interst in keeping it that way and being unafraid to continue to tweak. There is also, for most items outside of cases, to have a "with out objection" model rather than one where affirmative consent is needed. Put another way - if an action is proposed and a couple of u4c members agree and no one disagrees things move forward. I am curious if this will be able to last when it's a larger committee and if it is something about the personality of this committee - one very inclined towards consensus - that makes this work.
The other thing I think ArbCom should think about - and this one is I think actually doable - is adopting "Suggested solutions" as a standard part of the responding template and having a dedicated section for interaciton between parties and u4c members. This latter part would likely need some careful moderating - there's been some party interaction that so far hasn't been awful but also wouldn't fly on here - but I think is a huge improvement over the awkward way arbs and parties interact with right now. 02:03, 14 January 2025 (UTC)
December 2024: Case 1: German wiktionary
[edit]Our first "accepted" and resolved case involves the German Wiktionary. This was a nice test case for a number of reasons - including the fact that we largely are using the German Arbcom's style for case requests. I particularly like the "Suggested Solutions" section/requirement of parties which is one reason I suggested it when we started working on those templates.
In terms of this case itself, it resolved around a user who was creating tons of new articles, but in a way that some members of the community found sub-optimal as they were omitting gloss (which are helpful for words in other languages). Eventually an administrator chose to take esclating steps to stop this including a private edit filter aimed at this user and then a block. The user blocked appealed this to the U4C.
The first discussion among the U4C when receiving a request is whether or not we should handle it. We have received some requests for projects with ArbComs. Under the enforcement guidelines the U4C basically needs to leave these along except in the case of systemic failures. I'll probably blog about systemic failures another time. However, at least with this committee, we've also been inclined to defer to local processes even for projects without ArbComs. This was an important element of many U4C members declining a request which focused on the Arabic Wikipedia. In this case, it seemed like local processes weren't sufficient to responding to what had happened and so we agreed it was reasonable for us to handle it. This all happened behind the scenes because we were still setting up the public request system and so this request came in via email.
One feature of U4C requests which is different than enwiki ArbCom (enAC) is that there is a set period for the case request stage - 2 weeks. Basically at the end of that time a majority vote decides what happens. The U4C can choose to waive this when/where appropriate in either direction. In this case there was a bit of "ok what do we do now" after it became clear we were going to accept this case. Eventually we decided to resolve by motion. This way of resolving cases is something I brought to the committee from enAC. I personally liked the motion we came up with: we unblocked the filer and warned him for civility, made a recommendation about admins acting when involved (en's version of that here but this was its own thing), and made something between a recommendation and a "you must do this" (even while using the word recommendation) about holding an RfC to see if Gloss should be required.
Even if this weren't our first accepted case taken from start to finish I'd probably still have blogged about it, because of one thing that happened following the unblock. The person who filed the case (and had been previously blocked) started mass creation of new articles without glosses. This shows another project struggling with mass creation of technically compliant but in need of improvement articles. The U4C has no better answer for this than we do. I will be curious to see what dewikt decides in their RfC (already underway). 18:01, 20 December 2024 (UTC)