update ADR with requirements around PI objective tracking

Author: ifsimicoded

docs/adr/20251211-github-issue-management-agreement.md

@@ -24,59 +24,65 @@ These needs can be accomplished by agreeing to a structure of organizing informa
 Currently I've seen different individuals put effort into implementing and suggesting (Thank you @vitor) systems for managing github issues and a strong desire to have all project work logged. That leads me to believe we need it, and there's appetite to align on one! So hopefully the buy-in is there.
 
 ### Constraints?
-- The Development Seed team currently organizes sprint work within our [Veda Dashboard Team project space](https://github.com/orgs/NASA-IMPACT/projects/17). Github projects allows us to manage issues in a centralized way that are distributed across repos often having different configs for issue meta data (types, labels, etc). That means we cannot rely on repo level meta data fields.
+- The Development Seed and stakeholder teams currently organize work within Github project spaces (ex. [Veda Dashboard Team sprint board](https://github.com/orgs/NASA-IMPACT/projects/17)). Github projects allow us to manage issues distributed across repos in a centralized way. Repositories can have different settings for issue meta data (types, labels, etc) which require extra overhead to align across all repositories that not all team members will have access to do so. **That means we cannot rely on repo level meta data fields to organize our work**.
+- IMPACT stakeholders need visibility into PI Objectives as issues that can be viewed on [this project board](https://github.com/orgs/NASA-IMPACT/projects/39/views/8)
 - Users may already have existing workflows (@aboydnw) that need to be preserved or easily updated.
 - We work on projects across organizations and share repos, so this system will need to also be shared out with and work for our collaborators so there's consistency across our shared repo issues.
 
 ## Proposed Guidelines
 
-### Epics 
-(or maybe PI Objectives, I'm not yet sure @aboydnw how you prefer to organize bodies of work*, but I don't think these bodies of work should be tied to PIs as they can often span more than one PI).
+### Initiatives
+All bodies of work should have a parent initiative captured in a GH Issue that will be a **living** document for the project for team members to reference both during and after the project work is completed. It should act as the central hub for documentation for the epic that can be referenced in the repo(s) README that results from the initiative.
 
-All bodies of work should have a parent epic captured in a GH Issue that will be a **living** document for the project for folks to reference both during and after the project work is completed. It should act as the central hub for documentation for the epic that can be referenced in the final epic repo(s) README.
-
-The epic/objective issue should have 
-- as assigned project(s) so it can show up in our [Veda Dashboard Team project space](https://github.com/orgs/NASA-IMPACT/projects/17)
-<img width="1156" height="483" alt="Screenshot 2025-12-10 at 11 55 14 AM" src="https://github.com/user-attachments/assets/bde8ecd3-44fa-4c12-94ee-5bd61463a5fb" />
+The initiative issue should have: 
+- an assigned project(s) of [Veda Dashboard Team](https://github.com/orgs/NASA-IMPACT/projects/17)
+- a project issue type of initiative 
+- an estimated start date and estimated delivery date (these could be as rough as quarters / PIs)
+<img width="1259" height="779" alt="github issue project settings" src="https://github.com/user-attachments/assets/bcf25d27-d931-416b-a821-b8c7d0b560fe" />
 
-- a title with an acronym and full name (ex. [EIE] Earth Information Explorer)
+- a title with an acronym, the word Initiative and a full name (ex. [EIE] Initiative - Earth Information Explorer)
 - a summary of what the work entails / the problem it is solving
 - the expected owners of the work
 - the expected stakeholders of the work
 - if there's an ongoing meeting, when it happens (so users can easily find the invite, gemini notes, and recordings)
-- an issue type of epic (with owner org access it would be easy [to add 'epic' as a ticket type](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/managing-issue-types-in-an-organization))
-- an estimated start date and estimated delivery date (these could be as rough as quarters / PIs)
-<img width="1269" height="471" alt="Screenshot 2025-12-11 at 12 22 02 PM" src="https://github.com/user-attachments/assets/2accce9b-d2da-4b35-87f4-9bfc1872ba56" />
-
 - risks
 - scope of work / what we have agreed to do and not to do 
 (TBD - when this shows up in our project workflow, but it must be defined)
-- all related milestones (if relevant) where milestone fields have 
-  - title 
-  - description / scope of work
-  - due date
 - deployed urls
+- github repositories
 - a resources sections which includes relevant document links (especially those not on GH) 
   - our contract,
   - product briefs, 
-  - repos, adrs, infrastructure docs, 
   - weekly sync notes, 
+  - figmas
+  - infrastructure docs that do not live within a github repository, 
   - external google docs, etc.
 
+An issue template will be provided to assist in Initiative issue creation.
+
 Keep in mind, this is a living document, so as new documents are created, they should be linked here and as high level project definition changes, that should be reflected here as well.
 
-When an epic is considered complete, any open tickets should be closed or moved to a Project specific Tech Debt epic (ex. [EIE - DEBT] Earth Information Explorer TECH DEBT)
+When an initiative is considered complete, if there are open tickets, a new Tech Debt issue should be created (ex. [Tech Debt] - EIE). All open tickets should be moved to sub-issues of this parent Tech Debt issue, or they may be closed as unplanned. 
+
+### PI Objectives
+An initiative will be broken down into sub-issues labeled PI Objectives to fulfill stakeholder progress tracking. 
+The PI Objective issue should have:
+- a parent issue of type initiative
+- an assigned project(s) of [IMPACT Project Board](https://github.com/orgs/NASA-IMPACT/projects/39/views/8)
+- a project name of VEDA
+- a program increment that corresponds to the PI 
+<img width="299" height="244" alt="github issue project settings" src="https://github.com/user-attachments/assets/cdb6421f-173d-4f02-ac58-d90fd314d3c8" />
 
-### Milestones
-If the epic/objective is a large body of work, sub-issues can be grouped into [milestones](https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/about-milestones) for better tracking. Milestones are not issues, they are meta data attached to an issue (like a label) but can have a title, description, due date. Issues can easily be prioritized under a milestone by dragging and dropping.
+- a title prefixed with the initiative acronym, year and quarter, (ex. [EIE] - 26.1 Objective 1: Prototype EIE)
+- details not included in the parent initiative about the scope of work
+
+An issue template will be provided to assist in PI Objective issue creation.
 
 ### Sub Issues
-Tasks will be used to breakdown the work needed to complete an epic. Because these will be defined as issues under an epic issue, the heirarchy/relationship to the epic will already be present. We should limit sub-issues to two levels for task visibility.
+Tasks will be used to breakdown the work needed to complete an initiative. As timelines become more clear, these sub-issues can be moved under the appropriate Initiative's sub PI Objective ticket. Because these will be defined as issues under an initiative issue or a PI Objective issue, the heirarchy/relationship to the initiative or PI Objective will already be present. We should limit sub-issues to two levels beyond this for task visibility.
 
 An Issue should have:
-- a parent (unless it is the parent epic or of type bug. Even [Tech Debt] can have it's own epic that can be used to track repo health)
-<img width="356" height="202" alt="Screenshot 2025-12-10 at 12 22 24 PM" src="https://github.com/user-attachments/assets/9d3069e1-571d-4eb0-81c4-e55c27feede5" />
-
+- a parent (unless it is the parent initiative, a parent tech debt issue or of type bug. [Tech Debt] can be it's own parent that can be used to track repo health)
 - a title prefixed with the epic acronym (ex. [EIE] Initial repo/application scaffolding)
 - a subtitle if the issue will contain output that isn't production code, ie. ADR (it's my understanding that ADRs can be RFCs if their status is in progress / in review), Doc, Spike. (ex. [EIE] Spike: globe visualization, [EIE] Doc: deploy process). 
 - a description
@@ -85,7 +91,7 @@ An Issue should have:
 - as the work is completed, for ADRs, Docs or Spikes or any body of work w/o a linked PR a link should be provided in the comments to the completed work for reference.
 - continue to use labels for 'good first issue'
 
-All issues (epics, sub-issues, bugs) should live in their relevant corresponding repo where possible. Otherwise our current practice is to manage issues in the `veda-ui` repo. 
+All issues (initiatives, Tech Debt, PI Objectives, sub-issues, bugs) should live in their relevant corresponding repo where possible. Otherwise our current practice is to manage issues in the `veda-ui` repo. 
 
 ### Pull Requests
 - Should be linked to an issue. You can use [GH keywords](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) like 'closes' or the `#` to bring up issue numbers to link without automations.