Decide on editing workflow(s) about purl.obolibrary.org

[kltm]

1 is nice, and fits in with an automated travis checking system--check the schema, then run the test server and test all of the URLs; if passes accept request onto master; the addition to master triggers the rollout to a production site.

2 can just be a special case of 1: fork, edit in browser, PR. It would be super easy to setup a video guide for it.

In my mind, ideally, the .htaccess files wouldn't ever be committed to the repo--they are just temporary downstream product (although they would be available for debugging and inspection in Jenkins and Travis). In the same way you wouldn't commit a .fasl or .o file, the apache-specific product would be merely a specifc target product. Moreover, the more you commit to the repo, the more churn there is and the harder commit messages are to read.

[jamesaoverton]

I agree in general that you should not commit generated files. I'm a little nervous about these particular generated files, but automated tests should build confidence in them.

For option 3, I've just added commit dcf0313 with code for a local VM with Vagrant and Ansible. One advantage is that it should work cross-platform.

[jamesaoverton]

In commit dd5836e I removed the generated files. There are now examples in tools/examples/ instead.

But to do this right, we need a bulletproof solution for #2, so the master branch is never broken.

[jamesaoverton]

I added instructions in 3297f50. These can be changed or improved, but they'll do for now.