Core Contributors - Sprint grooming & planning

[antoviaque]

A minimal version of core contributors sprints has actually been implemented based on https://github.com/openedx/open-edx-proposals/issues/229 , providing a base structure and rhythm, with the 2-weeks sprints, the async checkins in Listaflow and the retrospective discussions based on these reports, both in the contributor meetup and on the forums. This ticket is meant to track the future work iterating on this base, to improve and extend it.

Specifically, most of the structure in place currently is reactive, looking back at what has been done in the past two weeks, but there is little in the way of planning or being able to coordinate/join current efforts. This next step would build upon a more consistent use of tickets to describe current and future core contributor work, and allow to do backlog grooming and sprint planning sessions (either asynchronously or synchronously) - cf https://hygger.io/blog/product-backlog-grooming-vs-sprint-planning/

The ability to implement these steps depend on ticket creation becoming more central and systematic to the work of core contribution, which should be enabled by the following two upcoming steps:

• Concluding the discussion about what is considered "core contributor time" -- the proposal currently uses the existence of tickets to define the scope, which should help encouraging it
• The initiative to make workflows more public - cf https://github.com/edx/open-source-process-wg/issues/83

To implement the grooming & planning of tickets, we could start with a synchronous session to be able to discuss and come up with a method together -- but we could also consider doing it asynchronously (OpenCraft does its planning async for 2 years now and it works well, though it requires more self-discipline than simply attending a meeting.)

[antoviaque]

@sarina @DeanJayMathew FYI - comments welcomed. I've created this task as a follow-up to https://github.com/openedx/open-edx-proposals/issues/229 as discussed there.

@ali-hugo @Kelketek Comments welcome too, about the way to implement the async planning/grooming -- maybe we can also use Listaflow for this, once we have moved OpenCraft to it for our own async planning and made sure it has everything needed for it?

@sarina What is the right project board to track this? Are we still using one specific to core contributors such as https://github.com/orgs/edx/projects/1 -- or maybe https://github.com/orgs/openedx/projects/33 ?

[sarina]

I think this makes sense. I like the idea of doing something once or twice as a synch meeting (to establish goals, make sure everyone is on the same page) before moving async. I'd like to make sure there's a clear motivation and value statement (why are we doing this?) that people can agree upon. I don't want to get to the point that multiple hours of everyone's commitment is spent prepping for meetings, planning, etc. I think focusing on the "what is CC work" is the most important thing we need to do right now.

@sarina What is the right project board to track this? Are we still using one specific to core contributors such as https://github.com/orgs/edx/projects/1 -- or maybe https://github.com/orgs/openedx/projects/33 ?

The first linked project is not in use, we did not migrate it because it really was a project only Nim was using. The latter project you linked seems to be @feanil 's project and I'm not sure if he intends for that to be "Feanil focused on community work" or "Work the community is doing to benefit the community"

[arbrandes]

This is relevant to my interests. I've been doing project managent for ongoing community frontend work - the work that I'm aware of, that is - via the Frontend Development board. It currently involves:

Sprint planning

The actual planning is mostly for tCRIL frontend staff (me and Brian S), potential funded work, plus the odd Build-Test-Release member. Otherwise, there's no planning: just pulling in tickets or PRs that are in progress.

• Jenna, Brian, and me meet before sprint starts to discuss what the priorities are. (Sometimes we don't have sync meetings, but have discussions in the epics prior to sprint start.)
• I create, groom, and (if applicable) assign epics and issues resulting from this planning
• I pull relevant issues into the next sprint with a "Backlog" status.
• Unassigned, "unsprinted" issues go in the Issue backlog view, prioritized from top to bottom, for anybody in the community to pick up.

What's missing here, as I see it, is:

• Knowing about what work is going to happen before it happens, and create issues for it
• Advertising the backlog so contributors could potentially pick from them, but also so people can add tickets to it

At sprint end

As "frontend community project manager" I review the sprint's issues and ping people about their status, updating them accordingly. Any issues that are still being worked on, or are blocked, I spill over into the next sprint. Issues where the assignee is unresponsive or cannot continue work are put back in the backlog.

This is of course frontend specific, but could be generalized.

[Kelketek]

Thanks for the ping on this, @antoviaque . I'll be watching closely.

So you all know, OpenCraft is transitioning to coordinating our sprint planning through Listaflow over the coming weeks. We'll update you all on how it's going, but we've been using a prototype version of the process on Monday.com for a while now. Essentially, we use a checklist every two weeks to prepare our sprint asynchronously.

This checklist includes items like:

1. Selecting your tasks for the next sprint
2. Verifying all of these tasks are properly refined
3. Reviewing your blocked tickets to see if any have been unstuck and pinging people on them if not.

It could have as many or as few tasks as the team needs to ensure get done each sprint. Of course, fewer tends to be better in terms of context switching and compliance. :)

[ali-hugo]

@antoviaque @Kelketek I'm interested to see how this develops. My only reservation would be adding yet another piece of admin for Core Contributors to complete each sprint (especially considering that most CC's are likely already involved in sprint planning for other teams).

Would it be possible for the sprint grooming and planning to be on a less frequent basis than every sprint?

[antoviaque]

@sarina

I'd like to make sure there's a clear motivation and value statement (why are we doing this?) that people can agree upon.

For me at least, this is about ensuring that:

• What I work on matches priorities -- without sprint planning work tend to be more reactive to passing urgencies, and tasks that are important but not urgent (or more difficult) tend to be postponed
• I only have to sort priorities once in a while during sprint planning, and can just rely on that work to focus on the tasks in the sprint and forget about all the other ones -- instead of having to reload the whole backlog in my mind every time I switch tasks or a new task gets added to it
• My time is properly allocated, with less interruptions and context switching -- proper sprint planning ensures that I will have time to do the work I select for a sprint so it isn't too hectic, and that I can also push back on sprint insertions confidently when they come in, because I already know that I won't have time for them if they aren't part of a task in the current sprint
• Be able to easily advertise to others what I'm working on, and more easily provide ETAs for when it will be ready, when they depend on my work or we need to collaborate on something at a given time (eg. reviews)

I don't want to get to the point that multiple hours of everyone's commitment is spent prepping for meetings, planning, etc. I think focusing on the "what is CC work" is the most important thing we need to do right now.

Yup, it makes sense to figure out "what is core contributor work" first, especially as the proposed measure will encourage the creation of tickets, which will be useful for implementing this.

In terms of time investment, I don't think it requires hours -- personally I only spend about 30-35min planning all my tasks (not just the 5h/week of core contributor work) each sprint. Also, in my experience every minute spent in focused upfront planning tend to save multiple order of magnitudes that amount later on -- it's of course possible to go overboard with this, but I have yet to witness this happening imho. :)

@arbrandes Looks like a good setup to me :+1: It doesn't really require more than that imho -- but that already makes a huge difference to do this.

@Kelketek Perfect! In the meantime we'll move forward on the dependencies here, and we'll regroup. :+1:

@ali-hugo

My only reservation would be adding yet another piece of admin for Core Contributors to complete each sprint (especially considering that most CC's are likely already involved in sprint planning for other teams).

It probably doesn't have to be a different step though, it could be part of the current sprint check-in flow in listaflow, just expanding the items related to "What are you going to work on this sprint?"? I'm reluctant to make sprints longer than 2 weeks, it's already quite a long time - and it usually works best when the various sprints someone has to participate in can be synchronized, and that all the planning/retro work can be done at the same time (the core contributor one just being exposing a subset of it, not additional work if you're already doing sprints).

[ali-hugo]

@antoviaque

It probably doesn't have to be a different step though, it could be part of the current sprint check-in flow in listaflow, just expanding the items related to "What are you going to work on this sprint?"

Ah, I see. That makes sense. Thanks for clarifying. I like this idea! :)

[sarina]

This issue hasn't been updated in two+ years, and this process has evolved. I'm going to close this out, and pending the result of the CC survey that ends 5/30, please open a new tracking issue in https://github.com/openedx/wg-coordination/issues