xushiyan commented on a change in pull request #3725:
URL: https://github.com/apache/hudi/pull/3725#discussion_r717208114
##########
File path: website/contribute/rfc-process.md
##########
@@ -0,0 +1,56 @@
+---
+sidebar_position: 3
+title: "RFC Process"
+toc: true
+last_modified_at: 2020-09-01T15:59:57-04:00
+---
+
+This page describes a Request For Comments (RFC) process for proposing any
major change to Hudi or even just sharing designs/vision for the project to get
early feedback.
+
+## When do you need an RFC ?
+
+Whenever a feature is considered to be causing a “major change” in the
project, such a feature requires an RFC.
+Any of the following can be considered a major change:
+
+ - Any new component, module or code that introduces a new concept into the
project or alters the behavior of an existing one
+ - Any large code refactor to address general code re-usability and structure.
There is no strong definition for “Large” and whether or not the refactor
requires an RFC can be discussed on the @dev mailing list.
+ - Any change that impacts the underlying storage layout/format. e.g changes
to the HoodieLogFormat, timeline layout version.
+ - New indexing schemes, New deltastreamer sources, New platform services.
+ - Any change that impacts the public interfaces of the project.
+
+It can also be used to describe large direction shifts to the project (e.g:
Flink support) or new green field ideas (e.g Hudi for ML flows)
+Not all RFCs require the same effort and detail. For critical changes such as
the File Format and Index, we need to deeply discuss the trade-offs of
+making such a change and how it impacts current and new users. Any changes to
such components affect the correctness of a dataset (backwards and forward
versions supported).
+Other changes such as code refactor might require more details around
abstractions but as long as there is good test coverage, a migration plan
section can be avoided.
+It may happen that you are making a bunch of changes across many components to
enable an already existing feature. For example, introducing a new config along
with reporting metrics,
+enhancing a tool and also improving documentation and the on-boarding
experience. If all of these changes are linked to a general feature/idea, these
can be grouped together under a single RFC.
+
+## Who should initiate the RFC ?
+Anyone can initiate an RFC. Please note that if you are unsure of whether a
feature already exists or if there is a plan already to implement a similar
one, always start a discussion thread on the dev mailing list before initiating
a RFC. This will help everyone get the right context and optimize everyone’s
usage of time.
+
+## How do you initiate the RFC ?
+
+### Proposing the RFC
+1. First, start a discussion thread on the Apache Hudi dev mailing list. The
subject of the discussion thread can be `DISCUSS <proposed idea>` to create an
RFC.
Review comment:
```suggestion
1. First, start a discussion thread on the Apache Hudi dev mailing list by
sending an email to `[email protected]`. The subject of the discussion
thread can be `DISCUSS <proposed idea>` to create an RFC.
```
##########
File path: website/contribute/rfc-process.md
##########
@@ -0,0 +1,56 @@
+---
+sidebar_position: 3
+title: "RFC Process"
+toc: true
+last_modified_at: 2020-09-01T15:59:57-04:00
+---
+
+This page describes a Request For Comments (RFC) process for proposing any
major change to Hudi or even just sharing designs/vision for the project to get
early feedback.
+
+## When do you need an RFC ?
+
+Whenever a feature is considered to be causing a “major change” in the
project, such a feature requires an RFC.
+Any of the following can be considered a major change:
+
+ - Any new component, module or code that introduces a new concept into the
project or alters the behavior of an existing one
+ - Any large code refactor to address general code re-usability and structure.
There is no strong definition for “Large” and whether or not the refactor
requires an RFC can be discussed on the @dev mailing list.
+ - Any change that impacts the underlying storage layout/format. e.g changes
to the HoodieLogFormat, timeline layout version.
+ - New indexing schemes, New deltastreamer sources, New platform services.
+ - Any change that impacts the public interfaces of the project.
+
+It can also be used to describe large direction shifts to the project (e.g:
Flink support) or new green field ideas (e.g Hudi for ML flows)
+Not all RFCs require the same effort and detail. For critical changes such as
the File Format and Index, we need to deeply discuss the trade-offs of
+making such a change and how it impacts current and new users. Any changes to
such components affect the correctness of a dataset (backwards and forward
versions supported).
+Other changes such as code refactor might require more details around
abstractions but as long as there is good test coverage, a migration plan
section can be avoided.
+It may happen that you are making a bunch of changes across many components to
enable an already existing feature. For example, introducing a new config along
with reporting metrics,
+enhancing a tool and also improving documentation and the on-boarding
experience. If all of these changes are linked to a general feature/idea, these
can be grouped together under a single RFC.
+
+## Who should initiate the RFC ?
+Anyone can initiate an RFC. Please note that if you are unsure of whether a
feature already exists or if there is a plan already to implement a similar
one, always start a discussion thread on the dev mailing list before initiating
a RFC. This will help everyone get the right context and optimize everyone’s
usage of time.
+
+## How do you initiate the RFC ?
+
+### Proposing the RFC
+1. First, start a discussion thread on the Apache Hudi dev mailing list. The
subject of the discussion thread can be `DISCUSS <proposed idea>` to create an
RFC.
+Use this discussion thread to get an agreement from people on the mailing list
that your proposed idea necessitates an RFC.
+2. File an umbrella JIRA for the RFC with the label `hudi-umbrellas` added to
it.
+3. Raise a PR, adding an entry to the table at `rfc/README.md`, picking the
next available RFC number. Hudi committers will help land that.
+
+### Writing the RFC
+1. Create a folder `rfc-<number>` under `rfc` folder
+2. Copy the rfc template file `rfc/template.md` to `rfc/rfc-<number>.md` and
proceed to draft your design document.
+3. [Optional] Place any images used by the same directory using the `` markdown syntax.
Review comment:
better to keep each RFC in its own folder? `rfc/rfc-99/README.md` so
it'll be browsable on github. also good to keep images in its own RFC folder.
##########
File path: website/contribute/rfc-process.md
##########
@@ -0,0 +1,56 @@
+---
+sidebar_position: 3
+title: "RFC Process"
+toc: true
+last_modified_at: 2020-09-01T15:59:57-04:00
+---
+
+This page describes a Request For Comments (RFC) process for proposing any
major change to Hudi or even just sharing designs/vision for the project to get
early feedback.
+
+## When do you need an RFC ?
+
+Whenever a feature is considered to be causing a “major change” in the
project, such a feature requires an RFC.
+Any of the following can be considered a major change:
+
+ - Any new component, module or code that introduces a new concept into the
project or alters the behavior of an existing one
+ - Any large code refactor to address general code re-usability and structure.
There is no strong definition for “Large” and whether or not the refactor
requires an RFC can be discussed on the @dev mailing list.
+ - Any change that impacts the underlying storage layout/format. e.g changes
to the HoodieLogFormat, timeline layout version.
+ - New indexing schemes, New deltastreamer sources, New platform services.
+ - Any change that impacts the public interfaces of the project.
+
+It can also be used to describe large direction shifts to the project (e.g:
Flink support) or new green field ideas (e.g Hudi for ML flows)
+Not all RFCs require the same effort and detail. For critical changes such as
the File Format and Index, we need to deeply discuss the trade-offs of
+making such a change and how it impacts current and new users. Any changes to
such components affect the correctness of a dataset (backwards and forward
versions supported).
+Other changes such as code refactor might require more details around
abstractions but as long as there is good test coverage, a migration plan
section can be avoided.
+It may happen that you are making a bunch of changes across many components to
enable an already existing feature. For example, introducing a new config along
with reporting metrics,
+enhancing a tool and also improving documentation and the on-boarding
experience. If all of these changes are linked to a general feature/idea, these
can be grouped together under a single RFC.
+
+## Who should initiate the RFC ?
+Anyone can initiate an RFC. Please note that if you are unsure of whether a
feature already exists or if there is a plan already to implement a similar
one, always start a discussion thread on the dev mailing list before initiating
a RFC. This will help everyone get the right context and optimize everyone’s
usage of time.
+
+## How do you initiate the RFC ?
+
+### Proposing the RFC
+1. First, start a discussion thread on the Apache Hudi dev mailing list. The
subject of the discussion thread can be `DISCUSS <proposed idea>` to create an
RFC.
+Use this discussion thread to get an agreement from people on the mailing list
that your proposed idea necessitates an RFC.
+2. File an umbrella JIRA for the RFC with the label `hudi-umbrellas` added to
it.
Review comment:
```suggestion
2. File an umbrella JIRA for the RFC with the label `hudi-umbrellas` added
to it. See an example JIRA https://issues.apache.org/jira/browse/HUDI-1292
```
##########
File path: website/contribute/rfc-process.md
##########
@@ -0,0 +1,56 @@
+---
+sidebar_position: 3
+title: "RFC Process"
+toc: true
+last_modified_at: 2020-09-01T15:59:57-04:00
+---
+
+This page describes a Request For Comments (RFC) process for proposing any
major change to Hudi or even just sharing designs/vision for the project to get
early feedback.
+
+## When do you need an RFC ?
+
+Whenever a feature is considered to be causing a “major change” in the
project, such a feature requires an RFC.
+Any of the following can be considered a major change:
+
+ - Any new component, module or code that introduces a new concept into the
project or alters the behavior of an existing one
+ - Any large code refactor to address general code re-usability and structure.
There is no strong definition for “Large” and whether or not the refactor
requires an RFC can be discussed on the @dev mailing list.
+ - Any change that impacts the underlying storage layout/format. e.g changes
to the HoodieLogFormat, timeline layout version.
+ - New indexing schemes, New deltastreamer sources, New platform services.
+ - Any change that impacts the public interfaces of the project.
+
+It can also be used to describe large direction shifts to the project (e.g:
Flink support) or new green field ideas (e.g Hudi for ML flows)
Review comment:
```suggestion
It can also be used to describe large direction shifts to the project (e.g.:
Flink support) or new green field ideas (e.g. Hudi for ML flows)
```
##########
File path: website/contribute/rfc-process.md
##########
@@ -0,0 +1,56 @@
+---
+sidebar_position: 3
+title: "RFC Process"
+toc: true
+last_modified_at: 2020-09-01T15:59:57-04:00
+---
+
+This page describes a Request For Comments (RFC) process for proposing any
major change to Hudi or even just sharing designs/vision for the project to get
early feedback.
+
+## When do you need an RFC ?
Review comment:
```suggestion
## When do I need an RFC ?
```
##########
File path: website/contribute/rfc-process.md
##########
@@ -0,0 +1,56 @@
+---
+sidebar_position: 3
+title: "RFC Process"
+toc: true
+last_modified_at: 2020-09-01T15:59:57-04:00
+---
+
+This page describes a Request For Comments (RFC) process for proposing any
major change to Hudi or even just sharing designs/vision for the project to get
early feedback.
+
+## When do you need an RFC ?
+
+Whenever a feature is considered to be causing a “major change” in the
project, such a feature requires an RFC.
+Any of the following can be considered a major change:
+
+ - Any new component, module or code that introduces a new concept into the
project or alters the behavior of an existing one
+ - Any large code refactor to address general code re-usability and structure.
There is no strong definition for “Large” and whether or not the refactor
requires an RFC can be discussed on the @dev mailing list.
+ - Any change that impacts the underlying storage layout/format. e.g changes
to the HoodieLogFormat, timeline layout version.
+ - New indexing schemes, New deltastreamer sources, New platform services.
+ - Any change that impacts the public interfaces of the project.
+
+It can also be used to describe large direction shifts to the project (e.g:
Flink support) or new green field ideas (e.g Hudi for ML flows)
+Not all RFCs require the same effort and detail. For critical changes such as
the File Format and Index, we need to deeply discuss the trade-offs of
+making such a change and how it impacts current and new users. Any changes to
such components affect the correctness of a dataset (backwards and forward
versions supported).
+Other changes such as code refactor might require more details around
abstractions but as long as there is good test coverage, a migration plan
section can be avoided.
+It may happen that you are making a bunch of changes across many components to
enable an already existing feature. For example, introducing a new config along
with reporting metrics,
+enhancing a tool and also improving documentation and the on-boarding
experience. If all of these changes are linked to a general feature/idea, these
can be grouped together under a single RFC.
+
+## Who should initiate the RFC ?
Review comment:
```suggestion
## Who can initiate an RFC ?
```
##########
File path: website/contribute/rfc-process.md
##########
@@ -0,0 +1,56 @@
+---
+sidebar_position: 3
+title: "RFC Process"
+toc: true
+last_modified_at: 2020-09-01T15:59:57-04:00
+---
+
+This page describes a Request For Comments (RFC) process for proposing any
major change to Hudi or even just sharing designs/vision for the project to get
early feedback.
+
+## When do you need an RFC ?
+
+Whenever a feature is considered to be causing a “major change” in the
project, such a feature requires an RFC.
+Any of the following can be considered a major change:
+
+ - Any new component, module or code that introduces a new concept into the
project or alters the behavior of an existing one
+ - Any large code refactor to address general code re-usability and structure.
There is no strong definition for “Large” and whether or not the refactor
requires an RFC can be discussed on the @dev mailing list.
+ - Any change that impacts the underlying storage layout/format. e.g changes
to the HoodieLogFormat, timeline layout version.
+ - New indexing schemes, New deltastreamer sources, New platform services.
+ - Any change that impacts the public interfaces of the project.
+
+It can also be used to describe large direction shifts to the project (e.g:
Flink support) or new green field ideas (e.g Hudi for ML flows)
+Not all RFCs require the same effort and detail. For critical changes such as
the File Format and Index, we need to deeply discuss the trade-offs of
+making such a change and how it impacts current and new users. Any changes to
such components affect the correctness of a dataset (backwards and forward
versions supported).
+Other changes such as code refactor might require more details around
abstractions but as long as there is good test coverage, a migration plan
section can be avoided.
+It may happen that you are making a bunch of changes across many components to
enable an already existing feature. For example, introducing a new config along
with reporting metrics,
+enhancing a tool and also improving documentation and the on-boarding
experience. If all of these changes are linked to a general feature/idea, these
can be grouped together under a single RFC.
+
+## Who should initiate the RFC ?
+Anyone can initiate an RFC. Please note that if you are unsure of whether a
feature already exists or if there is a plan already to implement a similar
one, always start a discussion thread on the dev mailing list before initiating
a RFC. This will help everyone get the right context and optimize everyone’s
usage of time.
+
+## How do you initiate the RFC ?
Review comment:
```suggestion
## How do I initiate an RFC ?
```
##########
File path: website/contribute/rfc-process.md
##########
@@ -0,0 +1,56 @@
+---
+sidebar_position: 3
+title: "RFC Process"
+toc: true
+last_modified_at: 2020-09-01T15:59:57-04:00
+---
+
+This page describes a Request For Comments (RFC) process for proposing any
major change to Hudi or even just sharing designs/vision for the project to get
early feedback.
+
+## When do you need an RFC ?
Review comment:
This is optional..just felt first tense sounds more engaging.. maybe
just me.
##########
File path: website/contribute/rfc-process.md
##########
@@ -0,0 +1,56 @@
+---
+sidebar_position: 3
+title: "RFC Process"
+toc: true
+last_modified_at: 2020-09-01T15:59:57-04:00
+---
+
+This page describes a Request For Comments (RFC) process for proposing any
major change to Hudi or even just sharing designs/vision for the project to get
early feedback.
+
+## When do you need an RFC ?
+
+Whenever a feature is considered to be causing a “major change” in the
project, such a feature requires an RFC.
+Any of the following can be considered a major change:
+
+ - Any new component, module or code that introduces a new concept into the
project or alters the behavior of an existing one
+ - Any large code refactor to address general code re-usability and structure.
There is no strong definition for “Large” and whether or not the refactor
requires an RFC can be discussed on the @dev mailing list.
+ - Any change that impacts the underlying storage layout/format. e.g changes
to the HoodieLogFormat, timeline layout version.
+ - New indexing schemes, New deltastreamer sources, New platform services.
+ - Any change that impacts the public interfaces of the project.
+
+It can also be used to describe large direction shifts to the project (e.g:
Flink support) or new green field ideas (e.g Hudi for ML flows)
+Not all RFCs require the same effort and detail. For critical changes such as
the File Format and Index, we need to deeply discuss the trade-offs of
+making such a change and how it impacts current and new users. Any changes to
such components affect the correctness of a dataset (backwards and forward
versions supported).
+Other changes such as code refactor might require more details around
abstractions but as long as there is good test coverage, a migration plan
section can be avoided.
+It may happen that you are making a bunch of changes across many components to
enable an already existing feature. For example, introducing a new config along
with reporting metrics,
+enhancing a tool and also improving documentation and the on-boarding
experience. If all of these changes are linked to a general feature/idea, these
can be grouped together under a single RFC.
+
+## Who should initiate the RFC ?
+Anyone can initiate an RFC. Please note that if you are unsure of whether a
feature already exists or if there is a plan already to implement a similar
one, always start a discussion thread on the dev mailing list before initiating
a RFC. This will help everyone get the right context and optimize everyone’s
usage of time.
+
+## How do you initiate the RFC ?
+
+### Proposing the RFC
+1. First, start a discussion thread on the Apache Hudi dev mailing list. The
subject of the discussion thread can be `DISCUSS <proposed idea>` to create an
RFC.
+Use this discussion thread to get an agreement from people on the mailing list
that your proposed idea necessitates an RFC.
+2. File an umbrella JIRA for the RFC with the label `hudi-umbrellas` added to
it.
+3. Raise a PR, adding an entry to the table at `rfc/README.md`, picking the
next available RFC number. Hudi committers will help land that.
+
+### Writing the RFC
+1. Create a folder `rfc-<number>` under `rfc` folder
+2. Copy the rfc template file `rfc/template.md` to `rfc/rfc-<number>.md` and
proceed to draft your design document.
+3. [Optional] Place any images used by the same directory using the `` markdown syntax.
Review comment:
ok sounds good.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
