Document the Github-based workflow

[swrichards]

Summary

Issue References

• Taiga User Story:
• Taiga Issue:
• Taiga Dimpact Issue:
• Github Issue:

Checklist

• CHANGELOG.rst updated
  • Deployment notes added
    
  • Breaking changes flagged
    
• Documentation updated
• Codecov report reviewed for untested lines
• Storybook component updated/created
  
• Vitest tests added/updated
• Updated the docker-compose.yml environment variables
  • Created an issue in https://github.com/maykinmedia/charts/ for new
    environment variables

---

📚 Documentation preview 📚: https://open-inwoner--2086.org.readthedocs.build/en/2086/

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.81%. Comparing base (c2f7aa0) to head (8054e27).
⚠️ Report is 2 commits behind head on develop.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #2086   +/-   ##
========================================
  Coverage    92.81%   92.81%           
========================================
  Files         1230     1230           
  Lines        47729    47741   +12     
========================================
+ Hits         44301    44313   +12     
  Misses        3428     3428           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jiromaykin]

We haven't really made use of milestones ourselves yet I think? So then milestones would need to b created first, etc, etc, I'm also sort of hoping for a 'shadow workflow' for developers to use as steps that we'd have to do as a team :-)
Also: our naming of PR branches has become a bit of a mess (_issue/task/feat/feature/fix_blabla) and I'd prefer them to be consistent with these 'feature/bug/tas' names but that's just a personal hang-up.

[swrichards]

We've only used them implicitly (the milestone was always the next release!), but they're fairly lightweight to create, and I doubt we'd ever have more than 1-3 at any given time. In fact, we could say that we only use milestones for the sprints, so we can easily see what was done in what sprint. I don't think it makes sense to use them for much else really, I'll amend the docs to say that.

I think there's a lot of space for "shadow" workflows: the board allows for many filters, and you can build different views for different purposes (e.g. based on a different tagging schema).

PR naming: agreed, but that's a different topic :) (related also to commit conventions). We'll turn to that soon.

[jiromaykin]

Here I would expect explicit mention of User Stories instead of 'issues'.

[jiromaykin]

These 'no status' issues can only be added to an active Github sprint I think?
(same for the chapter "Issue Creation" >> 'Developer')
I am a bit unsure on what to do with our long list of free floating issues that do not come from sprints that are in 'danger' of never being looked at again: https://taiga.maykinmedia.nl/project/open-inwoner/issues?order_by=status