M1 Pull Request Plans

• Instructions
• Grading Rubric

Instructions

Prior to the start of the Milestone M1 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 M1 iteration.
• The pull request plans must be documented in the team’s m1_pull_requests.docx document prior to the start of the M1 iteration.

Step 1: Getting Started

Your teammates must all have access to your team’s channel in Teams. If anyone is unable to access the channel, ask the instructor for help. Note that your team’s channel has shared file space (see the Files tab).

One team member should download this template file:

• m1_pull_requests.docx

Then, they should upload it to your team channel’s file space.

• This is the document into which your team must enter your pull request plans for Milestone M1.
• One document must be shared by all team members (i.e., do not create multiple files for pull request plans).
• Keep in mind that at this stage you will be adding only plans to the document; however, as your team members complete their pull requests during the M1 iteration, they will documents the outcomes of the pull requests in this same document. Thus, by the end of the M1 iteration, the document will look similar to this completed example.

Step 2: Assign Pull Requests to Team Members

Scenario-Implementation Work. Each team member must be assigned a set of scenarios from your team’s stories_scenarios_storyboards.docx document to implement and submit in GitHub pull requests for Milestone M1.

• Scenario plus Error Handling. 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 plan pull requests that total at least 10 hours of work for Milestone M1.
• 3-Scenario Minimum per Team Member. Each team member must be assigned at least 3 scenarios to implement and to submit as 3 pull requests.
• No Shared Pull Request Assignments. Do not assign a pull request to more than one team member. Although team members are encouraged to collaborate, the responsibility for completing a particular pull request must lie with one and only one 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 pull requests for M1 (e.g., demo-video creation, code reviewing).

Step 3: Plan Code Changes for Each Pull Request

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 Plan Formatting

Your team’s 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 whose scenarios 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).

To clarify what is expected, here are example pull request plans.

Grading Rubric

• 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.
• 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.
• Fail: Fails to meet requirements for Low-Pass.