Per-repository roles needed #10
Comments
Right. Now, we have organizational roles that are occupied by a few people, and not reflected in permissions, where the assumption is that people aren't going to use permissions if they have not an understanding with the people with a role. So, we are pretty liberal with the permissions now, but this, I assume, would lead us to where permissions match roles, which again would probably lead us to where we revoke permissions for people who have contributed in the past. It might be a good thing to tighten things a bit, but I don't know if it'll help the community. Perhaps there are other ways? |
One way it will help the community is that questions are targeted at the
right people. I’m often @-mentioned in things out of my control. I can bear
responsibility for solid-auth-client, for instance, but not others.
|
I think it's worth pointing out that in the draft of the community role descriptions that was published several months ago, we took the approach of describing Project Core Contributors, Project Contributors, and Project Release Managers. So, we have existing definitions for project specific teams (i.e. node-solid-server, solid-auth-client) per this issue. I think that the shortcoming is that in the most recent pull request there were no project contributors named, nor any language about why they were not. IMO, we should at least identify some of the higher profile projects (like node-solid-server, solid-auth-client) that are currently under the solid organization and provide some insight on associated team members there. |
Actually, I think we need to define what we mean by "project", "repository", etc. Actually, I didn't have the same understanding, @justinwb , I interpreted "Project" as a very broad thing, like in "Solid Project", and also "Repository" as pretty broad, i.e. github is a repository, npm is a repository. Now, we have github projects and repositories, that we also use operationally, so these terms aren't really that suited. We probably wouldn't want to have per-repo or per-package manager roles either, that would be a manager with a very narrow scope... I think it is better to have "backend manager", "dev tools manager", etc. The backend management role would encompass NSS and solid-project dependencies for example. I still think that we could use a role that is a day-to-day operational role to ensure the coherence of releases where needed though, which is what I have been thinking "Project Release Manager" should be, though we haven't needed to have those functions. And perhaps it is too much for a single person anyway. I think that what I have been performing lately is a "Tech Lead Backend" role, but that's more an Inrupt role than a Solid role. |
I’ll just bring a very narrow perspective, from my own point of view. I’m
the one currently managing solid-auth-client. I’d want clarity such that
either people know that it is my responsibility, or that someone else takes
that reponsibility; i.e., I’d rather not have undocumented reponsibilities,
because that might lead to issues in the future.
As an example, when I was still the de-facto person publishing
node-solid-server, someone else temporarily assumed that reponsibility and
accidentally published three broken releases.
So let’s make it clear, at least for the more important repos, who can
release and publish.
|
What do you think about holacracy https://www.holacracy.org for managing Solid project. |
I have a suggestion on how to resolve this.. Allocate the following roles: node-solid-server Repository Manager: @kjetilk @megoth @justinwb and others, who would be best suited to the following roles? There are some repositories that I feel would benefit from being merged. For example: solid-tutorial-intro, solid-tutorial-angular, solid-tutorial-rdflib.js, profile-viewer-tutorial, understanding-linked-data, solid-tutorial-pastebin, web-summit-2018, intro-to-solid-slides could all merge with resources.md in the community repo. Additionally, releases, solid-architecture, user guide, vocab, solid-namespace, solid-platform, solid-spec, web-access-control-spec, solid-apps, and solid.mit.edu could also potentially merge into the community repo. Perhaps there are similar combinations that could happen with other repos? If there are two people working on the same repo it would be a question of working out who is the manager and therefore responsible for oversight and who is the core contributor. Projects need to be defined in the plan.md of the community repo. Thoughts? |
yes
Only @timbl can do these I think.
Merged? As in, make them one repository?
There could be multiple for more complex repos. |
rdflib is in the linkeddata organization on Github, so might not fall under the work done as part of solid organization on Github. It is a vital package though, so we might want to ask the people at linkeddata to formalize their roles in that repository.
Yes, @timbl is the only one that can do this. He might want to delegate, but that's another discussion. |
Great, so a path forward is to put forward a suggestion of role allocations to Tim as follows: Who would be the repository manager for each of the repositories not mentioned on the list above? Or would they have no repository manger? These include: The following repositories also have no repository manager as of yet, however the content is mentioned in the community repo and they are related to governance processes, so I would be willing to become repository manager candidate for them. |
I think that the fallback is the Project Repository Manager. You could explicitly add me as manager for acl-check though, as it is clearly going to be maintained (unless @timbl wants to be the repo manager for that). |
@kjetilk assuming you mean the Project Release Manager? An alternative to changing the role description as the release manager being the fallback when there is no repository manager would be to list you as the repository manager for all the remaining repositories. Would that work? Perhaps an idea to take the conversation about merging to a different pull request. @megoth would you like to take on some of the repository manager roles? Summarising, here is the latest proposal to conclude this issue to be merged by Tim. mavo-solid, webid-oidc-spec, oidc-auth-manager, solid-multi-rp-client, folder-pane, wac-allow, pane-registry, oidc-rs, keychain, solid-pane, solid-notifications, solid-profile-ui, solid-connections-ui, solid, pane-source, jose, solid-inbox, oidc-op, solid-tif, solid-client, oidc-rp, issue-panes, solid, solid-idp-list, kvplus-files, solid-email, profile-viewer-react, oidc-web, solid-auth-client, solid-sign-up, solid, takeout-import, node-solid-ws, solid-auth-tls, ldflex-playground, query-ldflex, react-components, solid-auth-oidc, meeting-pane, solid-dips, solid-cli, solid-web-client, solid-permissions, acl-check, node-solid-server Repository Manager: @kjetilk solid-auth-client Repository Manager: @RubenVerborgh community, solid-tutorial-intro, solid-tutorial-angular, solid-tutorial-rdflib.js, profile-viewer-tutorial, understanding-linked-data, solid-tutorial-pastebin, web-summit-2018, intro-to-solid-slides, releases, solid-architecture, user guide, vocab, solid-namespace, solid-platform, solid-spec, web-access-control-spec, solid-apps, and solid.mit.edu Repository Manager: @Mitzi-Laszlo solid-panes, solid-ui, mashlib, Repository Manager: @timbl |
Just thinking... is there a particular reason why I'm not the "manager" of the |
Link to specific projects included. Project Release Managers should be explicitly responsible for leading a specific project. @kjetilk Include Project Core Contributor as @megoth Perhaps the Solid Core Contributors should be included as Project Core Contributors instead? As in, if you are not working on a project or managing a repository, what other contributions would you be focusing on? Repositories Manager per repository needs to be updated according to #10 Include a link to Solid Event Organisers individuals
I'd be open to that, @timbl would be the person who ultimately allocates individuals to roles #32 I've started a parallel conversation on information structure which is relevant because vocab and solid-dictionary double up. @csarven and @RubenVerborgh keen to hear your thoughts on how to move forward on this. |
(Also, #31 suggestions for other roles intertwine with this conversation) |
I don't see them as intertwined. vocab has a different purpose than solid-dictionary as far as I can tell. But if that's not the case, why does solid-dictionary exist to begin with? Wouldn't it have been better to contribute to the vocab repo? The purpose of the vocab repo is perhaps best expressed in this comment: solid/vocab#1 (comment) (at least that's pretty close to the reason why I created the repo in the first place). FWIW, at that time, we weren't managing the solid (RDF-based) vocabularies for the servers and apps we were building. We needed a place to have a better handle on what we have and needed.. , as well as to document and reach some consensus. solid-dictionary seems more like a place where components (eg vocabs, protocols) are used or can potentially be used in the "solid world". That's useful in and itself, but I wouldn't conflate them. |
@csarven wrote:
Yeah, that'd be my understanding too. My understanding is that vocab is for RDF, solid-dictionary is for descriptions of terms in prosa, purely intended for human consumption. @Mitzi-Laszlo asked:
Actually, I was thinking that since we started with a single "Repository Manager" role and then got per-repo roles, we'd have an analog to the "Project Release Manager", i.e. "Project Repositories Manager", that would delegate management of certain repos to other people as well as manage repositories that doesn't have one. If it is mostly a fallback role, it could be occupied by the Project Release Manager, as there shouldn't be any important checks and balances between the two. We might be over-engineering the roles a bit, I guess, so I'm open to it. |
I haven't done that much work on repositories outside of node-solid-server, so can't see which I should be a repository manager for. I might take on responsibility for some of the pane-repositories to help offload the work load for @timbl, but in general I think it's better to have him as a repository manager for those (i.e. folder-pane, solid-pane, issue-panes, pane-source, pane-registry). I would also think @RubenVerborgh should be repository manager for the LDflex-related projects (i.e. ldflex-playground and query-ldflex)? I would also think he should be repository manager for react-components? Otherwise it's a bit difficult to get overview of the repositories, as there are so many =P But then again, these roles are not set in stone, and if we find out we did something wrong earlier, it shouldn't be more than a bit of communication and a PR away to fix it ^_^ |
These need me as a repo manager (I fully wrote them): I think this one needs Tim: |
Is this the conclusion we have come to together? webid-oidc-spec, oidc-auth-manager, solid-multi-rp-client, folder-pane, pane-registry, oidc-rs, keychain, solid-pane, solid-notifications, solid-profile-ui, solid-connections-ui, solid, pane-source, jose, solid-inbox, oidc-op, solid-tif, solid-client, oidc-rp, issue-panes, solid-idp-list, kvplus-files, solid-email, oidc-web, solid-sign-up, solid, takeout-import, node-solid-ws, solid-auth-tls, solid-auth-oidc, meeting-pane, solid-dips, solid-cli, solid-web-client, solid-permissions, acl-check, node-solid-server Repository Manager: @kjetilk solid-auth-client, mavo-solid, wac-allow, solid-auth-client, ldflex-playground, query-ldflex, react-components, profile-viewer-react Repository Manager: @RubenVerborgh community, solid-tutorial-intro, solid-tutorial-angular, solid-tutorial-rdflib.js, profile-viewer-tutorial, understanding-linked-data, solid-tutorial-pastebin, web-summit-2018, intro-to-solid-slides, releases, solid-architecture, user guide, solid-namespace, solid-platform, solid-spec, web-access-control-spec, solid-apps, and solid.mit.edu Repository Manager: @Mitzi-Laszlo vocab @csarven solid, solid-panes, solid-ui, mashlib, Repository Manager: @timbl |
Practically, yes, but I think most of the repos I get are just as a fallback, and the person having the fallback role should also have the authority to delegate them to others. |
Updated role descriptions to accurately describe current roles and responsibilities as well as include conclusions from #10
Updated all the information here #44 feel free to comment further on the pull request. |
#9 captures project-wide roles, but doesn't capture things such as:
I think we need per-repository roles for at least the larger repositories, such as node-solid-server, rdflib, solid-panes, solid-ui, mashlib, solid-auth-client.
Also, terminology like "Repository Manager" might then be confusing, because they seem to imply per-repository.
The text was updated successfully, but these errors were encountered: