Skip to content

Instantly share code, notes, and snippets.

@brittanydionigi

brittanydionigi/workflow-rubric.md

Last active September 15, 2017 16:32
Show Gist options
  • Save brittanydionigi/8ee4d889c5f00a7c066ad9e69b63b576 to your computer and use it in GitHub Desktop.
Save brittanydionigi/8ee4d889c5f00a7c066ad9e69b63b576 to your computer and use it in GitHub Desktop.
Download ZIP
Sample Workflow Rubric
Raw
workflow-rubric.md

A sample Workflow rubric for projects. Feel free to modify per-project as you see fit.

4 - Developer(s) make many small, atomic commits that clearly document the evolution of the application and do not contain irrelevant changesets that aren't reflected by the commit message. Commit messages are concise and consistent in syntax and tense. Developer(s) effectively use git branches and pull requests when applicable to incorporate changes into the application, and are not pushing directly to master. There are no instances where the developer(s) have committed source code that should be .gitignored. There are no instances of "dead" or commented-out code and debugger statements like console.log.

3 - Developer(s) make many small, atomic commits that document the evolution of the application but sometimes contain irrelevant changesets and inconsistent commit messages. Developer(s) use git branches and pull requests when applicable to incorporate changes into the application, and are not pushing fresh changes directly to master. Pull requests may contain little or no code review. There may be slight instances where the developer(s) have committed source code that should be .gitignored. There may be some instances of "dead" or commented-out code and debugger statements like console.log that need to be cleaned up.

2 - Developer(s) make large, inconsistent commits that contain irrelevant changesets and make it difficult to follow the evolution of the application. Developer(s) rarely use git branches and frequently incorporate changes directly into master with little or no review process. There are instances of committed source code that should be .gitignored and instances of dead code and/or debugger statements.

1 - Developer(s) make very few commits that each cover too much responsibility and aren't indicative of how the application evolved. Branches and pull requests were not used and changesets were applied directly to master. There are many instances of committed source code that should be .gitignored and many instances of dead code and/or debugger statements.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment