Name: DeveloperPlaybook
Owner: Stanford University Digital Library
Description: A place to organize style guides, best practices, tools, and techniques for Stanford University's Digital Library Systems & Services group
Created: 2015-04-02 01:21:40.0
Updated: 2018-04-20 21:58:30.0
Pushed: 2018-05-01 22:52:28.0
Homepage:
Size: 102
Language: null
GitHub Committers
| User | Most Recent Commit | # Commits |
|---|
Other Committers
| User | Email | Most Recent Commit | # Commits |
|---|
README
Developer Playbook 
=========
A place to organize style guides, best practices, tools, and techniques for Stanford University's Digital Library Systems & Services Group.
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 © 2016 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.
