Hi, Also if I read it correctly, I think this proposal imposes the following workflows in "spec" folders :
1. Large and functional changes. These redirect to Iceberg improvement proposals, which ends in code-modification vote 2. bug-fixes or clarification, which is specified to require code-modification vote 3. grammar, spelling, minor formatting fix, not covered here (I guess it is like any normal code review?) To me, (2) is a bit new here and in the grey area for interpretation. I was thinking about this while reviewing https://github.com/apache/iceberg/pull/10793, which could be a category (2) and non-functional change but would need a full code-modification vote as per [Iceberg improvement proposal](#apache-iceberg-improvement-proposals). I can see both sides, to avoid a potential dispute/misunderstanding over the clarification, it would be nice to have a vote on the devlist. But it may also be yet another burden, when something can be more easily decided on the github discussion itself via approval by the relevant parties. So I think I would agree with Ryan in mentioning that significant (would maybe add "functional") spec change needs a vote on the dev list. Thanks Szehon On Mon, Jul 29, 2024 at 1:16 PM Ryan Blue <b...@databricks.com.invalid> wrote: > 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 >
