Define CODEOWNERS and teams

[SimonFinney]

Summary

Identify and define CODEOWNERS and teams for design and development to automatically assign for PRs.

[SimonFinney]

@carbon-design-system/ibm-cloud-paks I created this stub as a discussion point for how we might want to structure CODEOWNERS and GitHub teams for pattern and component governance across design and development - would anyone have examples of their current process to help us shape and define how this could look here?

[matthew-chirgwin]

For the CDAI components we have worked as follows (please update as needed @asfordmatt ). Our process covers more than just codeowners, but I will mention it for completeness:

• components are developed with a lifecycle attached - experimental, under construction, and production ready (reflected in our storybook: https://pages.github.ibm.com/cloud-integration-design/ide-components/?path=/story/production-ready-ide-navigation-components-ide-navigation-component-set--all-components-used-together ).
• these stages are used as an indicator of completness. A product may include/integrate/ship a component under construction, knowing that it is subject to change.
• components are developed and reviewed in PRs. These are reviewed by engineers from 2 different product teams, as well as design if required. These reviews check the change vs the design, that no product specific product information is contained, and that the changes follow our contribution/style guide.
• when a component is deemed complete, it moves to production ready. To do so, a file is modified to move it to this state. This file is mapped via codeowners to both @asfordmatt and members of our design team so they review the changes.
• further changes made to production ready components are reviewed by both engineering and design

This has worked for us, but there are drawbacks:

• Reviews require co-ordination and availability across teams
  • This then causes delays, and rushed reviews (bugs missed, contribution guide not followed etc)
  • It has even caused resistance to contribute - its too slow, we need X now etc
• Components which are not production ready have been used in production ready parent components
• Designs and the production ready components have deviated/not been kept in step

Nominated codeowners per package (eg, If I contributed a change to package Y, someone from package Y should review) seems like a sensible idea, along with design input as well. It will however need dedicated time from those nominated people so reviews can be actioned promptly and thoroughly.

[SimonFinney]

@matthew-chirgwin I love this, and I really like the idea of having a lifecycle attached to it - as you mentioned, I can definitely see delays arising as a result of roping in folks from offering teams, who have their own schedule.

I completely understand the value it brings as reviews are being requested directly from consumers! I'm curious to know from your experience if it has generally brought significant benefits and insight to the final output in comparison to the time it might take to conduct those 'external' reviews?

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.