M2 Pull Request Outcomes

• Instructions
• Grading Rubric

Instructions

By the end of the Milestone M2 development iteration, the team must document how the pull requests they planned turned out—that is, they must report their pull request outcomes.

• The pull request outcomes go alongside the pull request plans in the team’s m2_pull_requests.docx document.

Pull Request Outcome Formatting

In your team’s m2_pull_requests.docx document, the pull request outcomes must be specified and formatted as follows:

• Assignee: Carries over from the plan and should not change. If the pull request was reassigned to someone else, see the special cases below.
• User Stories Implemented: Carries over from the plan and should not change (unless to make a correction).
• Planned Code Changes: Carries over from the plan and should not change.
• Topic Branch: Carries over from the plan but may be updated if a different name was used.
• Outcome:
  • Status: Reports how much of the planned work was finished by the end of the M2 iteration.
    • Complete: The planned scenario-implementation work was all completed according to plan. The pull request was submitted and merged into main.
    • Partially Complete: A good portion of the planned functionality was implemented and is in working order; however, some of the planned functionality was not completed. The pull request was submitted and merged into main. A note must accompany this status explaining what was/wasn’t completed.
    • Incomplete: Not enough of the planned work was completed to qualify as a substantive contribution. The pull request wasn’t submitted.
    • Reassigned: A different team member than the original assignee completed the pull request.
  • Pull Request: The URL of the GitHub pull request (e.g., <https//github.com/green/pin-pics/4>). If the pull request status was neither complete nor partially complete, then this field should be empty.

To clarify what is expected, here are some example plans with outcomes.

Special Cases

• Reassigned Pull Request. If the team member who completed a pull request is not the one assigned the pull request in the plan:
  • In the original pull request plan, the status should be set to “Reassigned”.
  • A copy of the pull request plan should be added to the assignments for the team member who actually completed it, and the outcome part should be filled out as usual.
• Unplanned Pull Requests. During an iteration, the team may produce pull requests that were not originally planned. Such situations may arise because of an unexpected change of plans or because an (unanticipated) bug needed to be fixed. Such unplanned pull requests need not be documented in m2_pull_requests.docx; however, the instructor will note them among the list of closed pull requests in GitHub.

Grading Rubric

• High-Pass: 85% of required pull request outcomes are reported and followed reporting instructions.
• Low-Pass: 70% of required pull request outcomes are reported and followed reporting instructions.
• Fail: Fails to meet requirements for Low-Pass.