I like to follow open edX PRs and they often reference JIRA tickets in the description to give context. Unfortunately, not all the JIRA tickets are open (even after I log in to https://openedx.atlassian.net ).
I understand that some tickets can contain private edx.org user information that can’t be broadly shared, but sometimes I think it’s just an oversight that the tickets aren’t visible (to logged in, but non-edX users).
Today, I’m interested in looking at these tickets:
Hey Peter - I wanted to give some additional insight into why our PROD & CR projects are internal only to edX. I can’t speak to all of our projects, but those two are owned by my team.
The team that owns these projects at edX is our Sustaining & Escalations team. We manage incoming issues and requests from partners, learners, and other engineering teams within the company. This means that our tickets typically include non-public and confidential business information. Our team is also predominately remote and we use Jira to collaborate asynchronously for engineering discussions. In an effort to reduce friction in communication and remove the cognitive load to remember what information requires the setting of a privacy flag, we chose to maintain internal projects.
With this said, I would like to better understand your use cases for leveraging our Jira tickets and what problem(s) you are solving by having direct access? I would like to see if we can find other solutions that can help you to achieve the goal that you are trying to reach. Happy to learn more!
I can’t speak for @pdpinch, but as far as I am concerned, ticket information is important to understand what is being included inside Open edX. This information is needed in at least two occasions, among others:
When following PRs, in order to understand what features are being developed.
When debugging Open edX, I frequently run git blame to better understand why a particular line of code was changed or written. This helps to understant the general context around the change.
Of course, tickets that contain private information should be kept internal. In such cases, the commit messages should duplicate the relevant information from the Jira ticket. Does that sound reasonable?
Thanks @fsheets for that context. I know it’s a challenge, but often the escalation tickets are the ones that are of most interest, because you are fixing problems that we are struggling with – or fixing problems we haven’t realized are problems yet.
We actually watch the edX releases very carefully to keep on top of PRs that affect our course teams on edx.org and to plan ahead for future releases at MIT. I appreciate the amount of description you put into a PR like https://github.com/edx/edx-platform/pull/22181 but I still can’t understand if this is something we need to communicate to our courses teams, or keep on a change list for when we release Juniper.
Another example is https://github.com/edx/edx-platform/pull/22102 – this sounds like an issue one of our users reported to me, but I can’t tell from the brief description in the PR. I imagine the JIRA ticket has steps to reproduce on it.
I guess I understand the default private stance, but is there a mechanism to request tickets be opened when they can be? I’ve thought about asking questions on PRs, but they’ve often merged before I notice them and it seems hopeless to comment on merged PRs.
@fsheets Maybe we could try for public information to be in the pull request? I know it is difficult to know in JIRA who can see the ticket. When people are adding comments to pull requests, it’s easy to know that it is a public space. Maybe that will help with the difficulty of knowing where to put what?
That would be possible for sure, but I would still be interested in knowing what information is useful to those trying to find it. This way we may be able to come up with a standard template of what information to include to reduce back and forth here. I find that knowing what the correct problem to solve is half the battle – figuring out solutions is our forte as engineers
For the narrow category of bug fixes, it would be helpful to know what the steps to reproduce are. I presume that’s part of the discussion on the JIRA ticket, but I don’t know for sure.
