🏃‍♂️ TLDR

• Ward/Ryan will add tasks to the 📋 Backlog in priority order, each task should be under a week of work.
• We'll meet Mondays to do a retrospective of the last week. We'll then review the 📋 Backlog and pick tasks for the week by adding them to 🏁 Selected for Dev. We'll meet Wednesdays to go over progress & blockers.
• When starting on a task, move it from 🏁 Selected for Dev to 🧑‍💻 In Progress. Move it back to 🏁 Selected for Dev during the week if you're uncertain it will get done.

• Add a task breakdown label to any issue over a week in scope and create a milestone.
• The end result should be a list of tasks added to the 📋 Backlog.
• ✋ If the overall scope becomes larger than anticipated, ping Ryan/Ward.

• If there is an emergency, we'll let the Dev team know. But in most cases Ward/Ryan will add the issue to the 📋 Backlog for consideration in the current or next sprint.

• Link the PR to the corresponding task issue OR remember to close the corresponding issue after the PR is merged into Staging OR put "closes #<issue-num>" in the PR description to auto-close the issue when merging (more options).
• Request a PR review from msupdatebot - this will automatically trigger a ping in the Dev campfire to get reviews from the team.
• Fully test your changes in Staging and reach out to Support (by replying to an existing thread or creating a new one) to have them test as well (your call).

• Every weekday at 3pm ET, we should merge Staging into Production. You can additionally merge earlier if needed.
• ✋ Do NOT merge into Production after 4pm ET (unless it's an urgent bug fix).
• After Staging is merged into Production, (if applicable) please let the Support team know about any issues you've fixed by responding in the Basecamp thread.

♻️ Workflow

We will be working in weekly sprints and Dev tasks will be organized and tracked as a Github Project here.

If you want to view the board in a specific view (e.g. only tasks assigned to yourself) just click your picture, then bookmark that filter, and then use that bookmark as your default way to get to the project board:

Only the stakeholders (

Ward

&

Ryan

) will add various task issues to the 📋 Backlog.

This list will be in priority order and include customer feature requests, support issues, internal features, infrastructure updates, etc.

Everyone on the team is encouraged to post 💡 Pitches for new feature ideas/enhancements. This is how you can get your ideas into the product.

Many tasks will start life as a Pitch (i.e. it's been fleshed out in terms of the problem, proposed solution, constraints, and design ideas). All Pitches will be discussed among the entire team. The stakeholders will then determine if the Pitch should be included in the 📋 Backlog for a future sprint.

Most Pitches are over a week in scope and therefore need to be broken down into smaller tasks. A task should never be more than a week's worth of work and ideally around 2 days.

In other words, a Dev should be able to complete the task (and have it merged into in production if applicable) in less than a week. This breakdown process itself should be a task (more on that later).

A collection of related tasks is called a milestone in Github (aka an epic).

The 📋 Backlog is made up entirely of smaller tasks (some within milestones) that are ready to be worked on in a future sprint.

Every Morning
Please look over any pending PR reviews first thing when you get in so we're not blocking code getting into Staging: https://github.com/320ny/memberspace_platform/pulls?q=is%3Apr+is%3Aopen+review%3Arequired+draft%3Afalse

• First, we'll do a 30 minute or less show-and-tell where each Dev presents the work that was 🎉 Done in the past week. They will also discuss what went well and didn't go well during the last week of work. Each Dev will have about 5 minutes.
  • Let's keep discussion to a minimum, but feel free to ping or start threads after the meeting.
• Next, we'll discuss the 📋 Backlog and go over what should be worked on next.
  • We'll start at the top and have each Dev choose which tasks they can work on for the upcoming weekly sprint. This is a good time to double check that tasks have been broken down enough (i.e. under a week in scope) and address any initial questions about the task.
  • When a Dev takes ownership of a task, they are committing to finishing it before the next Monday meeting. These tasks will be manually moved to the 🏁 Selected for Dev column and the Dev should be assigned to it:

    

  • Each Dev will decide how many tasks they want to take ownership of for the weekly sprint (based on their schedule that week, how certain they are on scope, if they are feeling burned out, etc). The point of the weekly sprint is to work around you and be realistic. So if you're feeling off that week or need a quasi-break just commit to less tasks that week.
    • Please do your best to NOT over-estimate how much you can get done in a week. If you happen to finish all your tasks early, you have a few options:
      • You can reach out to another Dev to see if they need help with testing, blockers, etc.
      • You can use the extra time to think through and create a 💡 Pitch you feel would be impactful.
      • You can grab any small looking Bugs in the 📋 Backlog to squash.
      • You can work on any small code refactors you feel are needed.
  • When a Dev actually starts working on a task they should manually move the task from 🏁 Selected for Dev to 🧑‍💻 In Progress.
  • During the week, if a task from 🧑‍💻 In Progress is uncertain to get completed, please move it back to  🏁 Selected for Dev so the rest of the team knows the task won't necessarily be completed before the next Monday meeting and we can all discuss what the blocker was.

---

⛏ Task Breakdown

1. When there is a task issue that needs to be broken down, we'll add a task breakdown label to it and create a milestone:

   

2. The end deliverable from a breakdown task is you'll create a number of new task issues within 📋 Backlog that all have the same milestone attached to them.
3. When you finish the task breakdown itself, you should mark the original issue as Closed (it will automatically move to 🎉 Done).
4. Please select the first broken down task you want to work on and move it to 🧑‍💻 In Progress and start working. ✋ If after doing a Task Breakdown the overall scope is much larger than anticipated, please ping

   Ryan

   or

   Ward

   to let us know before you begin working on the tasks. This way we can assess if this milestone is still worth working on. 
5. When creating issues from Task Breakdowns, it's easiest to do that within the 📋 Backlog so it's automatically added to the project board. Just click the "+" icon:

   

⚠️ Support Issues

• Support posts issues to their message board just like they've been doing. Ryan/Ward will then ping the Dev team if it's an emergency that needs to be worked on ASAP. This should be very rare.
• If the issue is not an emergency, Ward/Ryan will then add it to the 📋 Backlog for consideration in the current or next weekly sprint.

⤴️ Pull Requests

1. Either link the PR to the corresponding task issue OR remember to close the corresponding issue after the PR is merged into Staging OR put "closes #<issue-num>" in the PR description to auto-close the issue when merging. Here are more details from Github.
2. (OPTIONAL) Add other labels to your PR. We have an existing list of labels to use, but feel free to add new labels if you need more. By adding labels it can make it easier to search for your PR in the future 👀
3. When your PR is ready for review, if you request a review from msupdatebot, that will automatically trigger a ping in the Dev campfire to get reviews from the team:
   

   

4. When reviewing code, do NOT comment about styling - leave that for the robots. Remember, this is not your code.
5. After there are at least two approved reviews, the owner of the task issue should merge the PR into Staging.
6. When the PR is merged into Staging, the PR and the task will automatically be moved into the 🎉 Done column. The task will also be marked as closed automatically in Github:
   

   

   
   One exception is when you are working on a task that is part of a milestone - the task won't necessarily have a PR into Staging. In these cases, when you finish working on the task, please close it (it will then automatically move to 🎉 Done).
7. Please fully test your changes in Staging and also reach out to the Support team (by replying to an existing thread or creating a new one) to have them test as well. If you don't feel they need to test your changes that's your call, but generally the more people testing something the better 👀

🛳 Merging Into Production

• Every weekday at 3pm ET, we should merge Staging into Production. There will be an auto-reminder in Basecamp about this. Whoever sees it first, please create the PR and merge into Production.
• If needed, you can merge Staging into Production earlier as well, but we want to keep up the default of always merging Staging into Production at 3pm ET so that we're not relying on ad-hoc merging.
• ✋ Do NOT merge into Production after 4pm Eastern Time (unless it's an urgent bug fix).
• After Staging is merged into Production, (if applicable) please let the Support team know about any issues you've fixed by responding in the Basecamp thread.