# Project management

In principle, **all project management is handled in [a central board](https://github.com/orgs/minvws/projects/7)**. Issues and PRs may be created in the repositories of the KAT modules, as long as they are linked to the central board. All (linked) issues and PR's should be assigned to a status column, and have an assignee so we know who is chiefly responsible / who should take action. Developers are encouraged to use the Review column(s) to get their PR's merged, and to regularly check if they can help review something.

## Feature Milestones

Although we have no fixed release schedules, we focus on a pre-defined list of tasks each iteration/cycle.

At the beginning of each release cyle, we take inventory of which (major) functionality we want to implement. This will most likely be based on cards in the "incoming features and refinements" column on the project board. We agree to prioritize our collective effort on implementing that functionality, although there is always time for bug fixing, testing, and quality control. All tasks that belong to that cycle should have an appropriate milestone label in the project board, and should be moved to the To-Do column.

A cycle only ends if either:
* functionality is no longer required (i.e. changing requirements);
* the changes on main are complete, have been approved by QA, and have been released to a production tag.

When a cycle has been completed, we hold a quick retrospective to evaluate what we did and did not manage to complete, and any additional problems that we uncovered.

## Bugs and Feature Requests

For effective bug reporting and feature requests there is **an issue template**. These should be used and submitted in the main/coordination repository's [issues board](https://github.com/minvws/nl-rt-tim-abang/issues). Please make sure to link them to the central project board as an incoming feature/refinement.

## Pull Requests

Each unit of work shall be submitted as a pull request using **a pull request template** and reviewed by at least one developer. The checklist should be completed by a functional and a code reviewer.

## In-depth content discussions

All formal discussions about the direction of the project or about significant technical choices should be done through [GitHub Discussions](https://github.com/minvws/nl-rt-tim-abang/discussions). It is important that there is a paper trail about why certain decisions were made, and this is not guaranteed through e.g. Signal or Jitsi.

# Project statuses

**Updated on 18-11-2022**

| | | [rocky](https://github.com/minvws/nl-rt-tim-abang-rocky/) | [boefjes](https://github.com/minvws/nl-rt-tim-abang-boefjes/) | [bytes](https://github.com/minvws/nl-rt-tim-abang-bytes/) | [octopoes](https://github.com/minvws/nl-rt-tim-abang-octopoes/) | [mula](https://github.com/minvws/nl-rt-tim-abang-mula/) | [keiko](https://github.com/minvws/nl-rt-tim-abang-keiko/) |
|--------------------------------- |------------------------------------------------------------------------------------- |----------------------------------------------------------- |--------------------------------------------------------------- |----------------------------------------------------------- |----------------------------------------------------------------- |--------------------------------------------------------- |----------------------------------------------------------- |
| **GitHub Templates** | | | | | | | |
| | Feature Requests | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ |
| | Bug Reports | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ |
| | Pull Requests | ✅ | ❌ | ❌ | ✅ | ❌ | ✅ |
| **(Python) Code Quality Tools** | | | | | | | |
| | [General-purpose pre-commit hooks](https://github.com/pre-commit/pre-commit-hooks) | ❌ (awaiting PR) | ✅ | ✅ | ✅ | ❌ | ✅ |
| | [black](https://github.com/psf/black) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| | [flake8](https://github.com/PyCQA/flake8) | 🟡 (Many checks are skipped) | ✅ | ❌ | ✅ | ❌ | ✅ |
| | [pylint](https://github.com/PyCQA/pylint) | ❌ (awaiting PR) | ❌ | ✅ | ✅ | ✅ | ✅ |
| | [pydocstyle](https://github.com/PyCQA/pydocstyle) | ❌ (awaiting PR) | ❌ | ❌ | 🟡 (Not yet automated in CI) | ❌ | ✅ |
| | [mypy](https://github.com/pre-commit/mirrors-mypy) strict, ignoring missing imports | ❌ (awaiting PR) | ❌ | ✅ | ✅ | ✅ | ✅ |
| | [vulture](https://github.com/jendrikseipp/vulture) with 90% min confidence | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ |
| | [eradicate](https://github.com/myint/eradicate) | ❌ (awaiting PR) | ❌ | ✅ | ✅ | ❌ | ✅ |
| | [robotidy](https://github.com/MarketSquare/robotframework-tidy) | ✅ | ⚪️ | ⚪️ | ✅ | ⚪️ | ✅ |
| | [pyupgrade](https://github.com/asottile/pyupgrade) | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| **Automated Testing** | | | | | | | |
| | Unit tests (for all supported Python versions) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| | Integration tests | 🟡 (Not yet automated in CI) | ❌ | ✅ | ✅ | ✅ | ✅ |
| | Code coverage | ✅ | ❌ | ❌ | ✅ | ❌ | ❌ |
| | Dependabot | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| **Automated Builds** | | | | | | | |
| | Debian packages | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| | Docker container images | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| **GitHub Workflow** | | | | | | | |
| | Linked to the central project board | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| | README and/or Wiki are sufficient for a standalone setup | ✅ | | | | | |
| | Documentation is centralized in the README and/or Wiki | ✅ | | | | | |
| | Merge is not possible if automated checks are failing | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| | Merge requires approval from reviewer(s) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| | Merge must be squashed or rebased | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| | Configured security policy and advisories | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| | `.env` files are well-documented | ✅ (Mostly self-explanatory) | | | | | |
| | `Makefile` is used for helper/convenience functionalities | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| | LICENSE - European Union Public License 1.2 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |