MySQL Community Developer Guide

Table of Contents

  1. Why this Developer Guide exists
  2. What’s changing
  3. Phased approach to how this will be implemented
  4. Transparency & participation (Phase 1 actions)
  5. How to request features (FRs)
  6. Early Access Release Builds feedback
  7. How to contribute code (patches)
  8. MySQL Contributions via Github pull request
  9. Community metrics & communications (what we’ll measure)

1. Why this Developer Guide exists

MySQL’s strength comes from its community. This Developer Guide describes how we will:

  • Reinvigorate MySQL Community engagement based on community feedback
  • Deliver more innovation into MySQL Community Edition
  • Expand and grow the ecosystem
  • Increase transparency and participation by making it easier to contribute while preserving MySQL’s quality, stability, and security

Your feedback is essential to shaping what comes next.

2. What’s changing

2.1 More innovation in Community Edition

Some features that were previously available only in commercial offerings will be included in MySQL Community Edition, where it’s safe and appropriate.

2.2 A more developer-forward focus

We’ll prioritize improvements that help developers build, run, and evolve applications on MySQL—without compromising compatibility or operational stability.

2.3 A clearer path to contribute

We’re strengthening the contribution pipeline so community members can more reliably propose features, provide patches, validate early builds and influence priorities through transparent feedback loops.

3. Phased approach to how this will be implemented

3.1 Phase 1 — Use existing tools, increase transparency for the next release in April 2026

3.1.1 Key outcomes

  • Publish a Community Roadmap and keep it updated
  • Enable, track and triage Feature Requests (FRs) mapping to the Community Roadmap in a consistent way
  • Increase visible engagement in bug triage and feedback, including CVE communications
  • Offer Early Access Release (EA) builds to gather feedback
  • Publish select worklogs
  • Public MySQL Community Discussions

3.2 Phase 2 — Increase openness and contributions

3.2.1 Key outcomes

  • Improve end-to-end contribution experience (guidance, review loops, predictability)
  • Increase Community Contributions to MySQL Community Edition
  • Expand transparency, visibility and opportunities for participation
  • Make it easier to collaborate on in-flight work
  • Continue to host Public MySQL Community Discussions and Contributor Discussions

3.3 Phase 3 — Evaluate and iterate

3.3.1 Key outcomes

  • Review what worked, what didn’t, and refine process/tools accordingly
  • Adjust roadmap practices and goals based on outcomes and community input

4. Transparency & participation (Phase 1 actions)

4.1 Community Roadmap

We will publish a Community Roadmap, then invite feature requests against it.

Feature requests will be triaged based on alignment to roadmap themes mentioned below.

MySQL Community Roadmap

  • AI & Cloud alignment
  • Developer experience
  • Performance
  • Observability
  • Extensibility
  • Ecosystem/tooling/connectors

Roadmap updates will reflect what’s changed and why (as feasible).

4.2 Contributor Summit Proposal Scope

Contributor Summit proposals should focus on features, improvements, or initiatives that the submitting contributor or organization intends to actively develop or drive forward.

The purpose of the Contributor Summit is to encourage discussion, technical collaboration, and review of contributions; priority will be given to requests that are aligned with the MySQL Community roadmap categories.

Proposals intended as feature suggestions for others to implement can follow the MySQL new feature request instructions and may be selected by another community contributor. Please note this in the request.

4.3 Selected work visibility

We’ll increase visibility into planned work items (e.g., selected work items/design notes) where appropriate.

Some items may remain limited due to security, privacy, or responsible disclosure needs.

4.4 Bug triage: faster signals, better engagement

Improve responsiveness and clarity in bug/FR triage outcomes (e.g., needs info, duplicate, accepted for review, deferred).

Encourage high-quality reports and constructive dialogue.

4.5 Early Access (EA) Releases

At feature freeze/code cut, we plan to provide EA builds intended for development/testing.

EA feedback will be used to improve quality, compatibility, and documentation before final release.

4.6 Community Wiki (GitHub)

https://github.com/mysql/mysql-community/wiki

  • Best practices and implementation guidance
  • Contribution-related documentation and examples
  • Notes from community discussions, proposals, and design ideas
  • Additional resources to support developers and contributors

Content will evolve over time based on community input and ongoing contributions.

We encourage community members to review, suggest updates, and contribute where appropriate.

5. How to request features (FRs)

5.1 Where to file

File feature requests in the MySQL public bug system (the same place bugs are tracked), using the appropriate severity type for feature requests.

5.2 What to expect

Triage outcomes will typically include existing fields:

  • Analyzing (under discussion / being evaluated)
  • In Review (accepted for deeper evaluation)
  • Verified (tracked, but deferred/unsupported for now)
  • Won’t Fix (declined, with rationale when possible)
  • Closed (Implemented in the product)

5.3 Feature Request checklist

  • Choose Severity S4 for FEATURE_REQUEST
  • For any feature requests aligned to the roadmap themes highlighted above, use the tag ROADMAP_CANDIDATE. (You can still submit feature requests outside of the roadmap without using this tag)
  • Clear problem statement
  • Why it matters (impact)
  • Proposed approach (optional)
  • Compatibility considerations
  • Examples / test case / sample schema (sanitized)

5.4 How to Submit New Feature Request

  1. Identify the feature you would like to request.
  2. Complete the Design Proposal Template.
  3. File a feature request in the MySQL public bug system.
  4. Attach the Design Proposal from step 2.

6. Early Access Release Builds feedback

Early Access(EA) release builds are focused on validating release readiness, so during the EA window we primarily accept feedback on critical/severe issues (e.g., crashes, data loss, security issues, major regressions, or upgrade/replication failures). Lower-severity issues and feature requests are still welcome but are typically deferred to a future release rather than addressed in EA.

6.1 ER feedback checklist

  • Enter appropriate Version/build identifier (Use the ER version/build number) e.g. 9.7.0-ER
  • Use tag EARLY_RELEASE
  • Repro steps
  • Expected vs actual behavior
  • Logs/metrics/benchmarks (sanitized)

7. How to contribute code (patches)

7.1 Contribution requirement: OCA

To contribute code that can be incorporated into MySQL, contributors must have a signed Oracle Contributor Agreement (OCA), and confirm that each contribution is submitted under the OCA terms.

7.2 Where to submit

To ensure contributions are reviewable and legally usable, submit patches via the official contribution submission mechanism in the MySQL public bug system (i.e., the dedicated contribution submission path/tab).

For more information please see: https://dev.mysql.com/community/contributing/

8. MySQL Contributions via Github pull request

To make contributions easier to track and integrate, MySQL has been accepting submissions through the MySQL bug system, providing clear intake, review, and status visibility. This same OCA-based acceptance process can be used for contributions proposed via GitHub pull requests with MySQL source code on GitHub http://github.com/mysql

9. Community metrics & communications (what we’ll measure)

We will work with the community to define baseline metrics and set shared goals, then report progress over time. Information and updates from our Public Discussions with the community are available on the MySQL Community Wiki: https://github.com/mysql/mysql-community/wiki

We will also provide clear, timely updates on submitted bugs, feature requests, and Early Access (EA) feedback, including status changes, next steps, and when possible, brief rationale for decisions.