search

zigdon / xkcd-Bucket

Bucket is the channel bot for #xkcd
http://wiki.xkcd.com/irc/Bucket
121 stars 31 forks source link

Support "someone kicked ____" factoids #98

Open dgw opened 7 years ago

dgw commented 7 years ago

In addition to the currently supported $nick kicked $user and $nick kicked someone triggers, users on my instance have proposed use cases for someone kicked $user and someone kicked someone.

As an extension to the existing "kicked" triggers, the resolution hierarchy would go from most to least specific in this order:

  1. $nick kicked $user (most specific)
  2. $nick kicked someone
  3. someone kicked $user
  4. someone kicked someone (least specific)

Doing it this way essentially adds the new functionality in such a way that the existing kick factoid types are preferred over the new types.

Per @zigdon below, the implementation must also look up the new kick triggers only if a related config flag is enabled.

zigdon commented 7 years ago

We used to have support for that, and decided it was too spammy (especially that last one). If we going to restore it, it should be guarded in a config flag.

On Sun, Mar 19, 2017, 20:44 dgw notifications@github.com wrote:

In addition to the currently supported $nick kicked $user and $nick kicked someone triggers, users on my instance have proposed use cases for someone kicked $nick and someone kicked someone.

As an extension to the existing "kicked" triggers, the resolution hierarchy would go from most to least specific in this order:

  1. $nick kicked $nick (most specific)
  2. $nick kicked someone
  3. someone kicked $nick
  4. someone kicked someone (least specific)

Doing it this way essentially adds the new functionality in such a way that the existing kick factoid types are preferred over the new types.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/zigdon/xkcd-Bucket/issues/98, or mute the thread https://github.com/notifications/unsubscribe-auth/AACtVHUBrW4xEe18lzq6L3SD0ohbHWahks5rnfYRgaJpZM4MiATu .

dgw commented 7 years ago

If we going to restore it, it should be guarded in a config flag.

That's fair.

dgw commented 7 years ago

@zigdon Would you prefer the default to be on or off? I'd lean toward making the default the current behavior, but only because I wouldn't want to suddenly switch it on for existing instances. Ideally I'd like the default to be enabled for new installs, and disabled for existing…not sure if that's possible with Bucket's current config (IIRC it has no awareness of whether it's been upgraded or created fresh).

zigdon commented 7 years ago

I'd say if it's a plugin, we can have it off by default, and have it added to the sample config, so that new installs will have it on.

dgw commented 7 years ago

This just came up in one of my Bucket-serviced channels, so… I guess it's time to put it officially on my plate.