Merge branch 'main' into treeview-roving-tabindex

Author: colebemis

contributor-docs/adrs/adr-008-experimental-components.md

@@ -47,15 +47,15 @@ The approach that has served us well since Dec 2021 has been "drafts" (along wit
 
 1. npm package: "Experimental" components, as defined by the component lifecycle, should not be part of semantically versioned npm package for `@primer/react`.
 
-2. npm package: Each experimental component should be independently published and versioned with semver. Breaking changes should be tagged as major versions. Example: `@github/react-commentbox`
+2. npm package: Each experimental component should be independently published and versioned with semver. Breaking changes should be tagged as major versions. Example: `@github/experimental-react-commentbox`
 
-3. The code for experimental components should live in [github/github/modules/react-shared](https://github.com/github/github/tree/master/app/assets/modules/react-shared) and published as individual packages as suggested in point 2.
+3. The code for experimental components should live in a new repository, example: [github/react-experimental](https://github.com/github/react-experimental) and published as individual packages as suggested in point 2.
 
-   The monolith already has a place where reusable react components live. This has the lowest barrier to entry for folks working in the monolith.
+This will help in sharing experimental components between the monolith and projects outside of monolith. The ownership and responsibility of maintenance will be shared by multiple teams (including primer).
 
 #### Risks:
 
-This decision would increase the amount of work required for non-monolith projects when upstreaming reusable components. Without improving the development and publishing workflow for react-shared, this could create more friction and make contributions more difficult.
+This will require improvements in the development and publishing workflow for experimental components. Without making that investment, we could create more friction and make contributions more difficult.
 
 
  
@@ -66,10 +66,8 @@ This decision would increase the amount of work required for non-monolith projec
 
    Keeping experimental components in primer _org_ suggests that the primer _team_ would take up maintenance of these components while they are still candidates (bugs, a11y remedial, etc.). This will be a new parallel workstream for the team and with our current team size, we might not be able to give it the required attention.
 
-2. The code for experimental components should live in a new repository `github/react-shared` or `github/primer-react-candidates` instead of `primer/react-candidates`
+2. The code for experimental components should live inside the monolith in [github/github/modules/react-shared](https://github.com/github/github/tree/master/app/assets/modules/react-shared) instead of a new repository.
 
-   This is not a bad option, it helps in sharing components between projects outside of monolith as well and the ownership and responsibility of maintenance is shared by multiple teams.
-
-   While primer would be one of the teams maintaining this repository, there is additional work required (compared to [github/github/modules/react-shared](https://github.com/github/github/tree/master/app/assets/modules/react-shared)) and the lack of a primary "owner" might mean that this repository only gets additions and the maintenance of components gets neglected.
+   This option has the lowest barrier to entry for developers working in the monolith, however this would be significantly more difficult for non-monolith projects (example: memex). The difference in how the same component is consumed in the monolith (relative import) and non-monolith projects (published package) would create additional challenges that we haven't explored yet.
 
 3. The code for experimental components should live in [github.com/primer/react](http://github.com/primer/react), but published to multiple npm packages, which would result in less maintenance overhead by keeping all components in one repository. However, this might make it harder to enforce different dev conventions/processes and code ownership for experimental vs non-experimental components.