Add Creating-Responding-to-GitHub-Issues.md to the practice directory

practice/Creating-Responding-to-GitHub-Issues.md

@@ -0,0 +1,39 @@
+## Creating and Responding to GitHub Issues
+During weeks 6, 7, & 8; participants will create their own GitHub issues and respond to their peers' GitHub issues, on past projects. 
+
+#### Objective
+The purpose of these exercises are to expose participants to the process of ticketing systems for picking up work when collaboratively working on a team. Such processes, "picking up issues" or "being assigned a ticket" is relevant to the work tasking processes they will experience in their first developer role. 
+
+### Week 6: Create & Share three GitHub Issues in Past Projects
+- Participants should have been exposed to creating GitHub issues by now. If they need a refresher, they can watch [this video on creating GitHub issues](https://www.dropbox.com/scl/fi/hbz2rzxbrda6gfvq11xnv/How-to-Create-a-GitHub-Issue.mp4?rlkey=0d63w2fisn33fepjnlcxj919g&st=1vy3gnu4&dl=0). They need to go back to their past week’s projects and add three different issues. 
+- They should create issues that call out fixing existing bugs, adding new or enhancing existing features, or contributing to prospective optimization. Their cohort-mates will request an issue to resolve through a pull request, in the following week, so the issue must be descriptive enough for someone unfamiliar to the project and its codebase.
+  - The participant's issue should be detailed about the existing state of the issue they are reporting (a screenshot or GIF), as well as where to find the issue (link to specific files or lines of code), how to recreate it, the existing behavior, and desired behavior.
+  - Their issue should have any project context to answer questions ahead of someone picking up the issue, to minimize the amount of time it takes them to onboard into working on the issue.
+- Participants should be prepared to also share their three issues during the week's project share. 
+
+### Week 7: Request to Work on a Peer's Past Project Issue
+- Participants should be ready to contribute to one of their cohort-mates past project issues.
+- They should take one day to find an issue to request to work on. 
+- As the issue owner, 
+  - they will need to respond to any incoming comments requesting to work on an issue; 
+  - they will also need to review incoming PRs related to the issue which includes reviewing code, leaving critiquing feedback and comments; as well as 
+  - submit PR approvals, branch merges, PR/branch closing, and issue closing after an issue is resolved. 
+- As the issue requester, 
+  - they will need to comment on the issue they would like, 
+  - wait for the owner to confirm you as assigned and/or follow up with the owner about being assigned if some time has passed, 
+  - manually assign themselves to the issue once confirmed (if the owner hasn’t done it),
+  - update the issue with a comment referencing the PR if the issue doesn't automatically pick up the PR, and 
+  - submit a PR in response to the issue (referencing the issue in the PR description). 
+- They should be prepared to also share their PR in response to a peer’s issue during the week's project share. 
+
+### Week 8: Submit a PR on a Peer's Past Project Issue
+- Day 1: 
+  - Participants should still be working on creating a pull request in response to one of their cohort-mates past project issues. 
+  - Participants may need to follow up with the issue owner if they haven’t been confirmed as assigned to work on the issue by now. 
+  - Participants should take the first day of the week to plan out their daily work for the PR if they haven’t already started making progress, in order to time manage their work alongside their weekly project and other deliverables. 
+- Day 2: 
+  - Participants should be approved to work on the issue and actively committing changes to a new branch on their repo. 
+  - Do they have any context questions you need to reach out about? 
+  - Is their PR clear enough for someone not familiar with the issue? 
+  - Do they have visuals (before and after)? 
+- Day 3 - 5: Submit their PR for approval and respond to any change requests or comments.