Extraordinary General Meeting, March 2025

by amdj

Note

This meeting was scheduled as an extraordinary general meeting (EGM) due to the February MGM failing to obtain quorum. This was necessary because the March MGM was also the scheduled annual general meeting (AGM), whose agenda was already quite long, and the bylaws state that only one MGM may occur in each month.

Proposition and motions

Board composition & restructuring

The January 2025 MGM proposed a new board structure whose discussion was then moved to the all-staff e-mail list.

That e-mail discussion thread was reviewed during this EGM and approved unanimously; the board now has a chair, a treasurer, an operations team representative, and two general board seats.

The two general board seats are occupied by organisation members who announce their candidacy for election by the entire membership, rather than be put forward as a team representative by the members of that team.

The operations team continues to have a dedicated board member, who must be a member of that team.

Codifying how people change membership status

The meeting sought to take first steps toward codifying how members withdraw from the organisation or change between ordinary / quorum status.

It was noted in the January 2025 MGM that changing one’s quorum membership status is not particularly visible to all members. More discussion on this topic occurred on the all-staff e-mail list, and that was visited during this EGM.

It was quickly decided that having both operations be very visible to all members and ideally triggered by the organisation member in question was a good idea.

It was decided to not codify a particular method into the bylaws; for example, making a GitHub pull request against the staff & members CSV was a popular idea, but writing that into the bylaws would cause issues for anyone having trouble accessing GitHub.

Other questions

Should we adjust the default channel creation mode?

At the moment, creating a new (unregistered) channel sets the default channel modes to +Cnst. This forbids CTCPs (except /me), external messages (from people not in the channel), changing the channel topic (unless done by a channel operator), and the channel from appearing in public lists or searches (e.g. /whois, /list, and ALIS).

A concern was raised that projects may create new channels as and when required, register them, and then fail to unset the +s channel mode when they don’t need it enabled for some specific reason.

It was decided that staff would reach out to various projects whose channels are +s without an obvious reason, in order to draw attention to the fact that their channels are not discoverable by our users.

It was also decided that we would make some form of public announcement, either a WALLOPS or a blog post.

Finally, it was also decided that we will have ChanServ send an additional notice to people when they register a channel, explaining that it is +s by default, and providing instructions for how to unset this if this is not desired.

Should we change the default MLOCK setting?

The default MLOCK setting (applied to newly-registered channels) at the time of this EGM was +nt-lk. It was noted that the MLOCK setting is also applied to registered channels that are being re-created (no-one is in them when someone joins), and thus keeping at least +nt was a good idea.

The option of enabling GUARD by default was noted, as it would reduce the need for MLOCK to set channel modes on channel re-creation. This setting makes ChanServ stay in the channel while it is registered, and thus ordinarily prevents a registered channel from being destroyed (because not everyone has left it). It was quickly decided that this is a bad idea, as people routinely register channels and then leave them for months at a time, and having that extra overhead is undesirable.

This topic was originally proposed because someone wanted to set +k on a newly-registered channel and couldn’t (due to the MLOCK including -k).

It was thus decided that the default MLOCK will not include -k or -l.

It was also quickly decided that the default MLOCK should include +C, to match the default channel creation modes (with the exception of +s).

Thus, the new default MLOCK setting, applied to channels registered beyond this point, is +Cnt.