June 2020 - Contrib - The Opensourceway 2.0 List Archives

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, 4 months

4
4
0 / 0

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, 5 months

3
3
0 / 0

Agenda item for 6/25/20 Meeting

by Brian Proffitt

It has been suggested that TOSW community can act as a more responsive resource of open source and community best practices. With that in mind, I would like to put forth the suggestion that we have a new mailing list, such as community(a)theopensourceway.org, where folks could come to ask questions and get advice. If this could be added to this week's agenda item as a discussion, it would be appreciated. Thanks! Brian -- Brian Proffitt Manager, Open Source Program Office Red Hat <https://www.redhat.com/> He/Him/His M: 5747805695 @redhatopen <https://twitter.com/redhatopen> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat Community <https://www.facebook.com/redhatopen> <https://red.ht/sig>

4 years, 5 months

3
6
1 / 0

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, 5 months

1
0
0 / 0

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, 5 months

1
0
0 / 0

Changing primary branch name

by Karsten Wade

At this point in the zeitgeist, I think it's pretty obvious[1] we need to change the name of this project's primary branch (origin?) from 'master' to 'main'. I created this issue: https://github.com/theopensourceway/guidebook/issues/106 I have not looked into what is needed here technically. Is anyone interested in helping or doing this change? We need to figure out the technical bit, we need to communicate to this group whatever needs to be changed in our own checkout/other steps, and we need to update any documentation. Then do it. Best regards, - Karsten [1] For all on this subject I could ever hope to say, I refer to my friend and colleague Rich Bowen: https://www.youtube.com/watch?v=hZuFeFuazwo -- 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, 5 months

1
0
0 / 0

Weekly stand-up :: 18 June 18:30 UTC (11:30 PDT)

by Karsten Wade

Hello friends, You are invited as always to join us for our weekly 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, 5 months

1
0
0 / 0

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, 5 months

1
0
0 / 0

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, 5 months

1
0
0 / 0

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, 5 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

Contrib June 2020