> > 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 >>>>> > >>>>> >>>>
