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.
In theory, it can split organization into circles by group of interest, each circle has a 'reason to be which clarify it , with a 'referent' as 'first link' roles and circles are determined, and mutation of those are regulated in fonction of the needs.

https://communitywiki.org/wiki/DoOcracy ;)

I have a suggestion on how to resolve this..

Allocate the following roles:

node-solid-server Repository Manager: @kjetilk
solid-auth-client Repository Manager: @RubenVerborgh
community Repository Manager: @Mitzi-Laszlo

@megoth @justinwb and others, who would be best suited to the following roles?
rdflib Repository Manager:
solid-panes Repository Manager:
solid-ui Repository Manager:
mashlib Repository Manager:

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?

node-solid-server Repository Manager: @kjetilk
solid-auth-client Repository Manager: @RubenVerborgh
community Repository Manager: @Mitzi-Laszlo

yes

rdflib Repository Manager:
solid-panes Repository Manager:
solid-ui Repository Manager:
mashlib Repository Manager:

Only @timbl can do these I think.

There are some repositories that I feel would benefit from being merged.

Merged? As in, make them one repository?
That's not a good idea for a couple of reasons (I can elaborate), but perhaps I'm misunderstanding?

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.

There could be multiple for more complex repos.

@megoth @justinwb and others, who would be best suited to the following roles?
rdflib Repository Manager:

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.

solid-panes Repository Manager:
solid-ui Repository Manager:
mashlib Repository Manager:

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:
node-solid-server Repository Manager: @kjetilk
solid-auth-client Repository Manager: @RubenVerborgh
community Repository Manager: @Mitzi-Laszlo
solid-panes Repository Manager: @timbl
solid-ui Repository Manager: @timbl
mashlib Repository Manager: @timbl
Any additional suggestions? edits?

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:
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

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.
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
@RubenVerborgh Yes, merged as in take the content and combine them into a logical searchable content in fewer repos. Reason being that as a newbie you could land to community repo to orient and find all governance related material. This would be an orientation before digging into the other repos (a map would be helpful). Curious to hear your thoughts on best way forward.

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 vocab repo? Or more generally, shouldn't the creator of a repo be the "manager" by default (unless of course they don't want that "role"). After all, I've created the vocab repo 3-4 years ago, and have actually worked on and around it.

I'd be open to that, @timbl would be the person who ultimately allocates individuals to roles

https://github.com/solid/community/issues/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, https://github.com/solid/community/pull/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: https://github.com/solid/vocab/issues/1#issuecomment-170134584 (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:

I don't see them as intertwined. vocab has a different purpose than solid-dictionary as far as I can tell.

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:

@kjetilk assuming you mean the Project Release Manager?

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.

@megoth would you like to take on some of the repository manager roles?

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):
mavo-solid
wac-allow
solid-auth-client
ldflex-playground
query-ldflex
react-components
profile-viewer-react

I think this one needs Tim:
solid

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 all the information here https://github.com/solid/community/pull/44 feel free to comment further on the pull request.