Skip to content

2022-07-13.md

Latest commit

 

History

History
117 lines (99 loc) · 8.47 KB

2022-07-13.md

File metadata and controls

117 lines (99 loc) · 8.47 KB

Solid Project: Solid Team

Present

Announcements

Meeting Recordings and Transcripts

  • No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
  • Join the queue to talk.

Participation and Code of Conduct

Scribes

  • Jackson Morgan & Timea Turdean

Topics

Apps Evaluation

URL: #28

  • Sarven: I disagree with the pseudo-actions. There should not be app removals from a list without following a publicly documented (and agreed) criteria/policy in place.
  • Sarven: Contacting app developers individually in private especially for open source software projects also doesn't look good. Contact them at their community project site/repo.
  • Sarven: Doing basic "reviewing" with next to nothing documentation or understanding of the apps or the scenario in which the review took place or even how one can reproduce the issue that they may have run into does not constitute removal of the apps.
  • Sarven: Similarly, we don't need to add apps to the list unless they meet a certain criteria. I'm not arguing about the exact checks here that's necessary for addition or removal, or even if they need to be the same.
  • Sarven: And removal without PRs and so on... that's a non-starter.
  • JM:
    • criteria 1) change: login must be available with Solid (with at least 1 Solid Pod - except with all).
    • I created multiple categories
      • 1 super feature - compatible with all Pod providers and pretty good UI.
        • I send out emails to those devs telling them that their App will be featured.
        • we do not have a list of project emails so I emailed devs. Does anyone know a list of such emails? (action item was created)
      • a feature - good looking UI not compatible with every server
        • i sent a message that they should upgrade their apps
      • keep - less impressive but still work
        • they received also an email asking for upgrading
      • 4th category was removes for different reasons
        • Reason 1: the app forces you to sign in with ONLY one dedicated Pod provider which goes against the idea of having a choice.
        • they got emails that it is planned to be removed and we ask for a response in case the evaluation was wrong
        • Jeff: I wonder if they should be removed or just mention a category of 'not ready for prime time'
        • JM: only 2 apps were like that from which one might have already been updated.
        • JM: We can create a separate category for that. I simply sent an email with an alert.
        • Other reason: some Apps were not Solid specific apps -> were just landing pages talking about plans to make Solid Apps or Linked Data pages but no apps.
        • Reason 2: Some apps were not able to authenticate with no server at all with different errors.
        • Reason 3: Some did not load at all
        • Reason 4: Some apps did not have deployed instances, only linked to GitHub repos. -> it would be better to have a dedicated section for such apps. (further testing if they violate any Solid values is hard)
  • direct reply to Sarven's concerns:
    • we see these reason as publicly documented criteria
    • we contacted the devs for now since we do not have a project email (best email found was used)
    • Apps were NOT removed but it is planned. They can contradict.
    • Removal without PRs was always the plan!
  • Timea: all sounds good to me, I like the idea of keeping up with Solid principles.
  • JM: the issue was that there was no public issue. So we should make one and include the criteria. This might be slower in the future.
  • Timea: great work! Let's make a public issue and ask for feedback. For now the process is underway so it is all good.
  • Tim: for our retrospective, to point to any action is always better.
  • JM: I will post on that issue, the list of issues, decisions on all apps, and info if people get back to me with a response. Let's say after 2 week or so I will make the PR to update the app!
  • Timea: YES!
  • Tim: how about a form for the apps?
  • JM: it would be nice to have the apps in Turtle.
  • Jeff: It is fairly simple with solid-ui. If Timea helps me on the ontology part we can have it easy done.
  • Timea: this is a subtask on the solidifying the solid project website.

ACTION:

  • Look at the apps page on the forum for the official email
  • Ask Sarven if he knows of an official location
  • Open a public issue with Apps removal/inclusion criteria
  • Jackson will post on that issue, the list of issues, decisions on all apps, and info if people get back to me with a response. Let's say after 2 week or so I will make the PR to update the app!

Moving SolidCommunity to CSS

URL: solid/solidcommunity.net#62 (comment)

  • Timea: We want to be sure the front end for mashlib doesn't break. We need a testing environment with the 2 flavors of CSS configuration. We need two ports on solidcommunity.net. Ports 3000 and 3100.
  • it would be easier to have the same file system, not to create new accounts.
  • Timea: Going through the issue overview:
    • Things considered blockers preventing Mashlib from working were actually configuration problems.
    • The additional ports would really help with the testing infrastructure. We'll loop back to see if work needs to be done on that.
    • How do you make CSS immediately installable when you clone MashLib.
    • We've been talking about the username password problem.
    • And the latest problem is CSS Updating a turtle file do not use relative notation nor use any @prefix: CommunitySolidServer/CommunitySolidServer#1366
      • Tim: This is a concern because of data migration. You have a meeting with a chat so a lot of the links are in the same Pod, or same document and it is shorter to use a prefix. If I take a whole test setup and copy all files to another Pod, they will still link to the old location because of this issue.
      • Jeff: CSS creates a lot resource as https://...food.ttl#food1 -> if I copy that file somewhere else it will be broken. If it would be a relative URL it would not be broken.
      • Tim: when you make a reference to a file you need the whole filename.
      • JM: is it a blocker for migration?
      • Jeff: a file that I created does not have a .meta
      • JM: so it is not a blocker for migration. Jeff: I would have a hard time to migrate knowing it will break.
      • Tim: it is a secondary way to link files to urls. Rdflib does not care about the space it cares about the files.
    • Timea: There are 2 issues for migration:
      • How to handle username and password
      • How to handle relative paths
      • Timea: I will keep discussing on this topics in different forums (SolidOS team and in between the 1 month Soldi Team meetings)
    • Timea: What is the plan of moving to CSS?
      • When do we want it to happen?
      • We need a deadline and more otherwise this will not happen
      • JM: who can take responsibility: password pb, running migration... I have the tech knowhow but it is a large task so I cannot devote to it without contracting agreement. If there is funding it would be great!
      • Tim: it keeps the system more maintainable and does not mean new features
      • Timea: true but it is necessary for the progress of Solid.
  • Timea: thank you for staying overtime on this topic. I just wanted to mention there is a plan and I am trying to keep up to date the plan and keep us aligned. Keep the discussion flowing and assess what is needed to continue.