I think discussions can happen everywhere by nature. It's the proposal and summary of different ideas that should have a central place and can easily be retrieved.
Regards, Manu On Wed, Feb 21, 2024 at 9:30 AM Renjie Liu <liurenjie2...@gmail.com> wrote: > 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 >>>>>>> > >>>>>>> >>>>>>
