Roadmap
The Presto roadmap is tracked in GitHub issues under the Roadmap issue label. The purpose of roadmap issues is to provide a collaboration point where people who want to effect larger changes can communicate the reasoning and design behind those changes as well as track implementation progress. Interested parties are then able to comment on the higher level roadmap issues as well as any sub-issues linked from the main roadmap issue.
Presto roadmap items should be things that are under active development. Roadmap issues should be closed with a comment if they are abandoned and not likely to make progress. A new roadmap issue can be created or an existing issue can be reopened when work resumes.
Roadmap items should be higher level and larger. A single enhancement to output of the CLI is too small. The entirety of Project Aria (optimizing scan, repartitioning, and hash join) is too large.
Exchange Materialization (https://github.com/prestodb/presto/issues/12387) is a good example of a large project that is focused on a single thing. The goal is that discussion won’t wander across many different subjects preventing progress from being made.
PRs associated with a roadmap issue should reference the roadmap issue so that Github adds a link to the PR. Sub-task issues or bugs should also reference the roadmap issue so that any discussion that occurs in them can be found from the roadmap issue.
There are no hard and fast rules as to what must be included a roadmap issue.
Some of the goals of roadmap issues:
- Communicate to potential collaborators what is under active development
- Solicit design feedback to avoid false starts and major changes later on
- Allow reviewers to see the larger context behind PRs
- Allow others to monitor progress of the project
Here some sections you might consider adding:
Explain why this change is necessary. What are the pain points being eliminated or potential benefits?
This is where you can specify the success criteria.
What isn’t going to be achieved. It’s important to reduce scope and ship smaller changes faster where possible.
How you intend to address the problem and achieve the goals.
Alternate solutions that were considered and why they were discarded.
People who are driving this set of changes and are responsible for addressing questions or concerns.
Self explanatory.
If there is uncertainty it’s important to call it out. It is possible effort should be made to reduce uncertainty.
What testing for performance and correctness is required?
Documentation, performance, API (user and internal), testing.