Development management guidelines

This section contains guidelines regarding the management of the applications development process.

Development management

• Each project lifecycle should start with the definition of the relevant APIs.

• All code related to a project should reside in one single repository.

• A project board should be created for each lab repository on Github to monitor its status, set goals and priorities, and track activities. Moreover, organisation-wide project boards may be created to manage complex projects.

• Each project board should contain at least the following columns:

1. Backlog: containing low priority implementation tasks.

2. Bugs: containing high priority implementation tasks.

3. TODO: tasks already assigned to team members.

4. Work In Progress - WIP: tasks that are linked to a pull request which is not ready to be merged yet.

5. Ready For Merge - R4M: tasks that are linked to a pull request which is ready to be merged but that is waiting for a code review.

• Every pull request has an owner, who can change its commit history at will.

• The owner of a pull request should move the linked task to the WIP column as soon as the pull request reaches a sufficient level of maturity.

• When moved to WIP, pull requests can start receiving high level comments, like:

  • Is the architecture clear?

  • Is there a clear goal?

  • Are the structures correct?

  • Should the testing include be improved?

• The owner of a pull request should move the linked task to the R4M column as soon as the pull request is ready to be merged. The owner should identify and ask the most suitable people to review the pull request.

• When moved to R4M, pull requests can start receiving detailed comments, regarding:

  • method- and variable-names

  • optimisations

  • typos

• When doing a code review, it should be made clear what the comments are about.

• Comments should be always justified, and preceded by questions to avoid misunderstandings.

• Pull requests should be merged when the reviewers are happy with the changes.

• Pull requests should not be merged by the owner.

Roadmap

• Every application should have a roadmap, so that users know what to expect in the next months. It has not to be very detailed, but it should be regularly updated.

Versioning

• Semantic versioning should be used. Major versions should be released when backwards-incompatible APIs have been implemented, minor versions should be released when new functionalities have been added in a backwards-compatible manner, and patch versions should be released when backwards-compatible bug fixes have been implemented.

• Use the project-language's idioms for versioning and releases. For Go, see the related section.

Maturity evaluation

• When an application is meant to be used in a real setting scenario, a maturity evaluation of the software should be planned to assess its current status and to plan next steps. In this respect you should contact [e-mail] for more information.