-
Notifications
You must be signed in to change notification settings - Fork 0
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
Convert to plain text formats #1
Comments
So the draft/trunk/development documents would be markdown, and when we tag (and assign a version number increment) something we’d create a pdf that would be a gitHub tag, get assigned a USGIN URI, and also get deposited in the USGIN repository (where the URI will dereference) First step is converting all the in-progress word docs here to Markdown and archiving the word docs. Who’s a good suspect to do that ? |
I'd say a good suspect is... a) someone that you want to be familiar with markdown syntax, because you want them to be writing a lot of documentation that way, and |
Another options for automated "views" of the markdown content is to make this a Jekyll site, hosted on github pages. Instead of pdfs the products would be HTML pages. To do that you need someone willing to learn Jekyll and be willing to write a bit of HTML and CSS. |
Let me know what I can do. I'm interested in liberating information, so would be happy to learn and/or work with folks to help get a system in place. J |
@janelday @ccaudill I think the place to start is to simply pull this repo, pick a docx, and start copy/pasting content into markdown. There's are great Markdown guides here and here. If we decide to spruce up the content a bit and make a Jekyll site out of it, we'll still need to do the Markdown work, so all the better if we've got a bunch of that in place first! |
Is this something Pam should be involved with, if she isn't already? J Sent from my iPhone On Dec 8, 2013, at 12:52 AM, "Stephen Richard" <[email protected]mailto:[email protected]> wrote: So the draft/trunk/development documents would be markdown, and when we tag (and assign a version number increment) something we'd create a pdf that would be a gitHub tag, get assigned a USGIN URI, and also get deposited in the USGIN repository (where the URI will dereference) First step is converting all the in-progress word docs here to Markdown and archiving the word docs. Who's a good suspect to do that ? Stephen M Richard From: Ryan Clark [mailto:[email protected]] I think it would be really helpful from the perspective of USGIN being an open-data initiative to manage and maintain these specifications as plain-text documents. There are so many advantageshttp://stackoverflow.com/questions/568671/why-should-i-use-a-human-readable-file-format Markdown is so easyhttps://help.github.com/articles/markdown-basics and it helps you focus on your text above your formatting. Open by default is kind of a buzzword but it is also a very good idea. I would try hard to think of MS Office docs and PDFs as products you build from the documents, and not the way that you manage them. Reply to this email directly or view it on GitHubhttps://github.com//issues/1. Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-30076983. |
Makes more sense for Janel and/or Christy to work on this so you’re familiar with the content. I think the metadata profile is going to be VERY difficult to reproduce in Markdown… We probably need to think about other approaches for that. |
I think it would be really helpful from the perspective of USGIN being an open-data initiative to manage and maintain these specifications as plain-text documents.
There are so many advantages
Markdown is so easy and it helps you focus on your text above your formatting.
Open by default is kind of a buzzword but it is also a very good idea. I would try hard to think of MS Office docs and PDFs as products you build from the documents, and not the way that you manage them.
The text was updated successfully, but these errors were encountered: