solid / team Goto Github PK
View Code? Open in Web Editor NEWLicense: MIT License
License: MIT License
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.
https://solidproject.solidcommunity.net could be used for the follow up
https://solidweb.me could be used to test the apps
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?
Two action items assigned to Jackson in minutes:
@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).
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:
Code of Conduct Committee
Creators
DIET
Editors
Panels
System Operators
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?.
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:
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:
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.
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.
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.
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
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.
The list of assets on this repository shows:
Accout | Link | Administrators |
---|---|---|
X | https://twitter.com/project_solid | Kelly O'Brien |
https://www.reddit.com/r/SOLID/ | Melvin Carvalho, Arne Hassel, et al. | |
Vimeo | https://vimeo.com/solidworld/ | Kelly O'Brien |
Forum | https://forum.solidproject.org/ | Oz Olivo (also: Justin Bingham) |
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.
Make sure to streamline this brand new list (#33) to:
Will work on this the week of June 7
Issue: solid/solidproject.org#248
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?
There are a few places where I think we should update the logo:
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)
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.
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.
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]
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.
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.
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?
Needs to be changed on:
If not already, clarify somewhere that all repositories under the GitHub solid
organisation use the Solid Code of Conduct.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.