Development Procedures - maar35/film-festival-planner GitHub Wiki
In the end, here will be descriptions of documentation, test, review and deploy procedures.
Planning Procedure
- Epic stories should be implemented using Milestones.
This means that the
epic
label will be decommissioned. - Each user story that has none of labels
bug
,technical debt
andkaizen
should have a milestone. - Each user story should conditionally have checkboxes
Add tests
andUpdate documentation
, see the documentation procedure and the test procedure. - Bug user stories should have a header
Reproduction instructions
and only one requirement:Fix the bug
. - If a bug user story has the label
workaround available
, the workaround should be described in the user story. - For user stories that implement parsing of a new festival edition the following requirements should be considered:
- Read films
- Read section data
- Read screens
- Derive theaters from screens
- Read screenings
- Read On Demand screenings
- Read Q&A property of screenings
- Read combination programs and screened films
- Read dictionary with film properties
Documentation Procedure
The documentation should be updated at least every time a new feature is added.
This means that every issue labeled enhancement
or kaizen
must have a checkbox "Update documentation".
The documentation is functional (for the time being).
No instructions how to use functionalities should be documented. The user interface should be intuitive enough to work without instructions. Functionality can be discovered by browsing through the menu structure, because every functionality should have both a direct visual trigger and a keyboard equivalent which is linked to a menu item.
Documentation style
Work in progress.
- Each line of a list (ordered and unordered) should and with a period (
.
).
In user stories:
- Checkbox labels should not end in periods.
Test Procedure
Testing in this project used to mean that before reviewing, the committed code is tested on my Mac mini and my MacBook Air.
But, as all of the code and documentation, this is work in progress, see testing for currently prescribed testing.
Every issue involving Python
code must have a checkbox "Add unit tests".
Testing committed code on both machines can still be done:
Code to de tested will be cloned to the test
branch, which is remote-tracking from both machines.
In subsequent phases (go back on failure of a step):
- Developer works on an issue.
- Developer tests his work.
- Developer checks all requirements in Github.
- Developer commits the changes and pushes the commit to origin.
- Developer uses
bash
scriptpush_to_test
to clone the working branch to thetest
branch. - Developer uses
git pull
to get the code to be tested on the other machine. - Developer tests his work on the other machine.
- Developer creates a pull request in Github.
- Developer links the pull request to the issue.
- Developer reviews the changes.
- Developer follows-up requested modifications.
- Developer resolves the conversations.
- Developer merges the pull request into the
master
branch. - Github Automation will move the pull request and the issue to
Done
.
A procedure to create a test plan may be added later. Also the procedure could be extended to include Hot Fixes, Feature Branches and solving technical debt.