M2 Pull Request Plans and Outcomes

• Instructions
• Grading Rubric

Instructions

Prior to the start of the Milestone M2 development iteration, the team must work together to create for each team member a set of pull request plans. The pull request plans specify the coding work that each team member is expected to complete and submit as a GitHub pull request during the M2 iteration. The pull request plans must be documented in the team’s m2_pull_requests.docx document prior to the start of the M2 iteration.

Scenario-Implementation Work. The M2 pull request plan for each team member must comprise a set of user scenarios from the team’s stories_scenarios_storyboards.docx document to implement by the end of the M2 iteration. To successfully implement a scenario, all the features required to enact the scenario in the app must be fully completed. It is assumed that error-handling will also be completed although not explicitly depicted in the scenario.

• 10-Hour Minimum per Team Member. Each team member must be assigned at least 10 hours of coding work.
• 3-Scenario Minimum per Team Member. Each team member must be assigned at least 3 scenarios to implement.
• No Shared Pull Request Assignments. Each pull request plan must be assigned to one-and-only-one team member. Although team members are encouraged to collaborate, the responsibility for completing a particular pull request must lie with a single team member. Teammates who assist on a pull request can be credited in the pull request.
• Other Work Assumed. It is assumed that each team member will have additional work beyond just their coding work for M2 (e.g., demo-video creation, code reviewing).

List of Planned Code Changes. For each pull request planned for each team member, the team member must document a list of the anticipated code changes required to complete the pull request:

• Code Artifacts to Include. Include all anticipated changes (create, modify, or remove) regarding the following types of code artifacts.
  • Model classes
  • Model class associations
  • Routes
  • Controllers
  • View templates
• Page Items. For page-implementation changes, you may list the route, controller, and view template as a single list item.
• Other Code Artifacts. It is expected that other code artifacts beyond those listed above may need to included in the list of planned code changes.
• Iterate between Pull Request Assignment and Code Change Planning. Planning the list of code changes may change the team’s assessment of how long a pull request will take. It is expected that, in creating the pull request plans, there may be some back and forth between updating the assignments and filling out the planned code changes.
• Plan together to prevent redundancy. The same artifact changes should not be listed in multiple pull request plans. The team must work together to decide who will make the change, so that the other pull requests can assume the change was already made.

Pull-Request Outcomes: By the end of the M2 iteration, the outcome of each pull request must be reported in the m2_pull_requests.docx document.

Pull Request Plan and Outcome Formatting. In your team’s m2_pull_requests.docx document, the pull request plans must be specified and formatted as follows:

• Assignee: The name of the team member who is responsible for completing the pull request.
• User Stories Implemented: The list of user stories from your team’s stories_scenarios_storyboards.docx document that will be implemented in the pull request.
• Planned Code Changes: The list of anticipated code changes required to complete the pull request.
• Topic Branch: The name of the topic branch on which the code changes will be committed. Branch names must be kebab-case. They should begin with the name of the team member doing the work, followed by keywords that convey what is being implemented (e.g., bart-picture-feed, lisa-display-saved-pins).
• 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.
  • Pull Request: The URL of the GitHub pull request (e.g., <https//github.com/green/pin-pics/4>).

To clarify what is expected, here are example pull request plans (no outcomes), and here are those same example plans with outcomes added.

Grading Rubric

Grade Requirements. Minimum requirements to earn each grade:

• High-Pass:
  • 85% of provided pull request plan content is clear and followed instructions.
  • For each team member, there are pull requests assigned that amount to at least 85% of the quantity of work expected.
  • 85% of expected pull request outcomes are reported and followed reporting instructions.
• Low-Pass:
  • 70% of provided pull request plan content is clear and followed instructions.
  • For each team member, there are pull requests assigned that amount to at least 70% of the quantity of work expected.
  • 70% of expected pull request outcomes are reported and followed reporting instructions.
• Fail:
  • Fails to meet requirements for Low-Pass.