Improving the effectiveness of panels

[justinwb]

We originally introduced panels as part of the Solid process ten months ago. Our aim was to drive focused and thoughtful collaboration around specific topics, leading to meaningful contributions to the Solid Specification and ecosystem. We held off on adding a lot of structure around how panels are formed, or how they operate, until we had some real experiences in the wild to learn from.

Work towards a normative Solid Specification has picked up considerably. We just merged the first candidate proposal from a panel into the editors draft. We have some real experiences to draw from now, and a lot of work left to be done. It's time to look at how panels have operated to date, and consider any opportunities to improve them. How can we help them drive positive, constructive contributions to the Solid specification and ecosystem in a timely manner?

Here are a few considerations and thoughts based on personal observations and discussions with panelists, editors, and others:

• There are too many panels, and only a few of them are active and/or productive. We should have less panels with greater coordination and more focus.
• There's no clear or consistent organizing structure in active panels. Who is responsible to set expectations, hold or be held accountable, and keep focus where it needs to be?
• Active panels aren't focusing enough on the most pressing needs of the specification, or the most important use cases in the real-world.
• The editorial team needs to provide more active support to panels, and better communication around specification priorities.

This list is not meant to be exhaustive, only to contribute to the discussion in this thread.

Whatever your role (panelist, community member, editor, etc) - please chime in and share your thoughts on how you'd like to see panels evolve.

[csarven]

One key aspect to help specs progress is grounding the requirements on implementation experience ( https://www.w3.org/2019/Process-20190301/#implementation-experience ). That's anything from experimental work to actual use in personal sites/tools covering what's proposed. Implementations should fulfil the basics:

• based on use cases documented and acknowledged by the community ( see also https://lists.w3.org/Archives/Public/public-solid/2020May/0000.html )
• multiple, independently built using different codebases, publicly accessible and reusable.

This may not seem vital for a panel to produce but it will eventually be required when implementation reports are requested in test suites for each requirement in the specs (we are borrowing from the WG process CR https://www.w3.org/2019/Process-20190301/#candidate-rec ).

No implementation => not in spec.

[emmettownsend]

Here are a few considerations and thoughts based on personal observations and discussions with panelists, editors, and others:

• There are too many panels, and only a few of them are active and/or productive. We should have less panels with greater coordination and more focus.

Absolutely agree. I think panel should only exist when it has a minimum number of active members and they are actively working together and generating output and outcomes.
In addition, I think one person from each Panel should meet together regularly to ensure all the Panels are heading in the same direction. These meetings should be small, focused and short. I think would be the place to ensure alignment between panels, not the place to do new thinking or talk about new ideas.

• There's no clear or consistent organizing structure in active panels. Who is responsible to set expectations, hold or be held accountable, and keep focus where it needs to be?

Again I agree. If a panel is to be focused and productive then I think it needs to have a Chair who is responsible for ensuring there is a clear agenda, goals for each meeting, actions that are followed up and even dates that are targeted.

• Active panels aren't focusing enough on the most pressing needs of the specification, or the most important use cases in the real-world.

I think each panel should be working against a set of documented real world use cases or requirements. Of course new ideas will come up during the work but then real world use cases should be created that align to those needs.
If there are a set of use cases then prioritization will be easier.
Prioritization is important and there are many ways that could happen from Chair decides to a voting system. Whatever way it happens, it is important that it does happen.
This would enable all panels to focus on a small number of items at a time and move them towards drafting rather than having a large number of items open all at one time.

• The editorial team needs to provide more active support to panels, and better communication around specification priorities.

Perhaps its the editorial team that does the prioritization and explicitly shares that along with rationale?

This list is not meant to be exhaustive, only to contribute to the discussion in this thread.

Whatever your role (panelist, community member, editor, etc) - please chime in and share your thoughts on how you'd like to see panels evolve.

[sideshowtom]

Inrupt has a number of employees and contractors working on Solid related things. Inrupt also has non disclosure agreements with customers that cover work it is doing for them. Presumably Inrupt employees and contractors are familiar with the work covered by these non-disclosure agreements. The rest of the Solid community is hindered in helping to make effective decisions in shaping the future of Solid without this knowledge, given that Inrupt is such a large part of the Solid community as it exists. Don't know how to solve it, just sayin'.

[justinwb]

Don't know how to solve it, just sayin'.

@sideshowtom You're free to raise other concerns in a separate issue, but this thread is dedicated to how we can improve solid panels to drive more contribution into the solid specification ecosystem. i can't find any connection in your comments to current or future panel operation. Let's stay on topic in this one please.

[csarven]

Agree with @justinwb re topic and creating a separate issue. @sideshowtom , you have voice! If you were not heard or got a chance to contributing in a way you like, we should note and try to resolve. Documented links would be great. IMO, perhaps suffice it to say, no one is intended to be hindered in helping to make effective decisions or even taking on roles as per process. As mentioned earlier, there is an open call for contributors to the UCRs that is intended to guide the project in several areas. Panels are wide open and include people with different affiliations - if anything, Inrupt's involvement is probably a minority. We do the best we can to capture meeting minutes (in the CG wiki).

[aschrijver]

The issue @sideshowtom just sliced may be a bit off-topic, but it comes from a feeling that there is a bit of an engagement problem between core team(s) where the real action is, and the places where the community resides. This has been discussed on the forum in relation to Gitter, but it also holds for the Panels.

Having so many repo's feels fragmented. If I want to keep up-to-date I'd have to Follow all of them.. but I am already following many dozens of projects. 1,000's of activities in github. That is untenable. So I would need to be either very dedicated, or just check now and then overlook stuff.

Both Github and the Discourse forum are not the perfect tools. Weren't the panels in the forum before? Not well enough organized maybe. I think user engagement would benefit if they were there again. At least for the first 2 and maybe the last bullet point of @justinwb and the community being more in touch again + core team members also on the forum more often.

You can look at SocialHub for an example:

• Official panel members are part of a Group
• The group owner is the Chair
• Create category (maybe 1 called 'Panels') and subcategories for each panel
• The special category pages (1st pinned post) hold the instructions and organization details
• Important topics are pinned (you can time how long)
• For documentation drafts and collaborative editing you use wiki posts
• For 'resolving issues' you use that feature, and can then mark any post as the chosen solution
• Create polls to reach agreement, make democratic decisions
• [Many more standard Discourse features]
• Plus you can have 2-way connectivity to github repo's via Discourse plugins
  • Use the repo's for 'finalized' stuff an rendering of html spec docs + code
  • PR's become posts on the forum at the right place
  • Add the repo's to the context menu of the forum (other plugin)
• Use plugin to have a glossary of terminology that is automatically marked up in all texts
• Lastly, if you didn't have Gitter showing forum activity install chatroom integration plugin

[csarven]

As @justinwb suggested, let's remain on topic. I'm responding to the earlier comments so that they are acknowledged (as opposed to dismissed). It'd be great to continue other (related) topics elsewhere.

---

@aschrijver Collaborating on Solid through GitHub and Gitter predates everything. In which way are the "core teams" not engaged adequately in your view above and beyond where the action is since their conception ie. in Gitter and GitHub [citations needed]? What's the expectation exactly? The forum - ie. Discourse, which is horrendous for archiving: https://web.archive.org/web/20200518152528/https://forum.solidproject.org/t/this-forum-should-be-central-to-solid-community-and-not-gitter/2747 - is used by some community members as something supplementary to Gitter chat. Neither does it serve well for documentation - again, see also archiving and versioning - because actual documentation happens elsewhere. The forum falls short in a number of fronts that's simply nowhere suitable for the work that's carried out in the panels. Having said that, the Solid community can exchange anywhere on the Web and there is no particular requirement that it all needs to happen under a single server or tool. We can and do talk about the Solid project anywhere. There just happens to be some preferred ones (partly for historical reasons) for certain kinds of communication.

Do you feel that the choice of GitHub and Gitter prevents or hinders you from participating on the panels, specifications, or even general chat, whether through text or audio/video, based on principle or some specific reason? Would you like the whole "core team" to switch to using the forum or just drop in once in awhile to answer questions? Would the members of the forum like to drop-by the panels / specifications channels with their feedback? As you'll surely agree, we all have limited bandwidth.

[aschrijver]

I have been looking at the GH repository organization of Solid, and frankly I find them an intimidating mess.

I strongly advise bringing more structure to it to make it easier for people to be on the same page.

One suggestion is to create multiple solid-related GH organizations, e.g. a solid-labs where only the spec + panels + related docs can be found.

Then maybe a solid-ecosystem with solid-ui and panes and supporting projects.

So that in solid you only have core projects, website, process, core docs.

Well, you get the idea. You probably can do much better than my try above 😄

[dmitrizagidulin]

@aschrijver I get that if you look at all of the repos in the Solid GitHub org, it looks way intimidating. Fortunately, you really don't have to follow all of them (or even most of them).
Honestly, you could do well just following the solid/specification repository and issues. (Because all output from the panels is going to end up in the specification repo anyway.)

[aschrijver]

Sure, if watching the spec is your usecase. If watching the panels is your use case you first need to find out about their existence in 'process' repo, or navigate the org's repo's where you find some on page 4 or 5. Also 'panes' and 'panels' are nearly the same words. You could easily confuse panels for code repo's if you are not familiar with Solid project structures.

Some more ideas:

Walls of text and formality

The process website is an entrypoint to many things solid, including panels. It leads you through walls of text and takes a newbie an hour to figure out. The text is needed, that's understandable. But may you could provide more overview by adding collapsible regions to them

Vision Panel Organization

Source

This gist

yes, even hidden code blocks!

print("hello world!")

Github teams and projects ➜ agile workflow for focused panel discussion

I am surprised that you are not using these features github offers. They seem to me the perfect way to address the original bullet points of this issue. They even added discussions recently, if you don't want to use the solid forum for that (which according to @csarven is indeed the case).

[joshdcollins]

Responding to @Mitzi-Laszlo 's call for feedback on panels (from the perspective of a Data Interop panel participant):

1. There are too many defined panels with not enough doing active work
2. Panels could benefit from increased attendance and activity in terms of proposals, reviews, feedback, etc.
3. Panels need to push more towards their stated goal of producing material targeted for editoral review
4. There can be better outreach to the community via the forum (meeting notes, call for agenda items, etc.), hopefully leading to productive involvement
5. The closest thing to answering the question of "How do I get involved?" for a newcomer is probably https://solidproject.org/standardisation and it could be more prominently featured

[sideshowtom]

4. There can be better outreach to the community via the forum (meeting notes, call for agenda items, etc.), hopefully leading to productive involvement

If this was to some limited extent a two way channel then it would increase productive involvement

[csarven]

There are too many defined panels with not enough doing active work
Panels could benefit from increased attendance and activity in terms of proposals, reviews, feedback, etc.

It is organic and evolves. If a proposed panel is not currently active, there are reasons for it. We don't have to go out of our way to make a panel work just because it was proposed. Panels should continue to be self-organised and collaborate with the other panels in context of the spec work.

Panels need to push more towards their stated goal of producing material targeted for editoral review

Already by definition but unclear how exactly. One thing that generally comes up is whether panel discussions are aware of the existing issues in solid/specification and elsewhere eg. in implementations. And as Emmet already mentioned: having a panel facilitator exchanging notes with the editors - this doesn't necessarily require meetings, if minutes and issues are well documented. Can panel members be active in solid/specification chat?

There can be better outreach to the community via the forum (meeting notes, call for agenda items, etc.), hopefully leading to productive involvement

I don't see strong case for this because there are many places where Solid is being discussed and worked on. As far as I know, the forum is not part of the Solid CG or tied in any way to the work in specifications or the panels. The panel and spec meeting minutes and other documentations is already publicly accessible. Suggestion [and this is really something the forum members should decide on what works best for the forum]: If members of the forum feel that they can benefit from the information in the panels and elsewhere, volunteers from the forum can gather and disseminate the information in the forum in a way that's suitable to them. Again, the panel activity is already available. Related: do we expect discourse in forums to flow back into the panels? Are any forum members taking on that task?

The closest thing to answering the question of "How do I get involved?" for a newcomer is probably https://solidproject.org/standardisation and it could be more prominently featured

Sounds good.

[aschrijver]

Related: do we expect discourse in forums to flow back into the panels? Are any forum members taking on that task?

There are Discourse plugins that facilitate 2-way interaction automatically (also mentioned on the forum discussion re:panels).

[csarven]

Irrespective of how that's done, panel engagement requires participants to:

• join the Solid CG.
• join the relevant panels.

[aschrijver]

FYI: This is also a new topic of forum discussion: https://forum.solidproject.org/t/communication-with-panels/3135

[happybeing]

I don't have the bandwidth to get into this discussion and have not yet read the above, so apologies for that (I'll try to do so later). I'm cross posting the following from the forum at request of @aschrijver:

---

I think there's a problem centring the core, those with most expertise, historical knowledge, and who carry the longest cultural view on GitHub because it is less accessible, even inaccessible to most people.

People arrive here and think, this is it?! Which further inhibits growth, and that inhibits creativity, collaboration, sharing of understanding, learning etc.

I understand there are reasons for focusing on GitHub, but I think they don't justify the damage this does. Gitter is more accessible, but it isn't a place for building community, and it further dilutes the knowledge and the social network of Solid.

And on top of this we have Inrupt which has removed a number of Solid's core players and doesn't share it's vision or seek to collaborate in public.

If you want to build a broad inclusive community, which IMO is very important, I think it helps if the hub is in one place and accessible, and that as many of those with more skills and knowledge see it as important to engage there much more than is currently the case.

It's not about making everyone be active in the hub, but shifting from Islands which are largely cut off, to a hub with spokes. Then everyone knows that when they want to engage broadly, share key information, seek collaboration, ask questions or search for like minded community members etc, there is one place everyone knows to go, or to direct people wanting to learn or contribute.

You can have niches radiating from the hub, so for people who want to examine code etc they can go to GitHub and discuss code issues there - because most who want to do that will not find GitHub a barrier. Etc.

Cross posted from forum .

[happybeing]

I've now read through the thread and it feels like there's not enough understanding of the issues being raised from the outside, by those on the inside. The responses seem to assume that things which are not known widely outside don't create problems for those outside, such as where things are, how to find them etc.

Whereas everyone of us coming to the project over recent years has had to wrestle with the fragmentation and disparate systems, and unless you spend a lot of your time buried in Solid, the problems persist. This is why this keeps coming up including from relatively long term participants. Things may technically be accessible, that's not the issue, it's how accessible, how easily discovered and understood, how easy to engage with, how broadly, and how that affects the community and the project. I think there needs to be a single place where things are regularly shared at a high level, and most people spend at least some time checking in with.

This discussion illustrates the problem IMO, not just with panels, but I think relevant to panels as well as the other "Islands" of Solid in gitter, Inrupt, and subprojects (community and core). We're jumping in here because there isn't a hub. Because we don't know the panels place, the solid process place, or how to engage in these islands, and frankly it doesn't seem worth the effort going around learning how to, or if we should engage with each of the different Islands we don't know. If you expect everyone who engages with a specific aspect of Solid to go through this, you are excluding the majority from seeing what's going on here.

So I acknowledge that this isn't focused just on the issue of panels, but having seen this discussed several times and nothing change, and not getting engagement across the islands, it should IMO be relevant to how panels fit in with everything else.

I've explained on the forum why and how I think things could be improved by moving to a hub and spoke model rather than these separate Islands. So again I'm cross posting here starting with a short post by @tag42git for context, where he is replying to my post which I copied above. Sorry if it's repetitive, I'm on my mini tablet and short of time to edit.

---

tag42git:
Nevertheless, I think we have to take lemons and make lemonade…

Forum link

---

happybeing/theWebalyst:
Or you get a small lemonade enthusiasts club, and everyone else goes to the pub. (If I understand you correctly).

I don’t engage at all with the panels, because for me is just a bit more effort than I can contribute to add them to all the other places and projects I engage with. If they were more visible here, and I could contribute with a reply to post, I’m sure I’d have done so.

In some cases you do want this kind of friction, you still want spaces for focused technical work etc. So I’m not, as noted already, suggesting that everything should happen in the most accessible spot.

You can though publish documents periodically here for feedback, or to provide milestones of thought and product development outside those spaces where everyone can find them easily, or visit from time to time to get the latest etc.

With a social hub key Island players can share their vision, set out the fundamentals, explain the organisation, seek collaboration, answer questions too. And help Solid grow!

I think there’s a sense we should eat out own dog food rather than use Discourse etc for this. I’m sure most of the enthusiasts would love that, but until Solid can do that well it would IMO be a mistake, except for the lemonade club of course. And that club can be at the end of a spoke.

Maybe this will happen, but IMO Solid is missing out by not doing so now, and it’s worrying that these concerns have gone on for so long without significant change or much input from key players in the different Islands.

[aschrijver]

Proposal: Simplify Solid organization structure

(This is a copy of a forum topic I just posted, FYI)

Keep it small and simple. Solid forgot the KISS principle and now it is an interwoven mess of procedures, teams, panels, repositories, and more. Here are some ideas that appeal to me personally to simplify:

• Have two github organizations to separate different concerns:

  • Solid: Everything that has to do with specification development, nothing more.
  • SolidProject: Everything that has to do with implementation of the specification.

• Solid github organization has:

  • specification repository.
  • panel-discussion repository.
  • solidproject-website repository.
  • (probably some more, I didn't go through the list)

• Solid Project website focuses on clearly explaining the spec, and what it brings to implementers.

  • Change the site look&feel from a product website to a documentation website.
  • Create accessible documentation for a broad (developer) audience, add diagrams, animations, etc.
  • Does the site need a separate staging repo? I think not.
  • Does the site need a process on top of the PR process? I think not.
  • Define a github team for Editors, have projects with a kanban board for issue tracking
  • Define templates for issues and PR's, assign clear labels for issues.
  • Kill the MIT website, or have it redirect. It is yet another confusing entrypoint to Solid initiative.

• Panel Discussion repository squashes all panel repo's into one single location.

  • Have one top-level README to drill-down into the panel structure.
  • Have issue labels indicating to which panel the issue belongs.
  • Have teams per panel, and a project + kanban board per panel, Assign issues to panel members.
  • Update a Changelog upon closing an issue, part of Definition of Done. What was the outcome?
  • Have stalebot auto-close issues untouched for 6 months. They are probably unimportant.
  • Use the new Discussions feature of github, if you don't want to use the forum (add pointer instead).
  • Remove elaborate, overly formal Process repository. Small explainer + some bullet points suffice.
  • Could even remove issue tracker from Specification repo: all goes through panel discussion.

• SolidProject repo contains all the various code projects.

  • Should only contain 'official' repo's (probably already does).
  • Have clear naming conventions, libs, tools, sdks, reference impls, examples, pocs, etc.
  • Archive every repo that is old an out-of-date.
  • Mention all official repo's on Solid Project website in a single page and highlight their purpose.

• Solid initiative now consists of only 4 parts forming an onion model from outside in:

  1. Solid Project website: First point of contact, top-level entry, onboarding, facilitate early adopters.
  2. Solid Community forum: Free-form discussion, ideation, sharing insights, giving feedback.
  3. Solid Panel discussion: Formalising feedback for standardization, elaborate technical concepts.
  4. Solid Gitter channel: Active team member day-to-day chatter, hop in for quick question / feedback

Thoughts? Please join the forum discussion.

[Mitzi-Laszlo]

#208

[Mitzi-Laszlo]

#206

[justinwb]

@Mitzi-Laszlo this issue should remain open until #206, #208 are merged and actioned