kern / hackbot Goto Github PK

Currently, filters are callbacks which receive the full thread as an argument, but this isn't terribly smart since we have to diff against previous versions of the thread to see what's changed. This is especially problematic with edits because the Graph API doesn't give you any indication that a post's content has changed, and hence commands can be issued retroactively if you edit old comments.

I'm moving over to an evented model for representing changes to the group's feed on the sentiment branch. There will be a PostEmitter of some sort which emits new, edit, and delete events whenever a post or comment is created, edited, or deleted. Persistence will be baked in so that we can diff thread versions, probably through an embedded database like nedb.

Hackbot needs the ability to create and delete posts on the behalf of at least one group administrator. Users that wish to use the upcoming canned-response commands (#10, #11, #12) will also have to authenticate with the application.

We'll need to implement the OAuth 2 web flow and persist the long-lived access tokens somewhere. The hacky method described in the README isn't so user-friendly. :)

This could allow a single hackbot instance to work across the HH ecosystem.

Would there be interest in a /slack command that would work similar to /tweet but post a formatted message to the HH Slack? Another extension of both commands could be /broadcast that would post a tweet and slack message (useful for announcing an AMA or something).

would be cool if possible and clean out member requests

http://imgur.com/a/QDbyt#0
plzplzplz

Anyone can use this command. Hackbot will delete the original comment and post a link to a search query in the group, which should handle the case when a question has been asked multiple times but hasn't yet been added to the FAQ.

Thanks for the suggestion in #9 @gsingh93.

Anyone can use this command, and it takes one argument, /redirect <group>. The argument will be something like python, which in this case would cause Hackbot to delete the original comment and post a new comment with a link to the HH Python group.

Thanks for the suggestion in #9 @gsingh93.

I have some proposed changes to improve the quality of posts in the main HH group. I'd be happy to implement some or even all of these myself. I wanted to post this issue to get approval and feedback before starting. Here are the changes:

1. Create a new user named Hackbot which will be used in the following items (is this against the Facebook TOS? Is there any alternative to this for the use cases below?).
2. Add an argument to the /thread command. The argument will be a set of predefined keywords explaining why the thread was closed. For example, /thread editor will close a thread comparing editors. Once a thread is closed, have Hackbot comment on the thread with a predefined message explaining why the thread is being closed. If the argument to the command doesn't exist, Hackbot won't post anything. This is so the mod who closed the thread can give a custom explanation if there is no predefined explanation. A detailed list of what should and shouldn't be allowed can be discussed later.
3. Add a /redirect <group> command. The <group> argument will be something like python, which in this case would cause Hackbot to comment with a link to the HH Python group. Whether this should be followed up with a /thread will be up to the moderator. Any user can run this command, not just mods.
4. Create a /wiki or /faq. Using this command will cause Hackbot to comment with a link to some page that answers the most common questions. Hopefully we can knock of all the "What are some good resources for X" questions with this command. Any user can run this command, not just mods.
5. Add a /report command. I think this will be easier than using the builtin FB functionality. Anyone can report a post. Reporting a post will send a notification to all of the mods. This could be useful as there aren't many mods so not all posts are seen, but any user can run /report on a thread that's becoming an editor war, which will notify the mods to close the thread. While I think this would be convenient, I can think of multiple reasons against it, so feel free to reject it.
6. Add a /repost command. Anyone can use this command. Running this command will make Hackbot post a comment with all of the previous reposts of the same link. Obviously it would be crazy to have Hackbot keep track of all the links posted ever, so this would be limited to some tweakable duration (i.e. all links older than 3 days would be removed from Hackbots cache).

For deleting nested comments.

Many topics are posted multiple times in a short time period (e.g., a week) especially as a newstory develops. There should be an easy way to detect these and allow a moderator to step and direct discussion to another earlier post.

This should probably trialled to see if it improves discussion. Is there a metric that is used to see if an experiment like this is actually useful?

Right now hackbot logs the ID of any comments it deletes to STDOUT. This isn't terribly useful, and I'd much rather see independent log files for each of the filters which are run that contain information such as the commentator's name, message body, and time it was posted.

Perhaps a lib like winston could do the trick?

Anyone can use this command. Running this command will make Hackbot delete the original comment and post a new comment with all of the previous reposts of the same link.

Thanks for the suggestion in #9 @gsingh93.

We have problems adding new members.

1. We get a ton of requests
2. There are some people who are clearly spammers and/or bots, but most people we can't be sure of.

Possible hackbot solutions to this issue:

1. Have a way for us to add new members, but notify hackbot about it.
2. Hackbot can run their new posts against spam detection model. Set user to quiet and notify mods if they're flagging positive.
3. Mods can deal with new user to see if actually spam. If not spam, unquiet. If spam, add data to a custom spam classifier (this isn't necessary but would be cool).

Result: we can add more members faster while maintaining good content.

The Facebook Graph API is really straightforward and doesn't necessarily require a specialized client to works its magic. The fb package isn't doing too much right now, and I think it'd make sense to remove it entirely.

Adds the post to a list on the HH website. Could be a jumping off point for an "HH Digest" or mailing list. :)

Thanks for the suggestion in #9 @gsingh93.

All we really need is an embedded database or in-memory store like Redis. Configuration and access tokens shouldn't be persisted, anyway.