search

pluralsight / guides-cms

DEPRECATED - Markdown based CMS with Github repository as persistent storage
http://www.pluralsight.com/guides/
GNU Affero General Public License v3.0
108 stars 35 forks source link

Ability to add free form tags to a guide #97

Open durden opened 8 years ago

durden commented 8 years ago

Currently we're categorizing guides based on a pre-defined list of 'stacks'. This is great for neatly organizing the guides in the github repository since all guides for a stack live in the same directory. However, these stacks are very generic and that poses a few problems:

  1. Difficult for readers to quickly find specific content their interested in
    • For example, it's hard for a reader to see if there are guides written specifically using the twitter API. Right now a guide using the Twitter API would probably fall into the 'Interesting APIs' stack.
    • The user would have to sort through all the guides in the 'Interesting APIs' stack to find what they want.
  2. Difficult for authors to tag their guides with more specific information
    • This is essentially the same as problem 1 but from the author's point of view. Author's could make it easier to find their guides if they could provide some custom metadata such as a tag.
durden commented 8 years ago

To implement this we need a few things:

  1. UI element on the editor page (or maybe a second page after submitting?)
    • This could be a text box allowing the user to type maybe a maximum of 3 words that would be used as 3 tags.
  2. Field in the metadata to hold the optional list of tags.
  3. Mechanism to query for guides based on tags

The mechanism for querying is the most challenging considering our current architecture. It's not feasible to query the tags directly from all the metadata files. This would result in a lot of requests to the Github API since we can only read 1 metadata file per request. So, we need to store the tag information in an additional place to make querying easier.

One option for this would be using the existing redis setup and storing guides in a redis list based on tags. For example, a new redis key, tags:<tagname>, pointing to a list of strings for each guide's unique identifier, <stack>/<title>. Then, we could handle a query based on tag by simply reading the tags:<tagname> key.

The downside of this approach is using additional redis storage space. We're currently using a Heroku plan that limits us to 100MB of storage space. However, we're barely using any of this space now, only around 3 - 5 MB. So, maybe this isn't a problem.

Another approach would be to store the tag information in something like Postgres, MongoDB, etc. I'm open to suggestions. However, using the existing redis setup is preferable since we're already depending on redis for the project.

Any additional thoughts on this @paulocheque?

durden commented 8 years ago

Any suggestions on adding or not adding this feature or the UI to add tags in the editor? @edroman @prtkgpt

paulocheque commented 8 years ago

It appears that the tags and stacks are the same thing with distinct names: we want to organize/categorize the guides and have the ability to search by these categories.

Just an additional idea, I am not sure about this:

We could use/search tags could be using the GitHub API GET /search/code. We could include the tags in the commit message, for example.

durden commented 8 years ago

Thanks for the input. Good to get some ideas bouncing around.

Tags are different in this context. They are more narrow and descriptive than the stacks. The stacks serve as organization for folders in the repo, but they are too broad for good search.

I'm not sure using the search API is a good idea. The search API has very strict rate limiting. Also, we might have people tag with a common word and the search could find that in a lot of places.

Maybe it would be better to save tags somewhere other than the commit message so we can search on tags only, not paragraphs of text. Also, using the commit message would mean we're using that for tags and a summary.

I think storing tags on the commit message would lead to useless commit messages if browsing on GitHub unless we come up with a clean format to accommodate a summary and tags, which would probably be easy and readable.

On Thursday, June 16, 2016, Paulo Cheque notifications@github.com wrote:

It appears that the tags and stacks are the same thing with distinct names: we want to organize/categorize the guides and have the ability to search by these categories.

Just an additional idea, I am not sure about this:

We could use/search tags could be using the GitHub API GET /search/code. We could include the tags in the commit message, for example.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/pluralsight/guides-cms/issues/97#issuecomment-226527340, or mute the thread https://github.com/notifications/unsubscribe/AADizyUqHM0IqFl9vngUfPyu6OrBkopGks5qMXA7gaJpZM4I3LXu .