Public workstream Pilot

[hurtstotouchfire]

The purpose of this is to attempt to externalize some of our prioritization and workload and to create an intake funnel for contributions from outside the team. Tooling wise, here’s what I think this involves:

• Public workstream tracking boards in GitHub for each participating team / project to aggregate:

  • Funded contributions
  • Blended development
  • Operations work (deprs, devops, dependency updates, and open edx release tracking)
  • Known bugs
  • High level (epics) feature roadmap for internal 2U work

• Design Jira <-> GitHub integration #86

• Public wiki space for approach docs, roadmap related docs, any further context needed to understand the work in flight or planned. (see #476 for thought-work around this)

• Connect 2U Jira to GitHub for Product epics #79

Jira Integration Spec:
- 1:1 ticket relationship
- Useful to have attributes (description, etc) synced over time

[hurtstotouchfire]

We had another use case we were trying to flesh out, @nedbat can you comment about it? I think it was something about getting community input on feature work? Sorry I've forgotten already.

[nedbat]

The other use case was the overall big-picture Open edX roadmap. I imagine it will be a discussion among everyone in the community, including 2U (Jira-centric), tCRIL (GitHub-centric), and everyone else (also GitHub-centric). How can we make sure the discussion flows well between Jira and GitHub? Perhaps this is out of scope for this ticket.

[jristau1984]

Is "everyone else (also GitHub-centric)" known, or an assumption? I know that RaccoonGang uses YouTrack internally, and OpenCraft uses Jira internally. I presume "GitHub centric" is our avenue for seeing into their work, not their preferred way of tracking.

[antoviaque]

It's great to see this initiative, thank you for leading it! We all do need to expose more of our workflows and task management to be able to collaborate more effectively, and I'd love to find an approach for OpenCraft to participate in the effort.

We mainly use Jira (internally) and Gitlab (externally) for our task tracking, but given that Open edX is currently centered around Github, it makes sense to me to try to have the Open edX public workstreams there.

@bradenmacdonald Do you think we could try this out with blockstore, and the upcoming projects around it with modular learning?

@itsjeyd Any comments on your side? Since we already expose our work through OSPRs tickets & updates, would it be worth considering this as part of the work Michelle and you are planning, to organize upstream reviews?

[nedbat]

[Grooming] I left the checkboxes here. The design of the mechanics is here, the implementation is in #79.

[bradenmacdonald]

@antoviaque Sure, once the Jira->GitHub syncing mechanism is done, I'm sure we could use it to help make our tasks more public on those projects. I'm not sure it would add too much value though, as it's more like "what we're currently working on" than a roadmap of what we're going to do over the longer term.

[itsjeyd]

@antoviaque Yep, the process changes proposed here definitely relate to the work that @mphilbrick211 and I started doing as part of the OSPR Project Manager role.

The prospect of having more visibility into how participating teams are prioritizing tasks seems especially relevant, as it would probably help us identify PRs for which to accelerate the review process. (I had already raised a question about that particular point on the wiki.)

It would also be useful to be able to point PR authors to public boards that they could check/follow themselves in order to get updates on when to expect a review for their PR. (Based on what I've seen so far, PR authors currently depend on OSPR Project Managers for that kind of information; and it's not always possible to answer their questions.)

[antoviaque]

@itsjeyd Thank you! 👍

@bradenmacdonald

Sure, once the Jira->GitHub syncing mechanism is done, I'm sure we could use it to help make our tasks more public on those projects

I'm not sure I would start with an automation step, at least on our side -- besides delaying the experiment (waiting for the tool/dev), it usually means that we automate something we don't really know how/if it works. I'm a big fan of starting processes with the human element, even if that means doing few things manually at first (and once it works, then automate it).

Couldn't we reuse the approach we are currently using for our own free software projects, like Listaflow, but with Github instead of Gitlab? Ie, create the tickets related to those projects on Github/gitlab first, and then only link to it from our internal tickets? The discussions can then also fully happen publicly.

I'm not sure it would add too much value though, as it's more like "what we're currently working on" than a roadmap of what we're going to do over the longer term.

Since the "what we are currently working on" affects others and generates upstream changes, it's important to have this information public imho -- otherwise it's like trying to contribute to an open source project where the task tracker is private?

[nedbat]

I've made a separate issue for designing the behavior of the integration: #86

[bradenmacdonald]

@antoviaque

Ie, create the tickets related to those projects on Github/gitlab first, and then only link to it from our internal tickets? The discussions can then also fully happen publicly.

Sorry, I think I am fundamentally confused about what is even being asked here. We are tracking the Modular Learning project on GitHub already, on this board: https://github.com/orgs/openedx/projects/4/views/14 So what is expected from this initiative that's different than what we're already doing?

[antoviaque]

@bradenmacdonald The idea is to make the progress and discussions fully transparent -- a bit like if we were able to open our Jira board & tickets for this specific project. So it depends on what we put in the tickets on that board. Some questions to figure it out:

• Is there a 1-to-1 match between the tickets on https://github.com/orgs/openedx/projects/4/views/14 and our internal tickets scheduled in our individual sprints? The tickets on the public github board look like individual features/mini-epics, no?
• If there is a 1-to-1 match between our internal tickets and these tickets, are all the discussions we would normally have on our internal Jira tickets held publicly on the corresponding github ticket?

[nedbat]

@hurtstotouchfire (cc @antoviaque @bradenmacdonald @itsjeyd): is there a more public place where this discussion could be moved?

[bradenmacdonald]

@antoviaque

Is there a 1-to-1 match between the tickets on https://github.com/orgs/openedx/projects/4/views/14 and our internal tickets scheduled in our individual sprints? The tickets on the public github board look like individual features/mini-epics, no?

More or less. We have some minor tasks that I create like 'Touch base with Jenna on Friday.', 'think of some new name ideas for "ALUs" project', 'onboard Jill', etc. but those are more related to internal process than this project.

For example, my only task in the current sprint is "MNG-3388 Contribute technical parts to Approach Spec Memo" which corresponds to my part of openedx/platform-roadmap#209

If there is a 1-to-1 match between our internal tickets and these tickets, are all the discussions we would normally have on our internal Jira tickets held publicly on the corresponding github ticket?

We aren't having any discussions on the internal Jira tickets, other than about onboarding someone else to the project. All project-related discussions are happening in public on Slack #modular-learning and/or in calls that we have every week or so. For example, the link to the draft approach spec Google Doc was posted on Slack, and that's where all our work is currently happening.

[antoviaque]

@bradenmacdonald Thanks for the details! Then it looks like we are already doing everything publicly, which is great :) Kudos for already moving it forward this way. 👍

@hurtstotouchfire Does the approach work for you too, and does it matches what you had in mind too?

[hurtstotouchfire]

Yeah this all sounds like a great start! @bradenmacdonald I think what you are doing with these high-level tickets is what we are planning to do for Epics and high level work as well. The tricky bit that we are getting into now is how to track smaller pieces of work.

I'm less concerned about public tracking for more granular tasks within epics / new feature work. The place where I think we need to track smaller tasks publicly is for bugs and certain types of maintenance & upgrades (for instance I want to track our work around Tutor support).

The other big thing is if we do end up having repos where 2U is deploying master to production but someone outside 2U is the official maintainer, then we'd probably want to have workstream tracking that ensures dependency updates are happening and that forecasts a landing date for any new features or potentially breaking changes.

Regarding @nedbat's question:

@hurtstotouchfire (cc @antoviaque @bradenmacdonald @itsjeyd): is there a more public place where this discussion could be moved?

I think the discussion should be happening as part of the next stage of the maintainers pilot.

[hurtstotouchfire]

It would also be useful to be able to point PR authors to public boards that they could check/follow themselves in order to get updates on when to expect a review for their PR.

@itsjeyd I think it's worth having some synchronous conversations about this. Frankly I would expect that it is not possible to forecast review periods for any repos until they come under Maintainership and within that framework we are only just starting to define the process. We can start with a 1:1 possibly but I think we need to ensure that your efforts are central to the next maintainership pilot phase.

[itsjeyd]

Thanks @hurtstotouchfire, I'd be happy to talk about where OSPR management would fit in with the next maintainership pilot phase.

As I mentioned on Slack, @mphilbrick211 should probably join the synchronous conversation as well.

[mphilbrick211]

Thanks @itsjeyd! @hurtstotouchfire let me know how I can help!

[bradenmacdonald]

@antoviaque FYI the new board will all the tickets for the modular learning project (not just the high level ones) has been created here: https://github.com/orgs/openedx/projects/36

[itsjeyd]

See 2021-12-09 Office Hours Notes for the latest status of this conversation.

[nedbat]

Changed to blocked, pending phase 2 of maintainership.

[nedbat]

Assigned (optimistically) to Q3 2023

[nedbat]

@hurtstotouchfire This seems like something that wouldn't happen until Q4?

[e0d]

This needs to be groomed and probably broken up into smaller deliverables. Part of the process should be understanding what's still valuable here and should be our priority.