Surfacing data about a "Project" entity (examples like Vite, Vitest, Rolldown, Eslint, etc) would make npmx more useful for maintainers and users. We're usually thinking of Open Source Projects, but this data also applies to other types of Projects (that we can now assume are at least maintaining one or more packages).
Projects have repositories, packages, maintainers, resources, releases, sponsors, and relationships with other projects, users, etc. This info is currently spread across several platforms (npm, GitHub, Discord, Notion), each with its own group/team/role definitions that end up diverging, making it very hard to keep them in sync. A lot of the data is just notes in chats/docs/mails, and also in the heads of team members.
A "Project" overlaps with the concept of a "Community". There may be Projects that don't feel like a Community (yet), such as an OSS Solo Project or a Company Project. A Community may also be involved in several projects. But this could be represented as a "Group of Communities" entity, so we could probably keep things simple and consider Project/Community at the same level.
It will take a long time to surface all the Project Data discussed in this issue (and the linked ones). We should do it iteratively, as we will learn while working on the visualizers/admins. We're creating these issues because it is useful to have a high-level overview of the data we can eventually surface for Open Source Projects. We can start discussing each data type in parallel and involve other teams to collaborate.
Implementation
We have already started storing user data (package likes and WIP package collections) in their Atproto PDSs. We're going to use keytrace to know who users are across different platforms from their domain identity (atproto account). We also need to consolidate how we show users (avatar, handle, display name) and using their atproto profile seems to be a good way forward (on hover we could show all the user claims in their profile card: github, npm, etc). We will then have an atproto account for all users who want to interact with npmx (except for seeing public pages).
So we can store Project data directly in users' PDS. The Vite Project is a user of npmx through the vite.dev domain, and we can then store Project data in the vite.dev PDS as records following a Project lexicon.
The Project lexicon may be an amalgam of several other existing shared lexicons (or new ones we create already with others). If we can have conventions around types and values, we can share these lexicons with other apps like Sifa to easily surface badges, memberships, etc in a generic way from data that Open Source Projects expose, but also from other projects, or other communities (that aren't project-oriented, like a book club).
A good starting point (that may be the right abstraction for us) is the work
@brittanyellich has already done on Open Social. Her latest ATMosphereConf talk is a great watch for context: Who owns the chat?. There are really good ideas here. A Project is a User/Account and that simplifies a lot of things. There are roles, permissions, etc.
Useful Project Data
We'll add an initial list of useful data and relationships between entities related to Projects that could be surfaced in npmx as sub-issues. We can use this umbrella issue to discuss the general Project lexicon or alternative implementations.
Surfacing data about a "Project" entity (examples like Vite, Vitest, Rolldown, Eslint, etc) would make npmx more useful for maintainers and users. We're usually thinking of Open Source Projects, but this data also applies to other types of Projects (that we can now assume are at least maintaining one or more packages).
Projects have repositories, packages, maintainers, resources, releases, sponsors, and relationships with other projects, users, etc. This info is currently spread across several platforms (npm, GitHub, Discord, Notion), each with its own group/team/role definitions that end up diverging, making it very hard to keep them in sync. A lot of the data is just notes in chats/docs/mails, and also in the heads of team members.
A "Project" overlaps with the concept of a "Community". There may be Projects that don't feel like a Community (yet), such as an OSS Solo Project or a Company Project. A Community may also be involved in several projects. But this could be represented as a "Group of Communities" entity, so we could probably keep things simple and consider Project/Community at the same level.
It will take a long time to surface all the Project Data discussed in this issue (and the linked ones). We should do it iteratively, as we will learn while working on the visualizers/admins. We're creating these issues because it is useful to have a high-level overview of the data we can eventually surface for Open Source Projects. We can start discussing each data type in parallel and involve other teams to collaborate.
Implementation
We have already started storing user data (package likes and WIP package collections) in their Atproto PDSs. We're going to use keytrace to know who users are across different platforms from their domain identity (atproto account). We also need to consolidate how we show users (avatar, handle, display name) and using their atproto profile seems to be a good way forward (on hover we could show all the user claims in their profile card: github, npm, etc). We will then have an atproto account for all users who want to interact with npmx (except for seeing public pages).
So we can store Project data directly in users' PDS. The Vite Project is a user of npmx through the
vite.devdomain, and we can then store Project data in thevite.devPDS as records following a Project lexicon.The Project lexicon may be an amalgam of several other existing shared lexicons (or new ones we create already with others). If we can have conventions around types and values, we can share these lexicons with other apps like Sifa to easily surface badges, memberships, etc in a generic way from data that Open Source Projects expose, but also from other projects, or other communities (that aren't project-oriented, like a book club).
A good starting point (that may be the right abstraction for us) is the work
@brittanyellich has already done on Open Social. Her latest ATMosphereConf talk is a great watch for context: Who owns the chat?. There are really good ideas here. A Project is a User/Account and that simplifies a lot of things. There are roles, permissions, etc.
Useful Project Data
We'll add an initial list of useful data and relationships between entities related to Projects that could be surfaced in npmx as sub-issues. We can use this umbrella issue to discuss the general Project lexicon or alternative implementations.