# eliminating jira/gh coordination pain points

## Mission
RH teams have to serve the BU mandates manifested in jira at the moment, including non-public work introduction (basis and entity graph: https://miro.com/app/board/uXjVMmhblrs=/)

CNCF communities have to serve the community mandates represented by codes of conduct and tools hosted in github.

RH teams working as/with CNCF communities have to satisfy the superset of mandates from both groups.

This leads to duplication.

We want to streamline operations to eliminate duplication to the extent possible.

Existing internal tooling is unidirectional and not nuanced vis-a-vis hierarchical relationships of issues (syncJira).

Existing external tooling provides no controls to prevent proprietary data leakage from private (jira) systems (but does provide for bi-directional transport).

As a result, no existing tooling meets the needs of our teams.

---
Enter a hack-day project that Jesus started called **gh2jira** ([root](https://github.com/jmrodri/gh2jira), [enhancements](https://github.com/oceanc80/gh2jira)). Originally created for gh --> jira cloning only, there has been some work to enhance it in the direction of a general sync tool.

---

## Ruminations
### Lifecycle Sync
A method/approach to providing:
1. mapping from GH<->jira projects
2. a workflow sketch for each side
3. the ability to identify when the workflows for each are out of sync

possible GH lifecycle:

flowchart TD
  start((Start))
  open
  assigned
  closed
  start --> open
  open --> assigned
  open --> closed
  assigned --> closed
  closed --> open

possible jira lifecycle:

flowchart TD
  start((Start))
  todo["To Do"]
  inprogress["In Progress"]
  codereview["Code Review"]
  done["Done"]
  start --> todo
  todo --> inprogress
  inprogress --> codereview
  codereview --> done
  codereview --> inprogress
  done --> inprogress

Is it necessary to be able to model the whole lifecycle (i.e. valid goal states) or is it sufficient to identify when issues are not synch'd?

# projects.yaml : project properties file
projects: 
- description: SDK # user-readable label
  githubProject: operator-framework/operator-sdk # domain/project notation
  githubLifecycle: github-issue
  jiraProject: OPECO
  jiraLifecycle: jira-agile
  lifecycleMapping: agile-lifecycle
  credentialsFile: config.yaml

# projects.yaml : project properties file
projects: 
- description: SDK # user-readable label
  github:
      - project: operator-framework/operator-sdk # domain/project notation
      - lifecycle: github-issue
  jira:
      - project: OPECO
      - lifecycle: jira-agile
  lifecycleMapping: agile-lifecycle
  credentialsFile: config.yaml

# lifecycles file : containing valid state-names with no opinion about graph
lifecycles:
- name: github-issue
  status:
  - open
  - assigned
  - closed
- name: jira-agile
  status:
  - todo
  - inprogress
  - codereview
  - done

# lifecycle-mapping file : containing GH --> Jira lifecycle phase mapping, with no opinions about order, flow
lifecycle-mapping:
   name: agile-lifecycle
   - open : [todo]
   - assigned : [inprogress, codereview]
   - closed : [done]

### Link directions and interpretations
Do we need to have a 'standard' for linking GH --> jira issues, or is it sufficient to have jira --> GH only? The goal here being that we'd not run the risk of 'downstreaming' an issue which has already been processed.

- bidirectional linking would allow us to know the issue has already been processed
- existing, cloned jira would have a link to $domain/issues
- any risk of false positives if we presume this is the evidence of a clone/link?
-
- maybe we could create a label in GH which is used for this process instead of a link?
- coordinate issue/out-of-github issue in general (other docs?)?
- coordinate epic/non-epic github issues?