(Aside: We’re not talking about DevOps anymore… is there a way in Discourse to split out this new conversation into a new thread?)
Good point. If we moved forward with this, I would rather call it openedx/community or something like that. It could replace public-engineering, too, which is currently our “catch-all” issue repo.
The benefit I see is that it reduces chances for confusion. Take DevExp WG as an example, which currently has both a repo (wg-developer-experience) and a project board. Currently:
-
When deciding where to make an issue, you have several options. Does it go in a WG repo? If so, is wg-developer-experience right, or would wg-devops be better? Or should it go in a specific code repository? Or does it go in
public-engineering? Orplatform-roadmap? -
If you add an issue to the repo, then someone needs to remember to add it to the project board, otherwise it’ll sit in the repo and the WG will forget about it.
-
If you want to look at all the issues that the WG is facing, the repo seems like it might be the right place, but it’s actually the project board. That’s because the project board includes issues from other repos, too.
-
If you want to move a DevExp issue over to BTR, you’ll need to remove it from the DevExp board, add it to the BTR board, and move the issue over to wg-build-test-release repo. Skipping any of these steps will leave the issue in an ambiguous place.
(There’s also minor benefit for us on tCRIL on-call: it’d reduce the number of repos we need to create and juggle access rights for. But, that might be cancelled out if we need to maintain new automation in order to route the issues to the right projects.)