Developer Playbook

A place to organize style guides, best practices, tools, and techniques for Stanford University's Digital Library Systems & Services Group.

• Best Practices
  • Documentation
  • Writing Tickets
  • Background Processing at DLSS
  • Communication
  • Deprecation
  • How To - Readme
  • Licensing
  • Monitoring
  • SSH Configuration
  • Puppet Prs
  • Releasing Gems
  • Using robots.txt
  • Setting Up Rails Projects
  • Testing
  • UI/Bootstrap
  • Updating NodeJS
  • Pair Programming
  • Version Control
  • Multi-factor Auth/Two Factor Auth
  • Accessibility (Infrastructure)
• Deployment
  • Automating Deployment
  • Capistrano
  • AWS Elastic Beanstalk for Blacklight and Arclight demos
• Style
• Code Review

Organized in a similar manner and inspired by the thoughtbot playbook and thoughtbot guides

Contributing

Please read the contribution guidelines before submitting a pull request.

In particular: if you have commit access, please don't merge changes without waiting a week for everybody to leave feedback.

Goals

The goals of the Developer Playbook are to:

• Provide a description of current accepted best practices within DLSS. These are not necessarily everyone's best practices, and they will certainly change in the future, but they're ours for the moment.
• Determine whether we have consensus on those practices, to document the ones that we do agree on, and have a list of issues for further discussion.
• Provide documentation about when our local best practices diverge from other established best practices, and provide opportunities to re-assess whether we still believe that our local practices are actually "best."
• Provide a starting point for new projects to build upon past, demonstrated successes, and have a default set of expectations in the absence of other requirements. We choose these acknowledged best practices by default, and discuss and justify any deviations from them.
• Provide a set of guiding directions for new hires to learn the ways of DLSS so they can quickly come up to speed and fit in with established development methodology.
• Mitigate against technical debt in the future by having consistency and coherency in development practices.

The goals are explicitly NOT to:

• Mandate or set in stone any unbreakable requirements. They are expectations that can be deviated from for good, documented reasons.
• Generate technical debt by retroactively applying current consensus to past projects.
• Have job description requirements for new hires.

The process is:

• broad, imperfect, and rapid. Future discussions can take it deep, refine the discussions, and go more slowly and carefully.
• modifiable under its own rules, as needed, and as and when desired.

License

Developer Playbook is © 2018 The Board of Trustees of the Leland Stanford Junior University. It is distributed under the Creative Commons Attribution License and is a derivation of guides.