gr2m
commented
3 years ago Org defaults
* repo details * allowed merge strategies
Only sqaush
* wikis/projects/downloads
disable projects and wikis
* branch protection
Require 1 review.
Require CI status from "test" and "WIP"
* team permissions
🤷🏼
In the past we had the idea to create teams for different eco systems, e.g. gitlab or circleci, things the previous maintainers didn't use and didn't want to maintain
* labels? (this gets a little clunky once certain repos need additional labels beyond the defaults)
I'm happy with the labels I use at @octokit, e.g. https://github.com/octokit/core.js/labels
Most important, I like to have
- bug
- feature
- maintenance
- documentation
For Octokit I've also built a little app that enforces categorizing pull requests with these labels and keeping an org project board up-to-date: https://github.com/orgs/octokit/projects/1
I always wanted to create more of a dashboard view that shows stats over time. Features shows that we work on adding new stuff, bug/maintenance shows the amount of work we spend on maintaining the status quo. I'd be happy to setup something similar for semantic-release
Per repo details
* name * description * homepage * visibility * team permissions when different than defaults * additional collaborators? (i'd prefer to define teams if the need for this exists)
agree
Security
since having access to modify the settings file effectively elevates someone to admin, it may be worth requiring owner review through
CODEOWNERS. currently the maintainers team is essentially the same as owners. do we want that to stay that way. especially since the bot currently does not push updates to all repos after updating the org level file, would it be worth creating an owners team for this now, even if it has the same members?
good point, I'd add @semantic-release/maintainers as CODEOWNERS for at least this file
to prepare for configuring https://github.com/probot/settings for this org, i thought i'd start by capturing thoughts here. i'll work to survey existing patterns, but feel free to comment if i've missed things that we want to make sure to capture or if there are specific defaults that we should target.
Settings
Org defaults
Per repo details
Security
since having access to modify the settings file effectively elevates someone to admin, it may be worth requiring owner review through
CODEOWNERS. currently the maintainers team is essentially the same as owners. do we want that to stay that way. especially since the bot currently does not push updates to all repos after updating the org level file, would it be worth creating an owners team for this now, even if it has the same members?