chef-oss-practices
chef-oss-practices copied to clipboard
chef
Consolidation of orgs
We have a large number of orgs at Chef. Do we want to consider consolidation of some of our orgs? It's hard to find projects sometimes since they're spread all over based on the teams that created them.
- chef
- chef-boneyard
- chef-cft
- chef-customers
- chef-marketing
- chef-partners
- chef-training
- chef-cookbooks
- learn-chef
- habitat-sh
- inspec
- opscode-cookbooks
I'm not sure that this will fly with the hab-team or not tbph. However, the larger concern that probably needs thorough discussion is how this might affect membership. We're going to have to start using GH teams very heavily if membership includes being added as a member to the org your project is a part of. Does having one org make that experience cleaner or dirtier? We could use GH teams like habitat-members, builder-members, habitat-reviewers and the like - does it make more sense for these orgs to instead exist separately with their own "members, reviewers, approvers" GH teams?
I'm not really suggesting habitat/inspec. More suggesting we take a serious look at our Chef orgs. We split out due to permissions issues. If we automate the permissions there we can consolidate our work into a single repo which is easier to navigate, easier to manage, and probably a bit cheaper.
I am 100% in favor of consolidating "Chef" organizations and it's something we've talked about on the ops team multiple - many times over the years.
I would still really like us to consolidate the chef and inspec orgs. Having components like train in their own org makes cross team collaboration very difficult and really serves no purpose in 2021.
@damacus For historical context, that organization was created in order to preserve the namespace so that some other person didn't "squat" it, or use it for nefarious purposes.