-
Notifications
You must be signed in to change notification settings - Fork 6
Development process
Development is done using Kanban with one week cadence for planning and reviewing. This has two purposes: Provide transparency and make it clear when work is planned and reviewed Add trust between "business team" and "development team" by continuously adding and demonstrating value.
- Tuesday 10:00 - 11:00; Planning
- Friday 14:00 - 15:00; Review
- Every Day 10:00 - 10:15; Daily
Friday agenda is crafted during the week. Everyone can suggest agenda topics in slack.
Currently we maintain separate backlog in excel and fill Kanban board from it when we need to.
Each task is worked on by the development team. We use GitHub tasks as much as possible. Task not ready = No check, Task ready = Check.
Once new functionality is ready, someone else than original implementor will do review for it. In case of HSL controlled software component this "someone" is from the development team. If software component is not controlled by HSL, review is done by upstream project. Ideally:
- Features should be available for testing in test enviroment
- All code is committed to some branch and is available for review
Once review is done and required fixes are done, new functionality is merged into master. By now code & documentation should adhere to our coding standards.
All code that we work on must reside under https://github.com/HSLdevcom. Repositories should be either:
- Forks from other repositories (e.g. OpenTripPlanner)
- Our own work (e.g. Digitransit UI)
It is high priority to keep our version of forks in sync with original repository. This means:
- All our changes should be made available to original repositories as pull requests. Hopefully they are accepted.
- We should periodically merge upstream repositories to our local copy in order to get updates made by 3rd party project