Skip to content
hfroger edited this page Mar 21, 2024 · 5 revisions

How to Propose Changes to Decidim (Octree Process)

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.

Bug

Triage

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.

Report the Bug

  1. Create an issue.
  2. Test on https://try.decidim.org.
  3. Test on a 0.27 Voca instance.
  4. Provide a stack trace and Errbit information if available.
  5. Always attach a screenshot.

Plan a Bug

  1. Link the plan to a milestone.
  2. Add the label todo to the issue.
  3. Describe in the issue the tasks to be done, with checkboxes.

Working on a Bug

  1. Replace the label todo with doing.
  2. Create a branch named fix/<name of the issue>.
  3. Assign a Reviewer.

Place the Bug in Review

  1. Replace the label doing with review.
  2. Write in the issue a comment mentioning the reviewer.
  3. Mention the reviewer again in Slack, in the #voca channel.

Place the Bug in Testing

  1. Deploy a live instance with the bug fixed, named <name of the issue>.dev.voca.city.
  2. Ask someone to test the instance (someone accountable for customer relations).
  3. Wait for the tester to validate the resolution.

Do the PR

  1. The Decidim Contributor makes the PR describing:
    1. What has been done.
    2. The link to the Octree issue.
    3. The temporary instance with the fix.