Document decision-making based on consensus

[VirginiaBalseiro]

The team has been operating on the assumption that decisions are made based on consensus, but it was not documented anywhere.

[KyraAssaad]

This is fine, but I don't know how we define "majority", re: "The focus on establishing agreement of at least the majority or the supermajority and avoiding unproductive opinion differentiates consensus from unanimity, which requires all participants to support a decision." from https://en.wikipedia.org/wiki/Consensus_decision-making

[jeff-zucker]

My personal opinion is that we should a) strive for concensus b) as soon as it becomes apparent we can't reach that, we vote according to the W3C rules, and c) if the vote results in a tie, the Director decides.

[csarven]

I think the README will do for now but the details on decision-making are part of the team Contributing/Process and could benefit from being detailed elsewhere. Examples https://github.com/w3c-cg/solid/blob/main/CONTRIBUTING.md#decisions , https://www.w3.org/Consortium/Process/#decisions .

In the case of Solid Team, it should break down types of decisions and decision criteria. Some may require the Director, some may need a team-wide decision specific to a task, and others fall into different categories. Decisions may be based on group consensus or require unanimity. Some decisions may need to be made by those present, may need to be communicated with the rest or ask for feedback, and so on. Identifying when to use each method makes a difference.

Voting should be a last resort exercise, reserved for cases where differences in views can't be easily resolved. The group should work towards reducing dissent by exploring alternative solutions, compromises, or breaking down the problem. There are techniques to achieve this without creating barriers or being overly bureaucratic or complicated. Voting is closely tied to who can vote, so capturing balance and diversity, and considering affiliations or conflicts of interest. It can get complicated.

[VirginiaBalseiro]

Added some details to address comments above.

[KyraAssaad]

break down types of decisions and decision criteria. Some may require the Director, some may need a team-wide decision specific to a task, and others fall into different categories. Decisions may be based on group consensus or require unanimity. Some decisions may need to be made by those present, may need to be communicated with the rest or ask for feedback, and so on. Identifying when to use each method makes a difference.

Who makes and how are the decision criteria made?

I think @jeff-zucker's suggestion is much more straightforward and actionable, and easier to implement in real life.

[csarven]

Who makes and how are the decision criteria made?

I thought it was implied that the Team would come up with that criteria?

For example, https://www.w3.org/2023/Process-20231103/#decision-types mentions common decisions types - who is involved. It helps to set expectations and how it will eventually be carried out. https://github.com/w3c-cg/solid/blob/main/CONTRIBUTING.md#decisions also provides a guideline on how to process PRs for example - it doesn't necessarily need a "vote" once basic checks are put in place.

I think @jeff-zucker's suggestion is much more straightforward and actionable, and easier to implement in real life.

I wasn't suggesting a particular solution in my comment but was just offering an outline or at least some considerations since the title of the issue calls for it, as well as a couple of people, including you, asked for specifics.

As I understand Virginia's last commit, it encapsulates the core ideas and perspectives that's shared here.

[michielbdejong]

Saying all decisions are consensus based is either inaccurate or unworkable. That would mean we could only ever work one hour per month, during our team plenary, sharing our screen to get consensus about every keystroke. The task forces defined in https://github.com/solid/team/tree/main/tasks can execute tasks during the month, they should be allowed to work on tasks without plenary consensus.

See my suggested improvement in #56.

[VirginiaBalseiro]

Saying all decisions are consensus based is either inaccurate or unworkable.

Updated to reflect different types of decisions in f31dc1f

[megoth]

Saying all decisions are consensus based is either inaccurate or unworkable. That would mean we could only ever work one hour per month, during our team plenary, sharing our screen to get consensus about every keystroke. The task forces defined in https://github.com/solid/team/tree/main/tasks can execute tasks during the month, they should be allowed to work on tasks without plenary consensus.

See my suggested improvement in #56.

@michielbdejong Have your concerns been addressed? If yes, maybe remove the status of requesting changes? If no, maybe readdress your concerns here as #56 has been closed? (Again, apologies if I closed that prematurely.)

[megoth]

I believe this PR addresses #52, i.e. if this PR get resolved, we can probably close the issue.

Lmk if anyone disagrees.

[michielbdejong]

When faced with unresolved strong objections in decision-making processes based on consensus, another mechanism may be employed to reach a conclusive outcome. This involves establishing a decision rule for each particular issue

Yes

, where a majority is defined to have a specific threshold, and subsequently conducting a vote. This approach is loosely based on the W3C's guidelines for deciding by vote, as outlined in the W3C Process Document. A vote should only be conducted after all attempts at consensus through technical discussion and compromise have failed.

It might be useful to document a conflict resolution mechanism, but I don't think voting among team members is the best one. In many cases I would probably prefer a referendum (and this is what we regularly do, when we don't know what to decide, we post the question on the forum for community input).

Also, unlike the CG and the proposed WG, the Team is tasked with "holding the space" for the "Solid Project" and the "Solid Community" - neither of those fall under the W3C, so we don't need to base our voting process in the team on W3C customs. We could even just say that whenever we don't reach consensus we decide on a per-case basis whether voting is appropriate, and if so what kind of voting.

It is important to note that, in this context, a Member or group of related Members is considered a single organization, aligning with the W3C's principles.

No. I don't think this is appropriate here - Team members are all equal and don't wear organization hats.

[VirginiaBalseiro]

No. I don't think this is appropriate here - Team members are all equal and don't wear organization hats.

I disagree. Affiliation matters when voting because otherwise there is potential over-representation of interests. Let's see what others think.

A referendum is literally a vote btw, so I don't understand your point.

[jeff-zucker]

In many cases I would probably prefer a referendum

Opening things up to the forum is appropriate for some kinds of decisions such as NSS/CSS. It is not appropriate for other decisions such as who has access to github repos and the various servers or whether someone should be accepted or removed from the team, or whether the team should take on a new task. These are team decisions, not community decisions.

[megoth]

I think each member should have a vote.

Yes, I agree that Inrupt is over-represented as of now, but I believe we must be able to trust each member to contribute their own opinion. Especially as there haven't been any rules/limitations on affiliations 'till now, and I hope there doesn't need to be.

That said, if it can be shown that Inrupt (or any other organizations that might be over-represented in the future) abuse this over-representation to force through their interests, this should be re-visited and a possible resolution is to group votes by affiliations.

A possible challenge here is of course that the representatives of the over-represented association might vote down any attempt of changing this in the future. Then again, given that all decision-making processes are public and transparent, I would hope that this problem would become apparent, and therefore there would be incentive for the over-represented company to not do this.

But again, my core premise is that we should be able to trust each member of the team to represent their own opinion/view when voting.

[michielbdejong]

I believe this PR addresses #52

In its original form this PR was actually saying the opposite but f31dc1f fixed that, so yes I'll close it!

[michielbdejong]

Suggested change

When faced with unresolved strong objections in decision-making processes based on consensus, another mechanism may be employed to reach a conclusive outcome. This involves establishing a decision rule for each particular issue, where a majority is defined to have a specific threshold, and subsequently conducting a vote. This approach is loosely based on the W3C's guidelines for deciding by vote, as [outlined in the W3C Process Document](https://www.w3.org/2023/Process-20231103/#decisions). A vote should only be conducted after all attempts at consensus through technical discussion and compromise have failed. It is important to note that, in this context, a Member or group of related Members is considered a single organization, aligning with the W3C's principles.

When faced with unresolved strong objections in decision-making processes based on consensus, another mechanism may be employed to reach a conclusive outcome. This involves establishing a decision rule for each particular issue.

[VirginiaBalseiro]

We added detail on this after feedback on needing more definitions around how to resolve strong objection. I won't remove because there is conflicting feedback and I prefer more detail, since that was requested. We can either wait on others' feedback or resolve. I recommend you read the discussion above.

[csarven]

AFAIK, the Project/Team is not blindly, randomly, or entirely adopting W3C processes. W3C material is first and foremost used as guidance, and even in the case here, hence the wording "loosely based on".

The following sentence can be removed from the paragraph, and its essence will still hold:

This approach is loosely based on the W3C's guidelines for deciding by vote, as outlined in the W3C Process Document.

The Solid Project has historically borrowed a lot from the W3C principles, processes, guidelines, e.g., W3C Process, Code of Conduct, Charters, Guidelines, and so forth. It is not out of the blue to mention the Team's processes is also re-using that work where necessary or applicable.

"Voting" is mentioned as "a last resort". If and when there is "voting" in whatever form, the process should be transparent and documented. It is essentially about the decision-making framework, and that it should prioritise transparency, inclusivity, and accountability.

When historically there has been no sense of "accountability" for the Team members, it is not particularly appealing to entertain the idea that each member leaves their affiliation at the door. That's in addition to the fact that ~50% of the Team is from one organisation. Emphasising again that, when voting is deemed necessary, there needs to be some clear rules (which needs to be hinted in the text here and possibly documented more clearly as needed). And so all things considered, "one vote per org" is the obvious thing.

[VirginiaBalseiro]

In its original form this PR was actually saying the opposite but f31dc1f fixed that, so yes I'll close it!

It wasn't saying "the opposite", and that commit only differentiated two types of decisions and added detail, it did not change the original intention of documenting consensus-based decisions. Why would you make the claim that it was saying the opposite when it clearly wasn't?

[megoth]

I would prefer to remove the last sentence "It is important to note that, in this context, a Member or group of related Members is considered a single organization, aligning with the W3C's principles.", but apart from that it looks good to me.