Rubric

You will be graded by your instructors on the criteria below. This rubric outlines the key areas in which you will be graded. Please note that all areas will be graded with equal importance. If you have any specific questions in regards to any of these key areas, let us know at any time.

Project Management/Agile Practices

• 4: Developer regularly uses Github Projects as their primary agile board. Before starting to code, they write user stories that focus on each individual feature that will be created in the application. Each user story will contain a descriptive title in relation to the feature being built. Each user story will also contain information pertaining to the feature being built within the description of the card. For example, this could include steps that a user may need to do in order to achieve their goal, or expected request/response data that may be seen during the use of an API. Developer is able to articulate the agile process during the project evaluation.

• 3: Developer regularly uses Github Projects as their primary agile board. Developer writes basic stories that convey what work will be done and what work has been finished. The developer uses the board regularly throughout the the duration of the project.

• 2: Developer creates an agile board but uses it sparingly after the initial start date of the project. Developer creates a few stories but never pulls them into their respective columns at the appropriate time. Most stories do not have written descriptions.

• 1: Developer creates an agile board but doesn’t utilize it for the duration of the project.

Git Workflow

• 4: Developer satisfies all criteria below in section three. Developer demonstrates their git workflow as being 100% consistent in regards to the creation of branches, issuing pull requests, using PR templates, asking for feedback, and writing clear and concise commit messages.

• 3: For each feature listed on their agile board, the developer has created a branch on git. Developer pushes their changes to their respective branches found on Github. Developer opens pull requests for every branch they create. All commit messages will be in imperative tense, start with a capital letter, and be consistent for the duration of the project. The name of pull requests are clear and concise of what work was completed. The title of the PR is not same name as the branch name.

• 2: Developer creates pull requests on separate branches but often pushes directly to master. Developer is inconsistent in how they write commit messages. Some commit messages lack clarity and purpose for the code submitted. Developer may tag collaborators at times.

• 1: Developer only pushes to master, never creates branches for their features work, and has very few commit messages at the end of the project. Commit messages are not informative and lack clarity as to what each piece of code is focused on. Commit messages are not consistent and lack proper structure across the project history.

Documentation

• 4: Developer satisfies all criteria below in section three. Developer contributes additional information. This includes links to their agile board and any available production links.

• 3: A thorough README is found in all related repositories. A README contains sections such as Introduction, Initial Setup, How to Run Tests, How to Use, Schema Design, Tech Stack List, and Core Contributors. Each section is thoroughly filled in with important information for visitors of your application’s repo.

• 2: A thorough README is found in all related repositories. A README contains sections such as Introduction, Initial Setup, How to Run Tests, How to Use, Schema Design, Tech Stack List, and Core Contributors. Each section is not filled out thoroughly, or some are missing.

• 1: A default README is found in all related repositories. No additional sections have been added. Developer has not added any related information to the project.

Peer feedback and communication

• 4: The developer requested a PR review from a peer, implemented the feedback and communicated back to the reviewer what changes were made and was able to speak to that experience, whether it be technical learning focused or workflow focused.

• 3: The developer requested a PR review from a peer, implemented the feedback and communicated back to the reviewer what changes were made. The developer reached out to instructors if at any time there were blockers they thought might prevent them from meeting any deadlines.

• 2: The developer requested a PR review from one individual, implemented the feedback and communicated back to the reviewer what changes were made. The developer did not consistently communicate with instructors about any blockers that prevented them from meeting prescribed deadlines.

• 1: The developer did not have any successful PR requests for review. The developer did not communicate with instructors about any blockers that prevented them from meeting prescribed deadlines.

Software functionality

• 4: Requirements listed below are complete and student has additional endpoints completed for project. Endpoints include happy path testing.

• 3: All endpoints within the project spec are working and complete. This also includes that endpoints are formatted correctly and deployed to production on Heroku.

• 2: At least two endpoints within the project spec are working and complete. Project is deployed to production on Heroku.

• 1: Fewer than two endpoints within the project spec are working and completed. Project not be deployed to production on Heroku.

Project Professionalism

Check-in one:

• 4: Developer fulfills all requirements below, and has most of the project completed. Developer comes with a plan to refactor their current application or work on extensions during the checkin.

• 3: Developer communicates and turns in any additional deliverables by the prescribed deadlines outlined by instructors. Developer has finished two endpoints and has their application deployed to production.

• 2: At least one endpoint within the project spec are working and complete. Project is deployed to production on Heroku.

• 1: Developer misses instructor deadlines, has zero endpoints completed, and doesn’t have their application deployed to Heroku.