#4964 Jira Project Setup for Multi-Program, Multi-Document-Type Tasks

-

#4964 Jira Project Setup for Multi-Program, Multi-Document-Type Tasks

#4964 Topic: Jira for managing task assignments. Given that I have 5 unique programs that assign document reviews, and 3 types of documents, how can I use epics, tasks and pull-down fields to organize the work?


To cleanly track 5 distinct programs and 3 document types without creating a messy web of redundant boards or projects, use a single Jira project and divide your data across three orthogonal layers: Program (who owns it), Container (the review event), and Classification (what is being reviewed).

1. The Structural Hierarchy (Epics, Tasks, Sub-tasks)

Jira Issue TypeRole in Your WorkflowExample
EpicProgram Container (1 per program, 5 total)Program Alpha — Document Reviews
TaskReview Package / Event (holds the overall due date)PDR Package Review — Notice #2026-14
Sub-taskIndividual Reviewer Assignment (1 per doc/reviewer pair)Review: System Safety Plan (Assigned: J. Doe)

  • Why Epics = Programs: Having 5 permanent Epics (one for each program) lets you filter your entire backlog by program in one click, group roadmaps/timelines by program, and pull program-level roll-up metrics without needing 5 separate Jira projects.

  • Why Tasks = Review Packages: A single review notice often bundles multiple documents or requires multiple reviewers to sign off before the package is closed. Putting the "Needed-By Date" on the Task gives you one master deadline while allowing individual reviewers to move at their own pace on their respective Sub-tasks.

  • (Note: If your programs only ever assign one single document to one single person at a time, you can skip Sub-tasks and make each document review a Task directly under the Program Epic.)

2. Custom Pull-Down Fields (Dropdowns)

Keep your custom fields strictly to single-select dropdowns so JQL queries, dashboard pie charts, and pivot tables stay clean and free of typos.

Field NameField TypeOptions / ValuesPurpose
Document TypeDropdown (Single-Select)Type A, Type B, Type C (your 3 specific types)Allows cross-program reporting (e.g., "How many Type B documents did we review across all 5 programs in Q3?").
Program (Optional)Dropdown (Single-Select)Program 1 through Program 5While the Epic Link already identifies the program on Tasks, Jira Sub-tasks do not always inherit Epic fields cleanly in basic dashboard gadgets. Adding a Program dropdown—or auto-copying it via Jira Automation—guarantees clean sub-task reporting.
Review DispositionDropdown (Single-Select)Approved, Approved w/ Comments, Major Rework Required, N/ACaptures the outcome when a reviewer moves a ticket to Done, giving management quality metrics beyond simple completion counts.

3. Recommended Ticket Creation & Automation Flow

  1. Create 5 Long-Lived Epics: Name them after your 5 programs. Keep them in an In Progress status permanently so they always appear in the Epic Link dropdown.

  2. Log Incoming Notices as Tasks: When a program sends a review request, create a Task, link it to the corresponding Program Epic, set the Due Date, and select the Document Type.

  3. Spawn Reviewer Assignments as Sub-tasks: Create one Sub-task per assigned reviewer (or per document-reviewer pair).

  4. Automate Field Inheritance: Set up a simple Jira Automation rule: When a Sub-task is created → Copy Document Type and Due Date from Parent Task. This prevents manual data entry errors and ensures every sub-task has full metadata for JQL filtering.

4. How This Pays Off in Reporting (JQL Examples)

With this structure, answering management questions takes single-line JQL filters:

  • All overdue reviews for Program 2:project = "DOCREV" AND "Epic Link" = "Program 2" AND duedate < now() AND status != Done

  • Workload by document type across all programs:project = "DOCREV" AND issuetype = Sub-task AND status != Done (Group by Document Type in a Two-Dimensional Filter Statistics dashboard gadget, with Assignee on the other axis).


I would prefer unique templates for each of the 3 types of document reviews

To give each of your 3 document types a distinct template—with its own pre-filled review checklist, tailored description prompts, and automatic sub-task generation—while keeping your existing Program Epics, Document Type dropdown, and New Work → Assigned → In Progress → In Review → Done workflow intact, pair native Jira Issue Type / Field Configurations with Jira Automation.

Jira Cloud does not offer built-in per-dropdown-value description templates out of the box without Marketplace add-ons, so Jira Automation triggered on creation or Document Type selection is the cleanest native way to stamp unique templates automatically.

1. Define the 3 Unique Review Templates

Structure each template as a standardized Markdown block that gets injected into the Description field (and optionally spawns document-specific Sub-tasks):

Template 1: Document Type A (e.g., Technical / Requirements Specification)

### Review Scope & Metadata
* **Document ID / Revision:** [Auto-populated or enter here]
* **Functional Area / Area 1 / Area 2:** 
* **Applicable Baseline / Standard:** 

### Verification Checklist
- [ ] Requirements are atomic, unambiguous, and testable
- [ ] Parent-to-child traceability is complete with no orphan requirements
- [ ] Interface boundaries and tolerances are explicitly defined
- [ ] TBD / TBR items have documented closure plans

### Reviewer Findings Summary
* **Critical / Major Issues:** 
* **Minor / Editorial Comments:**

Template 2: Document Type B (e.g., Safety / Hazard / Compliance Plan)

### Safety & Compliance Metadata
* **Document ID / Revision:** 
* **Hazard / Risk Reference IDs:** 
* **Compliance Standard:** 

### Verification Checklist
- [ ] All identified hazards map to verified controls and mitigations
- [ ] Software criticality / safety classifications match program baseline
- [ ] Verification methods (Test, Analysis, Inspection, Demo) are appropriate
- [ ] Off-nominal and fault-tolerance behaviors are addressed

### Reviewer Findings Summary
* **Compliance Gaps:** 
* **Recommended Dispositions:**

Template 3: Document Type C (e.g., Operational / Test Procedure)

### Procedure Metadata
* **Document ID / Revision:** 
* **Target Configuration / Environment:** 
* **Prerequisite Documents:** 

### Verification Checklist
- [ ] Preconditions, safety cautions, and warnings appear before action steps
- [ ] Step-by-step sequence is executable without undocumented assumptions
- [ ] Pass/fail acceptance criteria are measurable at each verification point
- [ ] Rollback / abort recovery steps are explicitly defined

### Reviewer Findings Summary
* **Execution Blockers:** 
* **Clarifications Needed:**

2. Implementation Option A: Jira Automation Templates (Recommended)

This approach preserves your exact single Task issue type and uses your Document Type dropdown to dynamically populate the ticket.

Automation Rule Setup (1 Rule with If / Else-If Branches)

  1. Trigger: Issue created (or Field value changed → Document Type, restricted to when Description is empty so you never overwrite existing notes).

  2. Condition: Issue Type equals Task (or Sub-task, depending on where reviewers enter their notes).

  3. Branch 1 (If): Document Type equals Type A

    • Action (Edit issue): Set Description to Template 1.

    • Optional Action (Create sub-tasks): Automatically spawn standard sub-tasks specific to Type A (e.g., Systems Engineering Review, QA Traceability Check).

  4. Branch 2 (Else-if): Document Type equals Type B

    • Action (Edit issue): Set Description to Template 2.

    • Optional Action (Create sub-tasks): Spawn Type B sub-tasks (e.g., Safety Analysis Review, Compliance Audit).

  5. Branch 3 (Else-if): Document Type equals Type C

    • Action (Edit issue): Set Description to Template 3.

    • Optional Action (Create sub-tasks): Spawn Type C sub-tasks (e.g., Dry-Run Walkthrough, Test Criteria Verification).

Pro Tip on Smart Values: Inside the Automation Edit issue block, you can dynamically pull fields already entered on the creation screen using Jira smart values—for example: **Document ID:** {{issue.Document ID / Revision}} and **Functional Area:** {{issue.Functional Area}}—so the template pre-fills itself on creation.

3. Implementation Option B: Distinct Issue Types (If Fields Differ Dramatically)

If the 3 document types require completely different custom fields on the creation screen (not just different text checklists), promote the 3 document types from a dropdown into 3 custom Issue Types:

Issue TypeParent EpicScreen Layout & Required Fields
Doc Review - Type AProgram EpicShows Document ID / Revision, Area 1, Area 2, and Traceability Matrix Link
Doc Review - Type BProgram EpicShows Document ID / Revision, Functional Area, and Hazard Report ID
Doc Review - Type CProgram EpicShows Document ID / Revision, Test Environment, and Procedure Phase

  • Trade-off: Option B gives each document type its own dedicated Create Screen and Default Description (configured via Project Settings → Issues → Screens and field configurations), and eliminates the need for the Document Type dropdown since issuetype itself becomes your reporting dimension. However, Option A is faster to maintain if all 3 types share the same metadata fields (area_1, area_2, Functional Area, Document ID / Revision) and only differ in review checklists and sub-tasks.

4. Combining Templates with Your 5-Stage Workflow

To enforce template completion before a review closes, add a lightweight Workflow Validator (or Automation check) on the transition from In Review → Done:

  • Require the Review Disposition dropdown to be populated.

  • Optionally check that the Description no longer contains placeholder brackets ([Enter...]), ensuring reviewers actually filled out the template before marking the ticket Done.




From <https://gemini.google.com/app/ba89c9c782b9550b>  Google Gemini (4 Hydrogen)

Comments

Post a Comment

Popular posts from this blog

#4297 ISS Astronaut Unable to Speak

-
#4297 ISS Astronaut Unable to Speak #4297  Why might an astronaut on extended stay on ISS suddenly, but temporarily be unable to speak? An astronaut on the International Space Station (ISS) experiencing a sudden, temporary loss of speech (aphasia or dysphonia) is a serious medical concern that could stem from several environmental or physiological factors unique to microgravity. Here are the most likely scientific explanations: 1. Transient Ischemic Attack (TIA) Often called a "mini-stroke," a TIA occurs when blood flow to a part of the brain is temporarily blocked. The Space Connection: Microgravity causes a cephalad fluid shift , where blood and interstitial fluids move toward the head. This can alter cerebral blood flow and increase the risk of stagnant blood flow in the internal jugular vein, which has been documented in ISS crew members and could potentially lead to small clots. 2. Space Adaptation Syndrome (SAS) and "Space Fog" During the initial days or duri...
Read more

#3356 PHP and JavaScript to Retrieve and Set an API_Key

-
Image
#3356 PHP and JavaScript to Retrieve and Set an API_Key #3356 Create a JavaScript function that uses AJAX to retrieve and set an api_key from from a PHP script Below is a step‐by‐step example showing how to expose an api_key via a simple PHP endpoint and then retrieve it in JavaScript using a classic AJAX (XHR) call. The JavaScript function will parse the JSON response and store the key in a variable (you can adapt it to inject into headers, a config object, or wherever you need). 1. PHP endpoint ( get_api_key.php ) <?php // get_api_key.php header ( 'Content-Type: application/json' ); // In a real‐world scenario, you’d pull this from a secure location // (e.g. environment variable, config file outside webroot, encrypted store, etc.) $api_key = 'YOUR_SECRET_API_KEY' ; echo json_encode ([ 'api_key' => $api_key ]); Content-Type: We set JSON so the client can parse it easily. JSON payload: Returns an object like { "api_key":...
Read more

#4188 Hybrid/GraphRAG

-
#4188 Hybrid/GraphRAG #4188  Given a knowledge graph, including embedded documents with indexed document chunks, describe the prompt sequence for answering a user's question about the knowledge graph Answering a user's question using a hybrid Knowledge Graph (KG) and vector database (embedded document chunks) is a powerful approach often referred to as Graph Retrieval-Augmented Generation (GraphRAG) . Because you are combining structured data (graph relationships) with unstructured data (text chunks), a multi-step prompt sequence is usually required to accurately extract, retrieve, and synthesize the information. Here is the standard prompt sequence used in this architecture. 1. Query Analysis and Entity Extraction Prompt Before searching the database, the system must understand what to look for. The first prompt is sent to the LLM to break down the user's natural language question into actionable search parameters for both the Knowledge Graph and the vector database. Syst...
Read more