Skip to content

Roadmap

aweisberg edited this page Aug 12, 2019 · 74 revisions

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.

Granularity

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.

Work tracking

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.

Content

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:

Problem description

Explain why this change is necessary. What are the pain points being eliminated or potential benefits?

Goals

This is where you can specify the success criteria.

Non-goals

What isn’t going to be achieved. It’s important to reduce scope and ship smaller changes faster where possible.

Proposed changes

How you intend to address the problem and achieve the goals.

Alternate solutions

Alternate solutions that were considered and why they were discarded.

Points of contact

People who are driving this set of changes and are responsible for addressing questions or concerns.

Dependencies

Self explanatory.

Risks

If there is uncertainty it’s important to call it out. It is possible effort should be made to reduce uncertainty.

Test

What testing for performance and correctness is required?

Impact

Documentation, performance, API (user and internal), testing.

Clone this wiki locally