More IRC operators

[japaric]

Currently @japaric is the only operator of the #rust-embedded channel, but we should increase the bus factor.

Options I see:

• Look for volunteers
• Make all the WG members into operators

I think the last one makes more sense since the WG members are to enforce the code of conduct on IRC.

Thoughts?

cc @rust-embedded/all

P.S. I have no idea how IRC operator permissions work. Can any operator remove another operator? Or is there some hierarchy?

[adamgreig]

It used to be that any operator could do anything but most modern IRC servers use IRC services (nickserv/chanserv) to help manage channels.

Mozilla IRC chanserv has very fine-grained access control (/msg chanserv help, then try help levels and help levels desc for more details), but basically you can set what users may do what things, including changing the access control itself. By default the person who registered the channel has 'founder' access which trumps everything else.

Perhaps we could give all WG members some level of access (e.g. to kick/ban and perhaps set topic) and a smaller group of people access to change the member list?

[japaric]

Nominating for discussion in the next meeting (#150)

[levex]

I used to be IRC Operator (note: not a channel operator) on a separate IRC network where the policy was that project volunteers were usually halfop (denoted by %, they could kick/ban and set +v), and op (denoted by @) was given to project maintainers. If there were more maintainers and a hierarchy was desired, we gave admin rights (denoted by !) to them. The main difference between admin and op rights was that admins could modify the op list.

Translating this to the Embeddded WG, my proposal would be:

• +a (admin) for WG lead(ers).
• +o (op) for people maintaining projects inside the Embedded WG.
• +h (halfop) for triage team and esteemed contributors.
• +v (voice) for generally helpful people and volunteers.

NB: It seems that what I call "admin" is called "owner" on Moznet.

[thejpster]

I'm not sure +v is useful right now, but I guess it doesn't hurt in case we get into a situation where the channel needs to be muted.

Provided someone from the Core Team / Mozilla can intervene should our +a go AWOL or act against the wishes of the rest of /all (or the +o list), I'm happy with the above. Otherwise we might need another +a.

[japaric]

@levex could you submit your proposal as a PR to adds a markdown document to the ops directory? Then we can request that /all votes on it.

[japaric]

Fixed by #172