Updating team workflow

[choldgraf]

We have been working on a team workflow to track our high/low-level issues, and to coordinate our work more effectively (and asynchronously).

The goal of this workflow is to be lightweight, but provide enough structure that we have a bit more "signal to noise" in order to figure out what we should work on next (and what others are working on).

I'd love feedback from @2i2c-org/tech-team about this! It doesn't have to be perfect, but good enough for us to try out over the next few weeks.

related to https://github.com/2i2c-org/meta/issues/165

[choldgraf]

I've made a couple of changes:

• Addressed the comments that @damianavila brought up above
• Renamed the Active Development Backlog to instead be called the Activity Backlog. I feel like this is shorter and more memorable. Do others agree?

[choldgraf]

OK I think this language is in pretty good shape for an "alpha level" process. I requested reviews from @yuvipanda / @GeorgianaElena / @consideRatio to see if this sounds like a reasonable process to try! Since we'll be integrating deliverables from everybody's projects in one space, I want to make sure this sounds like a sensible approach for the team.

Here's a place to preview the plan:

https://2i2c-team-compass--73.org.readthedocs.build/en/73/practices/coordination.html#team-development-workflow

[consideRatio]

I'm very happy about this process and how explicit it is!! I like it!

I have a platform specific question about how we couple and couple deliverables and tasks to the backlog boards. My mental model is that we would...

1. Let deliverables and task (github issues) have the label "deliverable" and "task", and they can exist across the org in various projects.
2. We have automation in the github project boards adding new "deliverable" and "task" labelled issues across the org to the respective github project board into the needs discussion column (project backlog / activity backlog).
3. We then manually move the backlog entries around between columns, but we have automation to automatically move github issues being closed to the done column.
4. An fancy option to step 3 would be to let movement of between columns associate with adding/removing labels representing the column as well. Then automation need to be two way so that movement in the project board update the issue, and changes in the issue move the issue in the project board. A benefit of this would be the visibility of the status an issue has in the associated project board by just inspecting the issue itself.

PS: Automation for step 3 and 4 automation may require the associated GitHub issues to be in our GitHub org, or not work at all - I'm not sure.

[consideRatio]

Suggested change

	A deliverable is ready to work (and can thus be added to the Project Backlog) when it has the following properties (adapted from the [INVEST methodology](https://agileforall.com/new-to-agile-invest-in-good-user-stories/)).
	A deliverable is ready to work (and can thus be advanced to that column in the Project Backlog) when it has the following properties (adapted from the [INVEST methodology](https://agileforall.com/new-to-agile-invest-in-good-user-stories/)).

[choldgraf]

Ah good point. My one concern is that if we automatically add anything w/ Deliverable on it, then it'll become extremely long (depending on how many deliverables we have across all of our repositories). What do you think about this?

[consideRatio]

Hmmm I'm a bit confused - are you commenting regarding automation associated with labels or the suggested change about "added" vs "advanced to that column"?

If we don't make this update, I'm considering how the column in the backlog about discussion is meant to be used. First add ready for work, and then it can transition back to needs discussion/refinement?

[consideRatio]

@choldgraf regarding automation of labels, I'm not sure. If we don't, it means we don't really keep track of our deliverables in one place as i imagined the project backlog would do.

That would be fine, but it raises a question about what deliverables and when to add/remove them from the project backlog.

[choldgraf]

I think I had imagined something like:

	Need more info	Ready for Work
Low Priority	Stays in issues	Put in Ready to work
High Priority	Manually put in Needs Discussion/Refinement	Put in Ready to work

However, I think you are suggesting a simpler model, like:

	Need more info	Ready for Work
Low Priority	Auto put in Needs Discussion/Refinement	Move to Ready to work
High Priority	Auto put in Needs Discussion/Refinement	Move to Ready to work

Is that right? If so, I think I'm 👍 on trying your approach out, and seeing how it goes. We can use GitHub labels to tag priority high/low. What do you think?

[consideRatio]

Beautiful overview! Yes, that is what I meant and I now have a clear grasp on what I didn't before about what you meant!

I think both options make sense as long as they were a bit explicit, like both options now are.

I've just assumed it would be plausible to setup such automation, but I haven't done it. I think we should go for the non-automated approach until its proven viable. Looking into things I found some indication of viability but not by GitHub's official setup, but through https://github.com/philschatz/project-bot.

[choldgraf]

Quick point on automation: I think the automation would be quite easy using ghapi (https://ghapi.fast.ai/) for example.

[choldgraf]

@consideRatio most comments addressed! (and I released a new sphinx book theme, which fixed the guilabel thing)

I think the main outstanding question is whether to automatically add deliverables to the project backlog, or whether we should do so manually. See here for conversation on this. Would also be curious to hear what @damianavila thinks about it

[damianavila]

I think the main outstanding question is whether to automatically add deliverables to the project backlog, or whether we should do so manually. See here for conversation on this. Would also be curious to hear what @damianavila thinks about it

This is a good question. I really like automation... BUT, I think we should try this manually first for a few weeks to see how that works. I am also afraid of too many deliverables on the first column that could confuse people, so let's start with a few high-prio deliverables at the beginning that we add manually. Then, if everything flows, and when people are used to the process, we can put ALL the deliverables in the first column and automate the whole thing as @consideRatio proposed.
I really like the idea of using labels to 1) establish prioritization across deliverables, 2) automating the movement between columns, and 3) quickly check upstream information (as an issue, I see which deliverable I belong to).

[choldgraf]

OK - in the latest commit I've added Table 1 from my comment above. This is the one that suggests we manually put high-priority issues that need refinement in the respective column (rather than automating it). I agree that over time we should revisit this and decide if we want to tweak it a bit.

I think that this PR is ready to go from my end, unless others have tweaks they'd like to see. I think the question is "is this good enough for our team to give it a try?"

In the future, we should discuss more the options of automating, using priority labels, etc.

[damianavila]

I think this is ready for a first try!

[yuvipanda]

I appreciate the level of detail in here - just enough without being overwhelming. +1 to trying this for a while and seeing how this goes.

[GeorgianaElena]

Thanks for putting this worflow together and for describing it so well. I like it! 👍
Let's see it in action 🚀

[choldgraf]

thanks all for this helpful feedback and all of your advice! Let's merge this in, and start giving it a shot as a team :-)

I will update some of our team processes / docs / infrastructure today and then try to close out this deliverable :-)