Merge pull request #1 from tdcmeehan/initial

Add the initial RFC template and instructions

Author: tdcmeehan

CONTRIBUTING.md

@@ -0,0 +1,74 @@
+This page contains instructions on how to propose and implement feature changes to Presto.
+
+# The Request for Comments
+
+## Overview of the process
+
+```mermaid
+graph TD;
+    id1["Create an RFC"]-->id2["Get feedback on the RFC"];
+    id2["Get feedback on the RFC"]-->id3["RFC is closed"];
+    id2["Get feedback on the RFC"]-->id4["RFC is merged"];
+    id4["RFC is merged"]-->id5["Create a Github issue linking the RFC"];
+    id5["Create a Github issue linking the RFC"]-->id6["Create PRs implementing the RFC (link to the issue)"];
+```
+
+## Step 1: Create an RFC
+RFCs are located in their own repository.
+
+To create one:
+
+1. Fork the https://github.com/prestodb/rfcs repository
+2. Copy the template file `RFC-0000-template.md` to `RFC-00xx-your-feature.md` and fill it out with your proposal.
+   The template is a guideline, feel free to add sections as appropriate
+3. You may also have the template simply link to another editor, like a Google Docs file, but please ensure that the
+   document is publicly visible.  This can make the template easier to add edit, but commenting doesn’t scale very well, so
+   please use this option with caution.
+
+## Step 2: Get Feedback on the RFC
+1. Submit a pull request [to the main repository](https://github.com/prestodb/rfcs) from your fork titled 
+`RFC-00xx-your-feature.md`
+2. Before your PR is ready for review,
+   [mark the PR as draft](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request#converting-a-pull-request-to-a-draft).
+3. Once it’s ready for review, [move the PR out of draft](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request#marking-a-pull-request-as-ready-for-review).
+4. A committer will review your proposal.
+5. Build consensus. Those committers will review your PR and offer feedback. Revise your proposal as needed until
+   everyone agrees on a path forward. Additional forums you can share the proposal on include the
+   [the mailing list](https://lists.prestodb.io/g/presto-dev), and the
+   [Slack channel in #dev](https://communityinviter.com/apps/prestodb/prestodb). Tagging interested stakeholders
+   (identifiable via [CODEOWNERS](https://github.com/prestodb/presto/blob/master/CODEOWNERS)) can help with consensus building.
+
+_(Note: A proposal may get rejected if it comes with unresolvable drawbacks or if it’s against the long term plans of the Presto committers)_
+
+## Step 3: Implement your Feature
+1. If your RFC PR is accepted then the PR will be merged.
+2. As soon as possible, create an issue in Github in the relevant repository (most likely
+   [prestodb/presto](https://github.com/prestodb/presto)) summarizing the RFC and linking to it.
+3. When you submit PRs to implement your proposal, remember to link to your issue that has a link to the RFC
+   so that reviewers catch up on the context.
+
+
+
+## Implementing an RFC
+Every accepted RFC has an associated issue tracking its implementation in the Presto repository; thus that
+associated issue can be assigned a priority via the triage process that the team uses for all issues.
+
+The author of an RFC is not obligated to implement it. Of course, the RFC
+author (like any other developer) is welcome to post an implementation for
+review after the RFC has been accepted.
+
+If you are interested in working on the implementation for an accepted RFC, but
+cannot determine if someone else is already working on it, feel free to ask
+(e.g. by leaving a comment on the associated issue).
+
+
+## RFC Rejection
+Some RFC pull requests will be closed without the RFC being merged (as part of the rejection process). A closed RFC
+is closed because we would prefer not to evaluate the proposal or implement the described feature
+until some time in the future, and we believe that we can afford to wait until then to do so.
+
+## Inspiration
+Presto's RFC process owes inspiration to the [PyTorch RFC Process](https://github.com/pytorch/rfcs) and [Hudi RFC Process](https://hudi.apache.org/contribute/rfc-process/).
+
+## License
+By contributing to rfcs, you agree that your contributions will be licensed under the LICENSE file in the root directory of this source tree.

README.md

@@ -1,2 +1,27 @@
-# rfcs
-Presto RFCs
+# Presto RFCs
+
+Presto uses RFCs to propose major features.
+
+## Proposing a Feature to Presto
+
+To propose a new feature, you’ll submit a Request For Comments (RFC).  This RFC is basically a design proposal where
+you can share a detailed description of what change you want to make, why it’s needed, and how you propose to implement
+it.
+
+It’s easier to make changes while your feature is in the ideation phase vs the PR phase, and this doc gives committers
+an opportunity to suggest refinements before you start code.  For example, they may know of other planned efforts that
+your work would otherwise collide with, or they may suggest implementation changes that make your feature more broadly
+usable.
+
+Smaller changes, including bug fixes and documentation improvements can be implemented and reviewed via the normal
+GitHub pull request workflow on the main Presto repo.
+
+RFCs are more suitable for design proposals that are too large to discuss on a feature-request issue, like adding new
+functionality to Presto, or if a discussion about the tradeoffs involved in a new addition are non-trivial.
+
+If you are unsure whether something should be an RFC or a feature-request issue, you can ask by opening an issue in the
+main [prestodb/presto](https://github.com/prestodb/presto) repository.
+
+## How to add an RFC
+
+See [CONTRIBUTING.md](CONTRIBUTING.md) for instructions on how to propose an RFC.

RFC-0000-template.md

@@ -0,0 +1,57 @@
+# **RFC0 for Presto**
+
+See [CONTRIBUTING.md](CONTRIBUTING.md) for instructions on creating your RFC and the process surrounding it.
+
+## [Title]
+
+Proposers
+
+*
+*
+
+## [Related Issues]
+
+Related issues may include Github issues, PRs or other RFCs.
+
+## Summary
+
+Briefly describe what you intend to propose
+
+## Background
+
+Brief description of any existing issues, user requests or feature comparison with competitors which explains why the proposed feature might be needed. How the proposed feature helps our users? Explain the impact and value of this feature.
+
+### [Optional] Goals
+
+### [Optional] Non-goals
+
+## Proposed Implementation
+
+How do you intend to implement the feature? This section can be as detailed as possible with large subsections of its own, or may be a few sentences depending on the scope of the feature proposed. Explain the design in enough detail for existing users/contributors to understand. Design should include all the corner cases you can think of. Feel free to include any new SPI method signatures, class hierarchies or system contracts here. It is recommended to mention any methods, variables, classes, or SQL language additions which you think are needed to provide a broader view of the code changes. Please mention/describe the below on a high level -
+
+1. What modules are involved
+2. Any new terminologies/concepts/SQL language additions
+3. Method/class/interface contracts which you deem fit for implementation.
+4. Code flow using bullet points or pseudo code as applicable
+5. Any new user facing metrics that can be shown on CLI or UI.
+
+## [Optional] Metrics
+
+How can we measure the impact of this feature?
+
+## [Optional] Other Approaches Considered
+
+Based on the discussion, this may need to be updated with feedback from reviewers.
+
+## Adoption Plan
+
+- What impact (if any) will there be on existing users? Are there any new session parameters, configurations, SPI updates, client API updates, or SQL grammar?
+- If we are changing behaviour how will we phase out the older behaviour?
+- If we need special migration tools, describe them here.
+- When will we remove the existing behaviour, if applicable.
+- How should this feature be taught to new and existing users? Basically mention if documentation changes/new blog are needed?
+- What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?
+
+## Test Plan
+
+How do we ensure the feature works as expected? Mention if any functional tests/integration tests are needed. Special mention for product-test changes. If any PoC has been done already, please mention the relevant test results here that you think will bolster your case of getting this RFC approved.