We desperately need more ops in #ubuntu.

Sun Dec 17 14:15:47 UTC 2023

Dear Ubuntu IRC Council,

I hope this finds you in good health and high spirits. I would like to follow up 
on this proposal with my own comments, and propose some steps forward. As you 
will read, I am not happy with quite a few elements, but you should not take 
this personally; someone MUST be firm about this.

Firstly, I am quite appalled by the reaction from the IRCC on this proposal. 
 From my understanding, this is generally being treated as, "Aaron just wants to 
be an IRC operator, and is making a huge fuss about it." That is NOT how we 
treat contributors in Ubuntu(!), and goes directly against the Code of Conduct:

(* = [*])
"Collaboration between teams that each have their own goal and vision is 
essential; for the whole to be more than the sum of its parts, each part must 
make an effort to understand the whole. Collaboration reduces redundancy and 
improves the quality of our work. Internally and externally, *we celebrate good 
collaboration*. [...] Our community is open, and any responsibility can be 
carried by *any* contributor who demonstrates the required capacity and competence."

Aaron took a large amount of time, as a volunteer contributor, to prepare this 
proposal for you all, and it is *quite* disrespectful that you seem to be 
discarding it. Inactivity is understandable at this time of year, but to my 
understanding, a quorum of the IRCC is active, so why was Melissa's response 
considered adequate in any way, shape, or form? #ubuntu is *literally* the 
frontpage of Ubuntu on IRC, this should be at the *top* of the IRCC's list.

Perhaps you are misunderstanding the urgency of this request; after talking to 
several key players within the community, the general consensus is, even if 
Aaron's data may need to be slightly adjusted, *he's right*. We NEED more IRC 
operators in #ubuntu. Some events may be false flags, but we are all human. If a 
pattern needs to be corrected, address it head on, *do not* talk about it in a 
clandestine manner as a point against someone being an operator, without doing 
anything about it. If you think someone is too aggressive in calling the 
operators, or as an operator banning people, *you need to address it, that is 
your job as the Ubuntu IRC Council*.

Do better. I'm not going to respond or read your angry PMs about how I'm 
overreacting, because *I'm not*. I will *not* let the IRC Council get away with 
treating someone, especially Aaron Rainbolt, like this. I am formally asking you 
to fix this, immediately. He deserves better than this.

Aaron, you did a really great job with this proposal. I really appreciate all 
the time and effort you put into this. Comments inline.

On 12/15/23 02:16 PM, Aaron Rainbolt wrote:
> Good morning/evening, and thanks for your time.
> 
> I wish to call attention to the current state of affairs as far as channel 
> moderation in the #ubuntu IRC room. Based on both recent and past activity, it 
> is my opinion that we do not have enough active IRC operators present to handle 
> the current rate of spam and disruption that flows into #ubuntu on a regular 
> basis. This can be shown by viewing the IRC logs for the #ubuntu room over the 
> last two years.

One-hundred percent agreed, qualitatively to start. #ubuntu is the frontpage for 
Ubuntu on IRC, so if additional moderators put themselves forward, the IRC 
Council should make it a priority to review those.

> To obtain the needed data, I grabbed all of the #ubuntu IRC logs over 2022 and 
> 2023, then scanned for events that needed operator intervention. I have defined 
> an "event that needs operator intervention" as being any discrete event within 
> the channel wherein which the !ops trigger was used due to an actual rule 
> violation, and the offending user did not cease misbehaving after the trigger 
> was used (or the misbehavior was very serious). Multiple !ops triggers in 
> relation to the same user are considered a single event, and illegitimate or 
> potentially overzealous uses of the !ops trigger are disqualified. From this 
> list of events, I then studied the logs to find all events that needed operator 
> intervention where no intervention was present. I have defined "operator 
> intervention" as being any activity by an operator listed by ubottu when the 
> !ops trigger was used, with such activity being at least somewhat in relation to 
> the misbehaving user's activity. Any visible or suspected activity is qualified. 
> Finally, any events which resulted in Libera staff stepping in are considered 
> the same as being handled by the ops team statistically (though are 
> distinguished from normal operator intervention).

I understand some heuristics are involved here, and I honestly agree with it; 
there is not quite a clear definition of what exactly defines an "event that 
needs operator intervention" and I could not have said it better myself. If 
anyone has ideas on how we can define this better, without saying "most calls to 
!ops are overzealous" (which, to my understanding, is a common opinion), I think 
we'd really get somewhere.

> I do note that the IRC logs do not keep record of joins, leaves, bans, kicks, 
> etc. Some of this info may be inaccurate as a result, though I suspect it is 
> mostly reliable as usually someone says "thanks" when a user gets banned, or the 
> operator says something.

In my experiences, when doing these types of analyses, I tend to use my own IRC 
logs. Of course, there are netsplits to worry about, but that will give you a 
more complete view of these items. They intentionally filter some of these 
events out from the IRC logs.

> In my personal opinion, if more than 15% of events that needed operator 
> intervention go unhandled, that likely means we need more active operators. 
> According to my study, the percentage of missed events is over double that. I 
> therefore conclude that we desperately need more ops in #ubuntu, and would like 
> for the IRC operator team to consider having a vote for additional IRC operators 
> in that channel.

Not disagreeing, but where did you come up with 15%? Where exactly should we 
draw the line here, and why?

> Thank you for your consideration.

For moving the needle forward, we should be thanking *you*!

> Here are the results of my study:
> 
> Number of events that needed operator intervention: 58
> Number of events handled by operators: 35
> Number of events that needed operator intervention where no intervention was 
> present: 23
> Percentage of unhandled events: 39.65%

(Small note; the most accurate percentage given the rule of significant digits 
would be 40%, rounded up.)

> Event list:
> 
> 2022-01-12: offending user Guest36, operator intervention from JackFrost/Unit193
> 2022-01-21: offending user elinfo, operator intervention from tomreyn
> 2022-02-23: offending user yrdsb, operator intervention from el
> 2022-03-05: offending user Kolusion, **no operator intervention**
> 2022-03-08: offending user merc (who ironically reported himself), operator 
> intervention from krytarik
> 2022-03-19: offending user oneone, operator intervention from krytarik
> 2022-03-26: offending user thelounge8575, **no operator intervention**
> 2022-04-03: offending user 079AAAL91, Libera staff intervention from A_Dragon
> 2022-04-09: offending user Phalor, **no operator intervention**
> 2022-04-11: offending users yrdsb and x0x, **no operator intervention**
> 2022-04-15: offending user PHDQue, *minor* operator intervention from CarlFK but 
> spam was left unchecked for over 30 minutes after the initial !ops call, thus 
> considering this **no operator intervention**
> 2022-05-04: offending user LinuxAspy, **no operator intervention**
> 2022-05-13: offending user Guest459, operator intervention from Unit193
> 2022-05-21: offending user NateDoge, operator intervention appears to have 
> occurred but op cannot be identified from logs
> 2022-06-03: offending user SleepyMario, operator intervention from tomreyn
> 2022-06-21: offending user funnyboy243, operator intervention from Unit193
> 2022-06-21: offending username inappropriate, operator intervention possible but 
> not apparent
> 2022-06-22: offending user retardedme-, operator intervention present, 
> presumably from Unit193
> 2022-07-04: offending user pitiless, **no operator intervention**, severe incident
> 2022-07-15: offending user filename, **no operator intervention**
> 2022-07-16: offending user nshire, operator intervention appears to have come 
> from a bot of some sort
> 2022-07-25: offending user Guest1845, operator intervention very likely
> 2022-08-12: offending user blei, operator intervention from sarnold
> 2022-08-14: offending users ZuppaVideos and ronmerkle, operator intervention 
> from krytarik and Bahhumbug
> 2022-09-05: offending user BASHitup, operator intervention very likely
> 2022-09-11: offending user scribz, **no operator intervention**
> 2022-09-14: offending user Morpheus_37, operator intervention from genii
> 2022-09-20: offending user lagunalorre, operator intervention from Eickmeyer
> 2022-10-18: offending user samouy, operator bot appears to have been triggered
> 2022-10-19: offending user supremekai, operator intervention from sarnold suspected
> 2022-12-05: offending user lagunaloire123, operator intervention from Unit193
> 2023-03-17: offending user Guest64, operator intervention possible but not apparent
> 2023-04-13: offending user invitado, **no operator intervention**
> 2023-04-23: offending user tyrell_willick6[, operator intervention from el likely
> 2023-04-24: offending user KIRIESHKA, **no operator intervention**
> 2023-04-25: offending user KIRIESHKA, **no operator intervention** again
> 2023-07-21: offending user fastwifi_, operator intervention from Unit193
> 2023-08-09: offending users zeroadrenaline and mort, operator intervention from 
> hggdh for mort and *maybe* for zeroadrenaline
> 2023-08-17: offending user diamat, operator intervention from genii
> 2023-08-22: offending user Phalanxer, **no operator intervention**, severe incident
> 2023-08-26: offending user diamat_, operator intervention from tomreyn, no !ops 
> trigger used but severe enough to mention nonetheless
> 2023-08-29: offending user WHATEVERYEAH (suspected to be Kolusion), **no 
> operator intervention**
> 2023-09-06: offending user HackerII (aka `oerheks, note backtick at beginning of 
> name), operator intervention from genii
> 2023-09-22: offending users mina34, delmina, and possibly Guest22, operator 
> intervention from el
> 2023-09-23: offending users casualuse and casualus8, **no operator 
> intervention**, severe incident
> 2023-10-03: offending user Reyaina, operator intervention possibly from tomreyn
> 2023-10-08: offending username inappropriate, **no operator intervention**
> 2023-10-09: offending user corey-aid (and several other nicks), **no operator 
> intervention**, moderately severe incident
> 2023-10-10: offending user notliks, **no operator intervention**, severe incident
> 2023-10-17: offending user con, operator intervention from el
> 2023-10-25: offending user naruto69, **no operator intervention**, severe incident
> 2023-10-26: offending user ruhsayngone, **no operator intervention**
> 2023-10-27: offending user kokomop3n0r, operator intervention from krytarik
> 2023-10-27: offending user Guest42, **no operator intervention**
> 2023-11-08: offending user librehats, **no operator intervention**
> 2023-12-01: offending user elias_a, **no operator intervention**
> 2023-12-08: offending user lagunaloire123, operator intervention suspected
> 2023-12-10: offending user violetflame, operator intervention from el
> 
> -- 
> Aaron Rainbolt
> Lubuntu Developer
> Matrix: @arraybolt3:matrix.org
> IRC: arraybolt3 on irc.libera.chat
> GitHub:https://github.com/ArrayBolt3
> 
> 

In my own, personal capacity,
-- 
Simon Quigley
simon at tsimonq2.net
tsimonq2 on LiberaChat and OFTC
@tsimonq2:linuxdelta.com on Matrix
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-irc/attachments/20231217/72578d01/attachment.sig>