3. Contribution process

Local snapshot only. The workspace page is authoritative.

3.1 One intake with explicit routes

PDS uses one intake and one ordered backlog. Every submission must select one request type:

• defect in an existing Core asset;
• new or changed reusable component or pattern;
• modification to an existing component;
• documentation correction or addition;
• token request or change;
• accessibility or localization finding;
• adoption or installation support;
• AI-generated validation or documentation finding;
• proposal to assess a product-owned component for Core.
  The Design Ops Lead owns the intake service and backlog. The Design Ops Lead performs routine classification and routing. Routine routing is not a cross-functional vote.
  Defects in existing Core assets go to the owning engineering queue. New or changed reusable work goes through evidence review. Documentation, token, accessibility, localization, adoption, and AI findings retain their request type so that the correct domain owner and service level remain visible.

3.2 Proposal evidence

A proposal for new or changed reusable work must include:

• the user or experience need;
• affected products and teams;
• the current workaround, duplicate, or local implementation;
• evidence that the need cannot be met by an existing Core or Extended asset;
• evidence of reuse or likely cross-product value;
• known accessibility and localization implications;
• design and engineering contacts willing to supply evidence;
• known consumers, timing, and delivery constraints;
• links to research, prototypes, Figma, code, Storybook, or production examples.
  Incomplete evidence produces a discovery request or a recorded missing-evidence state; it is not silently rejected.
  The Design Ops Lead and Design Ops Product Designer jointly decide whether the proposal represents a Core need; the Design Ops Lead separately assigns strategic priority and support level. Before it becomes a Core candidate, the PDP engineering lead must review feasibility, dependencies, package fit, implementation ownership, and maintenance cost. Engineering may issue a technical no-go for an unsafe or unmaintainable path but does not decide system fit or backlog priority. The Design Ops Product Designer separately issues the design-quality gate once design evidence is required for the accepted candidate.
  Defects in existing Core assets are routed to the owning engineering queue and linked to the PDS backlog. New or changed reusable work proceeds through evidence and classification review.
  Each request retains its type so that its owner, support level, required evidence, and status remain visible.

3.2 Initial review and evidence

A proposal for new or changed reusable work should include:

• the user, product, or system need;
• affected products and teams;
• the current workaround, duplicate, or local implementation;
• evidence that an existing Core or Extended asset does not meet the need;
• evidence of reuse or likely cross-product value;
• known accessibility and localization implications;
• design and engineering contacts able to supply evidence;
• known consumers;
• timing and delivery constraints;
• links to research, prototypes, Figma, code, Storybook, or production examples.
  Incomplete evidence does not produce a silent rejection.
  The request is recorded as one of:
• ready for assessment;
• discovery required;
• missing evidence;
• duplicate or covered by existing work;
• local product need;
• out of PDS scope.
  The requesting team remains responsible for supplying product evidence. PDS may provide guidance, but intake does not transfer discovery or delivery ownership to PDS.

3.3 Core assessment and priority

The Design Ops Lead and Design Ops Product Designer jointly decide whether a proposal represents a Core need. The Design Ops Lead resolves a tie.
Before work becomes a Core candidate, the PDS Lead Maintainer reviews:

• technical feasibility;
• architecture and dependencies;
• package fit;
• likely implementation path;
• technical risk;
• maintenance cost;
• required maintainer review effort.
  The PDS Lead Maintainer may issue a technical no-go for an unsafe or unmaintainable path.
  The Design Ops Lead assigns:
• strategic priority;
• initial support level;
• whether the work enters the PDS backlog;
• whether it may be prepared for contribution.
  The Product Manager records the decision, dependencies, capacity assumptions, support level, and required follow-up.
  Acceptance as a Core candidate does not mean work starts at once. Delivery depends on backlog order, confirmed capacity, technical sequencing, and maintainer review capacity.

3.4 Product-team responsibilities

The requesting product team remains responsible for:

• defining the user and product need;
• supplying research or realistic product validation;
• testing its product implementation;
• product-level accessibility and localization of the full experience;
• maintaining its local implementation;
• reporting adoption, consumer information, defects, and known risks.
  Product teams contribute evidence and may advise on priority. They do not receive PDS governance, maintainer, merge, or release authority through participation.
  A product team may build a local solution when PDS cannot meet its delivery timing. Design Ops approval is not required for local product delivery.
  A locally maintained reusable component should be registered with:
• an accountable owner;
• a repository or Figma link;
• known consumers;
• intended lifespan;
• known accessibility and localization state;
• any intent to seek later Core assessment.
  Registration provides visibility. It does not make the component Core or transfer ownership to PDS.

3.5 Work ready for contribution

A developer may contribute only to an approved PDS backlog item marked Ready for contribution.
No developer begins PDS implementation from:

• an informal request;
• a private message;
• an unlinked branch;
• a self-selected idea;
• an unapproved scope change.
  The Design Ops Lead decides which backlog items may be offered for contribution.
  The PDS Lead Maintainer marks an item Ready for contribution only when it contains:
• a bounded problem and scope;
• acceptance criteria;
• explicit exclusions;
• target layer and proposed maturity, when applicable;
• source design, code, token, or documentation references;
• affected packages, APIs, dependencies, and known consumers;
• required tests and documentation;
• accessibility and localization evidence requirements;
• release and compatibility expectations;
• required domain gates and named reviewers;
• expected owner and support model after merge;
• enough setup information for a developer who is not part of the standing PDS delivery group.
  The PDS Lead Maintainer may return an item for discovery, split it, reduce its scope, or defer it when it is not ready for safe contribution.
  A contributor may propose a scope change in the work item. The change must not be implemented until the Design Ops Lead and PDS Lead Maintainer approve it within their accountable domains.

3.6 Assignment and delivery capacity

An authorized the company developer may request an unassigned Ready-for-contribution item.
The PDS Lead Maintainer confirms technical fit and expected review demand.
The Product Manager confirms that the assignment record includes:

• the contributor;
• the contributor’s home team;
• the approved backlog item;
• the agreed scope;
• the maintainer or delegate;
• the expected allocation or availability;
• the start date or next check-in;
• dependencies;
• the next expected evidence;
• the planned review period.
  The Software Development Manager confirms any formal engineering allocation or delivery commitment made by PDP or another engineering team.
  A voluntary or side-of-desk contributor is supplemental capacity. The work must not be included in delivery forecasts or roadmap commitments unless the contributor’s home team has approved and recorded a specific allocation.
  Assignment does not:
• change backlog priority;
• promise a release date;
• grant maintainer authority;
• create a long-term PDS role;
• guarantee immediate review capacity.
  The Product Manager tracks committed and supplemental work separately.

3.7 Active assignments

An assignment remains active while the contributor:

• makes reasonable progress;
• attends agreed check-ins;
• reports blockers;
• responds to review;
• maintains the recorded availability.
  An item may return to Ready for contribution when:
• work has not started within the agreed period;
• progress has stopped without an updated plan;
• the contributor becomes unavailable;
• review feedback remains unaddressed;
• the contributor’s home team withdraws capacity;
• higher-priority work requires the review capacity.
  The Product Manager records the assignment state and recommends reassignment, pause, or return to the backlog.
  The Design Ops Lead decides whether the work is:
• returned to the backlog;
• reassigned;
• reduced in scope;
• moved to committed PDS capacity;
• paused.
  Returning work to the backlog is a capacity and planning decision. It is not automatically a judgment about the contributor’s performance.

3.8 Contributor implementation workflow

For each assigned item, the contributor must:

1. Work in the governed PDS repository.
2. Link the branch and pull request to the approved backlog item.
3. Follow repository setup, architecture, code, token, testing, documentation, accessibility, localization, and security standards.
4. Keep the change within the approved scope.
5. Disclose new dependencies, API changes, consumer risks, or scope needs before proceeding.
6. Add or update the required code, tests, Storybook examples, documentation, release-impact declaration, and component-health evidence.
7. Request review from the PDS Lead Maintainer or named delegate and each other affected domain owner.
8. Address review feedback or return the item with partial work, known gaps, and next steps recorded.
   A contributor may not approve their own required gate, merge their own change, publish a release, or change component maturity.
   Automated checks support review. They do not replace required domain decisions.

3.9 Joint contribution

Joint contribution is an agreed support route between PDS and a product team.
Before work begins, the backlog item must record:

• the approved scope and outputs;
• target layer and proposed maturity;
• contributor and reviewer roles;
• the product team’s work;
• PDS’s support level;
• required design, engineering, documentation, accessibility, localization, and release evidence;
• timing and dependencies;
• maintainer review demand;
• support after merge;
• ownership of the local product implementation;
• conditions for Core handoff.
  The product team may perform or fund the main development. PDS provides only the support that has been agreed and recorded.
  The product team continues to own its local implementation after a shared PDS version is accepted and published. Ownership changes only when the product team later migrates to the shared asset.
  A joint contribution does not become committed PDS delivery capacity unless the required design, engineering, review, and specialist allocations are confirmed.

3.10 Support levels

Each accepted request receives one support level.

1. Guidance only: PDS provides direction or references. The requester owns delivery and evidence.
2. Review and recommendation: PDS reviews named artifacts and provides findings. The requester owns delivery.
3. Joint contribution: PDS and a product team divide agreed work and evidence. Ownership is recorded for each output.
4. PDS-owned implementation: PDS accepts delivery and ongoing maintenance of the shared asset within approved priority and capacity.
   The Design Ops Lead assigns the support level based on:

• system value;
• evidence;
• risk;
• backlog priority;
• protected PDS capacity;
• PDP engineering capacity;
• maintainer review demand;
• required specialist support.
  The Product Manager records the support level and any limits.
  A support level does not promise a date. A dated commitment requires confirmed capacity and a separate delivery record.

3.11 Evidence and readiness review

Every contribution uses one checklist linked to the backlog item or pull request.
The checklist records the applicable evidence and named domain decisions for:

• component definition and purpose;
• design and Figma parity;
• behaviour, variants, dimensions, spacing, layout, colour, typography, states, and props;
• responsive behaviour and breakpoint alignment;
• engineering architecture and implementation;
• API and dependency safety;
• tests and Storybook examples;
• documentation and usage guidance;
• accessibility;
• localization;
• release and compatibility impact;
• AI-readable structure and documentation, when applicable;
• ownership and support;
• product or pilot validation.
  The Stable readiness material shown in the current working board may inform this checklist, but it must be reconciled with the maturity model in section 2 before becoming governed policy.
  Items shown as required or recommended must not create a second maturity standard that conflicts with section 2.
  Missing required evidence leaves the contribution in its current state.
  The Design Ops Lead and Design Ops Product Designer may not approve technical, release, or QA evidence by proxy.
  The PDS Lead Maintainer may not approve design-quality evidence by proxy.
  QA/SDET approves only the evidence it was assigned, qualified, and able to complete. Lack of available QA/SDET support is not approval.

3.12 Review, acceptance, and merge

The PDS Lead Maintainer or a named maintainer delegate must review every code contribution.
The technical review covers:

• architecture;
• implementation quality;
• tests;
• API and dependency safety;
• repository standards;
• version and compatibility impact;
• technical documentation;
• package and release implications.
  Other affected domain owners review design, content, token meaning, accessibility, localization, lifecycle, product evidence, or support decisions within their accountable areas.
  A contribution is ready for acceptance only when:
• required evidence is complete;
• all affected domains record go;
• unresolved risks are documented and accepted by the accountable owner;
• the PDS Lead Maintainer confirms merge readiness.
  The Design Ops Lead confirms any layer, support, or maturity governance decision after the required gates pass.
  The PDS Lead Maintainer or delegate retains merge authority.
  Acceptance into the repository does not by itself:
• publish a release;
• change maturity;
• create a package commitment;
• require product adoption;
• set a migration deadline.
  After merge, PDS owns the shared code and the maintenance commitment recorded for the Core asset.
  The contributor does not automatically become its permanent maintainer or support contact. Any continuing contributor role must be explicitly agreed with the contributor and their home team.

3.13 Maintainer review capacity

All developer contributions consume PDS Lead Maintainer capacity.
This includes:

• scoping;
• setup support;
• technical guidance;
• architecture review;
• code review;
• test review;
• documentation review;
• merge preparation;
• release support.
  The PDS Lead Maintainer determines how many contributions can be active or in review at one time.
  Contributor work may be queued or paused when review capacity is not available.
  Protected PDS work, production defects, releases, and higher-priority backlog items may take precedence.
  The Product Manager tracks review demand as part of the delivery plan. A contribution must not be shown as near completion until required maintainer review capacity is available.
  The Design Ops Lead may limit active contributions when the support and review cost would reduce delivery of higher-priority PDS work.
  More contributors do not automatically create more delivery capacity.

3.14 Repository access and safeguards

The governed repository must use the platform’s available controls to enforce:

• code-owner review for protected PDS paths;
• review by the PDS Lead Maintainer or named delegate;
• protected default and release branches;
• no direct contributor pushes to protected branches;
• pull requests linked to approved backlog items;
• required build, lint, unit, accessibility, documentation, and other relevant checks;
• prevention of self-approval for required code-owner and domain gates;
• least-privilege access;
• merge and release access limited to named maintainers and delegates;
• traceable review, exception, merge, and release records.
  Repository access permits contribution. It does not permit a developer to bypass backlog order, scope, evidence, gates, merge controls, or the release process.
  Security-sensitive defects must use the approved private reporting path.

3.15 Response expectations

PDS aims to acknowledge a new submission within one working week.
A request with sufficient evidence is reviewed at the next fortnightly core working team review or routed sooner when it is a critical defect or time-sensitive risk.
The work item records:

• request type;
• current state;
• decision;
• owner;
• support level;
• missing evidence;
• capacity status;
• next review point.
  Office hours may support early discussion, discovery, and visibility of local patterns. They do not replace intake, backlog records, evidence, or governed decisions.
  Contributor pull requests are reviewed within available PDS capacity.
  When review demand exceeds capacity, the PDS Lead Maintainer raises the conflict to the Product Manager and Design Ops Lead. The work may then be reordered, paused, reassigned, reduced in scope, or supported through additional confirmed capacity.