Update issues templates and labels to display recent agreements about…

… workflow (#4344)

Co-authored-by: Haiko Schol <[email protected]>
Co-authored-by: JimboJ <[email protected]>

.github/CONTRIBUTING.md

@@ -174,8 +174,8 @@ If a change does not alter any logic (e.g. comments, dependencies, docs), then i
 
 ###  Labels
 
-The set of labels and their description can be found [here](../docs/docs/repo/labels.md).
-To change labels update [labels.yml](./labels.yml) file
+The set of labels and their description can be found [labels.yml](/.github/labels.yml).
+To change update this file and CI will automatically add/remove changed labels. 
 
 ### Process
 

.github/ISSUE_TEMPLATE/bug_report.md

@@ -2,12 +2,12 @@
 name: Bug report
 about: Create a report to help us improve
 title: ''
-labels: 'Type: Bug'
+labels: 'T-bug'
 assignees: ''
 
 ---
 
-## Describe the bug
+## Bug summary
 <!-- A clear and concise description of what the bug is. -->
 
 - 
@@ -96,5 +96,19 @@ specification section if a specification is not applicable):
 - operating system:
 - additional links:
 
+## Acceptance criteria
+<!-- Acceptance criteria establish conditions to fulfill for the item to be complete. Usually can be a list of checkboxes.
+Please refer to DOD for general implementation issue:
+- There should be at least one unit test
+- Recreate bug in deterministic way 
+- Regression test
+- Bug is not reproducible anymore both deterministically and non-deterministically 
+Acceptance criteria should be added as a check boxes (eg [] Do this) 
+-->
+[] Bug was recreated in deterministic manner
+[] Unit test that covers the problem
+[] Regression test done
+[] Bug is not reproducible anymore
+
 
 <!-- Thank you 🙏 -->

.github/ISSUE_TEMPLATE/epic.md

@@ -0,0 +1,30 @@
+---
+name: Epic
+about: 
+title: 'collection of business/tech scope'
+labels: 'Epic'
+assignees: ''
+---
+## Epic summary
+<!-- A clear and concise description of what the Epic is about. -->
+-
+
+## Links to related tech. design or research documents
+<!-- Add any other context, links or screenshots about the issue here. -->
+- 
+
+## Sub issues
+<!-- Mention sub issues here so people without ZenHub can see them -->
+- 
+
+## Acceptance criteria
+<!--Acceptance criteria establish conditions to fulfill for the item to be complete. Usually can be a list of checkboxes
+Please refer to DOD for general implementation issue:
+- Regression testing of the feature. You might create regression testing issue separately within an Epic if necessary testing is complex by itself
+- Feature is complete and confirmed by Tech. lead and one more team member
+-->
+[] Feature is complete and confirmed by Tech. lead and one more team member
+[] Regression testing done
+
+
+<!-- Thank you 🙏 -->

.github/ISSUE_TEMPLATE/implementation.md

@@ -0,0 +1,34 @@
+---
+name: Implementation
+about: General purpose issue template can be used pretty much for every implementation
+title: 'Implement ... '
+labels: 'T-implementation'
+assignees: ''
+
+---
+
+## Issue summary
+<!-- A clear and concise description of what the task is. -->
+-
+
+## Implementation details
+<!-- How this issue should be addressed. -->
+-
+
+## Other information and links
+<!-- Add any other context, links or screenshots about the issue here. -->
+- 
+
+## Acceptance criteria
+<!-- Acceptance criteria establish conditions to fulfill for the item to be complete. Usually can be a list of checkboxes.
+Please refer to DOD for general implementation issue:
+- AC should be complete so list everything that this issue suppose to have
+- 60% test coverage. No less then 60% of coverage for newly added lines
+- If applicable Regression testing. If this issue can be tested by its won mention Regression testing. 
+Acceptance criteria should be added as a check boxes (eg [] Do this) 
+-->
+[] Add AC's here..
+[] Regression testing (if applicable)
+[] New code is 60% covered with unit tests
+
+<!-- Thank you 🙏 -->

.github/ISSUE_TEMPLATE/investigation_or_research.md

@@ -0,0 +1,26 @@
+---
+name: Investigation
+about: 
+title: ' Investigate/ Research on ...'
+labels: 'T-investigation'
+assignees: ''
+---
+
+## Summary
+<!-- A clear and concise description of what should be investigated or researched. -->
+
+## Related resources
+<!-- List of additional resource that might be useful when doing research or investigation -->
+
+## Acceptance criteria
+<!-- Acceptance criteria in terms of investigation or research usually (but not only) should consist of:
+- list of open questions that need to be answered 
+- some summary, research paper or meta knowledge as an outcome of research or investigation
+- at least two people sign off. One of them is the Tech lead second should be decided with team
+- workshop or knowledge sharing session should be conducted to share outcomes
+-->
+[] add open questions here..
+[] Summary, research paper or meta knowledge written and merged to main repo (if applicable)
+[] Tech lead sign off
+[] Team member sign off (mention who)
+[] Workshop or knowledge session conducted if needed

.github/ISSUE_TEMPLATE/software_design.md

@@ -0,0 +1,35 @@
+---
+name: Software Design
+about: 
+title: 'Design ...'
+labels: 'T-design'
+assignees: ''
+---
+
+## Scope 
+<!-- Clarify what the design or architecture should cover (e.g., a system, feature, component, or entire product). -->
+
+## Functional Requirements
+<!-- A list of functional specifications the system or feature must fulfill. Use cases or user stories demonstrating expected behavior. -->
+
+## Non-Functional Requirements
+<!-- If applicable provide Performance, Scalability, Security or other metrics and characteristics of module to design -->
+
+
+## Related resources
+<!-- List resources that might be useful during design/research -->
+
+
+## Acceptance criteria
+<!-- Acceptance criteria in terms of design or architecture usually (but not only) should consist of:
+- at least two people sign off. One of them is the Tech lead second should be decided with team
+- workshop or knowledge sharing session should be conducted to share outcomes of Design
+- Software design artifacts provided (eg  flow chart, use case, pseudocode)
+- After design have been confirmed issues should be created and estimated
+-->
+[] Summary, design paper or meta knowledge written and merged to main repo
+[] Artifacts produced
+[] Tech lead sign off
+[] Team member sign off (mention who)
+[] Workshop or knowledge session conducted
+[] Issues created and estimated (if necessary)

.github/labels.yml

@@ -22,6 +22,11 @@
   description: pull request with next release changes.
 
 # Action/attention needed label. Marks that there is a specific action needed for issue/PR
+- name: A-in-QA-or-regression
+  color: "#8ceac8"
+  aliases: []
+  description: pull request or issues is currently in QA or regression testing phase.
+
 - name: A-tooBig
   color: "#FBCA04"
   aliases: []
@@ -47,46 +52,41 @@
   aliases: []
   description: issue requires detective debug work to figure out what's going wrong.
 
-- name: A-design
-  color: "#FBCA04"
-  aliases: []
-  description: issue requires design work to think about how it would best be accomplished.
-
 # Describes the type of issue or pull request.
 - name: T-bug
   color: "#FEF2C0"
   aliases: []
   description: this issue covers unexpected and/or wrong behaviour.
 
-- name: T-feat
+- name: T-implementation
   color: "#FEF2C0"
   aliases: []
   description: this issue/pr is a new feature or functionality.
 
-- name: T-enhancement
+- name: T-research
   color: "#FEF2C0"
   aliases: []
-  description: this issue/pr covers improvement of existing functionality.
+  description: this issue/pr is a research type issue.
 
-- name: T-refactor
+- name: T-investigation
   color: "#FEF2C0"
   aliases: []
-  description: this issue/pr covers refactoring of existing code.
+  description: this issue/pr is an investigation, probably related to some bug with unknown causes.
 
-- name: T-security
+- name: T-design
   color: "#FEF2C0"
-  aliases: []
-  description: this issue/pr covers security sensitive problem.
+  aliases: [ ]
+  description: this issue describes design requirements
 
-- name: T-research
+- name: T-refactor
   color: "#FEF2C0"
   aliases: []
-  description: this issue/pr is a research type issue.
+  description: this issue/pr covers refactoring of existing code.
 
-- name: T-investigation
+- name: T-security
   color: "#FEF2C0"
   aliases: []
-  description: this issue/pr is an investigation, probably related to some bug with unknown causes.
+  description: this issue/pr covers security sensitive problem.
 
 - name: T-question
   color: "#FEF2C0"

docs/docs/repo/labels.md

@@ -1,55 +1,3 @@
 ## Labels
 
-Below is the list of labels and their descriptions used in Gossamer repository.
-
-
-- **Epic** - Issue used to track development status of a complex feature, aggregates several issues.
-- **Feature-branch** - pull request from feature branch to origin.
-- **Release** - pull request with next release changes.
-- **good first issue** - issues that are suitable for first-time contributors.
-- **`A-`**  Action needed label. Marks that there is a specific action needed for issue/PR.
-  - **A-tooBig** - issue or PR needs to be broken down to smaller parts.
-  - **A-stale** - issue or PR is deprecated and needs to be closed. 
-  - **A-blocked** - issue or PR is blocked  until something else changes.
-  - **A-triage** - issue description needs refactor and/or labeled.
-  - **A-debug** - issue requires detective debug work to figure out what's going wrong.
-  - **A-design** - issue requires design work to think about how it would best be accomplished.
-- **`T-`** Describes the type of issue or pull request.
-  - **T-bug** - this issue covers unexpected and/or wrong behaviour. 
-  - **T-feat** - this issue/pr is a new feature or functionality.
-  - **T-enhancement** - this issue/pr covers improvement of existing functionality. 
-  - **T-refactor** - this issue/pr covers refactoring of existing code.  
-  - **T-security** - this issue/pr covers security sensitive problem.
-  - **T-research** - this issue/pr is a research type issue.
-  - **T-investigation** - this issue/pr is an investigation, probably related to some bug with unknown causes.
-- **`C-`** Complexity label. We operate only 3 complexity levels.
-  - **C-simple** -  Minor changes, no additional research needed. Good first issue/review.
-  - **C-complex** - Complex changes across multiple modules. Possibly will require additional research.
-  - **C-chaotic** - Unpredictable nature of this task/changes makes its chaotic.
-- **`P-`** Priority level. We only have 3 priority levels, everything else is average by default. 
-  - **P-critical** - this must be fixed immediately or contributors or users will be severely impacted.
-  - **P-high** - this should be addressed ASAP. **Colour #FBCA04**
-  - **P-low** - this is mostly nice to have. **Colour #0E8A16**
-- **`S-`** Scope this work related to, could be multiple, but usually this means that task needs to be break down.
-  - **S-sync-[westend | kusama | polkadot | paseo]** -  related to particular network syncing.
-  - **S-tests** - issue related to adding new tests.  
-  - **S-doc** - documentation related.
-  - **S-cli** - issue related to Gossamer CLI.
-  - **S-ci** - issue related to continuous integration tasks or pipelines.
-  - **S-crypto** - issues related to the lib/crypto package.
-  - **S-grandpa** - issues related to block finality.
-  - **S-babe** - issues related to block production functionality. 
-  - **S-runtime**- issues related to the lib/runtime package
-  - **S-telemetry** - issue related to node telemetry and metrics reports. 
-  - **S-rpc** - issues related to the dot/rpc package.
-  - **S-scale** - issues related to the pkg/scale package.
-  - **S-utils** - issues related to all other lib packages.
-  - **S-network** - issues related to the dot/network package.
-  - **S-state** - issues related to dot/state package.
-  - **S-subsystems-overseer** - issues related to polkadot host overseer functionality.
-  - **S-subsystems-collator** - issues related to polkadot host collator subsystem functionality.
-  - **S-subsystems-backing** -  issues related to polkadot host backing subsystem functionality.
-  - **S-subsystems-availability** - issues related to polkadot host availability subsystem functionality.
-  - **S-subsystems-disputes** - issues related to polkadot host disputes subsystem functionality.
-  - **S-infrastructure** - issues related to infrastructure and DevOps.
-  - **S-dependencies** - issues related to dependencies changes. Used by dependabot.
+Please refer to the list of [labels.yml](/.github/labels.yml)