Cleanup README.md

[christetreault]

I've already cleaned up the formatting and flow of README.md quite a bit. Additionally, I added some info on building the .pdf. However, I am unsure of what to do about the TODO and Gotchas sections.

• TODO This section is full of work items. Perhaps each work item should be opened as an issue?
• Feedback and Gotchas This section seems to be full of feedback that I gave, as well as other random thoughts. There's not a lot of real organization here, and I'm sure a lot of this is not up to date. Maybe a wiki page can be created for this stuff?

I suppose both of those sections aren't really hurting anybody as-is, but I don't think they really belong in a readme file. Implementing both of my suggestions is probably only 15 minutes of work, and will go a long way towards making the readme feel more polished. Given that this repo is now public, I figure it couldn't hurt. Assuming management is OK with this, I can go ahead and make this change, then submit a pull request with the updated readme.

[ranjitjhala]

Hi Chris, thanks! Can you go ahead and make the todos issues as you suggested, and perhaps move the other stuff to a new file feedback.md? I find it convenient to have a single text file to read up and down rather than a wiki which I find harder to navigate...

Thanks!

On Aug 8, 2015, at 1:06 AM, Chris Tetreault notifications@github.com wrote:

I've already cleaned up the formatting and flow of README.md quite a bit. Additionally, I added some info on building the .pdf. However, I am unsure of what to do about the TODO and Gotchas sections.

TODO This section is full of work items. Perhaps each work item should be opened as an issue?

Feedback and Gotchas This section seems to be full of feedback that I gave, as well as other random thoughts. There's not a lot of real organization here, and I'm sure a lot of this is not up to date. Maybe a wiki page can be created for this stuff?

I suppose both of those sections aren't really hurting anybody as-is, but I don't think they really belong in a readme file. Implementing both of my suggestions is probably only 15 minutes of work, and will go a long way towards making the readme feel more polished. Given that this repo is now public, I figure it couldn't hurt. Assuming management is OK with this, I can go ahead and make this change, then submit a pull request with the updated readme.

— Reply to this email directly or view it on GitHub.