[Feature]: Add a "Triage" workflow #9

New issue

Open

opened 2024-10-21 19:54:55 -03:00 by aleidk · 0 comments

aleidk commented

2024-10-21 19:54:55 -03:00

Owner

Type of Feature

✨ New Feature

Description

Create a workflow to categorize issues in rapid succession. The main idea is to prioritize meaningful work in pro of completing milestone and be "done" with the projects.

"I, as a developer, want to organize my workload so I can move forward the project towards the deadline"

Add labels to missing issues
Move to high and low priority
Bulk assign to a milestone
profit?

Completion criteria

Create design/mockups
Create a step system
1. Manage milestones: create if there's not enough, add/change deadlines
2. Categorize issues:
- 2.1 Add a severity label to all issues that doesn't have it
- 2.2 Add an estimated number of "working session" (required)
- 2.3 Optionally, add a deadline to an issue, if not added, it should take the deadline of the milestone
3. Review the issues and further apply changes:
- A "priority" label will be assigned based in the priority vs time until deadline
- Allow to modify the values of each issue, the same as before, and update the view accordingly
- Show a warning if is not possible to meet the deadline with the sum of "working sessions"
- The review can be done in 2 views:
  - Nested lists for each priority
  - Eisenhower matrix

Additional Information

The triage should be a modal or a dedicated page?
The changes needs to be saved in each modification
The priority label should be persisted in the forge or only showed in the view to allow dynamic calculation?
There should be a configuration value of what's the maximum number of working sessions allowed in a day, 3 by default
There should be a configuration value of the default number of working sessions assigned to an issue
The Eisenhower matrix should be available as an independent view too
For each project, there should be always at least 2 milestones:
- The next project goal/release and should be versioned (Ex: v0.1.2)
- The one after that, could be called "next" and serves as a "will do eventually", it should trigger a warning when it's too big (define "too big" in the configuration)
- The "next" milestone should have the option to be converted to a versioned milestone

### Type of Feature ✨ New Feature ### Description Create a workflow to categorize issues in rapid succession. The main idea is to prioritize meaningful work in pro of completing milestone and be "done" with the projects. _"I, as a developer, want to organize my workload so I can move forward the project towards the deadline"_ Add labels to missing issues Move to high and low priority Bulk assign to a milestone profit? ### Completion criteria - [ ] Create design/mockups - [ ] Create a step system - [ ] 1. Manage milestones: create if there's not enough, add/change deadlines - [ ] 2. Categorize issues: - 2.1 Add a severity label to all issues that doesn't have it - 2.2 Add an estimated number of "working session" (required) - 2.3 Optionally, add a deadline to an issue, if not added, it should take the deadline of the milestone - [ ] 3. Review the issues and further apply changes: - A "priority" label will be assigned based in the priority vs time until deadline - Allow to modify the values of each issue, the same as before, and update the view accordingly - Show a warning if is not possible to meet the deadline with the sum of "working sessions" - The review can be done in 2 views: - Nested lists for each priority - Eisenhower matrix ### Additional Information - The triage should be a modal or a dedicated page? - The changes needs to be saved in each modification - The priority label should be persisted in the forge or only showed in the view to allow dynamic calculation? - There should be a configuration value of what's the maximum number of working sessions allowed in a day, 3 by default - There should be a configuration value of the default number of working sessions assigned to an issue - The Eisenhower matrix should be available as an independent view too - For each project, there should be always at least 2 milestones: - The next project goal/release and should be versioned (Ex: _v0.1.2_) - The one after that, could be called _"next"_ and serves as a "will do eventually", it should trigger a warning when it's too big (define "too big" in the configuration) - The "next" milestone should have the option to be converted to a versioned milestone