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 and kaizen should have a milestone.
  • Each user story should conditionally have checkboxes Add tests and Update 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):

  1. Developer works on an issue.
  2. Developer tests his work.
  3. Developer checks all requirements in Github.
  4. Developer commits the changes and pushes the commit to origin.
  5. Developer uses bash script push_to_test to clone the working branch to the test branch.
  6. Developer uses git pull to get the code to be tested on the other machine.
  7. Developer tests his work on the other machine.
  8. Developer creates a pull request in Github.
  9. Developer links the pull request to the issue.
  10. Developer reviews the changes.
  11. Developer follows-up requested modifications.
  12. Developer resolves the conversations.
  13. Developer merges the pull request into the master branch.
  14. 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.