# SolidOS Team Meeting

* Date: 11.05.2026 10:00 UTC
* Call: [https://meet.jit.si/solid-operating-system](https://meet.jit.si/solid-operating-system)
* Chat: [https://gitter.im/solidos/solidos](https://gitter.im/solidos/solidos)
* Repository: [https://github.com/solidos/solidos](https://github.com/solidos/solidos)
* Meetings home: [https://solidos.solidcommunity.net/public/SolidOS%20team%20meetings/](https://solidos.solidcommunity.net/public/SolidOS%20team%20meetings/)
----
## Present attendees

- Alain Bourgeois
- Sharon
- Timea
- Noel De Martin
- Michael Peters


### Scribes
* Notion AI meeting notes

## Some links
- current work: Milestone 3m -> new profile design https://github.com/SolidOS/solidos/issues/275
- our project board: https://github.com/orgs/SolidOS/projects/2/views/7
- SolidOS designs: https://www.figma.com/proto/88xQawSSXzfQprEZPaKplZ/Solid-OS?node-id=1101-12533&starting-point-node-id=1101%3A12533&show-proto-sidebar=1

## Topics

### Intro

This was a spontaneous organized meeting to get to know Michael and to align with the team on how we will work moving forward. The following notes are only about the technical aspects we got to discuss. We did not finish the topics, therefore we will continue tomorrow more or less the same time. We will be discussion Web-Components.

### Action Items

### Debugging Approach Discussion

Sharon explained the current debugging implementation, which includes multiple log levels (log, warning, error) and can be toggled on/off in different environments   . The implementation was created after Copilot review suggested the previous console.log approach wasn't functional .

**Team perspectives on debugging:**

- Noel expressed strong preference against extensive debug logging, arguing developers already have debugging tools (browser dev tools, breakpoints) and that many logs make it difficult to find useful information  . Noel advocated for specific exception classes instead and smart UI error handling
- Michael noted that debug logs help developers unfamiliar with the repository troubleshoot issues by examining console output
- Michael mentioned the `debug` npm package which allows scoped debugging via session storage
- Timea found Sharon's implementation "too much" with multiple levels and activation methods, concerned about scalability across all repositories

**Consensus reached:**

The team agreed to simplify the debugging approach significantly, removing log levels and local storage configuration . Sharon's implementation currently only has debug logs around mutations in edit dialogues (about six dialogues total)  .

### Error Handling Strategy

**Current approach in ContactsPane:**

Timea demonstrated the error handling pattern used in ContactsPane  :

- Catch errors at the most basic level where they occur
- Log detailed error messages for developers (including stack trace)
- Throw user-friendly error messages for the UI
- UI catches and rewrites messages for end users (e.g., "Unable to update your profile picture. If this problem persists, please contact your admin")

**Best practices discussed:**

- Noel recommended using the `cause` property in error constructor to maintain complete stack traces across error boundaries
- Noel shared approach from personal apps: throw user-friendly errors with a "View Details" button to show stack trace in UI, making errors accessible even on mobile devices where console isn't available
- Team agreed on progressive disclosure of error information - show simple message by default with option to view technical details

**Decision:**

Team will adopt [ContactsPane's error handling pattern](https://github.com/SolidOS/contacts-pane/blob/437ce1e5402a4d85fd41e3ee1cf25393e0eb878d/src/mugshotGallery.js#L58) for ProfilePane, with potential future enhancements for mobile developer experience and dedicated Solid error classes   

### ESCO Integration for Skills

Sharon explained ESCO (European skills/organizations/languages database) and the challenge that many common skills (like React, Vue) aren't included in ESCO's catalog   .

**Solution implemented:**

Created a system allowing both ESCO-linked skills and custom skills  :

- ESCO skills use named nodes with full URIs (e.g., skill/[long ID])
- Custom skills use blank nodes (identified by underscore prefix) that link to a name
- Combo box allows selecting from ESCO list or entering custom text

**Alternative approaches discussed:**

- Noel suggested using string literals instead of blank nodes for simplicity
- Michael proposed blank IDs could serve as anchors for future standardization, allowing collection of user-created skills to potentially submit back to ESCO
- Sharon explained difficulty of creating global catalog - simultaneous entries would create different IDs in different pods

**Technical considerations:**

- Current implementation maintains existing data structure to avoid requiring data migration
- Blank nodes vs. named nodes are distinguishable (blank nodes use underscore prefix, ESCO uses skill/ prefix)
- Noel noted irony of using "publicID" property for blank nodes

**Data model concerns:**

- Team acknowledged need for future data model improvements and potential user data migrations
- Suggestion to make publicID optional and use only schema:name for non-ESCO skills
- Team agreed to create ticket for future consideration but not change data model in current iteration

### Technical Details

**Current ProfilePane data structure:**

Skills are stored with both schema:name and publicID properties . ESCO skills use named nodes linking to ESCO URIs, while custom skills use blank nodes  .

**Mobile layout issue:**

Standalone version has correct section ordering with bio first, but SolidOS integration shows incorrect order on mobile   . Team confirmed only requirement is heading/bio must be first, other sections can be in any order  .

### Next Steps

Team ran significantly over the scheduled 30-minute time, reaching about 2 hours . Web components discussion was deferred to potential follow-up meeting  .

Michael requested guidance on priorities and what to focus on next after reviewing PRs  .


----
This template is based on the [W3C meeting template](https://github.com/solid/specification/blob/main/meetings/template.md)

[Code of conduct](https://github.com/solid/process/blob/main/code-of-conduct.md)

