diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md deleted file mode 100644 index d2e6e26eb..000000000 --- a/.github/pull_request_template.md +++ /dev/null @@ -1,93 +0,0 @@ - - -# Description - -Please include a summary of the changes and the related issue. Please also -include relevant motivation and context. - -## Type of change - -Please delete options that are not relevant. - -- [ ] Bug fix (non-breaking change which fixes an issue) -- [ ] New feature (non-breaking change which adds functionality) -- [ ] **Breaking change** (fix or feature that would cause existing - functionality to not work as expected, **including removal of schema files - or fields**) -- [ ] Documentation update - ---- - -### Is this a Breaking Change or Removal? - -If you checked "Breaking change" above, or if you are removing **any** schema -files or fields: - -- [ ] **I have added `!` to my PR title** (e.g., `feat!: remove field`). -- [ ] **I have added justification below.** - -```text -## Breaking Changes / Removal Justification - -(Please provide a detailed technical and strategic rationale here for why this -breaking change or removal is necessary.) -``` - ---- - -## Checklist - -- [ ] My code follows the style guidelines of this project -- [ ] I have performed a self-review of my own code -- [ ] I have commented my code, particularly in hard-to-understand areas -- [ ] I have made corresponding changes to the documentation -- [ ] My changes generate no new warnings -- [ ] I have added tests that prove my fix is effective or that my feature works -- [ ] New and existing unit tests pass locally with my changes -- [ ] Any dependent changes have been merged and published in downstream modules - ---- - -### Pull Request Title - -This repository enforces **Conventional Commits**. Your PR title must follow -this format: `type: description` or `type!: description` for breaking changes. - -**Types:** - -- `feat`: A new feature -- `fix`: A bug fix -- `docs`: Documentation only changes -- `style`: Changes that do not affect the meaning of the code (white-space, - formatting, etc) -- `refactor`: A code change that neither fixes a bug nor adds a feature -- `perf`: A code change that improves performance -- `test`: Adding missing tests or correcting existing tests -- `chore`: Changes to the build process or auxiliary tools and libraries - -**Breaking Changes:** - -If your change is a breaking change (e.g., removing a field or file), you -**must** add `!` before the colon in your title: -`type!: description` - -**Examples:** - -- `feat: add new payment gateway` -- `fix: resolve crash on checkout` -- `docs: update setup guide` -- `feat!: remove deprecated buyer field from checkout` diff --git a/.github/workflows/pr-triage.yml b/.github/workflows/pr-triage.yml new file mode 100644 index 000000000..26c1c44ce --- /dev/null +++ b/.github/workflows/pr-triage.yml @@ -0,0 +1,66 @@ +name: UCP Pull Request Triaging Agent + +on: + pull_request: + types: [opened, reopened, edited, synchronize] + branches: + - main + workflow_dispatch: + inputs: + pr_number: + description: 'The Pull Request number to triage' + required: true + type: 'string' + +permissions: + pull-requests: write + contents: read + +jobs: + agent-triage-pull-request: + runs-on: ubuntu-latest + timeout-minutes: 60 + steps: + - name: Generate Token + uses: actions/create-github-app-token@v1 + id: app-token + with: + app-id: ${{ secrets.APP_ID }} + private-key: ${{ secrets.APP_PRIVATE_KEY }} + owner: ${{ github.repository_owner }} + + - name: Checkout repository + uses: actions/checkout@v4 + + - name: Checkout .github repository for org-level configuration + uses: actions/checkout@v4 + with: + repository: ${{ github.repository_owner }}/.github + path: .github_org + ref: main + token: ${{ steps.app-token.outputs.token }} + + - name: Set up Python + uses: actions/setup-python@v5 + with: + python-version: '3.11' + + - name: Install dependencies + run: | + python -m pip install --upgrade pip + pip install requests google-adk python-dotenv + + - name: Run Triaging Script + env: + GITHUB_TOKEN: ${{ steps.app-token.outputs.token }} + GOOGLE_API_KEY: ${{ secrets.GOOGLE_API_KEY }} + GOOGLE_GENAI_USE_VERTEXAI: 0 + OWNER: ${{ github.repository_owner }} + REPO: ${{ github.event.repository.name }} + PULL_REQUEST_NUMBER: ${{ github.event.pull_request.number || github.event.inputs.pr_number }} + INTERACTIVE: ${{ vars.UCP_PR_TRIAGE_INTERACTIVE || 0 }} + PYTHONPATH: ${{ github.workspace }}/.github_org/agents + CODEOWNERS_PATH: ${{ github.workspace }}/.github/CODEOWNERS + CONTRIBUTING_MD_PATH: ${{ github.workspace }}/.github_org/CONTRIBUTING.md + PULL_REQUEST_TEMPLATE_MD_PATH: ${{ github.workspace }}/.github_org/.github/pull_request_template.md + run: python -m pr_triage_agent.main diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md deleted file mode 100644 index 855e0566e..000000000 --- a/CODE_OF_CONDUCT.md +++ /dev/null @@ -1,111 +0,0 @@ - - -# Code of Conduct - -## Our Pledge - -In the interest of fostering an open and welcoming environment, we as -contributors and maintainers pledge to making participation in our project and -our community a harassment-free experience for everyone, regardless of age, body -size, disability, ethnicity, gender identity and expression, level of -experience, education, socio-economic status, nationality, personal appearance, -race, religion, or sexual identity and orientation. - -## Our Standards - -Examples of behavior that contributes to creating a positive environment -include: - -* Using welcoming and inclusive language -* Being respectful of differing viewpoints and experiences -* Gracefully accepting constructive criticism -* Focusing on what is best for the community -* Showing empathy towards other community members - -Examples of unacceptable behavior by participants include: - -* The use of sexualized language or imagery and unwelcome sexual attention or - advances -* Trolling, insulting/derogatory comments, and personal or political attacks -* Public or private harassment -* Publishing others' private information, such as a physical or electronic - address, without explicit permission -* Disrespecting the community's time by sending spam or other unsolicited - commercial messages -* Other conduct which could reasonably be considered inappropriate in a - professional setting - -## Our Responsibilities - -Project maintainers are responsible for clarifying the standards of acceptable -behavior and are expected to take appropriate and fair corrective action in -response to any instances of unacceptable behavior. - -Project maintainers have the right and responsibility to remove, edit, or reject -comments, commits, code, wiki edits, issues, and other contributions that are -not aligned to this Code of Conduct, or to ban temporarily or permanently any -contributor for other behaviors that they deem inappropriate, threatening, -offensive, or harmful. - -## Scope - -This Code of Conduct applies both within project spaces and in public spaces -when an individual is representing the project or its community. Examples of -representing a project or community include using an official project e-mail -address, posting via an official social media account, or acting as an appointed -representative at an online or offline event. Representation of a project may be -further defined and clarified by project maintainers. - -This Code of Conduct also applies outside the project spaces when the Project -Steward has a reasonable belief that an individual's behavior may have a -negative impact on the project or its community. - -## Conflict Resolution - -We do not believe that all conflict is bad; healthy debate and disagreement -often yield positive results. However, it is never okay to be disrespectful or -to engage in behavior that violates the project’s code of conduct. - -If you see someone violating the code of conduct, you are encouraged to address -the behavior directly with those involved. Many issues can be resolved quickly -and easily, and this gives people more control over the outcome of their -dispute. If you are unable to resolve the matter for any reason, or if the -behavior is threatening or harassing, report it. We are dedicated to providing -an environment where participants feel welcome and safe. - -Reports should be directed to , the -Project Steward(s) for UCP. It is the Project Steward’s duty to -receive and address reported violations of the code of conduct. They will then -work with a committee consisting of representatives from the Open Source -Programs Office and the Google Open Source Strategy team. If for any reason you -are uncomfortable reaching out to the Project Steward, please email -. - -We will investigate every complaint, but you may not receive a direct response. -We will use our discretion in determining when and how to follow up on reported -incidents, which may range from not taking action to permanent expulsion from -the project and project-sponsored spaces. We will notify the accused of the -report and provide them an opportunity to discuss it before any action is taken. -The identity of the reporter will be omitted from the details of the report -supplied to the accused. In potentially harmful situations, such as ongoing -harassment or threats to anyone's safety, we may take action without notice. - -## Attribution - -This Code of Conduct is adapted from the Contributor Covenant, version 1.4, -available at - diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md deleted file mode 100644 index b06b27d62..000000000 --- a/CONTRIBUTING.md +++ /dev/null @@ -1,247 +0,0 @@ - - -# How to Contribute - -We would love to accept your patches and contributions to this project. - -## Before you begin - -### Sign our Contributor License Agreement - -Contributions to this project must be accompanied by a -[Contributor License Agreement](https://cla.developers.google.com/about) (CLA). -You (or your employer) retain the copyright to your contribution; this simply -gives us permission to use and redistribute your contributions as part of the -project. - -If you or your current employer have already signed the Google CLA (even if it -was for a different project), you probably don't need to do it again. - -Visit to see your current agreements or to -sign a new one. - -### Review our Community Guidelines - -This project follows [Google's Open Source Community -Guidelines](https://opensource.google/conduct/). - -## Other Ways to Contribute - -### Reporting Issues - -If you find a bug, a mistake in the documentation, or have a feature request, -please open an issue. -This helps us track problems and improve the project. - -### Discussions - -If you want to start a conversation, share an idea, or ask a question, feel free -to use GitHub Discussions. - -## Contribution Process - -### Significant Changes - -Any significant change to the protocol requires a formal -[Enhancement Proposal](../../issues/new?template=enhancement-proposal.md) -and will require Technical Committee approval. Because a change to the protocol -requires the entire adopting ecosystem to implement the change, we consider -significant changes to include: - -* Core Schema Modifications: Any change to JSON schemas, including - adding/updating fields or field descriptions -* Protocol Changes: Alterations to communication flows or expected behaviors of - operations -* New API Endpoints: Introduction of entirely new capabilities or services. -* Backwards Incompatibility: Any "breaking" change that requires a major version - increment. - -An [Enhancement Proposal](../../issues/new?template=enhancement-proposal.md) -is a living artifact that tracks a proposal through its lifecycle: - -* **Proposal:** Anyone can submit; idea is proposed and debated. -* **Provisional:** TC majority vote to accept; enters working draft iteration. -* **Implemented:** TC majority vote to finalize; code complete and merged. - -Every [Enhancement Proposal](../../issues/new?template=enhancement-proposal.md) -must follow a standard template requiring sections for a Summary, Motivation, -Detailed Design, Risks, a Test Plan, and Graduation Criteria. This creates a -permanent, public design record for the project's evolution. - -### Capability Maturity Levels - -After an Enhancement Proposal reaches "Provisional" status, the capability -enters the maturity lifecycle with the following stability guarantees: - -#### Working Draft - -* **Version:** `Working Draft` -* **Stability:** Breaking changes expected -* **Status:** Prototyping, gathering feedback, iterating on design -* **Exit criteria:** TC majority vote to advance - -#### Candidate - -* **Version:** `Candidate` -* **Stability:** API surface stable; implementation details may evolve -* **Status:** Early adopter implementations, production pilots -* **Exit criteria:** TC majority vote to advance - -#### Stable - -* **Version:** `YYYY-MM-DD` (date-based version assigned) -* **Stability:** Full backward compatibility within major version -* **Status:** Production deployments - -### Voting and decision making - -The path below should be followed for resolving issues that are technical in -nature. - -* L1: routine changes (bug fixes, documentation, minor improvements) require - approval from at least 2 Maintainers. -* L2: Any technical issues that span across topics and/or cannot be resolved - amongst maintainers and DWGs will be escalated to the TC. Significant changes - affecting core protocol architecture must follow the Enhancement Proposal - process, requiring TC approval before implementation. -* L3: Any changes made to the Governance process (e.g updating the - [GOVERNANCE.md](GOVERNANCE.md) file) or any changes that impact the core - protocol’s scope or adoption, must be approved by Governance Council (GC). - -The TC reserves the right to stop any discussions deemed non-critical to the -protocol. - -### Versioning - -The base protocol uses date based versioning. Major version increments (breaking -changes) require a majority Governing Council approval due to the high cost to -the ecosystem. A quorum requires all Governing Council members (or appropriate -representatives) to be present for decision-making. New features should -typically be attempted through the extensions framework first. If an extension -achieves significant usage, it can be considered for adoption into the next -minor version of the core. - -### Adding new extensions and capabilities to the core protocol - -UCP is designed to be extensible while keeping the core protocol light. A -core principle of UCP is to ensure that the set of extensions and capabilities -defined in UCP have broad ecosystem support. Vendors should first create -capabilities & extensions in vendor-specific namespace pattern -(e.g. com.{vendor}.*) for new use cases. Requests to add new capabilities and -extensions should only be submitted when there is proven widespread adoption of -vendor-specific capabilities and extensions. See -[Spec URL Binding](https://ucp.dev/specification/overview/#spec-url-binding) -and [Governance Model](https://ucp.dev/specification/overview/#governance-model) -for more details on using namespace pattern for creating vendor-specific -capabilities and extensions. - -### Code Reviews - -All submissions, including submissions by project members, require review. We -use [GitHub pull requests](https://docs.github.com/articles/about-pull-requests) -for this purpose. - -### Pull Request Titles and Commit Messages - -This repository enforces **Conventional Commits** for Pull Request titles. -Your PR title must follow this format: `type: description`. If your change -is a breaking change (e.g., removing a schema field or file), you **must** -add `!` before the colon: `type!: description`. - -**Common Types:** - -* `feat`: A new feature -* `fix`: A bug fix -* `docs`: Documentation only changes -* `style`: Changes that do not affect the meaning of the code -* `refactor`: A code change that neither fixes a bug nor adds a feature -* `perf`: A code change that improves performance -* `test`: Adding missing tests or correcting existing tests -* `chore`: Changes to the build process or auxiliary tools and libraries - -**Examples:** - -* `feat: add new payment gateway` -* `fix: resolve crash on checkout` -* `docs: update setup guide` -* `feat!: remove deprecated buyer field from checkout` - -### Linting and Automated Checks - -We use linters and automated checks to maintain code quality and consistency. -These checks run automatically via GitHub Actions when you open a pull request. -Your pull request must pass all checks before it can be merged. - -You can run many of these checks locally before committing by installing and -using `pre-commit`: - -```bash -uv tool install pre-commit -pre-commit install -``` - -This will set up pre-commit hooks to run automatically when you `git commit`. - -You can also run [super-linter](https://github.com/super-linter/super-linter) -locally by running `./scripts/super_linter_local.py`. This assumes you have -either [docker](https://www.docker.com/) or [podman](https://podman.io/) -installed on your system. - -### Submitting a Pull Request - -1. Fork the repository and create your branch from `main`. -2. Make your changes, ensuring you follow the setup instructions below. -3. If you've installed `pre-commit`, it will run checks as you commit. -4. Ensure your pull request title follows the Conventional Commits format. -5. Fill out the pull request template in GitHub, providing details about - your change. -6. Push your branch to GitHub and open a pull request. -7. Address any automated check failures or reviewer feedback. - -## Local Development Setup - -### Schema Development - -Schemas live in `source/` and are published with `ucp_*` annotations intact. -Agents use [ucp-schema](https://github.com/universal-commerce-protocol/ucp-schema) -to resolve annotations for specific operations at runtime. - -1. Ensure `ucp-schema` is installed: - - ```bash - cargo install ucp-schema # from crates.io - cargo install --git https://github.com/universal-commerce-protocol/ucp-schema # from git - ``` - -2. Make updates to JSON files in `source/` -3. Run `ucp-schema lint source/` to validate syntax and references - -If you change any JSON schemas, you may need to regenerate SDK client libraries. -For example, to regenerate Python Pydantic models run -`bash sdk/python/generate_models.sh`. Our CI system runs -`scripts/ci_check_models.sh` to verify that models can be generated -successfully from the schemas. - -### Documentation Development - -This project uses [uv](https://docs.astral.sh/uv/) for Python dependency management. - -1. Install Python dependencies: `uv sync` -2. Ensure `ucp-schema` is installed (see above) -3. Run the development server: `uv run mkdocs serve --watch source` -4. Open **** in your browser -5. Before submitting, run `uv run mkdocs build --strict` to check for warnings/errors diff --git a/GOVERNANCE.md b/GOVERNANCE.md deleted file mode 100644 index 3a8249d5f..000000000 --- a/GOVERNANCE.md +++ /dev/null @@ -1,101 +0,0 @@ - - -# Governance - -## Core Principles - -* Members are chosen and promoted to various committees based on their actual - contributions. -* Members work towards the overall health and adoption of a more open - ecosystem and agnostic to interests of the companies they represent. - -## Contributors - -* Open - Anyone can contribute but needs to sign a contributor license. - See [`CONTRIBUTING.md`](CONTRIBUTING.md) for details. -* All code changes need to be approved by at least 1 maintainer elected by - Tech Council (TC) and all TC members are cc’ed. - -## Maintainers - -* Responsible for reviewing and approving code changes to ensure they align - with the project's technical standards and governance principles. -* Build tools and documentation to facilitate adoption of the protocol. -* Tech Council (TC) can add, remove & nominate maintainers as needed. -* All code changes require approval from at least one Maintainer. - -### Domain Working Groups (DWG) - -* Because the TC cannot be experts in every field, Domain Working Groups - (DWG) may be formed as a natural part of expanding the protocol. -* DWG are subject to TC oversight - all DWG artifacts must be reviewed and - approved by the TC. -* Acts as the consensus venue for industry participants (e.g., multiple - airlines) to agree on shared interoperability standards within the - protocol, maintain the specific documentation and implementation guides for - their domain's capabilities. -* A group of 3+ organizations can submit a charter to the Governing Council - to form a DWG (e.g., "Travel WG"). Once chartered, the DWG has autonomy to - define capabilities for their domain and submit for TC approvals. - -## Tech Council (TC) - -* Responsible for maintaining core technical changes to the spec, e.g., adding - new features, reviewing enhancement proposals etc. -* Elected by the Governing Council (GC). -* Includes 8 core members, 4 from each founding organization (Google & - Shopify), each with 1 vote (total 8 votes). -* Includes 4 members from any org, each with 1 vote (total 4 votes), elected - by the TC every 6 months, based on their technical contributions towards the - protocol. Members can be re-elected any number of times. -* Decisions are made with a majority vote. -* Any TC member may request a review from the Governing Council at any time - for any additional inputs. - -## Governing Council (GC) - -* Responsible for governance, overall health and adoption of the protocol. -* GC serves as the ultimate owner of all UCP assets. Google - acts as the custodian of the UCP.dev domain, holding and managing it solely - for the benefit of the Council and the partnership’s collective interests. -* Includes a total of 2 core members, with each founding organization - (Google & Shopify) having 1 core member, each with 1 vote (total 2 votes). -* Includes 1 member elected annually by the GC for contributions to the - protocol's health and adoption from any organization. For the first year, - this seat is open, and Google holds the proxy vote for this seat, to - facilitate rapid early stage growth & adoption of the protocol. -* Can add/remove TC members via simple majority vote. -* May choose to review and veto TC decision or recommendation. -* Decisions are made with a majority vote. - -## Communication - -To ensure the protocol remains open and agnostic, all governance activities must -be visible, accessible, and searchable. All communication that is intended to be -public (concerning, e.g., adding a capability before creating an extension, -debating one approach versus another, or announcements relating to upcoming -launches, etc.) shall take place on a shared Google group with a mailing list. -This includes discussion on enhancement proposals, announcements about official -specification changes and final governance votes. - -* **TC & DWG Meetings:** Agendas should be posted 24 hours in advance. Minutes - and meeting notes should be published to the repository within 1 week of the - meeting conclusion. TC reserves the right to redact or edit meeting notes as - needed. -* **Governing Council Meetings:** Summaries of strategic decisions and budget - allocations will be published quarterly (specific sensitive partnership - discussions may remain private). diff --git a/SECURITY.md b/SECURITY.md deleted file mode 100644 index 7d78a307f..000000000 --- a/SECURITY.md +++ /dev/null @@ -1,25 +0,0 @@ - - -# Security Policy - -To report a security issue, please use [g.co/vulnz](https://g.co/vulnz). - -The Google Security Team will respond within 5 working days of your report on -g.co/vulnz. - -We use g.co/vulnz for our intake, and do coordination and disclosure here using -GitHub Security Advisory to privately discuss and fix the issue.