Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document decision-making based on consensus #49

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

VirginiaBalseiro
Copy link
Member

@VirginiaBalseiro VirginiaBalseiro commented Jan 19, 2024

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

@KyraAssaad
Copy link
Collaborator

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
Copy link
Collaborator

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.

Copy link
Member

@csarven csarven left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member Author

Added some details to address comments above.

README.md Outdated Show resolved Hide resolved
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
@KyraAssaad
Copy link
Collaborator

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
Copy link
Member

csarven commented Jan 19, 2024

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.

Copy link
Contributor

@michielbdejong michielbdejong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member Author

VirginiaBalseiro commented Jan 25, 2024

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

Updated to reflect different types of decisions in f31dc1f

README.md Outdated Show resolved Hide resolved
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
README.md Outdated Show resolved Hide resolved
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
@megoth
Copy link
Collaborator

megoth commented Feb 19, 2024

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
Copy link
Collaborator

megoth commented Feb 19, 2024

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

Lmk if anyone disagrees.


Routine and operational decisions are made in the context of [Task Forces](https://github.com/solid/team/blob/main/README.md#tasks) by their members in coordination with the Task Force Lead.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

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!


Routine and operational decisions are made in the context of [Task Forces](https://github.com/solid/team/blob/main/README.md#tasks) by their members in coordination with the Task Force Lead.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member Author

VirginiaBalseiro commented Feb 26, 2024

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?

Copy link
Collaborator

@megoth megoth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants