Individuals in roles #9
Conversation
|
Repository Manager and Project Release Manager are not project-wide but repository-specific. I expect different names for, for instance, node-solid-server and solid-auth-client. |
Actually, we decided way back (an eariler Boston meeting) that we'd have one, thus the "project". Then have several "release managers", as needed down the road. But yeah, we might already be at the point, I think it makes to divide up on frontend and backend soon at least. |
|
Mmm that doesn't sound aligned with current practice. Do we want to change current practice then? Or do we want to reconsider? In any case, the name "Repository Manager" suggests per-repository, so we might want to change that. But I personally think it makes a lot of sense that one person releases node-solid-server and another solid-auth-client, as we are currently doing. That is working fine, so I'd be in favor of putting the current practice (that we have tested) into guidelines as opposed to changing current practice to match guidelines (that we haven't tested). Maybe we need to discuss this internally. |
The thinking we had around this was that the Project Release Manager doesn't necessarily make all the releases, they merely need to stay on top of the things that happen to ensure coherence. So, on one hand, I haven't managed to stay on top of everything, but OTOH, it doesn't conflict with how we are doing it now, as the PRM simply needs to have people that they trust to do releases, and that is enforced with privileges to do so. So, as a management role, it mostly kicks in if bad releases are made that adversely affects the community, or if disagreements develop about what should go into various releases and not. |
|
Good job, just correction on my name, it is actually "Eduardo Ibacache Rodriguez" to be more correct :) |
Fair enough, but then we need another role for the person per repository actually doing the releases 😄 |
OK, please open another issue when you get around to it. |
Done! :-) |
|
I'm also missing names of people who have done contributions and still are working on Solid-related things, such as @csarven and @melvincarvalho. |
|
Question: does "Repository Manager" mean "Repositories Manager" i.e. "GitHub Manager", the person who manages repository creation and deletion on the /solid GitHub account? |
The current definition is https://github.com/solid/community/blob/master/community-roles.md#repository-manager So, yes. |
This actually exists in the role definitions that were published some months ago Project Release Manager. Added a bit of color on this in #10 (comment). |
|
this is also relevant #11 |
|
A possible compromise would be to list each of the repositories per role and name the individual responsible per repository even if the individual is the repeated. |
|
In the context of this PR, I think we should focus on whether this PR is OK, there can always be more PRs :-) |
|
@RubenVerborgh @kjetilk could you update the pull request to reflect the current status of project release managers. So, list the projects and who is responsible per project please. |
community-roles.md
Outdated
| Solid Core Contributors work across projects on initiatives that enrich the | ||
| Solid ecosystem as a whole. They must attend regular stand-ups and strategy | ||
| meetings. | ||
| Solid Core Contributors work across projects on initiatives that enrich the Solid ecosystem as a whole. Solid Core Contributors must attend the weekly recurring community support meeting. | ||
|
|
There was a problem hiding this comment.
I have to disagree with removing a requirement that core contributors attend regular stand-ups and strategy meetings. IMO - the community support meeting is one such regular strategy meeting, but there's a lot more to it than only that one meeting. I think the original language includes the community support meeting without removing other criteria that's ultimately important elements of core contribution.
community-roles.md
Outdated
| A Project Contributor is anyone who contributes to an official Solid project. | ||
| Contributions come in many forms, from coding and qa to experience design and | ||
| technical content writing. | ||
| A Project Core Contributor is a key team member on an official Solid project. Project Core Contributors must attend the weekly recurring community support meeting. | ||
|
|
There was a problem hiding this comment.
We removed any specific responsibilities and replaced it with a short description that doesn't really specify anything concrete. I'm okay with merging project core contributor and project contributor because it's probably best to simplify right now, but the explanations need to be informative and helpful.
If you are a project core contributor, then you should be actively participating in that project and leading it efficiently and productively in the context of the overall Solid ecosystem. You should be able to have issues assigned, act on those issues, review and merge pull requests, and attend regular stand-ups and strategy meetings specific to that project. While I agree that there should be a regular community-wide dialogue across solid projects - I'm concerned that inviting everyone working on any solid community project to one weekly meeting could become unwieldy?
community-roles.md
Outdated
| and project strategy meetings. | ||
| The Project Release Managers are responsible for determining which features and/or bug-fixes will be merged into the release of their respective projects. Project release managers must attend the weekly recurring community support meeting. | ||
|
|
||
| ## Solid Coordinator |
There was a problem hiding this comment.
Should this be "Panel Coordinator"?
|
|
||
| ## Solid Panelist | ||
| The Solid panel engages in continuous tests to improve the user experience. When a test is set up by the Solid panel coordinators the community manager will reach out to the Solid panel to ask if they would like to participate in this test. Tests will take approximately half an hour each on average. If the user tester is available and willing to take the test, they will be sent instructions by the Solid panel coordinators. Solid panelist can withdraw from the panel at any point. To volunteer to become a Solid panelist contact the community manager. | ||
|
|
There was a problem hiding this comment.
We should be trying to get as much feedback from as many people as we can, and I worry that requiring them to assume a named role in the community just to try something and provide feedback is heavy-handed. I think having the role is OK, but I'm not sure that we should manage "membership" ranks associated with the role. Instead, possibly provide attribution of who was participated.
This description is also quite skewed only to UX, when we would expect that panelists could provide feedback and discussion on other topics, from developer experience and linked data conventions to security.
|
|
||
| ## Solid Event Organiser | ||
| The [Solid Event](solid-events.md) Organiser is responsible for organising and coordinatiing a Solid Event in a stated city. The position of Solid Event Organiser will be filled by an individual for as long as an event is scheduled in the future. | ||
|
|
There was a problem hiding this comment.
Would like to propose a notion of community groups here, because I think they may provide some versatility. An example of some group ideas:
- Identity and Security
- Application Development
- Linked Data
- Solid Server
- Protocols and Standards
- User Experience
- Recognized Contributors (Alumni that may not be as active today but have played a substantial role and should be recognized)
Groups are a way to recognize people that are contributing around a given subject matter, which may span "projects". It may also be another angle on project contributors, where you back that out to a group which is responsible for a given set of projects / repositories. For example, the Identity and Security group could be focused on those projects / repos directly related to authentication, authorization, etc.
There was a problem hiding this comment.
Yes, I think we need to have a look at such divisions. One general goal I think we need to discuss is to what extent we would design the groups to be orthogonal, which I think would require us to put quite a lot of thought into it, or if we should just let them emerge and let it be quite fluid what goes where. There will be quite a lot of overlap between the "protocols and standards", "solid server" and "linked data", for example.
kjetilk
force-pushed
the
new-community-roles
branch
from
6e82f30
to
c3dfdeb
Compare
|
I can see this PR came to encompass a little too much relative to what was originally intended, so I branched off another branch, and made a new PR #12. This way, we can have an approval of the names that goes into the existing roles as this PR, it can be merged before we do a larger discussion in #12, or we can just move to #12 and discuss the whole thing there. |
Here is the list of people who are currently occupying different roles. Please review.