equinor / equinor/prisma-decision-api

[DRAFT] issue list structuration

Open
#360 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
C#
Stars
3
Forks
3
Avg merge
2d 13m
Merged PRs (30d)
27

Description

This is a _draft_ gathering explaining (or starting explaining) an idea on how to ease the conversion from the issue list to the influence diagram.

Per today, we assume (at least some) issues correspond to the variables which appears in the influence diagram. This is an assumption which has been challenged by our experience. It appears in practice we are not always able to gather and synthesize discussion points into clear and atomic concepts.

The suggestion here is to add a step between the list of issues and building the influence diagram. There, relevant issues are refined into variables appearing in the subsequent influence diagram. The general process would be

```bash
Issues (messy, overlapping, informal)
↓ decomposition
Candidate variables
↓ classification
Decision / Uncertainty / Value
↓ refinement
Influence diagram nodes
↓ linking dependencies
Final influence diagram
```

The step From issues → structured elements needs to be added to our current workflow. This step needs to be properly documented.

**Remark:**
One issue may lead to several variables
Several issues may lead to one variables

The relationship between issues and variables can be either/or represented by a table or a graph.

This also implies modifications of the database:
- An issue is then described by a description, the name is no more mandatory.
- A variable is described by a name (no more description is required), a type, and a domain (states)
- Links between issues and variables
- The influence diagram is build from the variables, not the issues
- Probabilities and utilities are attached to variables and not anymore to issues

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the current workflow from the issue list to the influence diagram, then compare it with the proposed decomposition, classification, and refinement steps. Define how issues, variables, links, influence-diagram nodes, probabilities, and utilities relate, including the proposed database changes. Done means the revised workflow and data model are documented and agreed.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
backend-api-design, databases
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.