As discussed in the meeting, here are the updates to the team memberships. This is a jumping off point. Feel free to comment if you think any of the suggestions should be different.

Administrators:

• Currently: @justinwb , @timbl , @bourgeoa , @timea-solid , @MarrelleBailey, @jaxoncreed
• Suggestion: Remove @MarrelleBailey (no longer works closely with Solid)

Code of Conduct Committee

• Currently: @csarven , @bourgeoa , @VirginiaBalseiro
• Suggestion: Add @oolivo to Code of Conduct Committee

Creators

• Currently @Vinnl , @kay-kim , @KyraAssaad , @VirginiaBalseiro , @jeff-zucker, @TallTed
• Suggestion: There may be future suggestions proposed by @jeff-zucker

DIET

• Currently @csarven , @KyraAssaad , @Hindia , @VirginiaBalseiro , @ewingson , @jeff-zucker , @MarrelleBailey
• Suggestion: Remove @MarrelleBailey (no longer works closely with Solid)

Editors

• Currently @kjetilk , @csarven , @barath , @RubenVerborgh , @dmitrizagidulin , @timbl
• Suggestion: No Change

Panels

• Currently Many members depending on panel membership
• Suggestion Let eat panel decide membership

System Operators

• @michielbdejong , @ericprud , @bourgeoa
• Suggestion: Add @jaxoncreed and @justin and change the name of this team to "solidcommunity.net maintainers"

I have put together a report about the situation of Solid World (SW), past discussion, decisions that were made, and where we stand today.

The following is a timeline of the discussions around Solid World in the Solid Team (ST) over 2 years:

Despite all this history and recent discussion and agreements, the 2023-09 SW event was unilaterally decided (by the ST member currently assigned to SW organization) to be organized as a private company event, without running it by the ST (or even informing us). This is, in my opinion, a blatant display of disregard for collaborative decision-making and a deviation from the principles of transparency and openness that we have been advocating for.

Since we have decided and re-confirmed on multiple ocassions that we want to keep SW as a ST event, also in line with Tim's wishes, I believe we should have another organizer replacing the currently assigned, since they've not communicated or collaborated with the ST on this subject. And more importantly, ignoring a decision made by the ST and going directly against it, unilaterally and without informing the ST, is in my personal opinion a serious violation of process and trust.

Furthermore, I have personally reached out to the assigned member to offer help with these tasks and my message went ignored.

As it has been discussed numerous times, if an organization would like to contribute to the organization of the event, and that is very much appreciated, they can do so in collaboration with another member of the ST who would like to volunteer to help. We can even ask the community at large for more volunteers.

PROPOSAL:

• Make a wider public call to assemble a new organization team for Solid World - "for the community by the community" - towards resolving solid/process#321

If not already, clarify somewhere that all repositories under the GitHub solid organisation use the Solid Code of Conduct.

• Get approval of the suggested name (Proposed Twitter Handle: TheSolidProject)
• Reach out to Twitter for the name
• Get approval from Twitter, make an announcement via Forum, Twitter and other social channels

• Ensure the updated privacy statement is ready to go
• Provision a discourse account
• Update discourse to latest version
• Schedule maintenance window - post a notice in the forum that we'll be doing a migration
• During maintenance window - backup forum and restore on discourse.org
• Add new privacy notice
• Setup sticky banner pointing to new privacy notice
• Follow up on original thread asking how GDPR is handled in the forum

This can be two separate discussions but keeping together for now: for the sake of transparency and openness, I think team meetings and chat should be open to everyone.

We could perhaps make the meetings listen-only for non-members (with maybe a dedicated portion for questions?), and the chat could be read-only for non-members as well.

Two action items assigned to Jackson in minutes:

• 2023-06-14
• 2023-07-19

@oolivo has responded on the Team chat that the people with access are administrators: https://github.com/solid/process/blob/main/administrators.md

4/6 members of administrators are either former or inactive team members (see #44). In addition, other members of the Team need access to these accounts for their tasks (see scope: #39)

PROPOSAL: all members of the Solid Team (see updated list: https://github.com/solid/team/pull/39/files#diff-7519aafe48e2ca696efec05f9bba9c9037718d4b4f9f9f032a666af5f9a3bc84) should have access to read emails directed to these email accounts.

Until this is resolved and all members of this team have access to those accounts, we should not include any references to [email protected] on the website. I will write it out of the pages where it is used and give alternative means of communication (mostly GitHub since it's the only one we all can see).

Make sure to streamline this brand new list (#33) to:

• process readme links (https://github.com/solid/process) like https://github.com/solid/process/blob/main/system-operators.md
• on website: https://solidproject.org/team
  And whatever place is needed. (If you find a file/list not updated please let us know)
• on SolidOS contacts

https://gitter.im/solid/team?at=620542df1fe6ba5a971b6b58

Actually there is an automatic snapshot taken by digitalOcean, but no process to restore one or more pod's from this snapshot
We had a user that deleted all his pod content by a recursive delete including root. This a NSS mistake and resolved.

You still can delete all your content or a full folder content, It should be nice to have a restore process for a folder.

Needs to be changed on:

• Twitter - @MarrelleBailey
• This Month in Solid newsletter - @MarrelleBailey
• Solid Forums - @justinwb
• Solid Gitter - @justinwb

Hi All,

As discussed in the last Solid team meeting, I'm cleaning up the Solid App (https://solidproject.org/apps) page.

I've created notes for each app listed here (https://docs.google.com/spreadsheets/d/1p0opUBL0vRpEdNzDuB8mVy5XTrAbhSdMIzytqn-ef-M/edit?usp=sharing), and I've reached out to each of the developers to alert them of their app's status.

Apps were evaluated based on the criteria listed at the bottom of the apps page (https://solidproject.org/apps). The criteria for an app to be Solid-compatible are:

1. If identifying users is necessary, they must be able to login using their WebID and pointing to the Identity Provider of their choice
2. Data consumed by the app should be fetched from Solid Pods if possible
3. Data generated by the app should be stored in Solid Pods
4. The interaction between the app, pods, and Identity Provider(s) must be compliant with the Solid specification

Based on this, I sorted the apps into 4 categories:

Super Feature
Super Featured apps will be listed at the top of the "Featured" category. Each of these apps is compatible with both the Old authentication standard, the new authentication standard, and the new-new (2022) authentication standard. Developers of super featured apps received the following in their email:

Your app, {App Name}, is fantastic and I’m going to move it into the featured section.

Feature
Featured apps were compatible with at least one authentication standard but not all, and they had a usable UI that would give a decent first-impression for people exploring Solid for the first time. Developers of featured apps received the following in their email:

Your app, {App Name}, may not work on the most recent version of Solid's auth. Upgrading to https://www.npmjs.com/package/@inrupt/solid-client-authn-browser should make it compatible, and you can test to see if it works by logging into the next-gen community server at https://solidweb.me.

Keep
Apps labeled keep were compatible with at least one authentication standard but not all. Developers of "keep" apps received the following in their email:

Your app, {App Name}, may not work on the most recent version of Solid's auth. Upgrading to https://www.npmjs.com/package/@inrupt/solid-client-authn-browser should make it compatible, and you can test to see if it works by logging into the next-gen community server at https://solidweb.me.

Remove
Apps marked as "Remove" either failed to meet the criteria listed on the apps site in some way or the criteria was un-testable. There were a few standard reasons for this, and I was sure to stress that the decision could be disputed before the page was updated.

Some apps didn't have an option to log in with other Solid servers and forced users into a specific server, thus violating rule 1. Developers received this message in their email:

Your app, {App Name}, may be Solid compatible, but there is no option to log into other Solid compatible Pods, so I’m planning on removing it from the list. You can always reach out to me and tell me if I’m wrong in that assessment. I’ll be happy to add it back.

Some apps encountered errors when testing that prevented me from testing rules 2-4. Developers received this message in their email:

In my testing, your app, {App Name}, encountered some problems that prevented me from being able to use it. {Describe the Error} I am planning on removing it from the list. You can always fix the problem or let me know if I’m incorrect. I’ll be glad to add them back.

Some apps were not Solid-Specific apps. They may have been linked-data related but lacked the ability to work with a Solid Pod. Alternatively, a few were simply landing pages for an organization and not apps. Developers received this message in their email:

Your app, {App Name}, doesn’t look like it’s a Solid-specific app, so I’m planning on removing it from the list. You can always reach out to me and tell me if I’m wrong in that assessment. I’ll be happy to add it back.

Some apps were not able to authenticate with any Solid server. Developers received this message in their email:

Your app, {App Name}, encountered an error while authenticating with any Solid server, including legacy ones, so I’m planning on removing it from the list. You can always fix the problem or let me know if I’m incorrect. I’ll be glad to add them back.

Some apps linked to sites that did not load. Developers received this in their email:

Your app, {App Name}, doesn’t seem to load, so I’m planning on removing it from the list. You can always fix the problem or let me know if I’m incorrect. I’ll be glad to add them back.

Some apps did not have a deployed instance and required a user to clone a git repository and host the app locally. This prevented the app from being tested. Though, this criteria was appealed and instead of removing these apps, I'll now add them to a new section called "Self-Installed." Developers received this in their email:

Your app, {App Name}, doesn’t have a deployed instance, so I’m planning on removing it from the list. You can always create a deployed instance and contact me, and I’ll be glad to add them back.

Today's solid-team meeting has decided an action on this subject.
@ewingson I proposed you be part of this.

The purpose of this issue is to organise the follow up and support to migrate solid apps from legacy to DPoP authorization.

The main tasks could be

1. apps Inventory.
   • First basis from Aad Versteden https://bourgeoa.solidcommunity.net/public/todo/solid%20auth%20migration.html
   • should include https://solidproject.org/developers/tools/
2. prepare a small paper explaining the change and the motivation for migration
   • DPoP is replacing legacy
   • library https://github.com/inrupt/solid-client-authn-js
3. make a small list of examples
   • https://github.com/0dataapp/helloworld/solid/
   • mediakraken, penny, SolidOS webApp
   • getting a cookie see https://github.com/jeff-zucker/solid-node-client
4. contact the authors to explain the change (create issue with links to point 3. and 4.)
5. make the follow up (reminders)

Pod ressources

https://solidproject.solidcommunity.net could be used for the follow up
https://solidweb.me could be used to test the apps

As dog food

• @jeff-zucker or @theRealImy could we have a ui-elements app for the follow up ?
  The app will link : author - app - auth status - follow history
• @timbl could the tracker pane be used for that kind of project

There are a few places where I think we should update the logo:

1. GitHub
2. Twitter
3. Gitter? (Unless that automatically pulls from GitHub)
4. Forum

I don't think we need to update it on the website, as it seems to be the most common practice to only do it on social sites and not the actual website (see https://www.verizon.com/ and https://twitter.com/verizon)

There are some on-going discussions (Document decision-making based on consensus, Guidance for content translations, Scope of the Solid Team, Should Solid Team meetings and chat be open/public?, Better definition of "Solid Team" and "Solid Project") that will affect the team's processes.

I propose that we create a centralized resource (e.g. something like solid/team/process or solid/process/solid-team) where we describe the processes of the team. This should make it transparent for ourselves and others how we proceed in various circumstances.

I propose that I create a PR with some suggestions on this, and we can take it from there. (I'll make sure that the PR doesn't conflict with anything at https://github.com/solid/process.)

This can be a huge undertaking, and spawn a number of discussions, and I want to proceed cautiously and mindful of others opinions. For now, I simply want to announce my intention of doing this work, and ask for feedback.

Are there more resources that I should be aware of?

• Determine the categories we need
• Organize the parent and subcategories
• Write a note and implement the new structure

Please use this issue to discuss which ontologies and terms we should use for storing and displaying solid process information about the Team. See also Solid People to RDF : What to display or store? for discussion on what data we want. Here's my preliminary example of a Team member record.

@prefix  foaf:   <http://xmlns.com/foaf/0.1/> .
@prefix  org:    <https://www.w3.org/ns/org#> .
@prefix  solid:  <http://www.w3.org/ns/solid/terms#> .
@prefix  vcard:  <http://www.w3.org/2006/vcard/ns#> .
@prefix  dbo:    <http://dbpedia.org/ontology/>.
@prefix  dbp:    <http://dbpedia.org/page/>.
@prefix  gitter: <https://gitter.im/solid/> .
@prefix  forum:  <https://forum.solidproject.org/> .
@prefix  tbd:    <http://example.com/> .

<https://marrelleb.inrupt.net/profile/card#me">

    a foaf:Person ;
    foaf:name "Marrelle Bailey" ;
    foaf:nick "Marrelle" ;
    solid:preferredSubjectPronoun "she";
    solid:preferredObjectPronoun "her";
    dbo:locationCountry dbp:United_States ;
    foaf:thumbnail <https://avatars.githubusercontent.com/u/66318176?v=4> ;
    foaf:account 
        [ foaf:accountServiceHomepage github: ;
          foaf:accountName "MarrelleBailey" ;
          foaf:homepage github:MarrelleBailey
        ] ,
        [ foaf:accountServiceHomepage forum: ;
          foaf:accountName "@MarrelleB" ;
        ] ,
        [ foaf:accountServiceHomepage gitter:chat ;
          foaf:accountName "@MarrelleBailey" ;
        ] .
    foaf:weblog <TBD-get-Marrelle's-blog-address> ;
    org:memberOf  tbd:Administrators, tbd:DEI-Board, tbd:DEI-Team ;

    foaf:workplaceHomepage <https://inrupt.com> ;
    org:holds [ org:postin ex:Inrupt ]; 
    #
    # AND/OR schema:worksFor OR  schema:affiliation ?

    # there's no "biography" term I can find, maybe schema:description ?
    #
    vcard:note """
        Marrelle Bailey is the moderator for Solid World and works on managing
        the Solid Team projects. She is also the lead chair for the Diversity,
        Equity, and Inclusion Team for the Solid Community. She works at Inrupt
        as the Community & Communications Organizer.
    """ .

[edit : added foaf:Person]
[edit : correct postin syntax]

• Agree that the target location is the Forum (tentatively discussed need official confirmation) – Action item done by: by May 7, 2021

• What notice needs to be given – Decided no later than the end of Solid Team Meeting May 12, 2021

• Notice to the community

• Get approval from the Solid Team

• Actually write and post a note to the community – Determined during the Solid Team Meeting

• Do the transfer of the applications

I don't think the work of individual team members should always be reviewed by the entire team.

I think we could become more productive as a team if we would all try to be more Zen about other team members doing work.

When you see another team member "doing something wrong", try to resist the knee-jerk reaction to call them out and hold them responsible. Instead, try to be curious and find out why that other team member did something in a way that was unexpected to you. You might learn from it, and you leave both yourself and the other person in a positive vibe where we all contribute instead of getting into debates.

This is obviously hard to do, and sure, important decisions need more pairs of eyes on them, and no single team member should run off in a direction that they can reasonably know that other team members would do very differently. We all try to work in the context of the team, and for the team's goal, never for individual goals. And peer review is definitely useful to increase the quality of everybody's work.

But the ideal of always reaching a "committee consensus" on every action, which we sometimes seem to aim for, is actually a dystopia in which nothing gets done and all actions are blocked by discussions.

Even with these caveats, when I brought this up in the team chat though, it seemed not everybody agreed, so let's have a discussion about it.

If team member Alice is doing work and team member Bob is not, but Bob is just pointing out the mistakes that Alice is making, and questioning whether all Alice's work is based on team-wide consensus or not, there is a real risk that Alice's enthusiasm will be smothered in discussions.

I think our team's output would be many times greater if we would just all try to be Alices more often, and be Bobs less often. :)

Let's try to be a team where everybody feels empowered to contribute and the whole is bigger than the parts, instead of a team where every action is preceded by a consensus meeting and followed by a review and a retrospective.

• Overview of current pages we have
• Perform a user test on the site map complete within 2 weeks
• Create a PoC of the revamp site
• Presentation to the Team
• Get approval from the team
• Set date for roll-out
• Execute/Roll out the new site

The list of assets on this repository shows:

We have discussed this in meetings, and it seems the consensus is we don't want to control the Reddit account.

For the remaining accounts, the administrators listed are mostly inactive members. We need to decide if we want to keep the X/Twitter accounts, but until we do so, we need the whole Team to have access to these accounts and/or come up with a process for how these accounts are managed.

Will work on this the week of June 7

Issue: solid/solidproject.org#248

Listed below is the current third-party applications that have access to the team. We'd love to clean these up. Could the people would enabled this third-party access chime in with what the access is used for and if the integration can be removed?

• Travis CI for Open Source: @deiu
• Gitter Public Repo Access: @dmitrizagidulin
• Gitter Webhooks: @dmitrizagidulin
• ZenHub: @dmitrizagidulin
• Slack: @dmitrizagidulin
• Coveralls: @dan-f
• Coveralls Pro: @deiu
• Docker Hub Registry: @deiu
• Snyk: @dmitrizagidulin
• Sourcerer: @RubenVerborgh
• Gitter Private Repo Access: @justinwb
• GitKracken: @megoth
• Docker Hub Builder: @michielbdejong
• Travis CI: @RubenVerborgh
• Zenodo: @RubenVerborgh
• LifeScope: @timbl
• Codecov: @RubenVerborgh

After we complete the scope-defining process, we should cycle back to the definition of "Solid Team" to reflect the scope we decide on. See the discussion at #37.

A confounding issue do we have three entities? The website (solidproject.org), an open source initiative (The Solid Project), and a team which facilitates that initiative (The Solid Team). However we split it up, the Team manages more than the website.

• Write update the application page to explain the new process
• Update the page with the specific applications

Please use this issue to discuss which of the fields for Solid Team members shown in the card below should be a) stored for our querying and/or b) displayed to users on sp.org either required or optional and also to discuss appearance formatting here. See also Solid People to RDF : Which ontologies?.

There’s been a lot of discussion around what the scope and responsibilities of the Solid Team are. In the meeting on April 19th, members of the Solid team will meet to decide what the scope is.

The point of this exercise is to define what is in the jurisdiction of the Solid team. Based on this we can begin efforts to find resources for and complete the items we determine are in our jurisdiction.

To prepare for the meeting, we can use this thread to propose potential areas of responsibility for the team, as well as other ideas.

I’ll list some I’ve heard below, and I'll include actions that the Solid team currently does as well as actions that we might do. Feel free to add comments of your own. If there is a specific proposal you want to put forward mark it with a “Proposal:” header.

• https://matrix.to/#/#solid:converser.eu has 1996+ people
• https://matrix.to/#/#solid_chat:gitter.im has 72+ people
• https://matrix.to/#/#_w3c_#solid:matrix.org has 9+ people
• https://matrix.to/#/#solid_specification:gitter.im has 227+ people and is now considered the main channel for the CG, but at the same time I think this is because it's about specs and the CG is supposed to be only about specs.

So in the context of the CG I'll point people to https://matrix.to/#/#solid_specification:gitter.im but in the context of the Solid Project as a whole we should still point people to https://matrix.to/#/#solid:converser.eu probably?

Action of https://github.com/solid/team/blob/main/meetings/2022-04-13.md#community-contributions-to-translate-content

People in the Solid community would like to make content translations. We should provide a guide on how they can contribute.

While content translations is useful across the project, it is particularly welcomed for Solid specifications ( see https://github.com/solid/specification/blob/main/CONTRIBUTING.md#translations ). We can call for contributions elsewhere.

• What can/should be translated?
• How can people find out what's called for?
• ...

As per Responsibilities (https://github.com/solid/team/pull/39/files#diff-7519aafe48e2ca696efec05f9bba9c9037718d4b4f9f9f032a666af5f9a3bc84):

Solid Team members must attend Solid Team meetings on a semi-regular basis. They are also expected to participate in Solid Team activities to some degree.

And Membership (https://github.com/solid/team/pull/39/files#diff-7519aafe48e2ca696efec05f9bba9c9037718d4b4f9f9f032a666af5f9a3bc84):

Solid Team Members may also be expelled by the Solid Director, by Team decision, or may resign.

Some individuals listed on the members list have been inactive for quite some time, haven't attended meetings or engaged in chat, some for well over a year or more. Tagging the following team members to re-confirm their commitment.

If there is interest to continue being a member of the Solid Team, please state in what capacity you will engage and which tasks you will be carrying out. If you're unable to attend meetings for whatever reason, please state so as well.

If no response, inactive members will be removed from the team by 30/01/2024.

• Kay Kim @kay-kim
• Kelly O'Brien @InruptKelly
• Justin Bingham @justinwb
• Kjetil Kjernsmo @kjetilk
• Nicolas Seydoux @NSeydoux
• Barath Raghavan @barath
• Dmitri Zagidulin @dmitrizagidulin
• Vincent Tunru @Vinnl

• Determine a date for change
• Notify the community about the changes on various channels (Forum, Twitter, Gitter, and possibly LinkedIn)

On 3 October 2022, we (Solid Team) needed to update the solidproject.org domain name registration, and were not able to do so well, due to a lack of effective password management (through 1Password or otherwise).

On 11 May 2023, the banner of the project_solid Twitter account needed to be updated, and again, it was not clear who was able to action this.

On Thursday we ran into a situation again where we wanted to update who the project_solid Twitter/X account follows, and in the end we needed to go through various people to get this actioned.

If there still is a 1Password account then let's make sure the right people (can be a subset of Solid Team) have access to it.
If the 1Password account that we used for this in the past has expired or needs payment, then let's renew it.

And as a follow-up once this is done, if we notice any assets that fall under the Solid Team's responsibility are not manageable through the 1Password account, then let's make sure we add them.

See also solid/process#308 where it seems this problem was partially addressed but apparently not resolved entirely.