meta-Decision needed: How does the FLWG decide upon curriculum content?

[gernotstarke]

IMPORTANT - PLEASE READ!!

As @rhoadesre asked in a private E-mail: How do we decide?

I'd like to make our "process" explicit in an ADR, so others can understand how we come to conclusions or decisions.

We have several cases of back-and-forth, without a decided-upon way of resolving such issues.

Therefore I propose to add an ADR to our documentation, with the following basic rules for decision-making: (and maybe add a summary to the README)

1. Leader Responsibility

The current WG-leaders (currently Gernot Starke and Alexander Lorz) will facilitate the decision-making process. The leaders ensure progress but do not unilaterally decide.

2. Collaborative Input

Every group member is encouraged to participate in discussions. Major decisions are openly discussed in GitHub Issues, and input is collected from all members. What constitutes a major decision can be made explicit by using a GitHub label.

3. Consensus Preference

The group strives for consensus, aiming for solutions that everyone can support or, at a minimum, live with. A discussion period will be set for each major decision to allow for thorough feedback.

4. Rule for Minor Decisions

Minor decisions can be made by any two members if there are no objections from the rest of the group within 48 hours. This allows for quick resolution of smaller matters without requiring full group involvement.

5. Voting When Necessary

If consensus cannot be reached, the leaders can call for a vote. Each member has one vote, and a simple majority (6 out of 10) decides the outcome.

6. Handling Low Voter Turnout

A vote is valid as long as a minimum of 3 members participate. A simple majority of those who vote decides the outcome. If fewer than 3 members vote, the leader will re-engage the team for further discussion before calling a second vote. If the minimum is still not met in the second round, the leader and the available voters will make the decision.

7. Leader’s Tie-breaking Role

In case of a tie, the leader has the tie-breaking vote.

8. Documentation of Decisions

All decisions must be documented as an ADR in the repository. Each ADR should summarize the decision, its rationale, and its expected impact.

9. Reevaluation

Decisions can be revisited if new information or circumstances arise. Any member can propose a reevaluation by opening a GitHub Issue.

[Hruschka]

Agreed

[bertjan]

Looks good, agreed!

[skogsbaer]

agreed!

[alxlo]

+1 from me, albeit I guess that we will just have to eyeball what's an "important decision". But works for me.

[ulibecker]

+1

[rhoadesre]

+1

1. Thanks for taking the initiative!
2. 48 Hours may be too short if, for example, I'm giving a class, it's hard to respond within 48 hours. But for minor issues, it's ok with me.
3. It should be defined what a "major" and "minor" issue is. But I'm OK with just starting and tagging the issues and addressing this topic only if it becomes a problem, e.g., an issue is marked as minor because for that person that created the issue, it's a "minor" issue, but others may see the issue as a "major" issue. This will probably come out during discussions in the issue.

[mikesperber]

+1

[gernotstarke]

Thank you for reacting so quickly.

So we have 6 (plus myself) positive votes - I take this as an "agreed upon" and will create this ADR.

Labels MAJOR and minor have already been created.

Here is the PR: https://github.com/isaqb-org/curriculum-foundation/pull/653

[gernotstarke]

PR has been merged