Document decision-making based on consensus #49
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -16,6 +16,14 @@ The Solid Team holds meetings at <https://meet.jit.si/solid-team> on every secon | |||||
|
|
||||||
| [Membership Information](/team.md) | ||||||
|
|
||||||
| ## Decisions | ||||||
|
|
||||||
| Strategic, tactical, and policy decisions are made based on [consensus](https://en.wikipedia.org/wiki/Consensus_decision-making). | ||||||
|
|
||||||
| 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. | ||||||
|
There was a problem hiding this comment.
Suggested change
There was a problem hiding this comment. 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. There was a problem hiding this comment. 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:
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. |
||||||
|
|
||||||
| ## Code of Conduct | ||||||
|
|
||||||
| The Solid Team follows the [Solid Community Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md) | ||||||
|
|
||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes
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.
No. I don't think this is appropriate here - Team members are all equal and don't wear organization hats.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
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.