> > In my mind there is a distinction between a voting and discussion. I > agree that discussion is probably best served on the document. I see > voting as a final notice that the feature is officially finalized. >
+1 for having a voting phrase once we have the discussion finalized. Also I really hope we have discussions in a central place, currently some discussion happens on prs, some happens on google docs, while some are on threads. It's quite easy to get lost in many places. Just FYI, rust lang community has a process to rfcs <https://rust-lang.github.io/rfcs/0002-rfc-process.html> that works quite well. The TLDR version of this process is that everything happens on github, each proposal is a pull request, and if it's accepted, the pull request is merged. On Tue, Feb 20, 2024 at 2:22 AM Micah Kornfield <emkornfi...@gmail.com> wrote: > I don't think there should be a vote on individual features as these are >> best discussed in the specification document. > > > In my mind there is a distinction between a voting and discussion. I > agree that discussion is probably best served on the document. I see > voting as a final notice that the feature is officially finalized. > > Thanks, > Micah > > On Wed, Feb 7, 2024 at 11:30 AM Jan Kaul <jank...@mailbox.org.invalid> > wrote: > >> It's difficult to pinpoint the exact size of a proposal. Generally these >> involve larger changes and often include changes to the specification and >> not just to the implementation. I think its a good idea to first advertise >> the advance in a proposal stage and then have a vote. I don't think there >> should be a vote on individual features as these are best discussed in the >> specification document. >> >> I have no experience regarding the requirements for a specification >> feature. >> >> @JackYe I would prepare an Github Issue template. >> >> Kind regards, >> Jan >> On 05.02.24 04:25, Micah Kornfield wrote: >> >> A few follow-up questions, if these are too off-topic I can start another >> thread. >> >> Can we clarify the scope of proposals? If these involve large changes, >> or new features in existing specifications or new specifications, would it >> make sense to advertise them on this mailing list at each part of the >> workflow stage? Also, how would people feel about requiring a formal vote >> on new specification features? >> >> What are the requirements for accepting a proposal for a specification >> feature (I believe informally it has been the proposed specification >> change + a reference implementation in Java)? I think it makes sense to >> document these in the contributor guide? Also, I'd like to understand how >> people feel about potentially requiring a second language implementation >> (e.g. PyIceberg) in these requirements? It might be too soon, but it seems >> like PyIceberg is quickly closing the gap to be a full fledged >> implementation and it would be nice a wide feature skew between the two >> libraries. >> >> Thanks, >> Micah >> >> >> >> >> On Wed, Jan 17, 2024 at 1:36 PM Jack Ye <yezhao...@gmail.com> wrote: >> >>> +1, and we should add a new template for that in >>> https://github.com/apache/iceberg/tree/main/.github/ISSUE_TEMPLATE. >>> >>> Best, >>> Jack Ye >>> >>> On Wed, Jan 17, 2024 at 10:12 AM Yufei Gu <flyrain...@gmail.com> wrote: >>> >>>> +1 Thanks Jan! >>>> Yufei >>>> >>>> >>>> On Wed, Jan 17, 2024 at 3:40 AM Brian Olsen <bitsondata...@gmail.com> >>>> wrote: >>>> >>>>> +1 to issues and the suggested process >>>>> >>>>> On Mon, Jan 15, 2024 at 3:12 AM Jean-Baptiste Onofré <j...@nanthrax.net> >>>>> wrote: >>>>> >>>>>> Hi Jan >>>>>> >>>>>> You are right, we quickly discussed about this during community >>>>>> meeting and on the mailing list. >>>>>> >>>>>> First, we discussed about using GitHub Discussions, but we agreed on >>>>>> using GitHub Issues. >>>>>> I like your proposal: creating a GitHub Issues with "Proposal:" prefix >>>>>> on the title sounds good to me. >>>>>> The discussions can happen on the GitHub Issues Comment. >>>>>> >>>>>> Regards >>>>>> JB >>>>>> >>>>>> On Mon, Jan 15, 2024 at 9:14 AM Jan Kaul >>>>>> <jank...@mailbox.org.invalid> <jank...@mailbox.org.invalid> wrote: >>>>>> > >>>>>> > Hey all, >>>>>> > >>>>>> > I was wondering if the community decided on a standard way to >>>>>> create new >>>>>> > proposals. In the community meeting it sounds like there is a >>>>>> consensus >>>>>> > on using Github issues with a special "proposal" label. I think it >>>>>> would >>>>>> > also be great to decide on how the proposal process should look >>>>>> like so >>>>>> > that we could publish it on the website. >>>>>> > >>>>>> > The process could look something like this: >>>>>> > >>>>>> > 1. The community member that wants to create a proposal creates a >>>>>> Github >>>>>> > issues starting with "[Proposal]". The special mark makes it easier >>>>>> to >>>>>> > find issues intended as proposals. The proposal text can either be >>>>>> in >>>>>> > the issue description or in a Google doc that is being linked to >>>>>> from >>>>>> > the issue description. >>>>>> > >>>>>> > 2. If the initial proposal is accepted, the Github issue is labelled >>>>>> > "proposal". All issues with a "proposal" label can be found in a >>>>>> > dedicated "Proposals" project. The "Proposals" project is further >>>>>> > divided into different stages. Initially a proposal gets assigned >>>>>> the >>>>>> > "stage 0". >>>>>> > >>>>>> > 3. If the proposal fulfills certain requirements like detailed >>>>>> > specification, reference implementation, presented at a community >>>>>> > meeting, ... it can be decided to promote the proposal to a higher >>>>>> stage. >>>>>> > >>>>>> > 4. If the proposal reaches the final stage it is considered >>>>>> accepted and >>>>>> > a Github issue is created that tracks the actual implementation. >>>>>> > >>>>>> > I would be interested in your opinions. Let me know what you think. >>>>>> > >>>>>> > Best wishes, >>>>>> > >>>>>> > Jan >>>>>> > >>>>>> >>>>>
