Decision Making Process

[yksflip]

As our Foodsoft developer community grows (which is so amazing ✨), I feel that we could improve and formalize our decision-making process a little bit. I’d like to suggest a lightweight framework that helps us make decisions more effectively, inspired by the Coop Cloud Federation decision-making process.

We already have a nice foundation with our monthly calls and GitHub discussions. And I think there is already an informal way we make decisions. Here’s what I propose:

1. Decision Documentation:

   • It would be helpful to define when and what was decided by whom.
   • A Wiki page could serve as a Decision Log, including:
     • What the decision is
     • The date and who was involved
     • A date for reviewing the decision (e.g. 6 months)

2. Decision Sizes:

   • To clarify who should be involved in decisions, we can categorize them based on impact:

     1. Small Decisions:

        • Minimal impact.
        • Individuals can make these decisions without needing to consult others.
        • No need to inform others about it.

     2. Medium Decisions:

        • Some impact (like modifying how an existing feature works) but don’t affect the overall Foodsoft project.
        • Relevant contributors should be involved.
        • Set a reasonable deadline (default: one week) for objections. If no one raises concerns by then, go ahead.
        • This can happen in an issue, pull request, or discussion.

     3. Large Decisions:

        • Significant impact (like changing fundamental processes).
        • Write a proposal in a GitHub discussion.
        • Should be set on the agenda for a monthly meeting or scheduled for a separate meeting.

3. Governance in Monthly Meetings:

   • Our monthly meetings can serve as a governance forum where we use a consent-based approach:
     • Decisions can move forward unless there are strong objections that could jeopardize our project goals.
     • We'll try to integrate objections to make the decision even better.
     • In some situations, a different decision-making scheme might be more handy (e.g., giving one person the mandate to make an informed decision about something).
   • Review past decisions and reflect if change is needed

Happy to hear your ideas and comments :)

[lentschi]

Sounds like a great idea 👍

Deadlines/Requiring Upvotes

I personally think, that for medium decisions we shouldn't just wait for objections, but for at least one upvote. (If there's no reaction at all, that's not actually a good sign.) Of course that would render the deadline a bit toothless - because what to do when there's neither objection nor upvote after the deadline has exceeded? 🤔

So maybe instead of deadlines, it would be better to use a certain tag for discussions/issues that include decisions, making them easier to monitor by us? (If there's really old open discussions/issues tagged decision in that list, we can try to readdress developers, who might be able to finally make the call. Failing that, we can raise the topic in our monthly call.)

Decision Documentation

It's a good idea to have documentation about past decisions 👍
(I'm just not sure, if a wiki page is the best decision. I always lean towards having *.md files covering this in the repo, thus linking it to the git history. Also, that way any references to code included in the decisions would always be in context. But I don't feel strongly about it - a wiki'd be okay too. 🙂 )

[yksflip]

As discussed in the Community Meeting today, we integrate following ideas into the Proposal:
* when a proposal is decided the discussion will be closed
* medium-sized decisions require at least 1 upvote
* Instead of documenting in the wiki we tag the gh-discussions with a #decision tag

---

Resolution 001: Decision Making

1. Decision Sizes:

   • To clarify who should be involved in decisions, we can categorize them based on impact:

     1. Small Decisions:

        • Minimal impact.
        • Individuals can make these decisions without needing to consult others.
        • No need to inform others about it.

     2. Medium Decisions:

        • Some impact (like modifying how an existing feature works) but don’t affect the overall Foodsoft project.
        • Relevant contributors should be involved.
        • At least one other person should actively upvote
        • This can happen in an issue, pull request, or discussion.

     3. Large Decisions:

        • Significant impact (like changing fundamental processes).
        • Write a proposal in a GitHub discussion.
        • Should be set on the agenda for a monthly meeting or scheduled for a separate meeting.

2. Decision Documentation

• Large Decisions must be documented as a GH-Discussion in the decision category.
• If a proposal is accepted the Discussion is closed and the final proposal marked as "Answer"

3. Governance in Monthly Meetings:
   • Our monthly meetings can serve as a governance forum where we use a consent-based approach:
     • Decisions can move forward unless there are strong objections that could jeopardize our project goals.
     • We'll try to integrate objections to make the decision even better.
     • In some situations, a different decision-making scheme might be more handy (e.g., giving one person the mandate to make an informed decision about something).
   • Review past decisions and reflect if change is needed