I think we should move this issue here, it may be moved somewhere else but, I thought it prudent to start an issue as a place to begin the discussion off of the chat so as not to interfere with day to day conversations related to general questions and answers.

@ @d-a-v-i-- In the excitement of a fast-evolving ecosystem representing many voices, an engaged team sometimes can get ahead of itself. We apologize for any confusion or unintentional expectations about a statement to be made by Inrupt today. Monday was offered as time to bring people into the discussion, not a deadline for a specific announcement.

We take our responsibility around transparency very seriously, so we can all learn, improve and better serve the community. In response to your feedback, we are taking steps to improve our clarity (core to being transparent) by establishing more formal messaging processes. If you have questions about transparency anytime please do post them in appropriate channels.

Thank you to the solid community channels for your questions and concerns. Keep them coming, we continue to iterate to do better!

Mike Adams @mikeadams1 18:30

Could major sections of the code of conduct document be styled with heading elements (e.g. H2) to make it easier to navigate?

The scope and form of active panels was changed without consultation with panel stakeholders, despite the fact that there are active projects in flight (e.g. data-interop) that have now been seemingly split between new panels. There was no pull request for conversation about this change. There was no period of wait. There was no constructive deliberation about how things should be combined that included all of the necessary stakeholders. There is nowhere in our process that says that the scope and form of panels can be changed on a whim. People requested, volunteered, and participated in panels based on a given scope, it should be up to those same people to decide if they want to change that, not others.

Consequently, I have to officially note for the record my disagreement with this change, and dissatisfaction with how it was made.

I have to insist that this change be reverted, and resubmitted as a pull request so that it can be deliberated properly, out in the open, over an acceptable time period, with all of the relevant stakeholders.

Guide how spec URIs are registered: solid/specification#141

This issue was prompted by discussion in another issue:

#202 (comment) .

These are some examples I can think of where the decision making of developers "in the wild" is adversely affected by the effect of non disclosure agreements.

Nobody from the forum, afaict, is working on solid-panes. The mashlib has been in a state that has been described as a proof of concept, and clunky. Though I cannot document it, I believe developers have been expecting it to be improved substantially for some time, but it hasn't happened. This is a cause of confusion that is relevant to non-disclosure agreements. Is it being improved for private customers? We don't know.

Another similar example is in the area of data interoperability. Again I can't prove it, but I believe developers on the forum are hanging back and expecting others to lead in this area. If they had more information, especially about what is not getting attention, they would probably be more inclined to pitch in.

As per https://github.com/solid/process/blob/master/panels.md#notifications-panel , we need a repository at https://github.com/solid/notifications-panel

Search terms you've used
https://solidproject.org/ navigation

Is your feature request related to a problem? Please describe.
There are errors on pages like https://solidproject.org/events and https://github.com/solid/solidproject.org/blob/staging/solid-labs.md as well as https://solidproject.org/press (the 2020-06-04 event is presented as "Upcoming" still today). It is impossible to promote the project's web site when it looks like this.

Describe the solution you'd like
The editors in the process need to be notified or keep an eye and be ready to act.

Describe alternatives you've considered
Assign this 'github helpdesk' task to a student, in exchange for a good comment in his/her LinkedIn profile for good professional proactiveness. :-)

Additional context
I need good quality data on the solidproject site for https://gitter.im/cern-solid/community#
Thank you very much!

We are running into disconnects where proposed changes to the solid process arrive as pull requests without traceability back to the original problem that led to the change. Additionally, we lack an accessible place to discuss the issue, or reference discussions about the issue that happened in any virtual or in-person meetings.

I think we should consider a Solid Community Security standard and follow in the footsteps of Inrupt.

To apply to be a Solid panellist, editor, administrator or creator one needs a GitHub account and know how to navigate GitHub enough to submit a pull request.

Because GitHub is a tool with specific professional and geographically distributed users these steps act as filters to the applications.

Submitting a pull request is very public which is good because when the Solid Director approves and application it is possible to refer back to the approval. However, the public nature may also mean applicants hesitate to apply at all.

My proposal is to include a text "If you are interested in applying to become a panellist, editor, administrator or creator then email [email protected] with your CV and motivation letter."

This email can be received by administrators and put forward to the director for review. When the application is reviewed positively one of the administrators can submit a pull request with the directors review to have the benefit of reference.

The thinking behind this design is that we may tap into a wider and more diverse pool of talent.

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.

Creating this issue to track a very legitimate request from @timbl that we represent many of the elements related to solid/process (i.e. panels, editors, projects, panelists, etc.) in linked data form.

While github is currently the primary medium for both storing and rendering this data, there is the potential to continue to use github for storage and versioning, but render some or all of it on webpages (like the new https://www.solidproject.org), so that it is consumable by people not used to reading RDF / turtle directly. We could also move the storage completely over to a solid pod from github for management via solid app, and/or for rendering it on different sites (like https://www.solidproject.org).

Solid Panels are groups of individuals focused on a specific problem or domain relevant to Solid, with an aim to propose changes to the Solid Specification.

The teaching materials panel has a focus that falls outside of the specification proposals and fits more closely into the Creators.

I propose inviting the participants of the teaching material panel to join either the Creators or submit pull requests that the Creators can edit and closing the teaching materials panel.

Phrases like "copyright 2018 - present" have been used in many documents. This is not correct for copyright notices, which require explicit numbers for relevant years.

Also, copyright notices must identify the entity claiming that copyright.

@Mitzi-Laszlo has suggested in the (closed‽) solid-contrib/information#293 that (Inrupt? the ephemeral "Solid"?) "[we] get the view of a professional and adapt all the licenses accordingly so that all repos have a uniform approach". I think that's a fine idea, and am opening this issue to track it.

Solid is a multi-protocol platform. Thus, there is no need for the current "legacy tag" associated with WebID-TLS.

WebID-TLS and WebID-OIDC are protocols supported by Solid.

In the editorial assignments the themes "data portability" and "data interoperability" are separate: https://github.com/solid/process/blob/master/editors.md#data-interoperability

In the panels there is only a theme "data interoperability" however sometimes data portability is discussed.

I propose to change the name of the editorial assignments and panel into "data interoperability and portability" because:

• It clarified which editorial assignment reviews proposals from which panel
• splitting the themes into to panels would mean the panels would be very small and members very similar

The Problem

Solid has grown to a point where it is not clear how to gather all the opinions from all the relevant parties on a specific subject and come to a legitimate route forward. This is particularly pertinent to the Solid specification.

A pattern has developed where suggestions are made in the form of pull requests and issues, conversations grow around these pull requests and issues, there is a general consensus as well as general uncertainty on how to legitimise the outcome. Additionally some conversations have happened via email or other channels, not on pull requests or issues in the Solid GitHub account, meaning that it is difficult to get a complete overview of all the conversations that have taken place.

Uncertainty around how to legitimise a route forward is especially pronounced when there is some difference of opinion. This results in pull requests and issues being left open for years (some date back to 2015).

Decisions are sometimes made by some parties to the point where they are implemented although this is not recorded meaning not all parties have the same understanding.

One part of the puzzle is to gauge an overview of the thoughts (i.e. the opinion of 'the community') the other is around how to decide on a route forward that is accepted as the official route forward to avoid fragmentation.

The question is how to process various opinions and legitimise decisions a wide range of questions around Solid, for example, around the Solid spec?

Conversations

There are several ongoing conversations which have all been concentrated in the culture repository.

There was a W3C call where many individuals who opened pull requests and issues presented them for discuss with minutes on https://www.w3.org/community/solid/wiki/Meetings

There are milestones set up in an attempt to work towards finding a solution:
https://github.com/solid/solid-spec/milestone/2
https://github.com/solid/solid-spec/milestone/1
https://github.com/solid/web-access-control-spec/milestone/1

Proposal

First do others understand and see the problem as explained above and if there are other related problems?

Second, what are our collective fears that we need to address in the process design? Let me start by listing a few that I've heard...

• an overly complicated process resulting in grinding to a halt because of all the bureaucracy
• a too dominant decision making process led by too few people resulting in forking
• no decision making process leading to stagnation through uncertainty
• overrepresentation of one profession leading to unbalanced decision making
• individuals who are not knowledgeable in an area having too strong of a voice in that area
• individuals who do not have skin in the game compromising the position of people who do have skin in the game
• a few bad actors playing the system to their personal advantage
• lack of accountability resulting in responsibilities falling through the cracks and it being unsure who is responsible and how to avoid problems repeating themselves

Third, to put forward a proposal. For example, by closing all pull requests and archiving .md files and milestones related to this conversation except one e.g. https://github.com/solid/information/pull/166/files#diff-898e7f1ceacb493c024554f5a7c87bdf where the final output can be collected, worked on together with all parties involved and submitted it to the Solid Leader for review and final merge.

Thoughts?

Creating this issue to track a comment @Mitzi-Laszlo raised in solid/process#95.

What would be great to include as well is:
the aim/ scope of the specification
the aim/ scope of the roadmap
the aim/ scope of the documentation
the respective repositories to which proposals in the form of pull requests to the specification, roadmap, and documentation should be made
the aim of each repo and how it connects to this process

Am tracking this separately since it would expand quite a bit the scope of the #95 when it's near the end of the review cycle. Any work towards this can go in new branch / pull.

When creating the *-panel repos, what LICENSE should we be using? Most of the code repos in the Solid project use the MIT license. The spec-type repos and the more informal -panel repos probably need something different, like a Creative Commons license or the general W3C license?

This issue is in response of @csarven in #202 (comment)

That's a lot of things to answer :)

• My expection: an open well-oiled community is forming (don't know if that was the intention)
• 'Adequate engagement': if the forum is just seen as supplementary thing for some members, and core members leave their info all over the web, then that probably explains much of that feeling.
  • I think its important for this to be more clearly communicated to the people interacting there!
• Forum: yes, I am also not suggesting having documentation there, but in github (wiki posts could be used for temporary stuff), the forum excels at communication over longer times when not everyone is 'live', and also as an archive of such communication (via search, not on archive.org unfortunately I see)
• Talking anywhere: that fragmentation also makes it harder to find those panels, keep the structure, and have interested outsiders get involved. I think people who are not Solid full-timers need a place to get overview of current status.
• Github/Gitter: as described above my Github is already incredibly crowded. I'd need to add, say 40-50 solid repo's and monitor them, but I'm no full-timer too. Most interested how Solid fits with ActivityPub. Same for gitter which is for real-time chat, mostly for fulltimers, or people that do a quick jump in now and then to ask a question. I'm not going to have a gitter window open all the time.
• Core team on the forum: Yes, when there are relevant, more thorough discussions that can't be handled in a quick chat. But aforementioned chat integration plugin would do the trick probably for you to judge by notifications when that is needed.

Feedback is useful.

It is also useful for expectations to be set around who is responsible for responding to what feedback and what kind of response the person giving feedback can expect from who.

The reason I bring this up is that there is a fair bit of conversation around the approved co-created process.

These conversations are all very theoretical and the current agreement hasn't been implemented yet.

It is impossible to find a process that caters 100% to everyone, we will need to compromise and I am very grateful to everyone who already has.

As Solid Manager, it is really important to me that everyone feels listened to and at the same time want to avoid getting stuck talking about the process in a legalistic way without maintaining a collaborative productive team spirit.

To avoid this scenario it is important that we draw a line underneath the co-created approved process and try it out for a few months/ years/ until there is am major block to avoid getting stuck in an unproductive never ending conversation about process.

@RubenVerborgh has raised some concerns on #64 and #57 and #36 and @justinwb has come up with concrete proposal on how to address them.

Considering it is the first time Solid has such an explicitly written down process and @RubenVerborgh as a member of the MIT academic project and active contributor to Solid you having a good feeling about the process is important I propose we put the three suggestions forward for approval in an exceptional fast track.

In the current approved process there is an explanation of how to submit a process proposal.

To avoid having to fast track and debate further in the coming weeks I propose to add another paragraph as follows:

"The person who starts a process proposal is responsible for actively and publicly sharing it with panels and stakeholders over a minimum time period of one month to gather feedback, which they need to demonstrate incorporating, along with publicly sharing the reasoning for the final result before submitting the process proposal for approval. In the interim the last approved process will be used."

Recently we have worked on ensuring there is no wiki rot as well as labeling the specification repositories, website repositories and non-specification repositories which were giving the working title label of 'experiment'.

Following the conversation in the latest weekly Solid Team meeting, to which you can find the meeting minutes here, I am following up on the action item to identify historical code within the repositories labelled 'experiement'.

Any repositories which have had activity in this year have been excluded from this list.

Below are the repositories that have not have activity since the year stated in the title.

2016

https://github.com/solid/solid-sign-up

https://github.com/solid/solid-zagel

2017

https://github.com/solid/mavo-solid

2019

https://github.com/solid/profile-viewer-tutorial

https://github.com/solid/solid-signup

https://github.com/solid/solid-takeout-import

https://github.com/solid/solid-inbox

https://github.com/solid/solid-tutorial-rdflib.js

https://github.com/solid/solid-architecture

https://github.com/solid/solid-tpf

https://github.com/solid/solid-email

https://github.com/solid/solid-tutorial-pastebin

https://github.com/solid/solid-auth-oidc
https://github.com/solid/solid-web-client

https://github.com/solid/solid-dashboard-ui
https://github.com/solid/solid-profile-ui

https://github.com/solid/solid-multi-rp-client
If any of these repositories above are not historical code i.e. they are being actively used and there is someone responsible for responsible for reacting to issues and pull requests please let me know here.

Below is a list of repositories that have had no activity this year but are still being actively used:

https://github.com/solid/node-solid-ws

https://github.com/solid/data-kitchen

https://github.com/solid/solid-auth-client

https://github.com/solid/solid-client

https://github.com/solid/profile-viewer-react

Can we omit email addresses from panel.md? Perhaps mention our WebIDs instead?

Why not storing data about panels on a Pod like this one https://panels.solid.community/public

Then we could visualize the links between those panels, who is working on with links to the profile, what libs it uses, links to repos, forums...

https://scenaristeur.github.io/spoggy-simple?source=https://panels.solid.community/public
If it's good for you, I can open the right to the public folder so everyone can post data

On #180 there was a conversation about a repo naming system and on #172 there is a repository overview.

There are 117 repositories in github.com/solid and it is not easy for newcomers nor for people working on the repositories for some time to navigate between these repositories in a way that it is crystal clear what is the aim of each of the repositories.

The Process repository was started as an attempt to collectively agree on how to work on specific aims within github.com/solid including: administration of solid properties, standardisation work, and creating and maintaining the website solidproject.org. There are more activities going on in github.com/solid that the three just mentioned.

This is a proposal about how to gain clarity around the aims of the work happening in github.com/solid as well as clarity around who is responsible for what.

There are some repositories that used to fill the functions of the repositories already described here above but are no longer maintained by defined people. The key information needs to be combined with the repositories above and archived to avoid thinning of information and wiki rot.

Solid Research

In the remaining ~50% of the repositories of github.com/solid there are a range of experiments and research on Solid. The aim of governance of the experimental research is not described in the process repository and largely started during the Solid MIT research project and has been picked up by the University of Ghent in more recent years.

Some of the research works on implementing the Solid standard to ensure the proposals are feasible. There is not a defined intention to provide this software as a service to end-users with a defined service provider, although some users do so organically. In particular node solid server is used by many developers as a reference Pod when building Solid applications.

Here are a list of repositories that could be tagged as 'research':

There are various implementations of the Solid specification.

There are various Solid-related libraries mostly being led by Ruben Verborgh.

Folllowing is a list of other Solid research:

• solid-email
• ldp-glob
• test-idp
• solid-takeout-import
• solid-inbox
• kvplus-files
• mavo-solid
• solid-web-client
• solid-notifications
• resource-access
• solid platform
• solid signup

There are a few different chat channels for conversations about Solid that have evolved organically. Here's a shot at looking at mapping the channel purposes and trying to make sure that the content doesn't get diluted over many channels while still allowing for software diversity.

Gitter seems to be used for Solid specification development.

In particular the following channel is a place for all panellists and editors to meet:

• specifcation

There are a few gitter channels for specific panels focused on authoring proposals for the Solid specification.

• security-cryptography-and-privacy
• app-authoriisation-panel
• authentication panel
• data-interoperability-panel

The test suite conversations are also very focused on:

• test-suite

Now there is a channel for the Creators to talk about solid project.org development including documentation for the Solid specification:

• solidproject.org

Until now all the conversation is happening on gitter.

Now we enter the areas where conversations start to double up. In particular there are two main places for Solid conversations: forum.solidproject.org and Solid gitter which are overlapping meaning that that sometimes people interested in the same material are not meeting.

Overlap

There are a few gitter channels talking about solid specification implementation:

• pods
• app development
• chat-app
• node-solid-server
• data browser

There are often doubled up on on https://forum.solidproject.org/categories meaning that all channels are diluted.
Similarly Solid Events conversations are happening on both the forum and gitter

• solid-events

My proposal is to phase out gitter as a place to talk about implementation and focus on solid specification development because it is linked to GitHub where the specification development is happening.

Unknown Purpose

There are a few gitter channels that are already covered including:

• solid-spec now "specification"
• site-and-docs now "solidproject.org"

My proposal is to delete these channels so that the energy gets concentrated into one place unless there are reasons for keeping two channels with the same purpose.

The following chat channels don't have a clearly stated focus at the moment If you use the chat channel regularly and know the focus please do say.

• solid-git
• suggestions
• community
• introductions
• Solid Chat

Although Solid chat seems to be a landing place, I think that solidproject.org should cover a lot of the early questions.

This is really just a first shot on my understanding so please do suggest improvements and let me know if you are using these channels in ways that are not mentioned here.

The test suite is in a separate repository from the specification so it could be interpreted as falling outside of the editorial process.

Although there is a test suite panel, there is no corresponding editorial assignment so it is unclear who would review proposals from the test suite panel.

One solution could be to have an independent group from the editorial process working on the test suite which is based on the specification produced by the editorial process.

There are several panels without editorial assignments including:

• accessibility
• artificial intelligence
• caching
• explaining the vision
• external interoperability and outreach
• internationalisation
• privacy and individuals rights protection
• self hosting
• specification entry document

This means it's unclear which editors would review proposals coming out of these panels.

I propose staring editorial assignments that match these panels or defining which existing editorial assignments would review proposals coming out fo these panels.

I've wrote down my thoughts while reading the various documents of this repository.
First of all, thank you for putting this together! This is great work and I like how it identifies the roles and how one can contribute to the spec.

I have open questions that I believe can help complete the documents. There is no need to answer them directly here, but I feel those needs some kind of answer in the document themselves, or the documents should be updated so they answer them.

These thoughts and questions reflect my view of them as an outsider who only passively followed the project in the past and only start actively contributing in the last weeks.

Panels

• What about "official" panels that cover specific parts of the spec, like OIDC-WebID, to ensure
  1. It collects, aggregate and sends upstream the community issues
  2. The spec keeps on making sense over time (technology changes, etc).
• Is a panel an informal or a formal group of people?

If we put ourselves in the view of a person who just got to know about the Solid project and wants to contribute:

• What conditions makes it so I should be part of a panel?
• What is the incentive of being in a panel, or create one?
• Why can't I just talk to whoever is in charge of a spec section if I have questions about it?

Stakeholders

• The stakeholder listing doesn't have individuals we can reach. I don't think "Solid Community" is helpful to know who to reach to, or how. There should be one person of contact or one front person for any type of org.
• If consulting the stakeholders not mandatory in any process (as far as I can see), why should I care about them?
• Users are "individuals, companies, or organizations" while Implementers are "companies or organizations"
  1. Is not listing individuals for Implementers an omission? or an explict choice?
  2. If choice, why?

Drafting proposals

Submit a pull request or issue on the Solid Specification repository in GitHub"

Shouldn't the link on "Solid Specification" link to the new repo?

"Propose an item for the W3C Solid Community Group call"

How?

"Any proposal must be realistic and reasonable to implement":

This is highly subjective, and not very useful. How should one judge if it is "realistic and reasonable to implement"? Is it a matter of considering all major programming languages? Or something else?

The vote proposal is good, but seems a bit out of place in the document.
Where should this take place? In a PR? In an issue? On Gitter?

Becoming an Editor

• Is the choice of accepting someone as an editor at the sole discretion of the director(s)?
• Are there already known specifics traits/facts to become one that the director will look for? e.g. what should I do before hand to maximise my chances to become one, if I wanted.
• What is the editor responsible for? What MUST they do? What SHOULD they do? What MAY they do? What they SHOULD NOT do? What they MUST NOT do?
• It seems relevant to also have the areas/realms that each editor is competent on, so outsiders know who to go talk to when drafting/presenting proposals.

Overall

It's all very abstract, and the process lacks the concept of "Point of contact". As an outsider contributor, the first and possibly only thing I worry about is who can I reach to for a specific topic, even if that person redirects me to someone else/

Reading the various documents, it feels like Solid is some unreachable entity that is not really human. I think we should humanize the documents a bit more, without changing the process itself.

There are two editorial assignments without corresponding panels: resource access and auditing.

Do any of the existing panels cover the same theme?

If not, I propose starting panels for Resource Access and Auditing so that it is clear who is working on proposals to be reviewed by these editorial assignments.

Currently, the https://github.com/solid/specification repository is top-listed amongst the six most exposed repositories. I think it should't be, as it is not the normative specification, and this creates an expectation that it is. The specification is essentially a draft, work in progress by a panel, and should not have that kind of exposure.

It appears to be that the solid/solid-spec repository still attracts enagement and causing confusion. In order to direct the energy to solid/specification and other relevant Solid repositories, I suggest to archive solid/solid-spec. Archiving the repository will continue to keep all information public while prohibits updates eg files, issues.

If agreed, how to proceed:

• Transfer useful issues to solid/specification or elsewhere.
• Update its README to indicate the freeze/archival.
• ?
• Archive

Including admins and editors for review so there is no oversight or surprises.

Perhaps we could make a naming system for repositories on Solid GitHub so that people, especially newcomers can search and navigate the work going on more easily?

Perhaps the repo overview will come in handy when designing the naming system.

What should be included in the name?

For example, the overarching aim might be helpful to include. Such as:

• Specification_ (includes spec work)
• Tools_ (includes any tools and libraries etc for implementing Solid)
• Implementations_ (apps, Pods, and identity providers as well as other experiments around making user-facing products using Solid)
• Websites_ (includes any website and general information repos)
• Any more?

Question about the roles in the Stakeholders document.

What's the difference between Pod Providers and Identity Providers?
(And which of these do 'solid server implementations' fall under?)

In the editorial assignments the themes "Cryptography" and "Security" are separate: https://github.com/solid/process/blob/master/editors.md#cryptography

In the panels there is only a theme "Cryptography (Signing and Encryption)": https://github.com/solid/process/blob/master/panels.md#cryptography-signing-and-encryption

I propose to have two panels "Cryptography" and "Security" or to merge the editorial assignments into "Cryptography and Security"

I propose to change the name of the editorial assignments and panel into "data interoperability and portability" because it clarifies which editorial assignment reviews proposals from which panel.

The Implementers paragraph reads very weirdly to me: https://github.com/solid/process#implementers. Being open-source and standardized, can't anyone (e.g. individuals or a loose group of friends, and not just 'companies or organizations') choose to implement any part (or all!) of Solid. Also, why explicitly list out 'Identity Provider, Pod Provider, and Application Provider' in the 2nd sentence - i.e. why just those 3, and where are they defined (not in this document anyway)? And the wording of that 2nd sentence seems strange too - i.e. those 3 things sound like 'parts of' a Solid implementation or eco-system, so how can a 'Solid Implementer' be any combination of those 'parts'? Do you mean an Implementer can choose to implement any 'part' of Solid (but if so, isn't that kinda redundant, given the specs are all open-source anyway)...?

There is a record of Solid communication to facilitate co-creation and gather ideas on how to improve.

The current process details how website changes can be suggested and reviewed but lacks a record of other elements of communication such as the newsletter, social media, and the webinar.

Here I would like to invite suggestions around recording these elements of the process.

Describe the bug
If clone the repository on a Mac, I receive the following message:

warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:

  'LICENSE.md'
  'license.md'

As a result, one of the files "wins" is automatically removed or modified.

To Reproduce
Steps to reproduce the behavior:

1. Use a Mac or other operating system that is case-insensitive.
2. Run git clone https://github.com/intuitmike/information.git from a command line.
3. See the error above
4. Run git status and verify that LICENSE.md is modified from git's perspective.

Expected behavior
A clean repo clone, with no errors or changes.

Desktop (please complete the following information):

• OS: MacOs 10.14.6 (Mojave)

At the moment forum.solidproject.org and solidproject.org are hosted on AWS.

As discussed at the Solid Team meeting with minutes on https://www.w3.org/community/solid/wiki/Meetings#2020-07-15 the intention is to move towards a third party hosting provider that is:

• equivalent in price to AWS
• equivalent in service convenience to AWS
• green energy
• hosted legally and physically in Europe to be linked to GDPR without the involvement of "third countries"

Any objections to https://greenhost.net/products/hosting/?

Any suggestions to other solutions that have the criteria mentioned above?

There are several people working on building libraries for Solid and no description of how they should work together in the process repository.

A panel is specifically for making proposals to the Solid specification for editorial review so a panel is not quite adequate.

Possibly a solution would be to have a section in the README of the process similar to solidproject website or test suite that describes the aim and where to list yourself if you choose to work in the Solid GitHub.

For example:

Solid Libraries

Anyone can write a Solid library based on the Solid specification. You can find an overview of Solid libraries in the the libraries repository. Librarians(link to GitHub.com/process/librarians.md) are responsible for keeping the overview of Solid libraries up to date as well as the libraries that can be found in the Solid GitHub account.

The requirement to have a SPARQL-based patch system to the PATCH method, is discussed in solid/specification#125 , but is spawning many different repositories, and also has connections to the W3C SPARQL 1.2 CG.

I think we would have a more focused effort on this topic if we activate the already existing query panel. However, it extends beyond the existing solid-tpf repository, and so, I suggest we add a query-panel repository as encouraged by the current process.

The process was written some months ago and here I would like to invite, particularly the editors to review the process around the specification to make sure that it accurately reflects the day to day implementation of the specification work.

For example, the headings on the specification kanban board seem to be different from the editorial process https://github.com/solid/specification/projects/1