# Github Issues Migration Plan

There are overall two areas
1) The figuring out of our processes
2) The actual migration of data

## The Processes

### Bugzilla

Downstream already links to Github Issues

Upstream
* Add a comment linking to BZ (https://bugzilla.redhat.com/show_bug.cgi?id=1234)
* Add a "bugzilla" label to the Github Issue

Port the Redmine Bugzilla script (which already runs on GHA) to be for GHA and

### JIRA

We don't have any integration today. Other folks are working on adding JIRA <-> GHI integration so that can help out with this portion later.

We should be able to rely on Satellite bugzilla <-> JIRA automation? (rchan suggestion)

For other stakeholders: any future integration is TBD

### Epics

#### Labeling Epics

TBD: Either use `[EPIC]` in the issue title, or create an `Epic` label

#### Identifying sub-issues and parent issues

option 1: In the parent issue description list the issues as clickable links and then child issues would show "a related"
option 2: Use a project board to organize the epic

### Issue Relation

Referencing another issue shows a relation

### Tags

Common labels use common colors

* Bugzilla
* High Priority
* Low Priority (maybe?)
* Katello
* GalaxyNG
* Documentation
* Easy Fix
* Wishlist (maybe?)
* Triaged
* Bug
* Feature
* Performance (maybe?)
* Demo-worthy ;)

Example label system (one of the better ones I've seen, skip to page 3-5 for the general ones) https://github.com/servo/servo/labels

We won't have Installer and Operator or CI/CD because they'll have their own GHI projects now

Default labels: https://docs.github.com/en/organizations/managing-organization-settings/managing-default-labels-for-repositories-in-your-organization

#### Project Specific labels
* Pulp2 (for RPM project only)
* Dev Environment (for installer only)

### Private issues and comments

We won't have these

### Querying and Filtering

* You can see issues for the pulp org: https://github.com/issues?q=user%3Apulp+
* Filter by label: https://github.com/issues?q=archived%3Afalse+user%3Apulp+label%3A%22Needs+Cherry+Pick%22

Filter syntax: https://docs.github.com/en/github/searching-for-information-on-github/searching-on-github/searching-issues-and-pull-requests

We won't have saved queries, but instead we can have a wiki page that will have links on it basically acting as saved queries

### Handling the workflow

NEW: Open and no assignee
ASSIGNED: Open with assignee
POST: Open and has linked:pr
MODIFIED: Issue was closed via merge PR with `closes #1234`
CLOSED - CURRENTRELEASE: Closed and on a milestone

https://docs.github.com/en/github/searching-for-information-on-github/searching-on-github/searching-issues-and-pull-requests#search-for-linked-issues-and-pull-requests

### Indicating a Release Blocker

Add an open issue to the milestone.

### Moving Issues between projects

Yes GHI can move issues between projects

### Checklist templates

Put these onto a wiki page as escaped markdown content and then paste it into the issue you need it in

### Sprint

Have a sprint label for the current sprint
To look at old sprints: have a query that uses sprint start and end dates and look for issues that were closed in that time window
Alternatively we can use a project board especially if we move to kanban

### Wiki

Yes we should use the wiki, and let's let each repo decide if they want to use it
We will port this data manually: https://pulp.plan.io/projects/pulp/wiki/

### Quarter field and wishlist buckets?

[homework] Experiment with project boards https://github.com/orgs/pulp/projects

## The Migration Plan

* Which issues do we migrate over (all? open?)
* Only NEW issues
* Should we keep redmine issues (as readonly)?
* Keep redmine but make it readonly
* Changelogs still point to redmine
* Need to align to a release
* Backports/old release branches
* Port release automation to old release branches
* Move repository by repository
* Move pulpcore later/last
* Lots of issues aren't labeled properly
* Have 1-2 people working with plugins to migrate their issues
* Unify labels across repositories (see line 45)
* Needs to happen before issue migration
* Use existing tooling
* https://github.com/IQSS/redmine2github
* Status of issues?
* Add a new status for migrated issues
* Migrate milestones?
* Migrate open milestones
* Make a project checklist