M1 Pull Request Plan - M0 Activity

Step 1: Assign pull requests to team members

Scenario-Implementation Work. Each team member must be assigned a set of scenarios to implement and submit in a GitHub pull request for Milestone M1. 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 three scenarios to implement.

• 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 2: 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.

Task-Plan Formatting

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

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