Serendip o matic 'go live' checklist

When deciding if a commit is ready to go to production, we would like to consider:

• are we staying true to the original vision / tone of Serendip-o-matic?
• are the design elements in line with pre-existing content?
• have any recent changes affected the accessibility of the site?
• a code review and reality-check functionality against the original vision - serendipity over utility

Some draft guidelines for how the whole team can most productively get on with things:

• Assume action is better than inaction (i.e. if you're not sure if you should jump in and do something)
• Search existing issues before adding a new one in case it's already in the list
• If you enter an issue, assign it to the most logical person. If you are assigned an issue, but can't work on it, assign it to the next most logical person or one of the leads.
• If you are working on an issue, assign it to yourself, so everyone knows who's working on what and so we don't duplicate effort.
• When you commit, please include the related issue number using the built-in GitHub syntax for linking commits to issues
• If you're the one who solved an issue (added the code, text, whatever) you should not be the one who closes the issue (in the interests of 'just enough Quality Assurance')
• In the spirit of the Collaborator's Bill of Rights (http://mith.umd.edu/offthetracks/recommendations/) all of the OWOT team members should feel empowered to write/blog/present, etc, about the project as well as take credit for the work that they have done. We have created an issue (#116) to track conferences so that we don't duplicate proposals.