MLflow RFCs

Many changes, including bug fixes and documentation improvements, can be implemented and reviewed via the normal GitHub pull request workflow.

Some changes though are "substantial", and we ask that these go through a lightweight design process to build consensus among the MLflow maintainer team.

The "RFC" (request for comments) process provides a consistent path for significant new features to enter the project.

When to follow this process

You should consider writing an RFC if you intend to make "substantial" changes to MLflow. Examples that would benefit from an RFC:

• A new feature that creates new API surface area
• Removal or deprecation of features that already shipped
• Changes to core architecture or data models
• Introduction of new conventions or workflows that affect users broadly

Some changes do not require an RFC:

• Bug fixes and performance improvements
• Rephrasing, reorganizing, or refactoring
• Addition or removal of warnings
• Changes only visible to MLflow developers, not end users

What the process is

1. Create an issue with enhancement label in the MLflow repository, with the brief description of the problem and the expected outcome.
2. MLflow maintainers will triage the issue and determine if it is a candidate for an RFC. If it is, they will mark the issue with ready label.
3. Once the issue is signed off, create a new directory rfcs/0000-my-feature in this repository (where "my-feature" is descriptive — don't assign a number yet).
4. Copy 0000-template.md to the directory and fill in the RFC. Put care into the details: RFCs that do not present convincing motivation or are not honest about drawbacks tend to be poorly received.
5. Submit a pull request in this repository. The RFC will receive design feedback from the community and maintainers. Be prepared to revise it.
6. Build consensus and integrate feedback.
7. The maintainer team will decide whether the RFC is a candidate for inclusion. This may take time — we encourage you to seek community review first.
8. An RFC may be accepted (merged), rejected (closed with rationale), or deferred for a later time.
9. Once the RFC is accepted, the author or another contributor will implement the feature and submit a pull request to the MLflow repository.

AI usage policy

We encourage using AI tools to explore the MLflow codebase, draft sections, and polish writing. However, an RFC is a thinking exercise, not a generation exercise. Proposals that read as unreviewed AI output may be rejected without detailed feedback.

Before submitting, ask yourself: Would I be comfortable defending every sentence in this document?

Implementing an RFC

The author of an RFC is not obligated to implement it. Once an RFC is accepted, anyone is welcome to submit an implementation as a pull request.

Being accepted is not a guarantee the feature will be merged — it means the team has agreed to it in principle.

Reviewing RFCs

We read all RFCs but cannot always review them promptly. When you submit an RFC, your primary goal should be to generate a rich discussion. Even if a proposal isn't accepted as-is, the resulting conversation often shapes future work in the same area.

Inspiration

This process is inspired by the React RFC process.