-
Notifications
You must be signed in to change notification settings - Fork 22
Feature development process and tracking
This document aims to describe how we go from a request (fix a bug, add a feature...) to a new deployed version.
Requests come from a varierty of sources. The prefered way to make a request is to send a message on Slack in #tapir, but any other way is fine too: tell a member of the Tapir team when you meet them at the shop, send a mail to the member office for them to forward to the IT-team, talk with a member of the Vorstand...
There is always one member of the team that is responsible for checking Slack messages and keeping track of all requests until the next team meeting. You can check who is currently responsible on our meeting minutes page and send them a reminder with an @ message.
The request will be discussed with the team on the next meeting. Meetings happen on Wednesdays evening on weeks A and C.
Format of the request:
- Context:...
- Request:...
- Expected outcome:...
- Priority according to you / impact on your work
As soon as the request has been received, a GitHub issue must be created by the Tapir team or the requesting member. All relevant details must be added to the issue.
Relevant details include:
- Who requested the feature, so that the team knows who to ask questions to
- Which concrete changes should be done to Tapir, in terms understandable by non-developers
- What are the expected results
Discussions about the issue can happen on Slack or anywhere, but it is important that all relevant informations are copied to GitHub, since Slack messages are not accessible if they are older than a few month.
The requesting member is welcome to create a free GitHub account and to participate in the discussion or add information on the issue directly.
The issue must be added to the Roadmap in the corresponding column. The requesting member must receive a link to the Roadmap so that they can track progress on the issue.
Whether the issue goes in the priority column should be discussed with the Tapir team and the requesting member, but the final decision is left to the requesting member.
The title of the issue should be understandable by non-developers, so that they can read the roadmap. Issues that are only technical, like refactoring, should be prefixed with (tech)
The newly created issue should get assigned to a developer as soon as possible.
The developer should give an estimate of when they can work on the issue and of how much time they need.
Since development is mostly voluntary, we cannot guarrantee when the work will actually be done, but we try to give reasonable estimates.
The requesting member is welcome to ask for status updates if work hasn't started at the estimated time.
Development should happen in a dedicated git branch, either directly on the Tapir main repository or on a personal fork.
If something prevents progress, the developer must signal it on the GitHub issue and ideally bring it up in the next team meeting. A dedicated agenda point is reserved for discussing blockers during those meetings.
Once development is done, the changes should be reviewed by at least one other member if the team. This is done by creating a pull request. A pull request should include the following checklist:
- Is the test coverage sufficient?
- Has the wiki been updated according to the changes?
It is possible to get feedback on changes that are not ready yet by creating draft pull requests.
Since reviewing can be a tedious process, it is strongly encouraged that changes that are over ~200 lines long are split in several pull requests. In that case, in order to avoid merge conflicts, it can be useful to merge partial changes to the master branch. Feature flags can help manage unfinished features. (TODO: create a wiki page explaining feature flags and link it here)
Each pull request should be assigned a main reviewer. The main reviewer should spend the time to understand the code in detail and suggest improvements if appropriate. Other members of the team are encouraged to read the code at least once to be aware of the changes, but are not required to do a detailed review.
The developer is responsible for communicating about the pull request so that the other team members are aware of the work being done. This can be done for example by tagging the other members on the pull request, or writing about it in the #tapir-dev channel
The requesting member should review the feature before it is deployed to the production server. This is usually done by deploying the feature to the test server.
If the feature is validated both by the Tapir team and the requesting member, the feature can be deployed to the live server. Who does the deployment and when it happens should be discussed within the team and with the requesting member.
Deployment of the feature must be announced in #tapir with the relevant people tagged.