search

ScottishCovidResponse / SCRCIssueTracking

Central issue tracking repository for all repos in the consortium
6 stars 0 forks source link

Decide how issue tracking works for this phase of SCRC #761

Closed alysbrett closed 3 years ago

alysbrett commented 3 years ago

I think I remember a conversation recently (with Richard?) where we thought it would make sense to move away from the single repo for issue tracking and have issues in the various repositories brought together on a project board for the data pipeline grant. I suggest we leave the issue tracking repo as it is with the record of issues under RAMP but if any open issues are part of the plan under the grant we more them across to the repo they relate to as and when we need to.

My questions are:

  1. Does anyone see a problem with this?
  2. Should we keep treat the SCRCIssueTracking repo as frozen and rename it RAMPSCRCIssueTracking or should we keep it alive for issues with no logical repo to live in? Alternative is that those could be cards on the project board if not linked to code.
github-actions[bot] commented 3 years ago

Heads up @alysbrett @richardreeve - the "Admin & management" label was applied to this issue.

alysbrett commented 3 years ago

Notes/cards are very limited I think - no comment threads or labels? So we probably do still need the central repo for random issues, like this one!

bobturneruk commented 3 years ago

I think this is a fundamentally good plan.

Thinking about the data pipeline api bit specifically. I was planning to have a project board specifically for that, but maybe it's best (as @alysbrett suggests) to have one for everything? We don't currently have a single data pipeline api repo per language. Maybe we should, or maybe the R and Julia should join the python, C++ and Java? I'd planned to discuss these sorts of things with the api developers.

I think every project board needs a regular meeting to review tasks (or for this to be part of another meeting). They can easily go stale.

My plan for simple network sim was to move live issues from the issues repo into simple network sim. Maybe there's some clever github api way of moving or copying all issues with a specific tag?

richardreeve commented 3 years ago

I know there's a programmatic way to move issues like that because someone did it to a repo I was involved in last year, but unless you're feeling v enthusiastic, I think it might be easier to click through a few times and transfer issues by hand... I definitely think we should open up all of the issue trackers on the active repos and transfer the issues across though anyway.

richardreeve commented 3 years ago

As far as the one project board vs many is concerned, we could do a bit of light voting on Mon 22nd at our meeting? I could set that up - I'm getting quite used to mentimeter... if we have a few questions and not just this anyway, such as separate vs monorepo for the API people. Julia by default assumes that repos are packages, but I think the package manager is now flexible enough to allow that not to be the case - we'd need to check though.

alysbrett commented 3 years ago

I would be happy with either one project board and labels as needed for filtering, or maybe project boards for each working group and a central one for top level issues. Do milestones cut accross project boards? If so they could be used for combined views accross the working groups. The working group meetings should review their project boards or filtered views and the Co-Is meeting should review the big picture goals, resolve gaps & communication issues etc.

bobturneruk commented 3 years ago

I think we should try one board per theme. With data pipeline API backlog issues migrated to https://github.com/ScottishCovidResponse/data_pipeline_api.