Update Contributing Guide with RFC Process#2799
Conversation
|
|
||
| We expect all community members to follow our [Code of Conduct](https://www.apache.org/foundation/policies/conduct.html). | ||
|
|
||
| ## RFC Process |
There was a problem hiding this comment.
Why this is needed on language connector? RFC / Substantial changes lands in main repo (https://github.com/apache/iceberg), and there is already corresponding note in contributing guide.
Can you bring 1/2 examples of good iceberg-rust scoped RFC (ideally with historical PR-s that lands them)
There was a problem hiding this comment.
I think we should limit the scope to implementation large features in rust only(not about changing spec, which should be discussed in dev list and main repo). Also we should also create a tracking epic issue to update the progress.
There was a problem hiding this comment.
i would say for language bounded features there is no need for RFC at all, RFC is a good process to sync cross repos to have some ground truth, if this limited just to Rust -- then it's better to be just tracking issue (with some discussions) + just pull-requests
There was a problem hiding this comment.
I see, the first one is quite a good example here!
There was a problem hiding this comment.
I think it would be great to include those examples below (perhaps #2183 too), especially as we want to direct spec changes to Iceberg's main repo and we can give these as good examples of language implementation RFCs.
laskoviymishka
left a comment
laskoviymishka
left a comment
There was a problem hiding this comment.
Looks good to me, but make it very clear - the scope of RFC is iceberg rust only
| For significant changes, new features, or substantial changes to public APIs, consider opening an RFC PR first: | ||
|
|
||
| 1. Create a markdown file in [docs/rfcs/](docs/rfcs/) using the next sequential number (e.g., `0003_your_feature.md`). Explain the scope, use case, and proposed design in prose. | ||
| 2. After the approach is reviewed and accepted, open a follow-up PR with the initial implementation. |
There was a problem hiding this comment.
I prefer to think of an RFC as more of a design document: something that complements the information in the actual PR and helps explain the changes more clearly. In that sense, the RFC and the PR could be reviewed simultaneously.
|
|
||
| ## RFC Process | ||
|
|
||
| For significant changes, new features, or substantial changes to public APIs, consider opening an RFC PR first: |
There was a problem hiding this comment.
We need to clarify that this change is iceberg-rust only, and any changes about spec should be discussed in dev list.
There was a problem hiding this comment.
Agree, this is a good opportunity to disambiguate on what should be an Iceberg spec change vs. what's only for iceberg-rust.
|
|
||
| 1. Create a markdown file in [docs/rfcs/](docs/rfcs/) using the next sequential number (e.g., `0003_your_feature.md`). Explain the scope, use case, and proposed design in prose. | ||
| 2. After the approach is reviewed and accepted, open a follow-up PR with the initial implementation. | ||
|
|
There was a problem hiding this comment.
We also need to open a tracking issue to track its progress.
dannycjones
left a comment
dannycjones
left a comment
There was a problem hiding this comment.
Broadly aligned with the other reviewers - thanks for writing this up!
|
|
||
| ## RFC Process | ||
|
|
||
| For significant changes, new features, or substantial changes to public APIs, consider opening an RFC PR first: |
There was a problem hiding this comment.
Agree, this is a good opportunity to disambiguate on what should be an Iceberg spec change vs. what's only for iceberg-rust.
|
|
||
| We expect all community members to follow our [Code of Conduct](https://www.apache.org/foundation/policies/conduct.html). | ||
|
|
||
| ## RFC Process |
There was a problem hiding this comment.
I think it would be great to include those examples below (perhaps #2183 too), especially as we want to direct spec changes to Iceberg's main repo and we can give these as good examples of language implementation RFCs.
|
|
||
| We expect all community members to follow our [Code of Conduct](https://www.apache.org/foundation/policies/conduct.html). | ||
|
|
||
| ## RFC Process |
There was a problem hiding this comment.
Rather than describing this section as the RFC process, should we instead have it as a "Larger Changes" section? Or at least point to this section from earlier on. I see under Merge Style, we talk about larger changes being directed to the mailing list and Slack. It might be a good opportunity to help guide contributors.
5 participants
Which issue does this PR close?
What changes are included in this PR?
Just doc changes
Are these changes tested?
N/A