Announcing Vector Tile 3.0 Specification Development

Nobody has claimed this yet.

At Mapbox we have been amazed by the success of our Vector Tile specification and have greatly enjoyed seeing the many different technologies that have grown around it since our initial public release of a specification almost 4 years ago. It has been quite a journey and we have learned so much along the way. We started the last change to the specification approximately 2.5 years ago to make sure that the development community developed a truly interchangeable format, but the time has come to consider further updates to the specification.

I am very much excited to announce that we are now beginning work on Mapbox Vector Tile Specification version 3 (VT3).

# Why Now?

In the past 4 years since the original vector tile specification was released many changes have been proposed for the Vector Tile format, many of which have been collected as issues of this repository. These proposed changes have been driven by many different causes and have highlighted many different needs of the specification going forward. We now believe that this is the right time to start experimenting with these different proposed changes.

# What Will Change?

In our last update of the specification we purposefully held back from any major changes to the format and focused instead on solidifying the original design and documenting what was not obvious prior. This meant that many great ideas we simply saved for a later date instead of considering for v2 of the specification. For VT3 we are opening the possibility of breaking changes to the specification.

## North Star

There are somethings about Vector Tiles that will never change. They will always be designed to:

* Deliver data at a massive scale
* Support high levels of data compression

# How will this happen?

We will be reviewing internally at Mapbox different ideas that we have been considering over the years in various repositories and will begin to migrate these ideas to issues in this repository. Those external to Mapbox are welcome to join in the process as we will be attempting to do as much as we can in the open and welcome others.

Once each issue has been added, I will add it as quickly as possible to the "Proposal Tracking Issue" that I will be opening shortly. Each proposal will be given one of the following status, which it could likely progress through:

1. Technical Design
2. Prototyping
3. Specification Writing
4. Accepted
5. Closed

The migration of issues between these steps will be controlled by the Vector Tile Working Group (@mapbox/vt-working-group) at Mapbox. The Working Group will be responsible for reviewing specific ideas, prototypes, and issues to make sure that the Vector Tile specification is well suited not only for Mapbox but also for other developers and applications using the specification. The Working Group will be responsible for what is accepted into the specification and what is not.

I will be acting as "Lead Author" during this development process. My responsibilities will be to support the Working Group by providing coordination of different efforts within the Working Group. Additionally, I will be focused on supporting any contribution from outside Mapbox. Finally, I will also be responsible for collecting accepted technical changes into a final edited specification, which we will then present for a final review.

## Technical Design

This is the first step a proposal will involve. It is the discovery phase of the process and often starts with simply stating something that is missing from the specification. This primarily is brainstorming, designing and scoping prior to the start of prototyping work. During this phase the following should be addressed:

* What is the problem?
* What is a proposed change to solve this problem?
* Does this belong in the Vector Tile specification?
* What needs to be prototyped?

## Prototyping

After a technical design has been completed, prototyping of a change will begin. This will be testing how effectively a design would work with:

* Encoders
* Decoders
* Downstream users and software

There are many different items to consider during this step and it is where a majority of time might be spent after an initial design is proposed. For each proposal the exact steps of a prototype might be slightly different, but prototype software in general should be linked to the issue for others to experiment with during this stage.

## Specification Writing

After a prototype step has been completed for a proposal and the technical changes accepted by the VT Working Group, work can start on the written changes to the specification. This will be done as a PR in this repository and will be merged in once it is ready.

## Accepted

Once a final specification change is accepted and merged in via PR, the proposal will be considered accepted and will be part of the V3 final specification.

## Closed

At any point during the above process a proposal might be moved to the closed state. Closing simply means that this issue will not be a part of the VT3 efforts. Some ideas might be recycled for later releases or might prompt other actions or efforts to be started.

# Timeline

Currently the only hard timeline that we can broadcast is the time period for submission of Technical Designs. This will be closed after July 1, 2018. Other dates in the timeline will be announced as we go through the process.

# Questions You Might Have

#### Who is allowed to participate in this process?

We encourage anyone who has interest in this process to speak up at any stage of the process with their concerns or comments. If you are interested in proposing an idea please check other existing issues before opening a new issue in this repository. If you need any other support with any proposal please `/cc @flippmoke` as necessary. Additionally, you may email me at `blake@mapbox.com`.

#### How long will this process take?

The timeline for this will greatly depend on many factors but we hope for a final release within a year **at the latest** of this process starting.

#### How do I express my approval or disapproval for an idea?

Please use the thumbs up or thumbs down reactions on GitHub to issues. Short responses of approval of disapproval here could become overwhelming otherwise.

#### Do we have a code of conduct?

Yes, https://github.com/mapbox/vector-tile-spec/blob/master/CODE_OF_CONDUCT.md. If you have any issue with anyone's actions during this process please email me at `blake@mapbox.com`.

#### Will people outside Mapbox be part of the Working Group?

The Working Group is currently limited to Mapbox employees. If you are outside Mapbox and are looking to have a larger contribution on the specification please email me and we can discuss how you could best work with members of the Working Group and have a bigger role in the process.

#### Will the specification be moved to a standards body outside Mapbox?

During this process we are not currently planning on moving the specification to be under the review of a standards body. We have always made the specification more open for this migration by licensing it under Creative Commons, but do not have any plans internally at Mapbox to lead such an effort.

#### How much is likely to change about the specification as part of VT3?

We are not entirely sure at this point. We will learn more as we continue in this process. We are very aware that many people have adopted technology that relies heavily on VTs. We also realize that changes to encoders and decoders can be very difficult, especially when there are multiple versions of specifications to consider. For these reasons alone we are always hesitant to change aspects of the specification as it can possibly cause painful transitions. However, we also want to allow new and exciting features that will make VTs even more useful. We know this is a balance and we are going to carefully consider all impacts of any changes to the specification.

Start by reviewing the existing issues in this repository and the Technical Design process described here; no implementation file, test, or specific proposal is identified. The issue mentions CODE_OF_CONDUCT.md and later specification-writing pull requests, but does not define a concrete change. Done would require a scoped VT3 proposal with a problem statement, proposed change, prototyping needs, and an accepted specification update.

Written by the indexing model from the issue text.