Replacement filing cabinet
Archived discussion
This page is an archive. Please do not edit the contents of this page, other than for maintenance. If you wish to revisit this topic, please bring it up again in a new thread.
Forums: IndexCommunity discussionsIRC channel reform | Forum new Post

Hello, I'm K6ka, the IRC contact for the wiki. As you may or may not already know, the wiki has an IRC channel on the freenode network, but aside from name and policy, that's where the similarities pretty much end.

The IRC channel is about as separate from the wiki as it can be. Many of the users that frequent IRC seldom or do not edit The Sims Wiki. Some of our administrators use IRC, but often sporadically. And this is where I must point out a fairly serious problem with the IRC channel as wiki activity declines sharply:

  • Currently, as it stands now, we have four tiers of channel operators[n 1]: non-admin ops, admin ops, bureaucrat ops, and the channel contact.
    • Non-admin ops are users who are not administrators on the wiki, but have been granted the ability to use chanop tools on the channel. Currently, their powers are limited to only being able to kick, ban, and set quiets[n 2] on disruptive users.
    • Admin ops are users who are administrators on the wiki. Per policy, administrators on-wiki are implicitly chanops on the channel as well. They have all the powers that non-admin ops have, plus the ability to modify the channel topic.[n 3]
    • Bureaucrat ops are users who are bureaucrats on the wiki. Per policy, bureaucrats on-wiki are implicitly chanops on the channel as well. They have all the powers that admin ops have, plus the ability to modify the channel's access list[n 4] and to set various control flags that can affect the way the channel operates.
    • The channel contact is the most highly-trusted user on the IRC channel. They are given the "founder" flag[n 5] and are responsible for maintaining the channel and keeping it well tended.

Our current system, thus, is very centered around the wiki and operates with the belief that administrators and bureaucrats on the wiki will be very active on and proficient with using IRC. This may have been the case in the past, back when the IRC channel (and the wiki in general) was a lot younger and livelier, but it isn't anymore. For one thing, quite a bit of our activity comes from users who are not administrators or bureaucrats, and do not edit the wiki on a regular basis (or at least, not anymore). Meanwhile, many of our on-wiki administrators and bureaucrats are slipping into retirement, either having lost interest in The Sims, or are moving on with life. From my observations, it's easier to stick with an IRC channel than it is a wiki, and with our current system, bureaucrats that have the permissions needed to keep the IRC channel's future alive are fast diminishing.

The IRC channel, in other words, is essentially being affected by a problem outside of its control, through no fault of its own. With the wiki and the IRC channel being so separate as they are now, it makes no sense that, if the wiki falls silent, the channel must go with it.

So what do you propose, then?
  • Local administrators and bureaucrats should not be automatically given chanop. This is already *unofficially* done to a degree; when I was made administrator, I didn't become chanop until several months later, mostly because I didn't want it. In practice, I always ask new admins wishing to become chanops whether or not they actually want ops, and if they do, I ask them if they have read up on the many IRC guides out there, but I still have a feeling this is not enough. From my observations, the only admins that are at least proficient with IRC are Wogan and me; all others are not exactly experienced even with things like setting bans and quiets, and I definitely do not want them answering newbie IRC questions. Also, we're having fewer and fewer active admin chanops, and recently the vast majority of operator actions on the channel have been from non-admin chanops (excluding actions that I took). Shifting the dependency on admin chanops away from the channel will be good for its health in the future.
  • Flags normally reserved for admin/bureaucrat chanops only should be made available to non-admin chanops. Like what I said above, what's the point of giving admin chanops all these permissions when they do not know how to use them? If many of them can't set channel bans without using client-based commands[n 6] I'm not sure if I can trust them to use some of ChanServ's commands, which can seriously damage the channel if misused.

With the latter point in mind, I want to revamp the chanop hierarchy system for the channel and make it less dependent on a user's on-wiki status and more about how trusted and knowledgeable they are in IRC. The current system is listed at The Sims Wiki:IRC Channel Operators. Here are the new hierarchies I propose:

  • HalfOp (Flags +AVeiorv)
    • Can kick, ban, and quiet disruptive users
    • Can op, deop, voice, and devoice themselves at any time
    • Set any channel modes not under an mlock[n 7]
    • Invite themselves to the channel using ChanServ's invite command
    • Use ChanServ's unban command to unban themselves
  • Op (Flags +AVeiortv) — can do everything a halfop can do, as well as:
    • Modify the channel topic
  • SuperOp (Flags +ARVefiorstv) — can do everything a halfop and an op can do, as well as:
    • Use ChanServ's recover, sync, and clear commands
    • Modify the channel access list (So they may appoint new chanops and remove existing ones. They can also add and remove voiced users)
    • Set and unset ChanServ control flags on the channel (This includes modifying mlock)

The biggest change is the naming of the hierarchies, so that they are no longer dependent on on-wiki statuses. This means that there should be separate processes for attaining chanop on the IRC channel, and simply being an administrator is not enough to automatically get ops. This also means that non-administrator ops can acquire more permissions on the channel (In the event of my prolonged absence, I wouldn't mind a trusted non-admin op becoming the new IRC contact). Secondly, auto-op is not enabled by default, unlike the old system where only administrators were automatically given ops by ChanServ upon joining the channel. Any chanop who wishes to be auto-opped can simply request a SuperOp or the IRC contact for it to be added without further discussion.[n 8] I also want to implement this change in order to weed out ops that don't know how to manually op themselves on the channel, see the section below.

How do we "grandfather" in existing users?

That is a good question. I want to put it out there very clearly that users who are not experienced with IRC should not have chanop. Basically, if you can't set bans, can't change channel modes, can't change the channel topic, don't understand the difference between an IRC network and an IRC channel, don't understand the difference between a kick and a disconnect, don't know how to use NickServ's ghost command, and don't know how to use ChanServ's op, deop, voice, and devoice commands, then you really shouldn't be chanop, because being a chanop requires that you know about these things. However, I also don't want to go and "cleanse" out all admin chanops, so I would like some input on what to do with them.

This is obviously a very significant change that is going to affect a small number of users on the wiki, but it's really time that the IRC channel gained some independence from the wiki.

So, thoughts? (Feel free to ask any question about IRC if you do not know what a term means, because I am aware that 99% of the users on this wiki haven't even heard of IRC) —k6ka 🍁 (Talk · Contributions) 21:49, June 2, 2016 (UTC)

UPDATE 03/06/2016

With regards to the new chanop hierarchy, I would like to make the following changes as to how they would be appointed:

  • Acquiring higher-tiered chanop positions require that previous, lower-tiered chanop be obtained first. So, in order to become an Op, one must be a HalfOp, and in order for one to become SuperOp, one must be an Op. Thus, any new, prospective chanops must first apply for halfop.
  • IRC contacts must be SuperOps before they can apply for the position.

MrC also brought up a fairly good point about inactivity. The Sims Wiki used to have an inactive admin policy, but that has since been repealed and is no longer enforced. There is no expiry system for accounts on Wikia, so accounts that go unused indefinitely aren't automatically desysopped, deactivated, or deleted. This is not the case for freenode, which has an inactive account policy, where accounts that have not been used for over ten weeks will be considered expired [1]. When that occurs, anyone may simply ask freenode staff to drop the account so they can re-register it; if that happens, they lose whatever permissions they had on any channel. I'm open to suggestions about enforcing such a policy on the channel.

k6ka 🍁 (Talk · Contributions) 15:18, June 3, 2016 (UTC)


Okay, as consensus seems to be favourable, the new channel hierarchies have been implemented and the relevant pages (The Sims Wiki:Requests for IRC Channel operator and The Sims Wiki:IRC Channel Operators) have been updated. Now, as I mentioned, the whole purpose of this proposal was to remove chanops that do not know how to use IRC. As such, I suggest the following user right changes be implemented:

  • Beds be deopped due to lack of IRC knowledge (User has voluntarily resigned)
  • LostInRiverview be deopped as he has voluntarily surrendered his op flags (This change has already been implemented, thank you for your services!)
  • C.Syde65 be deopped due to lack of IRC knowledge
  • Nikel23 be deopped due to lack of IRC knowledge
  • WikiBuilder1147 be deopped due to inactivity (According to freenode policy his nickname has pretty much expired and can be dropped at any time)
  • Frostwalker be deopped due to inactivity (Same as WikiBuilder1147)

I still do not know what to do with Random Ranaun, but they have a Wikia vHost/cloak, and I am comfortable with keeping him on the team. Woganhemlock is inactive, but he is the only other administrator who knows how to use IRC, and so I am reluctant to simply deop him.

Again, I know this is a pretty drastic change, which is why I have given targeted chanops plenty of time to respond to queries. I shall give them more time again to respond to this change. I am also very aware that this sounds like a form of punishment or "Arbitration Remedy", but know that I do not mean to deop you because you are at fault; this is not a punishment. You may reapply for chanops through the regular venues once you have attained sufficient IRC knowledge. —k6ka 🍁 (Talk · Contributions) 11:53, June 17, 2016 (UTC)


It has been a month since I started this thread. Relevant policy pages have been updated and the channel is pretty much set. I have waited over a month for affected users to respond; as I believe I have waited long enough, I have applied the agreed-upon changes. The following chanops have been deopped, but will still be voiced on the channel:

Again, like I said, this is not meant to be a punishment, but with the betterment of the IRC channel in mind. If you have any questions or comments about your deopping, you are more than welcome to contact me.

That being said, this thread has gone silent, and since the proposed changes have now been made, I am archiving this thread. Any additional comments should go in a new thread. Thanks, —k6ka 🍁 (Talk · Contributions) 02:27, July 3, 2016 (UTC)

  1. Also known as "chanops", a "channel operator" is the equivalent of a "moderator" in modern chat rooms. They have the ability to kick and ban users, as well as manage other aspects of the channel.
  2. On IRC, a "quiet" works similarly to a ban, except that it merely does not permit its intented target from speaking in the channel. The affected users can still join and leave the channel.
  3. In IRC, a "channel topic" is a short blurb of text that appears at the top of the channel. Historically, it was used to inform new arrivals what the current discussion topic on the channel was; nowadays, it is mostly used as a billboard containing announcements, notices, and other things of note to users on the channel.
  4. On IRC, a channel that is registered with channel registration services, or "ChanServ", will have an access list that can be used to grant certain permissions to trusted users on the channel. On our IRC channel, we use this list to manage channel operators and their different tiers of permissions.
  5. On IRC, the "founder" of a registered channel has full control of the channel. They are marked with a "+F" flag on the channel's access list, and essentially can do whatever they wish with the channel. Their founder flag can only be removed by other founders (including themselves) or by freenode staff.
  6. Most IRC clients have a "Ban" button that can automatically set bans based on the target user's hostname. While this is good for newbie ops or to quickly rid a troublesome user, such bans can be evaded fairly easily. To set more effective bans, a human op that knows what they're doing is needed.
  7. Mode lock, a mechanism used by ChanServ to restrict which channel modes can and cannot be set or unset. For example, if channel mode +C was set, nobody can unset that mode. Similarly, if channel mode -z is set, nobody can set that mode.
  8. freenode generally discourages the use of auto-op, but on #wikia-sims we don't necessarily adhere to this philosophy.


Personally I would be supportive of allowing non-admin channel operators to have abilities that are currently reserved for admin channel operators, and I personally wouldn't have a problem with limiting the ability to modify the channel topic to operators who are more active and dedicated to using IRC.

So overall, I wouldn't have a problem if following changes took place:

  • Current admin operators that aren't very active on IRC, that only became operators because they became admins, were limited only to non-admin operator abilities.
  • Non-admin operators that are active on IRC would be able to have admin operator abilities.

At the present time, I am hesitant to support the possibility of completely revoking the operator abilities from any current admin operators that only became operators because they became administrators.

At least at the moment. I may reconsider changing my thoughts on this possibility in the future. ― C.Syde (talk | contribs) 00:08, June 3, 2016 (UTC)

@C.Syde65: At the present time, I am hesitant to support the possibility of completely revoking the operator abilities from any current admin operators that only became operators because they became administrators. The problem with that is, if we don't remove those flags from said people, it defeats the whole purpose of this proposal — to get rid of ops that don't know how to use IRC. Most of these people barely know how to use their op tools, so not having them isn't going to hurt anybody. They may re-request once they actually have gained competence in using IRC. —k6ka 🍁 (Talk · Contributions) 11:24, June 6, 2016 (UTC)
Well I do know how to kick users from the IRC Channel, but I don't know how to do much else, which is why I wouldn't mind if any other abilities were revoked.
I'm not necessarily opposed to the idea of completely revoking the operator abilities from any current admin operators, I'm just not sure at the moment if it's something that I'm willing to support. ― C.Syde (talk | contribs) 20:37, June 6, 2016 (UTC)
Only knowing how to kick users? Doesn't count for much. —k6ka 🍁 (Talk · Contributions) 11:06, June 8, 2016 (UTC)
Weak support — One side of me is fully supportive of everything you've proposed, while the other side of me is debating whether I should support the idea of revoking channel operator rights from certain admins, even if those admins might not necessarily want their status revoked. But I'm very busy with my other hobbies, which probably explains why I haven't been using IRC much. So hopefully I won't regret weakly supporting this. ― C.Syde (talk | contribs) 22:58, June 9, 2016 (UTC)


I support this proposal as well. I also hope my observations will strengthen your argument.

(Note: When I refer to "channel access" I'm talking about being listed on the channel access control list, which determines who gets to be channel operator and the powers/flags/tools available to that user, not the ability to join the channel and chat).

The thought that the current way of doing things being too rigid had actually occurred to me several times in the past. However, I never brought it up first because I wasn't sure if it was appropriate or my place to do so, given my position. As one of the active non-admin channel operators who has been here a few years, I've observed a few things.

While this could be a subjective impression (I have not attempted to be scientific in any way), I feel almost as if fewer sysops and bureaucrats are joining than they used to, though some of this is the result of quitting the wiki and the automatic loss of channel access along with it (which probably shouldn't be the case anymore).

I've also noticed (could also be subjective, I suppose) most of the non-admin channel operators seem to have more experience with IRC than many of the wiki sysops/bureaucrats do, yet have fewer flags. This hasn't always been the case, but seems to have become the case over time.

This has led to a suboptimal situation where some of those with the most experience, aren't given all the tools they could make use of, while some others simply by virtue of sysop/bureaucrat status, are granted access to tools they may or may not understand thoroughly. We have not yet reached the critical tipping point in the channel, but if things continue as they have, eventually it will, and it won't be pretty.

One channel that shall remain unnamed (no, it's not that one) is for another wiki. They strictly adhered to their policy that only bureaucrats and sysops may be granted channel access. However, none of the bureaucrats seemed very well versed in IRC. If they were, I wouldn't have been asked if a bot I run could op them in the channel, when the bot in question didn't even have channel access. That channel was also opless over half of the time, with somewhat predictable results.

If I may digress slightly, I want to be very clear that just because one may not be as well versed in IRC, does not imply a lack of ability or capability while working on a wiki. The opposite is also true. For example, I would likely struggle if I were to attempt to create a new wiki template, and I always have to look up the wiki syntax every time I edit.

Because of that, and due to a lack of interest and time, it would be very inappropriate if, as an example, I were made bureaucrat or even sysop. But under the current system, it's the only way I, or the other non-admin channel operators, could potentially be granted additional channel access. The price of admission is simply too high, and eventually, it will cost the channel.

As for whether to grandfather in the existing sysops and how, I'm not sure of the best way that would be fair for all. In channels I've run or helped manage, I typically allowed people to stay on and avoided demotions, unless warranted. If someone was gone for a long time, I may cull the access list but generally gave at least 60 or 90 continuous days of absence, often longer. Basically, when it seems clear to me the user might not be coming back. Other times, I'd simply remove the +O flag (get ops automatically on channel join or ID to NickServ). However, I'm not sure if this system would work in this case, since the way I did things was to rarely grant access, and whenever I did, I always felt certain the user knew what he was doing on IRC. That was not the system followed here.

An interesting point as of this writing is there are four sysops on the access list, but two of them haven't logged into Freenode at all since 2015, despite it now being June 2016. According to Freenode Policy, this is far beyond the threshold (10 to 15 weeks of continuous non-use, depending; one extra week per year of registration, up to 5), they risk losing their nicks and accounts if someone requests it. On most networks, the account would have expired by now and the channel access along with it. There could be something to be said to removing entries (one time) that haven't been used in 120 days (17 weeks, 1 day). If the suggestion of culling the sysops who haven't been there for 120+ days is implemented, two will remain. For new sysops, the new policy can apply. This idea seems the most "fair" to me.

Just my two cents on the issue. Ben (talk) 05:29, June 3, 2016 (UTC)

I support the proposal as written. Since IRC exists as a separate entity from the wiki, it only makes sense that the rules that govern its functions should be independent of on-wiki rules. I have operator privileges in the channel despite my admittedly poor grasp of IRC channel operations (I always forget channel commands, which isn't a good thing when a quick response to an ongoing incident is needed), and I do not feel that I should have those rights simply by virtue of my being an admin here. Up to now I have held onto those rights to ensure that there are at least some people in the channel who still have them, but if this proposal is passed (regardless of any agreement on grandfathering in sysops like myself) I will be waiving operator rights. As Ben said, being wiki savvy and being IRC savvy are not one in the same.

Regarding the grandfather clause, I think that there should not be one. I think that we as a group can agree on who should and should not have operator rights at the present time, and then add or remove other individuals as time progresses. If a main reason for making this proposal is that sysops who are not IRC savvy have operator rights and shouldn't, then we have to go all the way and recommend that those persons have those rights removed. It's not a personal slight against anyone who may have those rights presently, it's simply an admission of the fact that some are more experienced in IRC operating than others.

One additional question I have is regarding how new operators, half-ops, etc. for the channel will be selected. Will this selection process take place on-wiki, or in the channel. In the former case, will wiki users who do not participate in the channel be allowed to voice their opinion on applicants, and will these applicants be required to be active on TSW, Wikia, or to even have a Wikia account? In the case of the latter, how will those selections be conducted in a fair manner? Will the IRC contact serve as a "bureaucrat" and simply promote whomever he/she deems worthy, or will some sort of democratic system be implemented? In the latter case I don't have a problem with K6ka promoting people unilaterally, since his position as IRC contact was community confirmed; if we keep the rule that the IRC contact must be confirmed on-wiki (and allow IRC-active, wiki-inactive users to participate in such discussions), then I have no issue with allowing the IRC contact to serve as the person awarding and removing rights in the channel. But if there is a way to implement some form of channel voting or democracy, I would be interested in that and may support that instead. -- LiR talkblogcontribs 22:40, June 3, 2016 (UTC)

@LostInRiverview: My thoughts on appointing new chanops would be that the existing, on-wiki process would be kept, and the page would simply be split up into three sections: one for nominations for half-ops, one for ops, and one for superops. More weight would definitely be given to comments made by IRC regulars (It wouldn't be that much different for a request for Wikia chat moderator if half the people that comment on it never set foot in chat). As for the users of IRC that do not have Wikia accounts, I don't know. Perhaps we could have a bot that could publicly log the channel and we could clearly see it when users commented on a candidate? Recently I brought wm-bot into the channel and it has an option to publicly log the channel. If enabled, logs would be periodically posted here. Then, when there's a nomination for chanop going on, people can just type in !vote <name of candidate> <rationale>, and that's how they'd provide their input. I do know that I'm going to need the channel's permission to have public logging enabled, if that's to happen. —k6ka 🍁 (Talk · Contributions) 23:14, June 3, 2016 (UTC)
I don't really have anything to add, as LiR pretty much summed it up in his large block of text. Ultimately, I support these changes to IRC. ~ Beds (talk - blog) 20:54, June 11, 2016 (UTC)


by approving this you are just giving the sims wikis irc channel away to anybody but the sims wiki. its the irc channel for the sims wiki and should be run by the community of the sims wiki. if this goes through then eventually the irc channel wont be run by the sims wiki at all.

if your going to do this then will the sims wiki use the wikia chat instead? (talk) 21:56, June 8, 2016 (UTC)

Wikia Chat is and will always be available, and it is separate from the IRC channel. Already there are community users that stick with IRC and community users that stick with Wikia Chat. Both are open and you may chat in either one or both of them if you wish.
[it] should be run by the community of the sims wiki. Except it isn't. Even as it stands now, the IRC channel is largely inhabited and run by people who are not very active on The Sims Wiki (They do have an on-wiki presence, but they seldom use it). The IRC channel is already de facto not run by The Sims Wiki's community as a whole, mostly because very few people in the wiki community use it. Also, these changes don't change the fact that ops still need a Wikia account to request ops in the channel. The community, it seems, already doesn't really care about the IRC channel, so "giving it away" (which is a misnomer) isn't going to affect the wiki that much anyway.
And if the argument is, "Shouldn't active community members be the ones selected for ops?", see MrBenC's comments above, and also keep in mind that some of our chat moderators for our on-wiki Wikia chat are not really regular editors. On Wikia Chat and IRC, a user's competency in handling situations on chat should be what is evaluated when deciding who gets moderator/ops, not what they do on-wiki. —k6ka 🍁 (Talk · Contributions) 23:44, June 8, 2016 (UTC)
Community content is available under CC-BY-SA unless otherwise noted.