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

Factoid aliases are, perhaps, too transparent #97

Open
dgw opened this issue Mar 18, 2017 · 2 comments
Open

Factoid aliases are, perhaps, too transparent #97

dgw opened this issue Mar 18, 2017 · 2 comments

Comments

@dgw
Copy link
Collaborator

dgw commented Mar 18, 2017

Say I have an alias: green eggs => Dr. Seuss

If a user triggers green eggs, Bucket will pick a factoid from Dr. Seuss and say it, using Dr. Seuss instead of green eggs.

For example:

<User> green eggs
<Bucket> Dr. Seuss can't possibly be wrong!

Ridiculous example aside, the point is that Bucket can seem to be talking about something completely different. Why don't triggered aliases use the name of the alias before the verb, instead of the name of the main factoid group?

@zigdon
Copy link
Owner

zigdon commented Mar 20, 2017 via email

@dgw
Copy link
Collaborator Author

dgw commented Mar 20, 2017

Yeah, it was a terrible example… my only excuse is that it was really late and I was too tired to come up with anything better.

But the most frequent case I see people "complaining" about on my instance is aliases like usernick_mobile => usernick, where triggering a factoid about someone who happens to be on their mobile/alternate nickname spits out a factoid using their primary nick. That case isn't a big deal IMO, but it's the most common.

To be fair, most aliases point to targets that almost exclusively use <reply>, so it's hard to dig up a real-life example that isn't nick-related. But I'm sure I'll come across one at some point, and then add it here.

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

No branches or pull requests

2 participants