forked from decidim/decidim
-
Notifications
You must be signed in to change notification settings - Fork 0
Home
hfroger edited this page Mar 21, 2024
·
5 revisions
We describe here the Octree process for proposing changes to the Decidim Product. It is based on our actual Holacracy Governance, so for outsiders of Octree, this document might seem obscure.
We handle bug resolution in a group to organize release sprints for fixes, every quarter:
- end of march
- end of july
- end of november
To report a bug in Decidim, go through the email [email protected]. This bug will then be registered as a problem and dispatched to one of the following:
- Voca PO if it's related to the Voca product
- Decidim Module Developer, if it's related to a module
- Decidim Contributor, if it's related to Decidim itself.
-> We are in the space of Decidim Contributor, and we will describe only the flow for this last item.
- Create an issue.
- Test on https://try.decidim.org.
- Test on a 0.27 Voca instance.
- Provide a stack trace and Errbit information if available.
- Always attach a screenshot.
- Link the plan to a milestone.
- Add the label
todo
to the issue. - Describe in the issue the tasks to be done, with checkboxes.
- Replace the label
todo
withdoing
. - Create a branch named
fix/<name of the issue>
. - Assign a Reviewer.
- Replace the label
doing
withreview
. - Write in the issue a comment mentioning the reviewer.
- Mention the reviewer again in Slack, in the #voca channel.
- Deploy a live instance with the bug fixed, named
<name of the issue>.dev.voca.city
. - Ask someone to test the instance (someone accountable for customer relations).
- Wait for the tester to validate the resolution.
- The Decidim Contributor makes the PR describing:
- What has been done.
- The link to the Octree issue.
- The temporary instance with the fix.