Design meeting June 29th

Topics to review Notes from meeting Site Settings & Admin Capabilities I presented the work on site settings. We agreed that giving admins more in-place control — site identity (logo, cover image), navigation, member list management, etc. — is the right direction. Based on this, I'll prioritize the create site flow next, since it will help clarify and define the site settings more concretely. Look and Feel We raised a question about our Seed's current look and feel, which increasingly resembles a "site." We need to confirm whether this is the direction we want to keep pursuing, if yes we need to optimize it, ie: adding the option to add a hero cover on the homepage with an intro. Site Settings User Story We discussed the site settings user story in detail — specifically what fields and options an admin should define when creating or managing a site. Product Alignment A key takeaway was the need for more internal alignment on what our product actually does and who it's for. There's a risk that our current, more philosophical view of the product doesn't fully match real user needs. To address this, I'm working on a Product Definition WIP to help ground the team. Next Steps Getting this internal alignment and a clear product foundation is essential so the whole team can move in the same direction.

Design meeting July 21st

Topics to review Notes

Meeting Iskaak and Horacio Identity and create site

Identity Create site

Meeting Gabo and Horacio August 11th

Meeting notes: Create site: Query blocks / embed Workshops to be done Inspiration to check Buzz

Unreferenced documents behaviour

In several scenarios, the system creates unreferenced documents at the bottom of the document. These documents appear without any context or explanation, making it unclear to users where they came from, why they were created, or what they are expected to do with them. Since users are not informed or guided when these documents are created, the experience feels confusing and unpredictable. Some scenarios that might create a unreferenced document: All these scenarios are responding with a unreferenced document. My believe is that we need to "fix" the source first and not create a unreferenced document as a solution. Examples: From Horacio and Bea conversation in Discord: H: Para que un documento NO SALGA en unreferenced documents, DOS cosas tienen que pasar: normalmente la primera cosa pasa bien, pero la segunda, por cualquier error, falla B: Claro, entonces me das la razón, hay que trabajar en la segunda (la actualizacion del contenido del nuevo padre (puerta de entrada) y minimizar/eliminar el error, no crear el parche de unreferenced no? H: Lo que pasa es que hay casos en el que dos podria fallar sin control nuestro, y de todas formas tenemos que gestionar el unreferenced document. pero si. tenemos que minimizar que 2 falle y si falla, explicarlo bien

Permissions meeting

✅ By default we include child documents so remove the check box ✅ Review the label of the members (no suscriber). Un public just writers in Public ? Show this, somewhere when the user has access to the parent which can not revoke the access to child documents How do we explain this to the user This is how is today(people tab): Turn doc. privacy You can invite private space with link???? TBD Space privacy: You can not make a private doc. from private space public BUT you can turn a private space ➡ Public and select what you want to keep private.