More an editorial comment: Perhaps it would be more suitable to refer to the expert-oriented panels as "Task Force", and then reserve the "Panel" as a more general advisory body?

More an editorial comment: Perhaps it would be more suitable to refer to the expert-oriented panels as "Task Force", and then reserve the "Panel" as a more general advisory body?

@kjetilk i do like the task force terminology. In an effort to keep things simple I tried to make one structure (a solid panel) that was versatile. A given solid panel could act as an advisory body, but also have the ability to spin up projects within their domain. For my part I'm much less attached to the name (panel), then to the simplicity of only needing one type of structure with one set of associated governance rules.

I think it's important that the structure we use can support more than one advisory body. For example, a security panel can act as an advisory body for security guidance. If the specification panel needed to settle an approach with security ramifications, that decision would probably be supported better if there was a panel to consult that was organized specifically for security. So we have the ability to create general and specific advisory bodies.

So the reason this conversation came about is because there are Solid spec issues open from 2015

Governance is a big heavy word. Culture is also fitting to this conversation.

Essentially, how do we come to an agreement to a collective action rather than end up in pull request ping pong or issue stagnation?

there are Solid spec issues open from 2015

That's interesting, because this gets into duties rather than rights/responsibilities.

Also listening to @csarven's suggestion about DoOcracy, perhaps we should think about appealing to a sense of duty within all members of the community (and many definitely feel that).

how do we come to an agreement to a collective action

Maybe the question becomes: what is the minimal amount of structure we need to foster such participation?

Perhaps we could have:

• Solid Community: as those who have skin in the game and can vote. Criteria would include: Solid users, identity providers, Pod providers, and Solid app providers.

• Solid Panels: who are experts appointed by the Solid Team (unless there is intervention from the Solid Leader) who put forward suggestions for the Solid Community to vote on.

• Solid Team: coordination role

Maybe the question becomes: what is the minimal amount of structure we need to foster such participation?

Yes!

I think we need to take a step back, and consider the options more systematically.

First, there is a spectrum between do-o-cracy on one end, where those who work on implementation (in a somewhat broad sense) get to make all the decisions, and a direct democracy where the public gets to make all the decisions, and where implementors are the public's servants.

One of @Mitzi-Laszlo 's concern is

when the Solid Team represents a handful of vendors and there are no mechanisms of accountability to users?

in a do-o-cracy, there is no accountability to users. Users only have the option of going away, which they will if we're not doing it right. Thus, there is some incentive for us to have further accountability to users, so the question is how that should look. Should users have actual power over the project?

If they should have actual power, then, I am of the opinion that merely having a voice is not enough. A voice is not power, a vote is somewhat more power, but not a lot.

Ultimately, all proposals, everything we would vote over would have to be implemented, interoperably, by several independent parties. Thus, everything comes down to implementation. Also, there will always be more ideas, and more good ideas than time to implement, so it really all comes down to implementors time, and how that is prioritized. We have been asking with what legitimacy a vendor-dominated body makes decision over the spec, and thus implementor's time, but we also have to ask the reverse: With what legitimacy can users decide how implementor's time is spent?

There are several types of implementors, some may be hackers who are volunteering their time, some are vendors with a commercial stake in the project. How can users require volunteers to spend their time on a certain feature? How can users require vendors to assign people to work on something?

Users can establish a relationship with vendors by becoming shareholders or customers, but in this world, this is basically it.

Now, users can influence the project through politics and enact laws that require certain things to be done. Laws and social norms are surely needed, and often both the right way and the only way to do it.

However, I think these problems highlight what I have been trying to communicate for a while, that the normative landscape is so much bigger than that, that code and technical standards also to a great extent is normative. In our case, the question is really how the public can influence this normative landscape. I also happen to think that this is the most important part, and the most ignored part of the normative landscape. Laws are, especially in light of the enormous amount of work that goes into them, quite ineffective.

The disconcerting answer to the question is that they can't. The public cannot influence the norms encoded in code and technical standards to any great extent. Which is very, very, very bad, but there is nothing our governance model can do to change it.

If you require from a volunteering hacker that they work on something, they are likely to go somewhere else where they have more autonomy. If you require a vendor to work on something where they see no customers, they are unlikely to be helpful.

The obvious fix to this problem is that governments hire implementors to work on certain features, based not on the commercial viability of that feature, but on the expected impact on society. Then, it also hires people from humanities and social sciences to participate in the normative work as well as to study if that feature has the expected impact. It must do so on the timescale of business, not on the timescale of research programmes.

My conclusion is that currently, there is no mechanism that can establish accountability to users by means of actual power. To establish that, changes in policy on societal level is required, and I think we should say so when talking with politicians.

Meanwhile (and this may take some time...), what we can do is having all our proceedings in public, making sure we closely consult the community, and that we provide a clear path for people to take the project in a different direction if they are unhappy with the decision bodies that currently oversee the project (concretely, by means of a fork and a W3C WG).

I actually do not have very strong opinion on the structure of the decision bodies, but I do think that the pursuit of giving users actual power over the project will not be fruitful given current societal politics.

If they should have actual power, then, I am of the opinion that merely having a voice is not enough. A voice is not power, a vote is somewhat more power, but not a lot.

Indeed, talking online is not direct power of significant influence.

The disconcerting answer to the question is that they can't. The public cannot influence the norms encoded in code and technical standards to any great extent. Which is very, very, very bad, but there is nothing our governance model can do to change it.

Everything starts small. The exciting thing about doing it on a very, very, very small scale here is that we can test it, try it, learn, adapt.

Everything starts small. The exciting thing about doing it on a very, very, very small scale here is that we can test it, try it, learn, adapt.

To me, it is more black and white... It then really comes down to which implementors are willing to commit to implementing things that they see no value in for themselves, or at least align priorities not with their own plans, but with the plans of others.

Obviously, things like that do happen, and standardization processes does rally support to achieve things like that, but it is a really hard thing to sell. Moreover, it is not something the Solid team can decide since it requires a commitment of all implementors.

Which brings us back to having the larger panel, I guess :-)

So, lets see if we can think about this in the metaphors of a parliament and a cabinet. So, the problem is that the public does not have an executive branch that answers to them, the executive branch (lacking future government funding for implementors), consists of volunteers who commit their own time and vendors, who commit time to attract customers.

Thus, the cabinet would consist of implementors, i.e. largely @justinwb 's Solid Team. Your's is much more the parliament, I think @Mitzi-Laszlo . The parliament could in principle solicit and get a commitment of all interested parties to implement whatever the parliament comes up with. The cabinet would then spring from the parliament as the executive branch. It would still not be accountable directly to users, but users would have a vote in the parliament to which they have committed to follow.

I suppose that could work, but I remain quite skeptical that we would get that kind of commitment, and if so, the structure could lead to a paralysis, or everyone-for-themselves. I'm not even sure it is the right thing to try right now given that the project isn't that old.

You raise a lot of important points @csarven, and so I've tried to respond to each one directly.

I want to reiterate again that what's proposed is not meant to be perfect, but to be a starting point for discussion. Thankfully it's already serving its purpose in that regard. I'm not personally wedded to every detail or structure in this proposal. The only thing that matters to me is that we have a better system for focusing and channeling the collective efforts in a way that moves Solid forward. That's a point that we should all be able to agree on.

At this point in time, besides Tim being the benevolent dictatordirector of the Solid project, I don't see a need for a governance structure. I'm in favour of DoOcracy. We need to let the Solid project shape itself based on the core principles and architecture of the Web. That's what brings us here.. and dare I say, pledge to holding it together?

But this is how it has been operating for (at least) as long as I've been around, and there's still so much to be done across the spectrum. If things were already cruising along, and we had consistent velocity evolving standards and resolving key problems, there would be less urgency for this. Solid isn't going to see the adoption we all want if we can't move things forward in a consistent way, all the time. Solid could impact many people's lives positively if we can only get it to them. They deserve better.

The fact that there is still confusion around "how do we run this project.. where is it going.. who should have real voice.." is probably a good indicator that establishing any governance structure - however well intended - may be premature. The reality may just be we haven't even scratched the surface, so I don't see how any governance structure can handle what is ahead. Even if it can theoratically adapt, it has consequences.

I'm not sure that pointing to the absence of something is a compelling reason to justify the continued absence of something. The danger is that if we don't have some focus and orchestration - Solid will not mature. There are a lot of key factors that have to happen for Solid to be successful, and (imo) we need better organizing principles to realize them.

The Social CG implicitly pursues the incubation of specifications for the ecosystem. Everyone can voice/vote. Anyone can participate, implement, and so forth. What's the case to override how that unfolds? Community or sub-groups roughly agree on how to pursue each spec that's of interest to them. Ditto the handling of implementations by those working on them. There is no need for an overarching team/panel/experts/decisionmakers/specialforces/magicians, and so forth. IMHO, that all unnecessary bureaucracy.

As described, this sounds a lot like the Solid Panels included in this proposal. If so, and you've got suggestions on how to adjust those, that would be well received.

Get involved in what interests you and find out how you can best contribute. Drop the hats. Control yourself, not others.

Again, this is how it has been operating to date, and (imo) there's too much left to be resolved that could've been done by now with better focus and coordination. We have lost people that had a lot of energy to contribute, but couldn't find a constructive way to engage. That needs to be fixed.

PS: I'm strongly opposed to seeing arbitrary decision making (especially "team" and alike) simply because some people are briefly entitled to access/control.

Assuming that decisions would be made arbitrarily is an unfair statement. I don't think you'll find anywhere in the document as written that says decisions would be made by random choice or personal whim. You could subject any type of decision making to that criticism.

The Solid project.. the RWW, LD, decentralisation efforts.. the Web.. didn't start a year ago. The "team" in fact goes further back in time and space. Let's be a bit more mindful about how all this emerged and be more inclusive, and leave space for diverse ideas to emerge from anywhere.

The team structure as stated certainly was never meant to diminish the great work done to date on Solid by many (like yourself) that deserve to be recognized, heard, and appreciated. The purpose of the team structure proposed, is that they dedicate considerable time now and for the forseeable future on work that most people aren't really willing to do consistently; facilitation, coordination, documentation, and fostering agreement on tough issues where all else fails.

To end where I started - this is admittedly not a perfect proposal. The hope is that we can work constructively to get there. If we accept none of this, but arrive at a structure that advances Solid in an optimal way, I will be ecstatic.

Maybe the question becomes: what is the minimal amount of structure we need to foster such participation?

This is the right question @RubenVerborgh. I would also add - how do we then channel that participation towards the highest value areas of the roadmap?

Specific comments on solid-team.md edits:

• What is the difference between ‘Solid’ and ‘the Solid Project’? Is there a benefit of distinguishing this
• Considering we have not clearly defined the Solid mission or the Solid Roadmap perhaps we should either detail the Solid mission and Solid Roadmap first, or not refer to it at all.
• Not clear what ‘provide an effective means of governance’ or ‘serve at the pleasure of the Solid Leader’ means exactly?
• Would be good to include the powers of the Solid Team and the limits. Was originally in this text:

The Solid Team has broad authority to make decisions about Solid. For example, they can:

• Formally accept or reject suggestions (usually in the form of a GitHub pull request or issue)
• Enforce or update the Solid project's code of conduct
• Manage Solid assets and infrastructure, including the Solid Github organisation and repositories, the bug tracker, mailing lists, conversation channels etc.

However, the Solid Team cannot modify this decision-making process or affect the membership of the Solid Panel (see below for description of Solid Panel), except via the mechanisms specified in this decision-making process document.

The Solid Team should look for ways to use these powers as little as possible. Instead of voting it's better to seek consensus. Instead of ruling on individuals it's better to define standard processes for decision making. It's better to establish a Code of Conduct committee than to rule on individual cases, etc.

• Rationale should be incorporated into the specifics of the decision making process design rather than a generic broad rationale
• Specific responsibilities of each of the Solid Team members need to be listed rather than a generic title for all three members. Suggestions are in original version.
• Decision making should be in the decision-making.md rather than the description of solid-team.md
• Solid Team should not be able to expand Solid team or remove members of the Solid Team (see comments above about the influence on the ability to deliver on avoiding vendor lock-in)

Specific suggestions on the readme:

https://github.com/solid/culture/pull/10/files

Specific feedback on the solid-panels.md

• @michieldejong proposed a more unconference style where anyone can raise a topic and anyone can join any conversation group. I’m reluctant to create a system where the Solid Team decides who is an expert on what (see comments above)
• Community Panel could be the Solid Community rather than a panel to distinguish expertise from skin in the game which is a different relationship to Solid and therefore has a different dynamic.
• Include rationale in the details of the design rather than generically

Specific feedback on the solid-panels.md

• Need to include the practical descriptions of how to run the votes and start them
• Need to include the way in which the collective opinion of the Solid Community is understood.

:)

I want to reiterate again.. we should all be able to agree on.

Surely there are broad agreements, however, not necessarily on the execution. For starters, how do you anticipate that we arrive at "a better system" when what's being pushed right now in this issue intends to give a higher voice to the few (whom are all listed under one organisation's website by the way) to have "broad authority" over things? Better for whom? How do you know?

What was the qualification and selection criteria? Who was initially reached out? What makes the current proposed people any more knowledgeable, equipped, disciplined, resourceful, or having the willingness to carry out the goals than those that have been around a decade, if not longer in various ways?

Let's not undermine the complexity of the landscape. There have been a number of groups and initiatives in close proximity (if not overlapping) to the Solid project. From which of those experiences does this proposal take lessons from? Put another way, how sure are you? What are the potential problems or costs to taking this on?

But this is how it has been operating.. less urgency for this.

Welcome aboard. It is not easy. There has been moving targets as well as things outside the control of the project and individuals. That's reality. What makes you so sure that a(ny) governance structure will handle all of that? Let's play with a real world scenario: you are on the Solid Team, and you find out (over the course of weeks, months, if not years) that standardisation and software around a fundamental piece of technology or workflow is getting dropped out or falling apart. Let's call that the cert system, keygen, browser UI/UX, ... meanwhile ("official" and highly visible) efforts nominating an alternative system to yours. If you don't know the answer to how to "better" handle that scenario for the ecosystem and community, then you're probably not bringing anything new to the table with the governance structure. Are you prepared to make those decisions? How committed are you to stand by it? 3 months? 1, 5, 10 years? What makes you think that a community will stand by your decisions and not organically come up with alternatives? What then? What kind of resources or energy are you willing to throw in so that there is interop or mutual understanding across projects, standards, people and so forth? What kind of technical (and unfortunately probably social) sacrifices are you prepared to make?

I am really not trying to pick on you nor think that you or anyone is incapable of accomplishing that. On the contrary, I don't expect anyone to have a magic bullet answer to these questions. Heck, at least no one did in the past. The point is that, it is extremely difficult and there are major consequences. The project needs to be able to outlive a single person's interest or a group within. Minds change. People move around (and have moved on!) That needs to be factored in. What remains is the system... if there is still a system. But none of that means that a governance structure is promised to fix what's not fixable by its very nature.

Solid isn't going to see the adoption we all want if we can't move things forward in a consistent way, all the time.

Sorry, that's handwaving. It is moving forward if we look at it in a long enough timeline. And, I've already discussed things that will be literally out of your control but you'll have to make a decision on whether you like to or not. And, making no decision, will be a decision in and itself. So, I suppose it depends on what you want to measure. Do you or community needs a standard by a certain date? Does the ecosystem need to "work" by a certain date? Was that a community decision?

I'm not sure that pointing to the absence of something is a compelling reason to justify the continued absence of something.

You can't have your cake and eat it too. Either you are sure that governance structure will resolve issues, and if so, I'd like to see proof that it has been at least tested and reasonably working, or you really don't know (and that's perfectly fine) and in which case, it is just hypothetical. Not demonstrably better than having no governance - I hate the double negatives but I'm feeling lazy. It is just as likely that due to the governance structure, the project can halt or be harmful. Have you considered that and documented? What happens then? Pack up? Start from scratch? Will you be still around?

The danger is that if we don't have some focus and orchestration - Solid will not mature.

Hypothetical.

We have lost people that had a lot of energy to contribute, but couldn't find a constructive way to engage.

How certain are you or know as fact that's due to a lack of a governance structure?

great work done to date on Solid by many (like yourself) that deserve to be recognized, heard, and appreciated

I don't think anyone - including myself - is looking for a badge, medal or special recognition. Many people have poured their time and hearts into bringing Solid to where it is - FWIW. However, I hope you understand my (and probably others') concern that when a small group of people - which happen to have access to things - proposing governance out of the blue (while being relatively new to the project and not actually faced or dealt with the "hard" problems) is not a simple thing to accept. Massage that. Pardon me, but, perhaps first prove yourself in the community. Get the community to call for a governance structure. Bottom up.

I'm ultimately concerned about the longevity of the project. I'm just one voice and may not mean much, but if you want to convince me of a governance structure, show me 1) what you have tried with the community 2) what worked and didn't 3) explain how the proposed structure will improve all of that.

Having said that, I can see a horizontal (or is it vertical, diagonal, zigzag?) grouping that's keeping an eye on various initiatives in the Solid project, and assists people (not rules or acts as authority).. off the top of my head: grounding the community on ethical considerations, as well as "accessibility, usability, and inclusion", security and privacy matters - like in W3C. Those things must be at the core of Solid's output.

Another area of grouping can be (and I think this is sort of already in place) is to make sure that certain principles / code-of-conducts can be enforced.

I feel that those two areas rest above any piece of technology, are tangible, and only requires a loose governance structure. Integral to a healthy and evolvable system. IMHO.

:)

The most important thing to keep in mind: are we serving the community? Is there a community demand for more governance?

If not, then we probably should not proceed until there is. We should not decide what is best for them.

I understand how @csarven's plea for less governance and @Mitzi-Laszlo's unconference analogies seem appropriate for a Decentralized Web community. OTOH, I am extremely concerned that we will under-deliver on a lot of fronts and get stuck in the hype trough. Maybe because I've been called a benevolent dictator, I'm pretty at ease with one, so long as they want to go in a reasonably optimal direction. Once you have that, any additional process distributes power and adds organization and community representation.

It may have been nice to work on this gradually over a decade, giving lots of people time to figure stuff out, but given the current level of public attention, I'm convinced that squandering it would be at our peril. I believe that having some invested experts responsible for decisions, including when and where they focus their expertise, is the best way to make sufficient progress to keep contributors and the public engaged.

Solid is an exciting new project led by Prof. Tim Berners-Lee, inventor of the World Wide Web, taking place at MIT. The project aims to radically change the way Web applications work today, resulting in true data ownership as well as improved privacy.

In what ever bigger mission you enbark on in life there has to be a vision, leadership, management, excecution, governance etc.. The success of the mission is determined of how well the organisation/community/structure are adapted to focus on the right tasks in each stage to be able to move forward. Failing is part of the journey and pivoting fast when taking a wrong road makes progress wanted faster.

As a new comer in the arena, not been on this mission as long as Tim, Ruben, Justin, Sarven, Kjetil and other veterans, what @RubenVerborgh mention, I have to agree on, is there really need for more governance from the community?

It all comes down to resources and time, what you focus on with what you have, there is TON of things needed to be done to make this revolution. Funding, Resources, Tools, SDK, Databrowser 2.0 and not mentioning getting companies and institutions onboard with Solid.

My stand from a community perspective is that please focus on enable progress on tasks that needs to be done with assistance from the community to move forward on the mission, governance is the smallest problem at the moment.

Set a culture where governance and this type of things, self regulates. A Culture We Want.

is there really need for more governance from the community?

I think the answer to that comes from whether you believe we're proceeding something close to optimally, given the resources. If I spend a weekend on a crackpot scheme and share it with the community, my ability to drum up interest in it is more coupled to my ability to sell it than its actual merit. This tends to favor simple stories over realistic consideration of the complexity.

Many of the problems that we're trying to solve are actually quite complex. For instance, right now I'm focusing on schema evolution and versioning, where traditional approaches have relied on course-grained versioning (e.g. SNOMED annual releases) while SemWeb ideals are more glissando. When making architectural decisions about versioning, I'm much more confident explaining the intricacies to a group of similarly focused people than in trying to describe it a more generalist group just before a vote. Whenever I end up in the latter situation, I find myself repeating the same briefing every few months. This saps my energy and I'm more inclined to drop it in favor of something that requires less shared context.

@csarven wrote

Get the community to call for a governance structure. Bottom up.

I think we had that call pretty loud and clear... Like for example on globbing. In a do-o-cracy, it is quite clear that none of those pouring in time into spec and server had any interest in it and think that we need to replace it ASAP with a better query system, so in a do-o-cracy, poof it'll be gone.

In that case, we do not really know the voice of the community, but we do know that such an action would make some people in the community really unhappy. To be able to make decisions on that, I think the call for a governance structure was pretty clear.

We also have the problem of who gets privileges to what and why. You have yourself asked about that, IIRC. And with the lack of governance structure, the answer hasn't been good. Those of us who can add people when we think they need it, and there isn't a very clear and consistent answer to "why". Again, it is the lack of governance structure. So, what I have heard from that is actually a call for governance.

But I may have misunderstood that entirely.

When we get to the point that things are more modular and independent, I think things will become quite a lot easier, but as long as we're writing specs and server, it is hard.

Now, I am quite happy with do-o-cracies, but I am also in a position where I would be quite powerful in one. I am also quite happy with a cabinet-without-parliament style governance model, because I would be quite powerful in that too, but neither is an ideal to me. I think at this point that the do-o-cracy has showed limitations, as exemplified by the globbing example above, and given the lamentable situation where the general public has hardly de facto or de jure power, I think that a certain cabinet-without-parliament could work in the short term, if we are also able to identify and distill the voice of the community somehow.

I think we had that call pretty loud and clear... Like for example on globbing. In a do-o-cracy, it is quite clear that none of those pouring in time into spec and server had any interest in it and think that we need to replace it ASAP with a better query system, so in a do-o-cracy, poof it'll be gone.

That's an interesting example, in the sense that I think it shows a do-o-cracy can work. Globbing was a feature that the community did not want, with the exception of one or two stakeholders. After some discussions, it was marked as "at risk" so it can eventually be deprecated and removed.

And globbing was a hard case because of the sensitivities involved; the majority are much more simple cases.

We also have the problem of who gets privileges to what and why.

That's probably the more pressing thing. Finding out who has merge privileges, who can supply mandatory reviews.

After much discussion on this thread and outside of it with a bunch of community members, it made sense to take an entirely new approach that is more lightweight and less prescriptive. Will be closing this pull without merging it in. A new branch will be created, and a new pull request will be submitted with a new proposal shortly.