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