We’re still figuring out how best to use repos and projects… One friction point for me is that adding something to a project means you create a “draft” and then have to convert it to an issue, picking a repo. The alternate way is to have an action in a repo that auto-adds new issues to a project.
Honestly, I don’t know which way I like better. But the auto-add action only works if a repo has an obvious project to add the issue to. For working groups, that only works if each working group has its own repo.
Auto-adding could also work if we had issue template(s) for each project that added some project-specific marker (like [DEPR] in the title, or a label) that could be used by the action to determine the destination project.
That said, the manual workflow of “create an issue and then choose a project” doesn’t seem that bad to me. For example, if you’re intending to create a BTR issue, and you have to create it in a repo named something like openedx/community, I imagine that you would intuitively remember that the next step would be to add it to the BTR project, since nothing in the process at that point had implied that your issue would be associated with BTR.
Can you say more about the advantage of a single all-working-groups repo? I don’t have a picture of when it would be useful to see all working group issues together.
For moving issues between working groups, issues can also be transferred between repos if need be.
(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? Or platform-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.)
