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!
4 years
Available to write or edit
by alicia
Hi folks,
I’m interested in getting involved with the new edition of The Open Source Way. What’s the best way for me to contribute?
Thanks,
Alicia
Alicia Cozine
She/Her
Lead Technical Writer, Red Hat Ansible Automation Platform
4 years
Splitting up the repo to specific & general
by Karsten Wade
In the meeting today I brought up the question of if we are jamming too
many meta activities into the repo that should be focused on being
source for the guidebook.
Currently we have guide-specific project boards mixed with project-wide
boards. The proposal here is to separate the specific from the general.
The general needs a new repo name, so get out your favorite bikeshed colors.
Talking it through with Ashley, and following our own practice of not
over-complicating when simple will do, it made sense to have just one
new "meta" repo that contains project wide content, tools, etc.
We would want to finish renaming the primary branch to 'main' before
doing this split, moving issues to the new repo, etc.
How does this look?
current
=======
github/theopensourceway/guidebook.git
|_ marketing/
|_ mediawiki-source-content
|_ templates/
Project boards for guidebook.git
1. Editorial (guide content only)
2. Governance (project governance)
3. Marketing (guide and project marketing)
4. Technical (project tooling, incl guide build tools)
proposed
========
github/theopensourceway/guidebook.git
|_ mediawiki-source-content
|_ templates/
github/theopensourceway/project-all.git <== BIKESHED ME PLEASE
|_ marketing/
|_ marketing/blog-posts
|_ tools/
|_ ...
Project boards for guidebook.git
1. Editorial (guide content only)
Project boards for project-all.git
1. Governance (project governance)
2. Marketing (guide and project marketing)
3. Technical (project tooling, incl guide build tools)
Best,
- Karsten
--
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
4 years, 1 month
Weekly stand-up : 25 June 18:30 UTC (11:30 PDT)
by Karsten Wade
Wow, it's about to be our last stand-up for June, and that more than
half a year has past since we got very active with this project.
For the meeting tomorrowe, we have a few agenda items we can address
right up front. We may interweave the checking of the project boards
with some of these discussions in a more organic manner.
After those items are addressed, we'll stick around after 19:00; in an
office half-hour-ish. It's a chance for Q&A, more discussion, project
tours, refresh for anyone who needs it, and so on.
https://meet.google.com/yzs-hpgb-iwf
= Agenda
1. Open spot for important topics
1.1 community-users mailing list
1.2 blog marketing plan
https://github.com/theopensourceway/guidebook/issues/129
1.3 move marketing, governance, technical to own code repos?
2. Major blockers this week
3. Walk the project boards:
https://github.com/theopensourceway/guidebook/projects
You are welcome to observe and participate, collaborate and contribute.
This is a place where your questions about all aspects of the project
and the creating of the guide are welcome.
Best regards,
- Karsten
--
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
4 years, 1 month
Editing process discussion
by Karsten Wade
We had a discussion about the editing process today that covered a lot
of topics. Here are my messy notes. Please add in your notes. From here
we can start to work up some documents such as:
* Our style guide that calls out to other style guides, then begins to
note our house preferences.
* More content into a sample chapter/template, as we have it style-wise.
* Workflow overviews for how the review process works.
== notes
- Chapter will have 3 edit phases
- SME or tech editor step
- single source is not ideal but may be needed
- development or style edit
- common terms, nomenclature
- without changing author's voice much
- copyedit
- last edit in process before labeled ready to publish
- may do more than one copyedit pass
- if not a lot of changes, more than one copyedit pass
- IBM Style, Chicago MOS
-
- author review process
- TBD to figure out still, to some degree
- in GitHub, we can have back/forth and annotation within the document
- keeping this back/forth in GH tooling
- in GitHub, you have
- work on own branch
- named reviews?
- use PR with github review feature
- first basic edit over check pass/no-pass (a reality check)
- is this ready to work onward or not?
- SME reviews
- document should show SME edit status
- can do their review on mailing list or issue
- add new columns to split up Editing
- ACTION
- ultimately our style guide will get generated as we go
- voice of chapters
- look to style guide as primary way to shape voice and narrative
- collective decisions migrate to the style guide
--
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
4 years, 1 month
Weekly stand-up : 11 June 18:30 UTC (11:30 PDT)
by Karsten Wade
Come one, come all!
Please join us for our weekly, as-lighthearted-as-we-feel check-in,
stand-up, and office hours.
We spend the first 25 minutes doing the core agenda, then the rest of
the time from 19:00 onward is office half-hour. It's a chance for Q&A,
more discussion, project tours, refresh for anyone who needs it, and so on.
https://meet.google.com/yzs-hpgb-iwf
= Agenda
1. Open spot for important items
2. Major blockers this week
3. Walk the project boards:
https://github.com/theopensourceway/guidebook/projects
You are welcome to observe and participate, collaborate and contribute.
This is a place where your questions about all aspects of the project
and the creating of the guide are welcome.
Best regards,
- Karsten
--
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
4 years, 1 month
things to consider adding to the style guide
by Diane Giangrossi
Hi, all: At our last weekly meeting, I volunteered to look at the style
guide I wrote when I was an editor at a book publisher, to find some
nuggets that might be worth adding to our style guide. I put together this
document pretty quickly, so I apologize if it's a little terse or hard to
follow! I'll be happy to provide more context or explanation for anything
that you'd like to discuss further.
Also, I have a lengthy list of tricky grammatical and word choice issues
that I didn't include in this document. But I'd be happy to share those as
well if you're interested.
https://docs.google.com/document/d/1RrE4H2ey_7nu8877w2iVvWR9O4L_8y_2QChwe...
--
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>].
4 years, 1 month
