I think the proposed doc looks good, but I'm not sure that it is better to add this to our guidelines.
On one hand the doc describes how ASF communities work in general: committers review and commit PRs and are expected to use good judgement, ask one another for help when necessary, and broaden the set of people in the discussion when there's a disagreement. I really appreciate that Micah called out that this is intentionally vague to emphasize committer judgement. The problem I'm worried about is the tendency to misuse docs like this and become focused on it as a rule. People tend to apply written rules mechanically and I worry about people substituting a reading of this text for judgement. For example, a strict reading of "encouraged to ask another committer" means that it is optional. Given that the majority of the content here is stating how ASF communities work and the only Iceberg-specific parts are the proposal process and calling out that we vote on spec changes, I would probably just have a description of how to handle proposals (which is already there) and a note that significant spec changes should use a vote on the dev list. On Sun, Jul 28, 2024 at 11:15 PM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi Micah > > Thanks ! It looks good to me now you have included comments from everyone. > > Regards > JB > > On Fri, Jul 26, 2024 at 1:15 AM Micah Kornfield <emkornfi...@gmail.com> > wrote: > > > > As part of the bylaws discussions that have been happening, we are > trying to make small focused proposals to move things forward. As a first > step towards this I created a proposal for guidelines on committing pull > requests [1]. Feedback is appreciated. > > > > Given the level of interest in the discussions so far, it seems that the > best path forward is to hold an official vote before merging. I intend to > do this once we appear to have consensus but if the people prefer we can > try to avoid the overhead. > > > > Thanks, > > Micah > > > > > > [1] https://github.com/apache/iceberg/pull/10780 > -- Ryan Blue Databricks
