# CDPool / CodeLab Meeting Agenda

## Process

### Addressing work
1. Any new requests, changes and fixes should be passed to Scott.
2. Scott figures the details of the task and its priority and addresses it to Codelab via GitHub issue.
- Bugs should always be first reproduced by CDPool, then all the steps to reproduce a given problem show be provided in the issue description with as much details as possible.
4. CodeLab PM, Tzvetan reviews the issue:
- **All issues**: specify milestone, priority type of issue etc.
- **Bug / Hotfix**: Reproduce the issue and assign developer to work on it.
- **Enhancement** - Clarify all details with Scott in the GitHub issue, assign developer to provide time estimation.
5. Scott and Tzvetan have a weekly meeting:
- Review the work from the previous week (current week's release)
- Discuss and schedule current week's work and priorities for the project

### Code Delivery

#### Weekly Release (Bugs and Enhancements):
1. An issue is closed by developer(s) when it is complete and deployed to the QA and UAT environments for testing.
2. CodeLab QA is testing on QA server to confirm the request is properly implemented and matches the requirements specified in the GitHub issue. If the work does not pass QA, the issue is re-opend with detailed comment and passed back to the developer(s) to work on.
3. Scott reviews the work on UAT server to confirm it is working as expected. The issues is then moved by Scott to 'Scheduled For Release' project Kanban board to indicate it is developed as requested, otherwise it is re-opened with a comment what is missing or not working properly.
4. Once all the issues of the current sprint are scheduled for release (accepted as properly developed) a release to production is done. Usually Wednesdays are the days for deploying the work from the previous week's sprint.

#### Hotfixes
When a P1 or P2 issue is addressed it is considered top priority and as such it requires immediate fix - a **hotfix**. These are provided separately from the main release workflow.
1. An issue is addressed via GitHub providing all the details to reproduce.
2. Depending on the day and time the issue is given to a developer via Tzvetan or a developer takes the issue on his own.
3. Developer investigates what causes the problem and what would be a suitable solution for fixing it.
4. A hotfix is developed on a separate branch, then it is merged to `origin/master` branch directly as a minor release version. Any additional changes are developed in the same branch and merged to `origin/master` via PR and released as a minor release version. Once the issue is resolved in Production environment, the issue is closed by the developer and moved to the 'Waiting Approval - Live' Kanban column. The hotfix branch is also merged to `origin/release` branch so the hotfix is also available on UAT/QA servers as part of the release.
5. Once Scott confirms the problem is fixed, the issue is really considered done after moving it to the 'Done' column of the project Kanban board.

### Issue Priority Description
These priorities are used to indicate the priority of a bug or problem found in production environment only.
- **P1** - Due to total inoperability of developed interfaces or the website is unavailable to CDPool and visitors. A significant or critical part of the Software unusable, creating serious customer impact.
- **P2** - A significant part of the website or its interfaces is unusable.
- **P3** - Disruption of a single element of the website creating minor customer impact.
- **P4** - Non-critical problem – not customer impacting

## Billing and Pricing Changes
Starting **1st of January, 2022** we are changing our price per hour and moving to prepaid package deals. More details will be provided on this matter as soon as they become clear.

## Contract - Service Level Agreement
We need to document our agreements in written form and sign them. This will be worked on in the upcoming months and passed for review and comment to CDPool as soon process and pricing details are clear.