code.vegaprotocol.io/vega@v0.79.0/DEFINITION_OF_DONE.md (about)

     1  # Definition of Done (DoD)
     2  
     3  ## What is a Definition of Done (DoD)?
     4  
     5  We use a Definition of Done to clarify what exactly the team means when we declare something ‘done’.
     6  
     7  In more concrete terms, it lists the criteria we’ll meet before you claim a feature, enhancement or bug fix can be shipped (released).
     8  
     9  The difference between a Definition of Done and Acceptance Criteria...
    10  
    11  - The Definition of Done applies to all your work. Acceptance Criteria only ever apply to a single item on your backlog
    12  - The Definition of Done clarifies what you do as a team. Acceptance Criteria clarify what the protocol does — its functionality
    13  - The Definition of Done can contain criteria for “non-functional” aspects and cross-cutting concerns.
    14  
    15  ## Vega Core Team Definition of Done
    16  
    17  **Before merging**
    18  - Create relevant for [system-test](https://github.com/vegaprotocol/system-tests/issues) tickets with feature labels (should be done when starting the work)
    19  - Code refactored to meet SOLID and other code design principles
    20  - Code is compilation error, warning, and hint free
    21  - Carry out a basic happy path end-to-end check of the new code
    22  - All acceptance criteria confirmed to be met, or, reasons why not discussed with the engineering leadership team
    23  - All APIs are documented so auto-generated documentation is created
    24  - All Unit, Integration and BVT tests are passing
    25  - Implementation is peer reviewed (coding standards, meeting acceptance criteria, code/design quality)
    26  - 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)
    27  
    28  > ℹ️ In most cases the person that raised the PR should be the one to squash branch history to string of passing, sensible commits, and merge the PR.
    29  
    30  **After merging**
    31  - Move development ticket to `Done` if there is **NO** requirement for new system-tests
    32  - Resolve any issues with broken system-tests
    33  - Create [documentation](https://github.com/vegaprotocol/documentation/issues) tickets with feature labels if functionality has changed, or is a new feature
    34  
    35  **Before Testnet**
    36  - Acceptance (feature) tests passing (end to end / black-box testing)
    37  - Full set of functional regression tests passing
    38  - Incentives (where applicable) have been planned with the community team
    39  
    40  **Before Mainnet**
    41  - Incentives (where applicable) have been run successfully in testnet
    42  
    43  > ℹ️ In most cases the person that raised the PR should be the one to squash branch history to string of passing, sensible commits, and merge the PR.
    44