Update decision-making-processes.md #138
Conversation
|
This draft process is being tested on the following pull request solid/solid-spec#92 |
This document is an in-progress proposal which is not currently in effect. It describes how decision-making within the Solid project might work. Importantly, the Solid Leader needs to approve any decision making processes for it to be legitimate and the Solid Leader can block decisions at any point. In short, the proposal is for the Solid team to lead decision making processes concerning Solid which can involve votes by the Solid Decision Panel. # Purpose There are several converstaions happening via pull requests and issues around the Solid specification. Some of these conversations date back to 2015 and there is a range of complexity and degrees of agreement. The Solid project has been worked on by multiple changing teams who each had slightly different ways of deciding how to decide. Although, largely there is agreement on those working on Solid, it is unclear how to resolve open ended questions especially when there are light differences of opinion between some individuals. Therefore open ended questions tend to lie in a vacuum of uncertainty around how to decide how to decide. This purpose of this proposal is to come to a collective agreement about legitimate decision-making on Solid between all the parties working on Solid.
|
@konobi suggested using the tool https://www.loomio.org, any thoughts on this? |
|
I really like Loomio in theory but have never used their tools and don't know many (any?) people who have. My understanding is that it's better for small groups, but if you want hundreds or more people able to participate in the decision-making process, it quickly gets too expensive. So it might be a good tool if you have an elected/appointed board/panel making decisions in a democratic and transparent way, but not a good tool if you want mass participation. |
|
Thanks @Mitzi-Laszlo !
I think web-access-control-spec and webid-oidc-spec could stay independent specs and solid spec could just depend on them.
That sounds to me more like Project Team members acting as authors and @RubenVerborgh (Project Manager) acting as editor. Commonly specs have more authors and just few editors.
IMO we shouldn't try to add another communication tool unless we really start feeling pain from github lacking some features. I will stay offline for a week, I hope I'll get back online on time for next community call on 23rd 🙇♂️ |
Agreed. WebID-OIDC can be used independently of the pod spec. (@michielbdejong Probably another indication why "the" Solid spec will not be sufficiently precise; OIDC is not necessarily a subspec, but an independent spec that can also be used to front other HTTP interfaces such as TPF.) My practical suggestion would be to keep al spec documents in one single repository https://github.com/solid/specification/, but they can (should?) have different editors. (For instance, I am likely not the right editor for WebID-OIDC.) |
Update decision-making-processes.md
|
Another helpful reference is https://tc39.github.io/process-document/ |
There was a problem hiding this comment.
I can't edit this PR, so here are my suggested changes (mostly typos). Line numbers all refer to added line numbers (not deleted lines!):
Line 5 (one typo)
The scope of Solid governance includes but is not limited to
Line 20 (two typos)
...indiviudals apointed...
SHOULD BE:
...individuals appointed...
Line 43
First mention of a ' Solid Panel' - what is this?
Line 47
'...Passing requires a strict majority of non-abstaining council members' - what's the 'council'?
Another reference on line 49.
Line 54
First mention of '... Solid Decision Panel' - what's this 'panel'?
Another reference on line 58
Line 64 (typo)
may resign their position
Line 143 (missing full stop)
'...every six months***.*** For a change'''
Line 146 (remove superfluous 'to')
'...to which the suggestion pertains to will be responsible...'
Vincent's initial comments were: "There's three instances of the word "council" there - I think that should be Team? And "exmaple" should be "example" 🙂 Some other remarks: - It says: "The Solid Panel can request a vote on issues that they feel are important to open up to a wider vote." However, it's not clear what "a wider vote" means - is that among the Solid panel, or open to everyone, or...? - The election process for non-appointments states that it also applies to "changing a Solid Project", but it's not clear what constitutes a change - assuming not every line of code will need to go through a formal process other than a PR. - There's also mention of a "Solid Manager", but it's not stated who that is. It also seems like a lot of work to coordinate every vote - perhaps that would be better suited to the initial proposer, i.e. the "champion"? - I've got a feeling that it's not unlikely that some members of the Panel will not be able to respond in a timely manner, or at all, to every vote. Thus, it might be a good idea to explicitly set time limits during which the Panel can vote on proposals, after which a non-vote will count as abstaining. Ah, I see the Solid Team page includes a description of the Manager, but nothing about how they get appointed."
decision-making-processes.md
Outdated
| * collect the final results | ||
| * communicate the outcome | ||
|
|
||
| Solid specification 0.9 will be released on July 1st, and new versions of the Solid specification will be released every six months For a change to the Solid specification to be merged there needs to be at least one working implemetation that adheres to the changed Solid specification. |
There was a problem hiding this comment.
Let's not bind to a specific timeframe; it should be done when it's good.
There was a problem hiding this comment.
What defines the spec being good and who is the judge of goodness?
There was a problem hiding this comment.
What defines the spec being good
Correctness, clarity, and non-ambiguity.
and who is the judge of goodness?
The editors are expected to deliver blurbs of text that conform to the above criteria. They deliver these through PRs, which members of the public can discuss on for at least a week.
|
|
||
| This document was put together with inspiration and learnings from the following resources. | ||
|
|
||
| * Python (2018) [Python Lanugage](https://www.python.org/dev/peps/pep-0013/) |
|
|
||
| To use its powers, the Solid Team votes. The Solid leader can always veto the voting outcome. Every Solid Team member must either vote or explicitly abstain. Members with conflicts of interest on a particular vote must abstain. Passing requires a strict majority of non-abstaining Solid Team members. | ||
|
|
||
| Whenever possible, the Solid Team's deliberations and votes shall be held in public. |
There was a problem hiding this comment.
Cases where this is not possible are…?
There was a problem hiding this comment.
You mean the Solid leader veto or that the deliberations of the Solid Team being public?
Do you have cases in mind?
There was a problem hiding this comment.
It says "whenever possible", so I'd want to make that explicit, or maybe remove if no cases exist. I don't see any (unless urgent security bugs).
|
|
||
| Some decisions can be made purely by the Solid Leader; however, there are many decisions at a lower category of important for which it would be useful to have a legitimate process that could always be blocked by the Solid leader. The operations of legitimate process could be [...?] | ||
| # [The Solid Team] | ||
| The Solid Team is a 5 person trusted group who manage Solid, which currently consists of: |
There was a problem hiding this comment.
"manage" has many meanings; what do we mean?
There was a problem hiding this comment.
Management scope is covered in the section #Mandate
There was a problem hiding this comment.
Best to link that word to the relevant section then
|
I would like to have a separate document/process for spec editing. I do not consider spec editing a decision process; it is writing down what people have agreed upon. (Spec making is a process.) As such, I don't think it fits in a "decision making process" document. So in my mind, there is a separate document "spec writing process", and in my ideal world, it says something like:
|
switched from BDFL (term inherited from Python) to Solid Leader
included suggestion from Ruben to have the table as an optional format
|
Yes, agreed, Solid specification writing is crucial to Solid and deserves special attention. However, I do see decisions needing to be made in that writing process. How do people come to an agreement about what to write? Who are 'people'? |
typo fix suggestions from Pat included
|
@pmcb55 thanks for eagle eye typo work, have updated the pull request to include the fix |
|
@RubenVerborgh - it sounds like you think specification editing will require very little discretion and cause very little controversy. But as you say, there may be edge cases where we'd want to use a decision-making process. I think the key thing to figure out is how that decision-making process would be triggered. What would the process be, and who would be able to trigger it? It may never get triggered, but it's good to have a plan just in case. |
We start from the spec 0.7 document and NSS.
Anyone in the community as far as I'm concerned. But I don't think it's going to be that difficult at first; perhaps the process can be adjusted once it does. |
Indeed, perhaps just an example of what would be done. Current draft document:
An editor could instead write in the spec:
Aside from the technical meaning, note how the second is a clearer and non-ambiguous version of the first (it's clear who does what etc.). This is non-controversial, we just properly write down something we've been doing for ages. Now in the process of writing this down, because of the more exact language, new questions might arrive. For instance, Then we can discuss those things, and 90% of cases there will be agreement. So then we just accept the PR after a week.
An editor sees that people don't agree (i.e., it's not just one person objecting, but there is a genuine concern), then it moves to decision. Something like that. |
|
How about we have free writing via pull requests that are left open for 36 hours before being merged by the Solid Team. If 5 people in the Solid Panel raise a concern by writing 'concern' in the pull request then the vote process is triggered. The Solid Panel can have criteria to apply and are appointment by the Solid Leader. Then there could be a list of the names of the people on the Solid Panel. That way we give the possibility for free uninterrupted writing of the Solid spec while also having a mechanism to raise concern so that the free writing result is something that everyone can get on board with. |
|
Perhaps one could be inspired by the Scala community process too. They host a repository of the best scala libraries, which I think they use when making improvements to the compiler to see what breaks. I am not sure how one would translated this to Solid though, as it is not just a matter of compiling apps and apps are a lot more difficult to test. Google uses its crawl of the web to test new spec improvements and how that would affect the changes to the existing useful web pages. Currently there are not so many deployed apps perhaps, but it would make a good case for having them listed, and so debates can point to code that may need changing if something is changed. |
Too short I'd say. Not all people are online once every 24 hours. |
|
Would a week be a good time period? |
include comments from the pull request conversation about allowing for Solid Team led decisions and the way in which a voting process is triggered.
|
A week sounds reasonable to me; perhaps could/should also be tied into the call schedule. |
small typo and structure changes to make it an easier read
include review period
|
See https://github.com/solid/culture for further conversation on this topic |
Had a shot at incorporating feedback from @shaunagm on #132
Please feel free to add and edit further.
The proposal is to generate the first draft of the Solid specification v0.8 in the following way, as described in the Solid Specification v0.8 Solid Project . After Solid spec v0.8 the following decision making process could be used to make changes to the Solid spec.