Update the Core Team DoD and issue templates (#4636)

* Update the Core Team DoD and issue templates

closes #4635 .

* Update CHANGELOG.md

* Fix spellings

* fix spellings

* fix last spellings

.github/ISSUE_TEMPLATE/bug_report.md

@@ -8,7 +8,7 @@ assignees: ''
 ---
 
 # Problem encountered
-A clear and concise description of what the bug is.
+A clear and concise description of what the bug is. Adjust the bug labels to identify assumed severity.
 
 # Observed behaviour
 A clear and concise description of how the system is behaving.
@@ -31,14 +31,28 @@ Steps to reproduce the behaviour manually:
 ## Automation
 Link to automation and explanation on how to run it to reproduce the problem/bug
 
-https://github.com/vegaprotocol/system-tests/tree/master/....
-
-`Add the necessary file(s) needed to reproduce the problem`
-
 # Evidence
 
 ## Logs
 If applicable, add logs and/or screenshots to help explain your problem.
 
 ## Additional context
 Add any other context about the problem here including; system version numbers, components affected.
+
+# Definition of Done
+>ℹ️ Not every issue will need every item checked, however, every item on this list should be properly considered and actioned to meet the [DoD](https://github.com/vegaprotocol/vega/blob/develop/DEFINITION_OF_DONE.md).
+
+**Before Merging**
+- [ ] Code refactored to meet SOLID and other code design principles
+- [ ] Code is compilation error, warning, and hint free
+- [ ] Carry out a basic happy path end-to-end check of the new code
+- [ ] All APIs are documented so auto-generated documentation is created
+- [ ] All bug recreation steps can be followed without presenting the original error/bug
+- [ ] All Unit, Integration and BVT tests are passing
+- [ ] Implementation is peer reviewed (coding standards, meeting acceptance criteria, code/design quality)
+- [ ] Create [front end](https://github.com/vegaprotocol/token-frontend/issues) or [console](https://github.com/vegaprotocol/console/issues) tickets with feature labels (should be done when starting the work if dependencies known i.e. API changes)
+
+**After Merging**
+- [ ] Move development ticket to `Done` if there is **NO** requirement for new [system-tests](https://github.com/vegaprotocol/system-tests/issues)
+- [ ] Resolve any issues with broken system-tests
+- [ ] Create [documentation](https://github.com/vegaprotocol/documentation/issues) tickets with feature labels if functionality has changed, or is a new feature

.github/ISSUE_TEMPLATE/feature_ticket.md

@@ -6,117 +6,56 @@ labels: "feature"
 assignees: ''
 ---
 
-_Ensure the ticket title clearly communicates what this feature ticket makes possible_
-
-_Add the **milestone** and **project** of the Major Release this feature is part of i.e. Oregon Trail_
-
-_Add a **label** for the feature that this ticket is part of i.e. Data Sourcing_
-
 # Feature Overview
-A simple overview that describes **what** this feature (or sub feature) needs to do and **why** it's valuable. 
-This should be brief, understandable by anyone in the business and use one of the following the formats: 
-
-**As a** (who - the type of user/actor the feature serves)
-**I want** (what - the action to be performed / made possible)
-**So that** (why - the goal/result/value it achieves to the user/actor or the business)
 
-or
-
-**In order to** (context - overcome a problem or meet a requirerment)
+**In order to** (context - overcome a problem or meet a requirement)
 **We will** (what - carry out this piece of work / action)
 **So that** (why - we create these outcomes)
 
 ## Specs
-
 - [Link](xyz) to spec or section within a spec
-- [Link](xyz) to another spec or section
 
 # Tasks
-A checklist of the tasks that are needed to develop the feature and meet the accceptance criteria and feature test scenarios. Ideally, tasks would reflect the pull requests likely to be created when developing the feature. 
-
+A checklist of the tasks that are needed to develop the feature and meet the acceptance criteria and feature test scenarios. Ideally, tasks would reflect the issues/pull requests likely to be created when developing the feature. 
 - [ ]
 - [ ]
-- [ ]
-
-# Product Owner
-The name of the person in the Product team that is responsible for this feature. This will be the go-to person for the engineer working on this ticket for any questions / clarifications, to get feedback on work in progress and who will ultimately accept the feature ticket as 'done'.
-
-_**Assign** the named product owner to the ticket_
 
 # Acceptance Criteria
-A list of criteria (aim for 3!) that have to be met for this feature to be accepted as 'done' by the product owner. Acceptance criteria should be simple, single sentence, statements written from the perspective of the work already having been done. Each statement should be able to be objectively determined to be true or false. For example:
+A list of criteria (aim for 3!) that have to be met for this feature to be accepted as 'done' by the product owner.
 
 - It is possible to
-- It is possible to
-- Vega does
-- Vega does
 
 Acceptance Criteria and Feature Test Scenarios can, in some cases, be closely related. If acceptance criteria become fully covered by feature test scenarios they can be removed leaving on acceptance criteria that can't be directly or fully proven with tests.
 
 # Test Scenarios
 Detailed scenarios (1-3!) that can be executed as feature tests to verify that the feature has been implemented as expected. We use the follow format:
 
 GIVEN (setup/context) 
-
 WHEN (action) 
-
-THEN (assertion) 
-
-For example...
-
-```gherkin
-    Feature: Account Holder withdraws cash
-    Scenario: Account has sufficient funds
-    Given the account balance is $100
-      And the card is valid
-      And the machine contains enough money  
-    When the Account Holder requests $20
-    Then the ATM should dispense $20
-      And the account balance should be $80
-      And the card should be returned
-```     
-
-See https://github.com/vegaprotocol/vega/tree/develop/integration/ for more format information and examples.
-
-_TBC whether these should be separate files  - will come back to this_
-
-# Impacted Systems / Engines
-A list of the engines that we believe will be impacted by the development of this feature. _Delete as appropriate_
-
-- Core - banking
-- Core - collateral
-- Core - execution
-- Core - fee
-- Core - governance
-- Core - liquidity
-- Core - oracles
-- Core - positions
-- Core - risk
-- Core - settlement
-- Core - monitor
-- API
-- Wallet
-- Liquidity bot
-- Trader bot
-
-# API Calls
-A list of the API calls that are needed for this feature, written in an implementation-agnostic format i.e. "Get a list of widgets, categorised by X", rather than "GET /widgets?category=X":
-
-- Get a list of widgets, categorised by X
-- Get x
-- Get y
-
-# Dependencies
-Links to the tickets that represent work that this feature ticket is dependent on to be able to start / finish development. This could be another feature ticket, an important refactoring task, some infrastructure work etc. For each dependency please add a categorisation of the type of dependency (hard or soft) and whether it is internal or external to the team.
-
-- #Link to ticket + Dependency ticket name | hard/soft | internal/external 
-- #Link to ticket + Dependency ticket name | hard/soft | internal/external
-- #Link to ticket + Dependency ticket name | hard/soft | internal/external 
-
-_Add a **label(s)** to represent the types of dependency this feature ticket has (soft_internal_dependency, soft_external_dependency, hard_internal_dependency, hard_external_dependency)_
+THEN (assertion) For example...
+See [here](https://github.com/vegaprotocol/vega/tree/develop/integration/) for more format information and examples.
 
 # Additional Details (optional)
 Any additional information that provides context or gives information that will help us develop the feature. 
 
 # Examples (optional)
 Code snippets from the spec for reference
+
+# Definition of Done
+>ℹ️ Not every issue will need every item checked, however, every item on this list should be properly considered and actioned to meet the [DoD](https://github.com/vegaprotocol/vega/blob/develop/DEFINITION_OF_DONE.md).
+
+**Before Merging**
+- [ ] Create relevant for [system-test](https://github.com/vegaprotocol/system-tests/issues) tickets with feature labels
+- [ ] Code refactored to meet SOLID and other code design principles
+- [ ] Code is compilation error, warning, and hint free
+- [ ] Carry out a basic happy path end-to-end check of the new code
+- [ ] All APIs are documented so auto-generated documentation is created
+- [ ] All acceptance criteria confirmed to be met, or, reasons why not discussed with the engineering leadership team
+- [ ] All Unit, Integration and BVT tests are passing
+- [ ] Implementation is peer reviewed (coding standards, meeting acceptance criteria, code/design quality)
+- [ ] Create [front end](https://github.com/vegaprotocol/token-frontend/issues) or [console](https://github.com/vegaprotocol/console/issues) tickets with feature labels (should be done when starting the work if dependencies known i.e. API changes)
+
+**After Merging**
+- [ ] Move development ticket to `Done` if there is **NO** requirement for new system-tests
+- [ ] Resolve any issues with broken system-tests
+- [ ] Create [documentation](https://github.com/vegaprotocol/documentation/issues) tickets with feature labels if functionality has changed, or is a new feature

.github/ISSUE_TEMPLATE/spike_ticket.md

@@ -6,27 +6,23 @@ labels: "spike"
 assignees: ''
 ---
 
-
 # Spike Overview
 
-**In order to** (gain an understanding of...)
-**We will** (carry out investigation / prototype)
-**So that** (we reduce risk when implementing....)
+**In order to** (gain an understanding of... agreed scope)
+**We will** (carry out investigation / prototype... within the scope)
+**So that** (we reduce risk when implementing.... given feature)
 
 ## Specs
 - [Link](xyz) to spec or milestone document info for the feature
 
-
 # Acceptance Criteria
 How do we know when this spike is ready to either drop or move into technical tasks:
-
-- We understand that...
-- It is possible to...
-- Vega is able to...
-
+- [ ] We understand that...
+- [ ] Scope of the spike is covered; reasons why not discussed with the engineering leadership team
+- [ ] Spike findings presented in order to determine the next steps for the work
 
 # Additional Details (optional)
-Any additional information including known dependacies, impacted components.
+Any additional information including known dependencies, impacted components.
 
 # Examples (optional)
 Code snippets, links to prototypes.

.github/ISSUE_TEMPLATE/technical_task.md

@@ -8,7 +8,7 @@ assignees: ''
 
 # Task Overview
 
-**In order to** (context - overcome a problem or meet a requirerment)
+**In order to** (context - overcome a problem or meet a requirement)
 **We will** (what - carry out this piece of work / action)
 **So that** (why - we create these outcomes)
 
@@ -17,7 +17,6 @@ assignees: ''
 
 # Acceptance Criteria
 How do we know when this technical task is complete:
-
 - It is possible to...
 - Vega is able to...
 
@@ -27,14 +26,32 @@ Detailed scenarios (1-3!) that can be executed as feature tests to verify that t
 GIVEN (setup/context) 
 WHEN (action) 
 THEN (assertion) 
-
 See [here](https://github.com/vegaprotocol/vega/tree/develop/integration/) for more format information and examples.
 
 # Dependencies
 Links to any tickets that have a dependant relationship witht his task.
 
 # Additional Details (optional)
-Any additional information including known dependacies, impacted components.
+Any additional information including known dependencies, impacted components.
 
 # Examples (optional)
 Code snippets, API calls that could be used on dependant tasks.
+
+# Definition of Done
+>ℹ️ Not every issue will need every item checked, however, every item on this list should be properly considered and actioned to meet the [DoD](https://github.com/vegaprotocol/vega/blob/develop/DEFINITION_OF_DONE.md).
+
+**Before Merging**
+- [ ] Create relevant for [system-test](https://github.com/vegaprotocol/system-tests/issues) tickets with feature labels
+- [ ] Code refactored to meet SOLID and other code design principles
+- [ ] Code is compilation error, warning, and hint free
+- [ ] Carry out a basic happy path end-to-end check of the new code
+- [ ] All acceptance criteria confirmed to be met, or, reasons why not discussed with the engineering leadership team
+- [ ] All APIs are documented so auto-generated documentation is created
+- [ ] All Unit, Integration and BVT tests are passing
+- [ ] Implementation is peer reviewed (coding standards, meeting acceptance criteria, code/design quality)
+- [ ] Create [front end](https://github.com/vegaprotocol/token-frontend/issues) or [console](https://github.com/vegaprotocol/console/issues) tickets with feature labels (should be done when starting the work if dependencies known i.e. API changes)
+
+**After Merging**
+- [ ] Move development ticket to `Done` if there is **NO** requirement for new system-tests
+- [ ] Resolve any issues with broken system-tests
+- [ ] Create [documentation](https://github.com/vegaprotocol/documentation/issues) tickets with feature labels if functionality has changed, or is a new feature

.github/ISSUE_TEMPLATE/user_story.md

@@ -27,14 +27,33 @@ Detailed scenarios (1-3!) that can be executed as feature tests to verify that t
 GIVEN (setup/context) 
 WHEN (action) 
 THEN (assertion) 
-
 See [here](https://github.com/vegaprotocol/vega/tree/develop/integration/) for more format information and examples.
 
 # Dependencies
-Links to any tickets that have a dependant relationship witht his task.
+Links to any tickets that have a dependent relationship with this task.
 
 # Additional Details (optional)
-Any additional information including known dependacies, impacted components.
+Any additional information including known dependencies, impacted components.
 
 # Examples (optional)
-Code snippets, API calls that could be used on dependant tasks.
+Code snippets, API calls that could be used on dependent tasks.
+
+# Definition of Done
+>ℹ️ Not every issue will need every item checked, however, every item on this list should be properly considered and actioned to meet the [DoD](https://github.com/vegaprotocol/vega/blob/develop/DEFINITION_OF_DONE.md).
+
+**Before Merging**
+- [ ] Create relevant for [system-test](https://github.com/vegaprotocol/system-tests/issues) tickets with feature labels
+- [ ] Code refactored to meet SOLID and other code design principles
+- [ ] Code is compilation error, warning, and hint free
+- [ ] Carry out a basic happy path end-to-end check of the new code
+- [ ] All acceptance criteria confirmed to be met, or, reasons why not discussed with the engineering leadership team
+- [ ] All APIs are documented so auto-generated documentation is created
+- [ ] All Unit, Integration and BVT tests are passing
+- [ ] Implementation is peer reviewed (coding standards, meeting acceptance criteria, code/design quality)
+- [ ] Create [front end](https://github.com/vegaprotocol/token-frontend/issues) or [console](https://github.com/vegaprotocol/console/issues) tickets with feature labels (should be done when starting the work if dependencies known i.e. API changes)
+
+**After Merging**
+- [ ] Move development ticket to `Done` if there is **NO** requirement for new system-tests
+- [ ] Resolve any issues with broken system-tests
+- [ ] Create [documentation](https://github.com/vegaprotocol/documentation/issues) tickets with feature labels if functionality has changed, or is a new feature
+

CHANGELOG.md

@@ -39,6 +39,7 @@
 - [4588](https://github.com/vegaprotocol/vega/pull/4588) - Add `--update` and `--replace` flags on `vega genesis new validator`
 - [4522](https://github.com/vegaprotocol/vega/pull/4522) - Add `--network-url` option to `vega tm`
 - [4580](https://github.com/vegaprotocol/vega/pull/4580) - Add transfer command support (one off transfers)
+- [4636](https://github.com/vegaprotocol/vega/pull/4636) - Update the Core Team DoD and issue templates
 - [4629](https://github.com/vegaprotocol/vega/pull/4629) - Update `CHANGELOG.md` to include `0.47.5` changes
 - [4580](https://github.com/vegaprotocol/vega/pull/4580) - Add transfer command support (recurring transfers)
 - [4639](https://github.com/vegaprotocol/vega/pull/4639) - Add cancel transfer command
@@ -49,6 +50,7 @@
 - [4650](https://github.com/vegaprotocol/vega/pull/4650) - Restore code from rebase and ensure node retries connection with application
 - [4570](https://github.com/vegaprotocol/vega/pull/4570) - Internalize Ethereum Event Forwarder
 
+
 ### 🐛 Fixes
 - [4521](https://github.com/vegaprotocol/vega/pull/4521) - Better error when trying to use the null-blockchain with an ERC20 asset
 - [4516](https://github.com/vegaprotocol/vega/pull/4516) - Fix release number title typo - 0.46.1 > 0.46.2