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