Repo permissions and teams
by Ashley Nicolson
Hi everyone.
Just following with the repo permissions discussion originally started here:
https://github.com/theopensourceway/guidebook/issues/90
So my opinion is very much from an organisational governance so this may reflect my proposal. I’m happy to adapt as the project’s governance hasn’t yet been finalised.
Currently new users (lets say users instead of members as this is a term used in GitHub) invited to the opensourceway organisation default to being Member. These users will be able to clone and pull all repos the organisation owns – currently that would be guidebook and theopensourceway_old_website
“By default, members of an organization will have Read permissions to the organization's repositories.”
This “green room” allows the owners to allocate higher level of permissions if and when required. I think we should keep this default whilst teams are being decided and when more teams are being added.
Just to note that there are both “base permissions” and “repository permissions” allowing more refinement of access for members of the organisation (or external collaborators) specific to a repo. The above suggested Read permission would be the base permission of the organisation.
To apply repository permissions I would suggest we use teams with the appropriate access.
https://help.github.com/en/github/setting-up-and-managing-organizations-a...
From least access to most access, the permission levels for an organization repository are:
• Read: Recommended for non-code contributors who want to view or discuss your project
• Triage: Recommended for contributors who need to proactively manage issues and pull requests without write access
• Write: Recommended for contributors who actively push to your project
• Maintain: Recommended for project managers who need to manage the repository without access to sensitive or destructive actions
• Admin: Recommended for people who need full access to the project, including sensitive and destructive actions like managing security or deleting a repository
Currently there is only really a need for the Triage where members can:
• Assign labels, issues, and PRs
• Apply milestones
• Request PR reviews
See more of a detail breakdown here: https://help.github.com/en/github/setting-up-and-managing-organizations-a...
However Triage can not physically push to the repo i.e. merge or force push to that repo or branch directly. They can, like other users, create a Pull Request from a forked repo and follow the review process.
This maybe considered too restrictive but I feel its acceptable that authors themselves, who wrote the piece, are not permitted to push to the repo – it would imply that a review hasn't taken place. Ideally it would be the review team that would say OK after some back and forth and they themselves merge the author’s content in. This implies that that there would be a team of editors.
Editors themselves would have the Write permission which of course grants more permission including:
• Push to the contributor’s branch (easily)
• Lock conversations
• Submit reviews that affect a PR’s mergeability (this feature flags when PRs shouldn’t be merged)
• Apply suggested changes to PRs
Of course members can be added to multiple teams with the more permissive level being applied.
It really comes down to the teams and what roles they play in the repo and gradually adding more teams if and when required. Currently I can envision the below teams based on the current flow of the workflow process:
• Authors: members of the organisation that have been assigned as author or co-author of a chapter. They are also able to assist with labeling issues to help other authors on boarding.
• Editors: members of the organisation that can perform editorial reviews on author’s contributions permitting successful contributions to be merged into the repo.
These teams are very simple and serve a very distinct role in the project, but we should also consider the glue that keeps the repo going identifying that group of members. Usually we would have the term “core” team that do a wide range of things outside the scope of the current authors and editors. But at the moment I think there isn’t a current need to identify that but something to consider when the project becomes more mature.
Another note that Outside collaborators (those not invited to the organisation) can be invited to a repo’s team in case they wish not to be added to the opensourceway organisation.
Lastly only owners can assign repositories to teams and therefore manage team access (though I believe members of an organisation can create teams).
Here are steps to do this here: https://help.github.com/en/github/setting-up-and-managing-organizations-a...
Any thoughts would be much appreciated!
2 years, 8 months
editor opportunities
by Diane Giangrossi
Hi! I watched your Community Central presentation and am excited about this
project. Thank you for offering the opportunity to participate!
I was a lead copy editor and owner of the style guide at Dummies Press
(publishers of *DOS For Dummies, Sex For Dummies,* etc.) for 4 years, as
well as a senior technical communications specialist at multiple software
development companies for close to 10 years. I'm new to Red Hat and open
source but able and willing to help with copy editing and/or the
development of a style guide.
Thanks!
Diane
--
Diane Giangrossi, CSPO
She/Her
Business Analyst, Product Security
Red Hat Remote (Florida USA) <https://www.redhat.com/>
diane(a)redhat.com
941.263.3404 IM: diane
<https://www.redhat.com/>
I respect your work/life balance: no need to reply to this email if it is
outside of your normal working hours [Red Hat link
<https://mojo.redhat.com/docs/DOC-1199578>].
2 years, 9 months
Idea for formatting of personal stories
by Shaun McCance
One thing we discussed in our last standup was what to do about
consistent voice, whether people should write in the first person,
whether we need bylines on chapters if they do, and whether that turns
the guide into an anthology instead of something with a consistent
narrative. I had an idea I'd like to run by folks.
What if we put personal stories into some sort of sidebars? An author
(or authors) could write a chapter with general guidance, all written
in a neutral voice. Then, when they want to write a supporting story,
that could be in a sidebar, and the sidebar could have a byline. It
looks good in my head, but I might be failing to convey the idea
without a mockup.
Interested in people's thoughts.
--
Shaun
2 years, 10 months
Updating website
by Michael Scherer
Hi,
After a quick meeting with Karsten (as it was more efficient to have 10
seconds of audio lag over Google Meet than 12h over IRC), I just
created a git repository on github:
https://github.com/theopensourceway/theopensourceway_old_website
it is a copy of the old fedorahosted.org git repository with the
current production website files. I switched the server to pull files
from there, so any commit should appear sooner or later (around 5
minutes) on https://theopensourceway.org/
If it doesn't, there is a problem on the server, and a admin would have
to take a look (admins being people listed here:
http://git.theopensourceway.org/cgit/ansible/tree/roles/admin_ssh_keys/ta...
so me, my coworker Duck or Karsten for now)
There is no verification or anything, no fancy CI, so if there is
invalid HTML, or something outrageous like "proprietary is the way to
go" using marquee and blink markup on the front page, it will be
deployed if someone push.
--
Michael Scherer / He/Il/Er/Él
Sysadmin, Community Infrastructure
2 years, 10 months
Schedule and release timing thread
by Karsten Wade
tl;dr -- things are moving quickly in this project in the context of The
World Around Us, and I'm worried they are moving too quickly for our
friends and family out there who haven't found us yet but who may be
available to contribute "soon".
I've been worried about a few things around our schedule:
1. The world around us is shifting literally daily in terms of what we
can all expect life to look like in six weeks, six months, and sixteen
months.
2. With more ramp-up time for people to ponder and commit to writing a
chapter, we would have a better diversity of writers.[1] Yet ...
3. We have momentum that we don't want to lose by dragging out the
schedule too much.
4. Ultimately, we shouldn't force those who are able to act now wait for
others to come along before they can make progress and complete
chapters. Early and late contributors should be welcomed and enabled to
be successful.
One option is to shift the release date out and give us another month or
two of recruiting writers. People are already writing, but they would be
looking at a longer time until the gratification of publication.
Another option is to work with what we have, accepting fewer voices are
involved in the final work. Folks who come along in a month can be
subject matter expert reviewers instead of writers, at least for the 2.0
release.
Today when discussing this with Bryan Behrenshausen, he suggested a
middle road that I really liked. I opened this thread partially to
tee-up his presenting that idea.
What thoughts, feelings, questions, and ideas does this bring up for all
of you?
Best regards,
- Karsten
[1] In that, all the chapters will eventually get written -- there are
several of us from Red Hat who are preparing to write whatever is needed
to get this guide done, but that will mean fewer voices at the writing
level.
--
Karsten Wade [he/him/his]| Senior Community Architect | @quaid
Red Hat Open Source Program Office (OSPO) : @redhatopen
https://community.redhat.com | https://next.redhat.com | https://osci.io
https://theopensourceway.org | https://github.com/theopensourceway/guide
2 years, 11 months
