Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changes to meetbot #700

Closed
lramati opened this issue Jan 4, 2015 · 10 comments
Closed

Changes to meetbot #700

lramati opened this issue Jan 4, 2015 · 10 comments

Comments

@lramati
Copy link
Contributor

lramati commented Jan 4, 2015

Given the things decided in the last board meeting the following things should probably be implemented in meetbot to make those things easier for the board. namely:

  • Since #board is now an open channel, meetbot should only start a meeting if the user is one of a given subset allowed to start the meeting, instead of allowing anybody to start a meeting at any time
  • For the same reason, Meetbot should now automatically mute the channel when a meeting is started, and unmute it when the meeting ends
@elad661
Copy link
Contributor

elad661 commented Jan 4, 2015

Since #board is now an open channel, meetbot should only start a meeting if the user is one of a given subset allowed to start the meeting, instead of allowing anybody to start a meeting at any time

NAK. meetbot is general-purpose like the one in supybot. Anyone can start a meeting anywhere. that's the point.

For the same reason, Meetbot should now automatically mute the channel when a meeting is started, and unmute it when the meeting ends

NAK. This is a completely ridiculous policy that no other IRC meeting room has, only your network. It makes no sense to do this. You should change your policy instead.

@tyrope
Copy link

tyrope commented Jan 4, 2015

Actually, making .startmeeting requiring halfop or above might be a valid usecase. Since it's something only one can exist on in a channel and isn't able to be turned off except by the meeting starter and his/her chair(wo)men.

I sort of see both sides of the argument regarding channel mode +m and will hence stay neutral on that point.

@lramati
Copy link
Contributor Author

lramati commented Jan 4, 2015

Its also worth noting that the .comment(s) commands seem to imply one not participating wouldnt be able to speak regularly in the channel where the meeting is happening, so something somewhere needs to get cleared up

@elad661
Copy link
Contributor

elad661 commented Jan 4, 2015

Not sure. On freenode zodbot can start a meeting in any channel and we use it in public meeting rooms and such where ops are the infra team and they don't care about most meetings.

I have a compromise that would work, but it will be more complicated: ops and halfops should be able to set meeting accesslist for a channel, and if meetings are allowed.

Default would be meetings not allowed. If you allow meetings, you get a public meeting room. You can then set the access list for who can start meetings if you wish. Does that work for you?

Its also worth noting that the .comment(s) commands seem to imply one not participating wouldnt be able to speak regularly in the channel where the meeting is happening, so something somewhere needs to get cleared up

What? I didn't understand anything from this sentence.

@lramati
Copy link
Contributor Author

lramati commented Jan 4, 2015

The .comment command is built to allow somebody not actively in the meeting to comment on something going on in the meeting. If the channel is unrestricted, why do they need to use .comment as opposed to just typing their comment in the meeting?

@elad661
Copy link
Contributor

elad661 commented Jan 4, 2015

It was implemented in f7903c6

I don't think it's needed at all if you have open meetings, which is what most people do

@embolalia
Copy link
Contributor

I think @elad661 is right about not specializing meetbot to the NFIRC board. comments really doesn't make sense for anyone else's usecase, but it also doesn't change their workflow, so it's marginally okay. Auto-muting and limiting startmeeting to (half)ops would. An access list would probably work, preferably tied into #64. A quick patch to paper over abuse would be to let channel (half)ops kill meetings; if someone's abusing the bot in your channel, you should kick them anyway.

@tyrope
Copy link

tyrope commented Jan 4, 2015

I agree with the .endmeeting being able to be done by channel staff to be a good (temp) compromise against abuse.

@dgw
Copy link
Member

dgw commented Jan 14, 2019

After following the reference here from #1450, I was thinking to close it, but this is definitely still relevant. If someone starts a meeting in a channel where it turns out to be disruptive, channel operators have no way of ending the meeting. Even if they kick the instigator.

That's not the only issue (not that I've done a comprehensive review), but it's the main one. So I'm going to leave this open still, and if the meetbot module ends up moving to its own repository this can be moved along with it. (So glad GitHub added that function…)

@Exirel Exirel mentioned this issue Jan 15, 2019
40 tasks
@dgw
Copy link
Member

dgw commented Jul 10, 2023

The meetbot plugin is being removed to its own package (#2477). I will drop a quick summary of the discussion here in the new standalone plugin's repo, along with a cross-reference for anyone who wants to read the full history.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants