>
> 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
>
> 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
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 wrote:
> In my mind there is a distinction between a voting and discussion
>
> 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 real
>
> 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 th
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
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
+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 wrote:
> +1 Thanks Jan!
> Yufei
>
>
> On Wed, Jan 17, 2024 at 3:40 AM Brian Olsen
> wrote:
>
>> +1 to issues and the sugg
+1 Thanks Jan!
Yufei
On Wed, Jan 17, 2024 at 3:40 AM Brian Olsen wrote:
> +1 to issues and the suggested process
>
> On Mon, Jan 15, 2024 at 3:12 AM Jean-Baptiste Onofré
> wrote:
>
>> Hi Jan
>>
>> You are right, we quickly discussed about this during community
>> meeting and on the mailing lis
+1 to issues and the suggested process
On Mon, Jan 15, 2024 at 3:12 AM Jean-Baptiste Onofré
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 GitH
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.
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 lik
12 matches
Mail list logo
