I just added a new blip to the tech radar to capture an experiment that is about to begin around the usage of GitHub Issues.
Blip Text:
Historically Open edX issue tracking was intertwined with edX internal issue tracking in Jira. As edX moves onto 2U internal infrastructure, the Open edX community needs a way to track issues (DEPR,bugs, feature requests) for the Open edX platform. We will enable GitHub Issues on a subset of Open edX repos as a part of recent updates to the DEPR process to learn more about whether or not GitHub issues meets our needs. Based on early experiences in the BTR working group and our overall desire to improve locality of information closer to the code we believe GitHub issues is a good initial tool to trial to solve this problem.
Is there documentation around the experiment, and what success would look like? Where will this be discussed?
For repos that were historically owned by a team at edX, who will be responsible for managing the GitHub issues? The exceptional case of edx-platform will also need to be looked at in particular, since it is more likely to have issues (based on size), and more difficult to manage (for many reasons). Are there tentative answers to these questions we can read about?
@nberdnikov that’s good to know, my understanding is not necessarily that the OSPR board would become private but that the edX’s work in general would move off of this instance of JIRA onto one that is internal to 2U. Which would mean that the only thing on this JIRA would be OSPRs, perhaps that’s still valuable and we should leave it like that but it would be useful to understand if we could just use the issues directly in GitHub to solve this problem if the benefit of tight integration with edX’s workflow is not there.
@robrap For the initial trial of DEPR issues specifically, the DEPR working group will track and manage those issues across all projects (this is what is under discussion in the PR linked above). No one on the working group has raised any issues with taking on this responsibility so it’s likely that this small change will land once some mechanics are worked out.
The thinking that I wanted to vocalize and share is that, we will probably try to do this for more types of issues as time goes on with the aggreement of the relevant stake holders(maintainers/owners). There are clear benefits to doing so:
Better localization of information.
Ease of visibility for the whole community.
Reducing toil between Jira/Github integration for OSPRs.
But again, I want to stress, that in order for issues to be the answer, there need to be people who are responsible for triaging, maintaining, updating and closing those issues for any given project. If those people don’t exist or don’t want to use GitHub issues, then we will probably not move those processes/workflows to GH Issues. Though, balancing individual preference and community consistency will come in to play a bit when we have this tough conversation.
Thanks @feanil. Once you open issues on a repo, I’m not clear on how you ensure that only DEPR issues will be created, but I think that is what you are saying is the current plan.
In any case, I’m happy to simply see acknowledgement of the larger issues/discussions that will be needed before rolling out github issues more widely. It’s useful to see both the benefits and the challenges. Thanks.
@robrap I am playing with some github issues templates seeking to clarify for individuals as to how they may use issues in a given repo - see https://github.com/openedx/tcril-engineering/issues/new/choose for some examples of how we’re using them at tCRIL. I’m hoping to extend this to indicate that only depr tickets may be filed, and to otherwise go to the forums. My hope is people will read, and few to none will do the wrong thing. We can’t know how this will work until we try, and I hesitate to go overboard to account for people doing the wrong thing until it’s proven that they do.
I have made a first attempt to address the following constraints:
We would like to create DEPR tickets in GH Issues
In order to do so, we will wish to gradually turn on GH Issues across multiple repos
We would like to try to head off potential spam, as well as questions/bug reports which ought to go in the forums
Further, I would like to avoid over-engineering a solution. I would like to get consensus that this MVP looks good enough, and if needed, we can tweak it if there is too much being created than we can keep up with.
Making blank issues is disabled. You’re clearly directed to the forums. And the DEPR template’s first line says “this is only for DEPR”. I could make a checkbox that asks people to ack that they understand the purpose of the ticket, but to me that feels oddly unwelcoming and punitive and I’d consider only post-MVP, if we think we need it.