Transition to GitHub Projects for DITP Enterprise Teams

[swcurran]

We can use this issue to track the transition from ZenHub to GitHub issues.

Proposed Approach:

Columns

Assignment Ready, Assigned, In Progress, In Review, with the assumption that closed issues/PRs disappear off the board.

Initialization:

Use ZenHub assignments, GitHub assignments to populate the project from the current work in process. On first pass, do not add anything that is not assigned. There is not a need to add repos.

Process:

• Get two side by side brower windows
  • For each person, view their GitHub assignments (all repos)
  • Add the tasks to the Projects.
    • Should be able to do them all in one from BC Gov repos, but will likely have to be done by repo in Hyperledger.

On going management:

• Always create new issues in Project and in a repo
  • Avoid creating issues in specific repos if they are to be immediately part of the project, as we then have to do the extra step of importing the issue into the Project.
  • Can create issues in Hyperledger projects as well as BCGov issues by prefixing "hyperledger/" to the repo.
  • We can skip creating "general" issues in the DITP repo and just use Project issues (like this one) for that.
  • Continue to create "general" isssues in the DITP repo, as Project issues do not allow for comments.
• When we are ready to add an issue from an existing project into the Project, import it, updating it as necessary.
  • I think this should be fairly easy to do during Standups.
• Once a PR exists for an issue, I suggest closing the issue, and importing the PR into the Project. Importing the PR will be an additional step.
  • Developers will be "encouraged" (strongly) to add their own PRs to the Project for tracking.

Issues/PRs are NOT auto-added, and I don't think we want that. If the issue is going straight into the project, create it in the project -- no overhead in adding it. If the issue already exists, only import it when (to be) assigned.

The only pain I see with that are the PRs, and that will be a matter of reminding the developer to add them as they are created, or add them during the Standups.

Bigger Efforts -- Epics

There is not the concept of an Epic in GH Projects, but I don't think we made a lot of practical use of that in ZenHub, and I think that is OK not to be there. The proliferation of repos in our world mostly covers that, and often the work of an "epic" is an assignment to an individual on our team. We can use milestones and/or per repo labels in place of epics to get "groupings" of work.

Permissions

We will still have the editing issues with Hyperledger tasks (e.g. assigning), but it appears anyone will be able to drag'n'drop work as they move status values. We'll find out...

Standups:

The filtering will be sufficient during standups to manage/display the work by developer.

[swcurran]

I think the migration is complete. What I did:

• Went through each team member in ZenHub and added their issues to Projects, moving their ZenHub issues to the "Migrated" column.
  • For ZenHub issues -- added the linked issue directly to the Project, if any. Added ZenHub only comments that were relevant.
• Went through all remaining issues in the columns other than "New Issues" and "Epics", created them in the new Project, and moved them to "Migrated"
• Left a couple of ZenHub only issues that were not linked to any GitHub issues.
• Went through each team member's GitHub "All Assigned" PRs and Issues page and added any relevant ones not already in the Project to the Project.
  • Closing/unassigning issues as I went along.

I think we are now ready to go -- at least to get started.