Proposes an RFC process

[Golodhros]

Adds a Readme information with the proposed process for RFCs

[ttannis]

typo in sentence.

[Golodhros]

Oops! Thanks!

[feng-tao]

should we disable github issues for this repo and make sure people only create PRs? also should we add a template (the feature one in github issue would be a good start)? maybe also request them to label as aip-N(Amundsen improvement proposal) which is a common acronym for other projects similar process (e.g KIP: https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals, AIP: https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvements+Proposals)? What do others take on this?

[Golodhros]

should we disable github issues for this repo and make sure people only create PRs? also should we add a template (the feature one in github issue would be a good start)? maybe also request them to label as aip-N(Amundsen improvement proposal) which is a common acronym for other projects similar process (e.g KIP: https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals, AIP: https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvements+Proposals)? What do others take on this?

1.- I think disabling issues make sense. That said, Ember, Rust, React or Vue haven't done it on their RFC repos, and their issues are filled with feature requests. Probably not what we want, right?
2.- Yes, these same projects have several templates that I wanted to include. I liked the idea of having a new feature and feature deprecation templates like they have in Emberjs.
3.- Adding labels was one of the possible steps of the process, but AFAIK, non-maintainers cannot add labels.

[feng-tao]

looking at https://github.com/rust-lang/rfcs which proposals spread across issues and pr which is confusing. I think we should disable issues and just request others to create pr for rfcs.

[verdan]

@Golodhros the only confusing part for me is the active state, which is basically 2 states, i.e., Working or Merged in master. How do people search for the RFCs which are available to be picked up?

How feasible is that to assign the RFC to a person, if he picks that up that means he is working on that. And if he wants to withdraw or if the original person is inactive and someone else wants to work on this then we can unassign the old person in favour of new one.

[Golodhros]

@Golodhros the only confusing part for me is the active state, which is basically 2 states, i.e., Working or Merged in master. How do people search for the RFCs which are available to be picked up?

How feasible is that to assign the RFC to a person, if he picks that up that means he is working on that. And if he wants to withdraw or if the original person is inactive and someone else wants to work on this then we can unassign the old person in favour of new one.

Hi @verdan, thanks for your feedback!

The thing that other projects are doing with the RFCs is that they have at the top of the document a link a ticket on the main repository that tracks the work of the RFC. That means that we'll use the ticket on github.com/amundsen-io/amundsen to assign people and discuss about it.

To search for work to do, our contributors will use the main repo issues, filtering by labels like "Status: Accepted" and "Status: In Progress"