# SolidOS Team Meeting * Date: 20.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 - Noel De Martin - Timbl joined later ### Scribes * turboscribe.ai ## 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 ### Action Items No situation review in this meeting. - [x] Sharon to finalize mobile layout fixes in profile pane - [x] Sharon to go through all copilot review comments in solid panes PR - [x] Sharon to review and perfect projects section - [x] Sharon to test and verify all mobile improvements - [x] Sharon to move button components back into profile pane temporarily - [ ] Timea to review all tickets in ProfilePane and provide feedback - [x] Timea to work with Sharon on photo capture dialogue and add to contacts button - [x] Noel and Michael to work together on SolidUI web components, focusing on both behavioral (solid-specific) and design system components - [x] Noel to take lead on web components implementation - [x] Noel and Michael to create one component (button or select) using new approach with storybook as proof of concept - [x] Noel and Michael to review and address issues in PR comments - [x] Noel and Michael to update SolidUI code structure as they see fit, with freedom to decide approach - [ ] Noel to create the first reusable Solid Web Component (not specific to Solid UI) - [x] Michael to support with accessibility improvements - [x] Michael to complete accessibility ticket on ProfilePane - [ ] Michael to optionally explore browser HTML improvements in Meshlib - [ ] Michael to consider working on [friends page (social pane)](https://github.com/SolidOS/solid-panes/tree/main/src/social) design implementation later - [x] Alain to look into updating dependencies for SolidUI, profile pane, and solid panes - [ ] Team to discuss with Jeff about migration path if significant changes are made to [his web components](https://github.com/SolidOS/solid-web-components) library - [ ] Team to ask designer about icon set preference (Lucide vs alternatives) - [ ] Team to decide on [open source font](https://matrix.to/#/!wAfwwonbRnRLYejFOR:gitter.im/$wjQHKNd2JbSEVJ5bER0Q-pNtmrjvDiHTCQxE7TngRFM?via=gitter.im&via=matrix.org&via=chat.semantic.works) from three suggestions and have designer update Figma designs - [ ] Team to add conventions and guidelines document to Git repository, possibly in SolidUI - Started a ticket https://github.com/SolidOS/solidos/issues/288 - [ ] Alain and Michael to replace Inrupt OIDC client with Uvdsl Solid OIDC client https://github.com/SolidOS/solid-logic/issues/274 - [ ] Alain to create `staging` branches on SolidOS repos ### Timea items for the Technical Discussions #### Feedback Design: user logged in viewing sommeone else's profile * design: https://www.figma.com/proto/88xQawSSXzfQprEZPaKplZ/Solid-OS?node-id=1990-8367&starting-point-node-id=1990%3A8367&show-proto-sidebar=1 * Timea: I would expect that when I look at the logged in profile - the only thing different is that there is no tab buttons but the new row of buttons from the designer. * The consequence of the new design is: * you always have the main details of the person you are viewing on top (logged in user or not) And than the pane open. So: profile-pane would start with Bio. * From my point of view, this makes it clearer who is looking at what. Our solution, currently, is the small tab buttons on top. Which we all agreed is not enough. * So the question is: Having the new menu row (Profile-Storage (Dashboard) - Friends) under the Person's card, does it make it explicit to which profile you are viewing? #### Decision on font * Free fonts that share the modern, clean, and geometric-grotesk style of Neue Einstellung include Inter, Questrial, and Satoshi. These alternatives offer similar Swiss-style design, high readability, and a neutral aesthetic suitable for both headers and body text. Inter https://fonts.google.com/specimen/Inter Questrial https://fonts.google.com/specimen/Questrial?preview.script=Latn and Satoshi https://www.fontshare.com/?q=Satoshi * Pls select your options in poll: https://docs.google.com/forms/d/e/1FAIpQLScw0tly6TpCqkRFUKfUy-534n6O_aq2KBrZ1H-6L26FILob_w/viewform?usp=sharing&ouid=116915067443610453109 ---- # AI transcript Final Overall Summary ===================== The meeting focused heavily on improving SolidOS architecture, development workflow, UI/UX consistency, and repository management practices. Major themes included: - **Reusable web components and interoperability** - Noel presented ongoing work on reusable Solid web components using Lit and modern web component patterns. - A major architectural concern is decoupling authentication and global state management from SolidOS-specific implementations (`solid-logic`) so components can work across projects. - **Dependency and infrastructure updates** - Alain updated dependencies across major repositories and began replacing the Inrupt OIDC client. - Compatibility with multiple Solid server implementations and development environments remains an important concern. - **Mobile development/testing** - Sharon completed major work on mobile dialogues and successfully configured Cloudflare tunnelling for live phone testing. - The team agreed that, for now, browser device emulation is sufficient instead of full live-device localhost testing. - **Branching, staging, and deployment workflow** - The group extensively discussed transitioning away from massive long-lived PRs toward: - Small granular PRs, - Staging branches, - Frequent deployments, - Automated test deployments. - Consensus formed around: - Creating `staging` branches, - Keeping staging releasable at all times, - Encouraging small independently-reviewable work items. - **UI/UX discussion around profiles and navigation** - The team debated the distinction between: - The logged-in user, - The currently viewed profile/URL. - They identified UX confusion caused by mixing: - Personal navigation, - Viewed-profile navigation, - Sidebar duplication. - No final UX decision was reached. - **Fonts and design system** - Participants reviewed open-source font options including Satoshi and Inter. - Voting was deferred asynchronously. - **Tooling and security** - Noel proposed eventually migrating from npm to PNPM because of: - Better dependency caching, - Faster installs, - Improved protection against malicious post-install scripts. - **Team collaboration improvements** - Sharon committed to creating smaller PRs with ticket references. - Noel agreed to help review them. - Alain committed to creating staging branches from `main` across repositories. Overall, the meeting reflected a transition from experimental development toward a more scalable, collaborative engineering workflow with improved architecture, deployment practices, and contributor coordination. Detailed Technical Discussion Summary ===================================== Part 1 ------ - **\[00:00 - 00:30\] Introduction and meeting structure** - Alain opened the meeting by explaining that several technical questions raised by Timea would be discussed. - The meeting would begin with a roundtable update from participants, followed by a review of action items. - **\[00:31 - 03:11\] Noel’s progress on reusable Solid web components** - Noel explained he had been working on reusable web components. - The previous week, he created a simple UI-only button component with multiple styles. - Current work focused on “solid reusable components” intended to remain independent from Solid UI while still integrating with it. - He described the complexity of building a “solid account component,” responsible for: - Login/signup buttons, - User avatar display, - Authentication flows, - Dialogues and modals. - Noel emphasized the challenge of implementing these components using the new web component paradigm. - He planned to share a first prototype version the following day. - A major unresolved architectural issue concerned authentication handling: - Current authentication relies on `solid-logic`, which is tightly coupled to SolidOS/Solid UI. - If components are intended for external reuse, authentication and RDF store access must become interoperable across projects. - Noel referenced ongoing discussions with Angelo and other teams also building web components. - He proposed using interfaces/abstractions so that future authentication or global state systems could be swapped without rewriting all components. - **\[03:12 - 03:15\] Alain questions dependency on solid-logic** - Alain asked whether the components could function solely with `solid-logic`. - **\[03:17 - 04:43\] Noel explains interoperability concerns** - Noel clarified that `solid-logic` is a SolidOS-specific package and not a general-purpose solution. - He explained that different projects currently implement login/authentication differently: - Angelo’s approach, - Jeff’s web components, - SolidOS using `solid-logic`. - For interoperability, all components must either: - Share the same authentication mechanism, - Or at least share the same global data/storage location. - Noel reiterated that abstraction layers/interfaces would minimize future rewrites once standards emerge. - **\[04:49 - 07:10\] Alain’s dependency and OIDC client updates** - Alain reported updating dependencies for: - Solid-ui, - profile-pane, - solid-panes - mashlib. - He introduced an updated RDFlib version containing recent commits. - Updates were pushed to: - solid-logic, - pane-registry. - Alain and Michael began replacing the Inrupt OIDC client with the UVDSL OIDC client. - He raised concerns about compatibility with existing npm start scripts across repositories. - Alain initially feared a “service worker” HTTPS restriction issue, but clarified it was actually a “web worker.” - He wanted to ensure: - Development over HTTP remained possible, - Existing deployments behind reverse proxies/engines would not break. - **\[07:12 - 07:34\] Noel comments on HTTPS concerns** - Noel explained browser-side HTTPS enforcement should not affect backend HTTP infrastructure behind proxies. - However, local development over HTTP could still become problematic. - **\[07:35 - 08:35\] Alain discusses remaining RDF and server compatibility work** - Alain noted additional RDF-related work remained because Angelo had pushed more commits. - He intended to test the new OIDC implementation across: - NSS, - Pivot/CSS. - He emphasized NSS differs because it does not rely on static assets. - Goal: ensure no regressions or compatibility issues. - **\[08:36 - 10:08\] Sharon’s mobile dialogue and Cloudflare tunnel work** - Sharon explained she had been working on mobile dialogues. - She spent time configuring Cloudflare tunnelling so localhost could be accessed from a physical phone via a purchased domain. - She reported: - The system generally worked well, - But occasionally became unstable, - Rebuilding/restarting environments slowed development. - Despite that, she was satisfied with the current state of the mobile dialogues and only needed final styling touches. - **\[10:08 - 10:29\] Test server refresh coordination** - Sharon asked Alain whether he could create/update a test server that day and again the following day after she completed her work. - Alain confirmed it was easy and only took about 10 minutes. - **\[10:30 - 10:48\] Sharon schedules follow-up deployment** - Sharon agreed to notify Alain after pushing the completed mobile work. - **\[10:50 - 11:08\] Transition to action items** - Alain suggested moving from roundtable updates to reviewing action items. - **\[11:10 - 12:38\] Sharon reviews completed action items** - Sharon confirmed: - Major mobile issues were resolved, - Remaining work was minor styling. - She also: - Addressed review comments in the Solid Pains PR, - Fixed section styles in the projects section, - Confirmed some tasks could be closed. - They decided not to remove buttons because Lit was now being used. - Sharon mentioned the photo capture dialogue task had likely already been completed. - **\[12:42 - 14:30\] Noel reviews architecture/action items** - Noel suggested marking several generic architectural tasks as completed because decisions had already been made: - Separate component types, - Lit/web component direction, - Initial simple component implementation. - He noted: - The button component PR existed, - Review comments had already been addressed. - Noel proposed adding a new task: - “Create the first reusable solid web component.” - **\[14:31 - 15:09\] Accessibility and dependency update discussion** - Alain clarified that accessibility improvements by Michael were ongoing support tasks rather than finite tasks. - Alain also confirmed dependency updates had been completed. - **\[15:11 - 15:40\] Remaining open tasks** - Alain noted: - Discussion with Jeff remained pending until the May 26 meeting. - Questions around icons and preferences remained unresolved. - **\[15:42 - 16:38\] Fonts, conventions, and OIDC migration** - Sharon believed icon decisions were mostly resolved around Lucide icons. - Alain mentioned: - Open-source font decisions would be discussed in technical topics, - A conventions/guidelines document still needed work. - Alain also added a task to replace the Inrupt OIDC client. --- Part 2 ------ - **\[16:39 - 16:54\] Clarification about conventions and guidelines documentation** - Noel asked what was meant by adding a “conventions and guidelines” document. - He interpreted it as documenting coding standards and architectural decisions such as: - Using Lit for web components, - Development conventions. - **\[16:55 - 17:05\] Sharon begins documenting conventions** - Sharon explained she had already started creating a ticket/document containing remembered conventions and practices. - She asked whether she should share it with the group. - **\[17:06 - 17:10\] Noel requests integration into action items** - Noel suggested adding the document link directly into the action items list. - **\[17:11 - 17:22\] Sharon struggles editing HackMD** - Sharon noted she could not edit the HackMD document directly and offered to share the link via chat instead. - **\[17:23 - 17:38\] Editing permissions discussion** - Alain suggested Sharon might need to log in to edit HackMD. - Noel added she could also be in “view mode” instead of “edit mode.” - **\[17:53 - 18:18\] Sharon explains current state of the draft** - Sharon described the conventions document as an incomplete collection of remembered ideas. - She envisioned it becoming collaborative, with everyone contributing. - **\[18:27 - 18:34\] Sharon gains editing access** - Sharon confirmed she could now edit HackMD successfully. - **\[19:08 - 19:33\] Linking tickets and action item review** - Alain asked Sharon to link relevant tickets. - He then asked if anyone wanted to add further action items before moving to technical discussions. - **\[19:34 - 20:13\] Discussion about “staging” branch naming** - Noel confirmed he had already added his action item. - Alain revisited the earlier technical meeting outcome regarding branch naming. - He asked whether the agreed name was “stage” or “staging.” - The group confirmed “staging.” - **\[20:16 - 20:35\] AI meeting transcription feedback** - Alain asked whether participants were satisfied with the AI-generated meeting summary/scribing. - Noel said he skimmed it and found it acceptable. - Sharon also said the level of detail looked good. - **\[20:36 - 20:50\] Transition into technical discussion** - Alain proposed moving into the technical discussion topics submitted by Timea. - **\[20:53 - 21:04\] Sharon offers to share UI design** - Sharon asked whether screen sharing the design mockups would help facilitate discussion. - **\[21:05 - 22:05\] Alain asks about purpose of redesigned pane** - Alain admitted he did not fully understand the purpose of the proposed pane redesign and asked for clarification. - **\[22:06 - 22:44\] Sharon explains redesign changes** - Sharon described how: - The “follow” functionality had moved, - The header now occupied the full width. - She liked the updated flow visually. - However, she raised concerns about how tabs would behave on mobile devices. - **\[22:47 - 22:57\] Noel comments on sidebar behavior** - Noel suggested tabs might remain visible while the sidebar becomes collapsible or hidden on mobile. - **\[23:00 - 23:14\] Sharon explains profile navigation** - Sharon demonstrated how users could navigate between: - Profile, - Dashboard, - Friends sections. - **\[23:16 - 23:37\] Alain questions profile representation** - Alain asked whether the displayed profile represented: - The browser URL target, - Or the currently logged-in user. - He emphasized the distinction between: - Viewing someone else’s pod/profile, - Being logged into one’s own pod. - **\[23:40 - 24:03\] Sharon clarifies viewed vs logged-in user** - Sharon explained: - The main profile displayed is the viewed user, - The sidebar/account area represents the logged-in user. - **\[24:09 - 24:42\] Noel critiques sidebar UX** - Noel found the sidebar confusing because: - It mixed personal navigation with viewing another person’s profile, - There were no breadcrumbs or contextual indicators. - He suggested removing or simplifying the sidebar in such contexts. - **\[24:44 - 25:33\] Mobile sidebar behavior discussion** - Alain noted the sidebar disappears on mobile. - Noel clarified it should ideally be hidden behind a button rather than removed entirely. - Noel argued users viewing someone else’s profile should perhaps not simultaneously see all their own personal navigation links. - **\[25:36 - 26:08\] Sharon proposes conditional dropdown behavior** - Sharon suggested: - The user dropdown/menu could relocate depending on whether users view their own or another person’s profile. - She recalled earlier UI versions behaved differently. - **\[26:42 - 26:55\] Alain comments on performance** - Alain remarked that SolidCommunity.net still felt slow despite recent server-side improvements. - **\[27:01 - 27:15\] Sharon questions access to personal sections** - Sharon worried that removing parts of the menu might make it harder to access: - Friends, - Storage, - Personal sections. - **\[27:15 - 28:35\] Tim joins and receives context** - Tim joined late. - Alain summarized the ongoing discussion: - Distinguishing between: - Browser URL/profile currently viewed, - Logged-in user context. - Alain explained the UX dilemma: - Users can browse profiles they do not own, - Yet still access their own data/navigation from the sidebar. - He invited Noel to further explain the issue. --- Part 3 (timestamps adjusted by +28:35) -------------------------------------- - **\[28:35 - 28:37\] Noel explains navigation interaction** - Noel briefly described how users click menu items to view corresponding content. - **\[28:37 - 28:56\] Alain explains original multi-pod concept** - Alain explained the broader design goal: - Allow multiple pods/accounts to coexist in the same environment without changing browser URLs. - He suggested the logged-in user’s identity should perhaps appear at the top of the sidebar to clarify context. - **\[28:59 - 29:02\] Noel clarifies sidebar placement** - Noel interpreted Alain’s suggestion as placing the logged-in identity above navigation items. - **\[29:03 - 29:26\] Sidebar location discussion** - Alain continued discussing where the logged-in user’s name should appear. - Sharon reopened the relevant design view for reference. - **\[29:28 - 29:51\] Logged-in username placement** - Alain noted that earlier mockups showed the logged-in user’s name at the bottom of the sidebar. - He proposed moving it to the top for clarity. - **\[30:28 - 30:36\] Tim comments on standard UI conventions** - Tim argued that common UI conventions place: - The logged-in user’s avatar/name in the top-right corner, - With a dropdown menu for account-specific actions. - **\[30:37 - 32:58\] Tim explains distinction between user identity and viewed content** - Tim described how users typically: - Start from their own profile, - Then navigate through linked entities such as: - Contacts, - Projects, - Meetings, - Other users. - He stressed that once navigation progresses, content no longer represents the logged-in user. - Tim questioned the wording “My Dashboard,” preferring “Your” as historically used in SolidOS. - He also noted “my” becomes ambiguous in AI contexts. - **\[33:05 - 33:30\] Noel agrees wording may need reverting** - Noel agreed that restoring “Your” instead of “My” could reduce confusion. - He reiterated that displaying both: - The logged-in user menu, - Another user’s profile, - On the same screen remains conceptually confusing. - **\[33:31 - 33:39\] Tim proposes moving account controls** - Tim suggested placing personal-account controls beneath the avatar/profile section. - **\[33:42 - 33:46\] Noel agrees with avatar-linked placement** - Noel agreed controls logically belong beneath the user avatar. - **\[33:51 - 34:15\] Discussion of previous implementations** - Noel recalled older UI versions behaved similarly. - He speculated changes may have been motivated by planned multi-account support. - **\[34:15 - 34:17\] Tim asks about multiple-account support** - Tim requested clarification about what “multiple accounts” meant. - **\[34:21 - 34:47\] Noel explains planned account switching** - Noel described intended support for multiple simultaneous profiles/logins similar to Google account switching. - **\[34:53 - 34:56\] Alain questions implementation status** - Alain asked whether this feature actually existed yet. - **\[34:59 - 35:14\] Noel clarifies feature likely unimplemented** - Noel said he believed the idea existed conceptually but had not yet been implemented. - He did not know whether the designer independently introduced the UI change. - **\[35:28 - 35:31\] Tim notes designer absence** - Tim observed the designer was not present to explain reasoning. - **\[35:45 - 35:58\] Alain asks for conclusions** - Alain asked whether the group could conclude anything actionable from the discussion. - **\[36:02 - 36:08\] Noel seeks group opinion** - Noel directly asked whether others also found the simultaneous display confusing. - **\[36:10 - 36:20\] Alain says he is accustomed to it** - Alain admitted he personally no longer found it confusing because he was used to the interface. - **\[36:24 - 36:29\] Noel proposes gathering more feedback** - Noel suggested broader feedback from others, including Timea. - **\[36:30 - 36:56\] Alain reflects on Timea’s understanding** - Alain believed Timea only recently realized the system simultaneously represents: - Browser URL/profile, - Logged-in user identity. - He personally considered the approach efficient. - **\[37:07 - 37:16\] Tim clarifies sidebar semantics** - Tim confirmed the left sidebar represented the logged-in user’s resources and actions. - **\[37:18 - 37:57\] Sharon prefers keeping viewed-profile navigation separate** - Sharon preferred: - Keeping viewed-profile navigation tabs in the main content/header area, - Rather than duplicating them into the sidebar. - She felt adding more sidebar menus would create clutter. - **\[37:58 - 38:01\] Tim confirms interpretation** - Tim summarized: - Sidebar = logged-in user, - Main profile section = currently viewed user/profile. - **\[38:04 - 38:35\] Sharon discusses duplication problem** - Sharon pointed out duplication occurs when viewing one’s own profile because: - Both sidebar and profile tabs expose similar navigation. - She suggested tabs might disappear when users view themselves. - **\[38:42 - 39:00\] Noel considers adaptive layouts** - Noel acknowledged layouts could adapt depending on whether users view themselves or others. - **\[39:01 - 39:07\] Alain notes editing permissions differ** - Alain emphasized own-profile views should differ because editing permissions become available. - **\[39:20 - 40:56\] Tim raises project/group-account editing use case** - Tim introduced another UX case: - Project/group accounts with shared write access. - He described scenarios where project members can collaboratively edit a project profile through group permissions. - He asked whether this collaborative model should be encouraged and reflected in the UX. - **\[40:58 - 41:00\] Noel supports shared project editing** - Noel agreed collaborative project editing made sense. - **\[41:06 - 41:16\] Sharon wonders how projects fit into UI** - Sharon speculated project identities might appear in the same profile-navigation areas. - **\[41:16 - 42:16\] Noel distinguishes permissions from identity** - Noel clarified: - Having edit permissions does not mean users are logged in “as” the project. - He revisited duplication concerns: - Sidebar links vs profile tabs. - He proposed: - Reducing sidebar links to a single “Your Profile” entry, - Then exposing tabs within profiles themselves. - **\[42:19 - 42:26\] Tim asks about dashboard meaning** - Tim asked what “My Dashboard” actually contains. - **\[42:29 - 42:40\] Sharon explains current interpretation** - Sharon believed: - “My Dashboard” referred to personal content, - “All files” referred to storage. - **\[42:44 - 42:51\] Alain clarifies dashboard contains preferences/type indexes** - Alain corrected that “dashboard” currently mainly exposes: - Preferences, - Type indexes, - Public/private settings. - **\[42:53 - 43:07\] Tim categorizes type indexes as personal data** - Tim agreed those are effectively “my stuff.” - **\[43:07 - 44:51\] Alain concludes design discussion remains unresolved** - Alain said the designer’s proposal had not yet been fully discussed. - The group lacked consensus on desired UX behavior. - He proposed moving to the next technical topic: - Font selection. - **\[44:51 - 45:12\] Font selection discussion begins** - Alain explained there was a poll with three proposed fonts. - He mentioned links were available in HackMD and Matrix chat. - **\[45:16 - 45:23\] Tim asks where the poll is located** - Alain reiterated that links had been posted in Matrix and the chat. - **\[45:32 - 45:38\] Alain expresses no strong preference** - Alain personally did not strongly prefer any of the candidate fonts. - **\[45:49 - 46:10\] Alain reposts poll links** - Alain again shared the voting links and explained the HackMD contained references to all three font options. --- Part 4 (timestamps adjusted by +28:35) -------------------------------------- - **\[46:15 - 46:22\] Tim confirms poll location** - Tim verified the poll existed in the SolidOS Matrix space. - **\[46:30 - 46:41\] Alain reposts vote link** - Alain stated he had also placed the vote link directly into the meeting chat. - **\[47:00 - 47:01\] Tim asks about font preferences** - Tim asked participants whether they preferred any particular font. - **\[47:18 - 47:35\] Noel comments on font aesthetics** - Noel said he was undecided between two fonts. - He disliked one font because it appeared too square and preferred a friendlier style. - **\[47:39 - 48:03\] Sharon compares Satoshi and Inter** - Sharon said she personally liked the “Satoshi” font. - She also thought “Inter” looked good. - She appreciated Inter’s preview because it displayed more words/examples, making evaluation easier. - **\[48:05 - 48:34\] Tim prioritizes open-source licensing** - Tim said he did not strongly care which font was selected as long as it was free/open-source. - He apologized and announced he had another meeting to attend. - **\[48:36 - 48:41\] Alain says voting can continue later** - Alain reassured Tim that voting was not urgent and could happen asynchronously. - **\[48:50 - 49:03\] Tim leaves the meeting** - Tim apologized again and exited the call. - **\[49:06 - 49:23\] Meeting wrap-up on fonts** - Sharon wished Tim a good day. - Alain proposed ending the font discussion and letting everyone vote independently. - Noel agreed. - **\[49:25 - 49:34\] Alain asks for final discussion topics** - Alain asked whether anyone wanted to add anything before ending the recording. - **\[49:35 - 49:51\] Noel introduces PNPM discussion** - Noel asked whether others knew about PNPM, an alternative package manager to npm. - **\[49:52 - 49:53\] Alain says he only heard of it** - Alain replied he had heard of PNPM but never used it. - **\[49:55 - 50:15\] Noel asks whether migration would be acceptable** - Noel asked whether Alain had any objections to potentially adopting PNPM. - Alain said he was open to changing habits if necessary. - **\[50:17 - 52:20\] Noel explains PNPM advantages** - Noel described PNPM’s dependency caching: - Shared dependencies across projects are downloaded only once. - Benefits included: - Faster installs, - Better efficiency in multi-project environments. - Noel also raised recent npm security concerns: - npm post-install scripts can automatically execute arbitrary code. - He explained malicious packages had recently exploited this behavior. - PNPM improves safety because: - It asks users to approve install scripts, - Rather than running all scripts automatically. - **\[52:22 - 52:28\] Alain asks about multi-repository compatibility** - Alain questioned whether PNPM would work smoothly with their many simultaneously-open repositories. - **\[52:31 - 52:53\] Alain explains current multi-repo workflow** - Alain described working with many repositories together in a single Visual Studio workspace. - **\[52:53 - 53:27\] Noel explains migration implications** - Noel clarified PNPM behaves very similarly to npm. - Main change: - Replace `package-lock.json` with `pnpm-lock.yaml`. - Commands remain nearly identical: - `pnpm install`, - `pnpm run dev`, - etc. - **\[53:27 - 53:32\] Alain asks about coexistence with npm** - Alain asked whether npm and PNPM could coexist in the same repository. - **\[53:33 - 53:56\] Noel explains only one lockfile should be used** - Noel explained projects generally commit to one package manager because lockfile formats differ. - **\[53:58 - 54:21\] Alain remains open to team decision** - Alain reiterated he would follow whichever tooling direction the team chose. - **\[54:23 - 54:32\] Noel asks Sharon about PNPM familiarity** - Noel asked Sharon whether she had used PNPM before. - **\[54:32 - 54:48\] Sharon says she is unfamiliar but flexible** - Sharon said she had never heard of PNPM. - She trusted Noel’s judgment and was willing to learn whatever tooling the team selected. - **\[54:49 - 54:53\] Noel postpones decision** - Noel said he would revisit the PNPM discussion once the new branch structure was in place. - **\[54:54 - 55:26\] Sharon requests PR reviews** - Sharon said she planned to: - Open smaller branches and PRs, - Include ticket numbers in commits. - She asked Noel whether he could review PRs because Timea seemed overloaded. - **\[55:26 - 55:36\] Noel agrees to review small PRs** - Noel agreed, especially if PRs remain small and manageable. - He noted large current PRs are difficult to review effectively. - **\[55:37 - 55:42\] Sharon thanks Noel** - Sharon thanked Noel for helping with reviews. - **\[55:42 - 55:47\] Noel explains GitHub review workflow** - Noel reminded Sharon she could explicitly request him as a reviewer when opening PRs. - **\[55:48 - 55:49\] Sharon acknowledges** - Sharon thanked him again. - **\[55:49 - 56:11\] Alain proposes creating staging branches** - Alain asked whether the team should begin creating staging branches immediately. - He proposed creating staging branches from the latest `main` branch across repositories. - **\[56:12 - 56:13\] Sharon approves** - Sharon thanked Alain for handling the staging setup. - **\[56:15 - 56:26\] Meeting closure** - Alain officially closed the meeting and wished everyone a good day. - Sharon thanked Noel again for rebasing help. - Noel replied that she was welcome. 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) Overall, the meeting reflected a transition from experimental development toward a more scalable, collaborative engineering workflow with improved architecture, deployment practices, and contributor coordination. 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)