docs: add additional contribution documentation (#2062)

.storybook/components/Docs/Guidelines/CodeGuidelines.mdx

@@ -6,6 +6,7 @@ import { Canvas, Meta } from '@storybook/blocks';
 
 EDS component code follows these principles and conventions for HTML, CSS, and JavaScript/TypeScript/React:
 
+- [Reading Figma APIs](#figma)
 - [HTML](#html)
 - [CSS](#css)
  - [CSS design principles](#css-design-principles)
@@ -22,6 +23,24 @@ EDS component code follows these principles and conventions for HTML, CSS, and J
 - [Accessibility](#accessibility)
  - [Tools](#accessibility-tools)
 
+# Reading Figma APIs <a name="figma"></a>
+
+Both code and figma component documentation have different needs. Tackling the API is not an exact science, so we include some guidelines on how to read and implement the APIs.
+
+## Exact matching APIs
+
+Cases where the API names match **exactly** between code and figma:
+
+- **boolean fields** (e.g., `isFullWidth`, `hasLeadingIcon`) - match the names of boolean fields between code and figma, to avoid ambiguity and confusion
+
+## Figma APIs not in Code
+
+- By convention, some APIs shown in Figma are for designers and should not be implemented in code. These should include a marker both in the API table and figma component UI (e.g., the gear emoji)
+
+## Code APIs not in Figma
+
+- In code, there will be APIs for handling events, controlling other UI behaviors, and some props needed for React implementations. We annotate these by grouping the APIs in the props in the types either under `// Component API` or `// Design API`.
+
 # HTML principles and conventions <a name="html"></a>
 
 - **Use semantic markup.** That means using the `<button>` tag rather than `<div onClick={toggle}>` when a button is required, an `<a>` tag when a link is required, and so on.

docs/CONTRIBUTING.md

@@ -35,21 +35,21 @@ This project uses [Git-flow](https://nvie.com/posts/a-successful-git-branching-m
 
 - The `main` always represents the latest production-ready version of the design system. Each commit to `main` indicates a new release (either from changes on `release` or from `hotfix`).
 - `next` represents the unpublished changes for the next release of the design system. These can be standalone commits, or merged in from `feature`.
-- `feature` branches are for standalone/larger product features, and are created using the syntax `[FIRSTINITIAL][LASTNAME]/[FEATURE NAME]`.
+- `feature` branches are for standalone/larger product features, and are created using the syntax `[FIRSTINITIAL][LASTNAME]/[FEATURE NAME|TICKET NUMBER]`.
 - `release` branches are for preparing the next release of the design system from `next`. Only bug fixes and metadata changes should happen in release branches.
 - `hotfix` branches are for urgent fixes that need to be production.
 
 EDS follows the process outlined in [this article](https://nvie.com/posts/a-successful-git-branching-model/), which gets into the specifics.
 
 ## Contribution workflow
 
-**Note**: For urgent hotfixes, use `main` instead of `next` as the base of your changes.
+**Note**: For releasing urgent changes, read about how to publish hot fixes in [Publishing](./PUBLISHING.md).
 **Note**: If you suspect your change will be breaking, flag the team ahead of time to discuss any conflicts with EDS release planning.
 
 In order to contribute to EDS, please follow this workflow:
 
-1. Create a feature branch from `next` called `[FIRSTINITIAL][LASTNAME]/[FEATURE NAME]` (e.g. `ahu/add-tertiary-button`)
-2. Do feature work in accordance to the library's [code guidelines](./CODE_GUIDELINES.md). EDS uses [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/), so each commit should follow commit guidelines reflecting the nature of the work.
+1. Create a feature branch from `next` called `[FIRSTINITIAL][LASTNAME]/[FEATURE NAME|TICKET NUMBER]` (e.g. `ahu/add-tertiary-button` OR `aholloway/EDS-1234`)
+2. Do feature work in accordance to the library's [code guidelines](https://chanzuckerberg.github.io/edu-design-system/?path=/docs/documentation-contributor-guidelines-code-guidelines--docs). EDS uses [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/), so each commit should follow commit guidelines reflecting the nature of the work.
 3. When work is ready for review, issue a pull request into `next` following the pull request guidelines. Tag `chanzuckerberg/edu-design-system` as reviewers for every PR.
 4. The library owners and trusted contributors will review the work and suggest revisions or approve the pull request
 5. Upon approval, feature gets **Squash and merged** into `next` to be slated for the next library release
@@ -60,7 +60,7 @@ A few notes about breaking changes:
 
 - If you anticipate a breaking changes is inbound, let the team know as soon as possible. This is to give everyone a chance to double-check the sequence of commits or create a `release` branch if needed.
 - Not all breaking changes are equal! Changes removing deprecated components/APIs require careful communication. Changes affecting in-use components also require more scrutiny.
-- Consider writing a codemod (using [JSCodeShift](https://github.com/facebook/jscodeshift) for systematic changes.
+- Consider writing a codemod (using [TS Morph](https://ts-morph.com/)) for systematic changes. See examples in src/bin/migrate.
 - There may be a way to make the change in a backwards-compatible way. Consider this during implementation, providing some rationale in cases where it is not feasible/practical to do so.
 
 ## Making Edits to Tokens