MySQL Community Developer Guide
MySQL Community Developer Guide
Table of Contents
- MySQL Community Developer Guide
- Why this Developer Guide exists
- What’s changing
- Phased approach to how this will be implemented
- Transparency & participation (Phase 1 actions)
- How to request features (FRs)
- Release Candidate feedback
- How to contribute code (patches)
- MySQL Contributions via Github pull request
- Community metrics & communications (what we’ll measure)
1. MySQL Community Developer Guide
2. 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.
3. What’s changing
3.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.
3.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.
3.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.
4. Phased approach to how this will be implemented
4.1 Phase 1 — Use existing tools, increase transparency for the next release in April 2026
4.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
4.2 Phase 2 — Increase openness and contributions
4.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
4.3 Phase 3 — Evaluate and iterate
4.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
5. Transparency & participation (Phase 1 actions)
5.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.
- AI & Cloud alignment
- Developer experience
- Performance
- Observability
- Extensibility
- Ecosystem/tooling/connectors
Roadmap updates will reflect what’s changed and why (as feasible).
5.2 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.
5.3 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.
5.4 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.
6. How to request features (FRs)
6.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.
6.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)
6.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)
7. Release Candidate feedback
Release Candidates are focused on validating release readiness, so during the RC 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 RC.
7.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)
8. How to contribute code (patches)
8.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.
8.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/
9. 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. The community has now extended this same OCA-based acceptance process to include contributions proposed via GitHub pull requests with MySQL source code on GitHub http://github.com/mysql
10. 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. Please join our March 23, 2026, Public Discussion on this topic.
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.