Add `/resource` Slash Endpoint for Sending Various Resources to Users

[BethanyG]

Rather than have all the commands under /welcome, suggest we add a different "slash command" to the greetbot around sending/asking for resources. This would be a new route/endpoint. The idea would be to have /resources respond with a DM to a channel or user with CB "recommended" resources. Something along the lines of :
__
/resources [name of topic] [level] [channel] [user]
__
So -- /resources python beginner @username would DM a specific user beginner-level resources for Python.

Current thoughts:

1. /resources would result in a help message
2. /resources list would list available resources
3. /resources python would DM the requestor with python resources (default would be beginner level, unless otherwise specified)
4. /resources python beginner @username would DM the specified user with beginner python resources.
5. /resources python beginner #channelname would send a Slack Post of the beginner python resources to the channel specified.
6. /resources python beginner #channelname @username would do both Add /resource Slash Endpoint for Sending Various Resources to Users #4 and Add Interactive Message for How to Ask for Technical Help #5 (and would only be a nice to have).

[BethanyG]

Starter list of things we'd /resources (Beginning / Intermediate / Advanced):

• Web Dev
• FullStack Dev
• Databases/SQL
• Python (done)
• JavaScript (done)
• HTML
• CSS
• Ruby
• Go-lang
• Data Science

[railsstudent]

I probably do it phases, submit one PR for each command.
Will start after studying the current codebase.

[BethanyG]

Totally agree - a phased approach would be the best. Just getting the resources, and deciding on formats, etc. is a whole project itself.

See https://github.com/codebuddies/greetbot/projects/4 & https://github.com/codebuddies/greetbot/projects/3

Recommend we open some issues or sub-issues around which commands we'd like to implement -
and when. That way, each can be on the board, and we can track their progress.

In addition, recommend we start parsing out topic/language messages for those commands into their own issue set that can be assigned separate from the code that adds the endpoints/commands. That way, we can have some people focusing on the messages & formats, and others (who are more interested in node & JS) focusing on wiring things up.

As a side note to that: Slack's messages are required to be in this slightly weird markdown format. It's markdown, but an adapted sub-set of markdown. And to get that to render with JSON.stringify requires some special escapes, too. So - I can't this morning, but later today I will take a shot at putting together some documentation so that people formatting/working on the content of messages know what to do.

I also would like to get a template or several templates going for these messages - that way, someone could theoretically sit down and crank through a bunch with less effort.

@angelocordon, @robinfla, @lpatmo, @stain88, @rmorabia - please weigh in with thoughts, concerns, ideas. Thank you! Also please feel free to add/open new issues around this, so that we have a to-do list.

[stain88]

Proposal:
Resources are hosted in data/slash/resources/resources.yml, with general format:

- resources:
  - name: "resource1"
    level: "beginner"
    language: "python"
  - name: "resource2"
    level: "advanced"
    language: "webdev"

etc. Easy to add to, no need for sorting, can easily add other keys if needed (like paid, blog, book...)
We can then split req.body.text on spaces, grab username/channel with the same regex as welcome, and if what's left isn't list, grab the data from yaml and filter on all the keywords. List returns all names/languages/whatever we want it to return.

[railsstudent]

if using yaml, do we need to convert yaml to JSON format and nodejs code access the key/value in the JSON object.

[BethanyG]

@stain88 -- excellent suggestions! I may have complexified things a tad too much with the refactor....

The way things are now, all the parsing logic for the incoming /slash POST lives in util/incomingParser.js. It gets called by src/routes/endpoints/welcome/welcome.js to deal with the incoming request message.

My thought there being that no matter the POST to /slash (whatever) we always hand back {target_user, target_channel, action, payload}. What the particular /slash endpoint logic does with them is then up to whomever is coding that endpoint.

So - with the addition of /resources --> we'd use the exact same incomingParser.js....BUT.... we'd change the API (and so the logic in welcome.js slightly as well) to hand back a list of actions that the endpoint would then unpack.

...does that make sense? Or does it make more sense to do a second incoming parser for /resources? I am open to any and all ideas. 😀