> > discussions are also quite valuable to help people to understand the > summary, people could understand the context of the final summary and > decision > Sometimes, they can also be distracting and have lower signal-to-noise ratio. We can link discussions in the final summary if possible.
On Wed, Feb 21, 2024 at 9:50 AM Renjie Liu <liurenjie2...@gmail.com> wrote: > I think discussions can happen everywhere by nature. > > > In fact, I want to say that discussions for the same proposal happen in > one place, either all in docs or all in prs. It's quite easy for people to > lose context if it happens in different places. > > It's the proposal and summary of different ideas that should have a >> central place and can easily be retrieved. > > > +1. I think discussion also deserves a central place since discussions are > also quite valuable to help people to understand the summary, people could > understand the context of the final summary and decision. > > On Wed, Feb 21, 2024 at 9:42 AM Manu Zhang <owenzhang1...@gmail.com> > wrote: > >> 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 >>>>>>>>> > >>>>>>>>> >>>>>>>>
