Thanks for the summary, Yu.
Hi all,
Just want to loop back on this thread. The META-FLIP actually does not
change much in the current FLIP process. It did add a few more details that
are currently not explicitly written down in the FLIP wiki page. More
specifically:
1. In general FLIPs should
Thanks for the summary and bring the discussion to public again Becket!
Looking through the whole thread I think later discussion has covered a
broader scope than what Aljoscha initially proposed (strict voting process
for FLIP), and please allow me to categorize the topics to help decide how
to
Hi Robert,
That is a great point.
Completely agree that we should have our own bylaws. Technically speaking
it should come before FLIP process as FLIP refers to the voting process
definition. Kafka's bylaws is a good reference. It has been in place for
years and seems working well. Maybe we can
Thanks for your summary Becket.
Your list of items makes sense to me.
I wonder if we should start working on some project Bylaws to write down
how we want to work together. I really like your thoughts around "sticking
to the process" to make us more efficient and approachable for new
Hi Aljoscha,
Thanks for the quick response. Yes, you are right. I meant "Voted and
accepted FLIPs should be immutable". Sorry for the confusion.
Thanks,
Jiangjie (Becket) Qin
On Tue, Jul 9, 2019 at 10:09 PM Aljoscha Krettek
wrote:
> +1 to what Becket said.
>
> I have one comment on 5.: I
+1 to what Becket said.
I have one comment on 5.: I think you meant that they should be immutable once
they have been voted on and accepted. During the initial proposal and
discussion they will change, of course. At least that’s what I think
Aljoscha
> On 9. Jul 2019, at 11:29, Becket Qin
This discussion thread has been quiet for some time. It looks most people
think sticking to a strict voting process is a good idea.
In addition to that, there are a few related details that are also
discussed, I listed them below and personally I am +1 on all of them.
1. Stick to the current
Thanks a lot for bringing this up, Aljoscha.
+1 for sticking to the "lazy majority" vote process.
In my opinion, after the "lazy majority" vote process, we will have a
community consensus about the accepted FLIP.
Best,
Congxian
Becket Qin 于2019年6月28日周五 上午10:06写道：
> Thanks a lot for bringing
Thanks a lot for bringing this up, Aljoscha.
Big +1 to the following:
1. Stick to a strict FLIP voting process.
In practice, I rarely see a FLIP with a voting thread. In fact, the search
in mail archive
+1 to re-think the FLIP process a bit.
I think more explicit approval is certainly a good idea.
Who can vote on FLIPs is a question to be answered, though. I think PMCs
only would be a bit too strict.
On Thu, Jun 27, 2019 at 11:38 AM Hequn Cheng wrote:
> Hi all,
>
> Thanks for raising the nice
Hi all,
Thanks for raising the nice discussion @Aljoscha.
+1 to sticking to the "lazy majority" voting process.
It is good to get more people involved in the design discussion and get
enough binding votes.
As for the scope of the FLIP, previous replies show a lot of good thoughts.
On the other
Hi community,
Thanks Aljoscha for bringing us this discussion.
As Aljoscha said, "lazy majority" is always the voting rule of FLIP. It
seems that people just ignored or didn't realized this rule.
My concern is that what we can do to make sure developers will obey the
rules.
I think Kurt has
Hi all,
I do very much agree with the statement from Aljosha's initial message,
which is currently also expressed in the description page of a FLIP.
These will stick around for quite a while after they’re implemented and the
PMC (and the committers) has the burden of maintaining them. I
+1 for sticking to the lazy majority voting. Especially for the reason that
if all committers don't have
time capacity to help discuss and review the changes which bring up by the
FLIP, it will be meaningless
for this FLIP to be considered as accepted.
I don't have much suggestions about the
+1 for sticking to the lazy majority voting.
A question from my side, the 3+1 votes are binding votes which only active
(i.e. non-emeritus) committers and PMC members have?
Best,
Jark
On Wed, 26 Jun 2019 at 19:07, Tzu-Li (Gordon) Tai
wrote:
> +1 to enforcing lazy majority voting for future
+1 to enforcing lazy majority voting for future FLIPs, starting from FLIPs
that are still currently under discussion (by the time we've agreed on the
FLIP voting process).
My two cents concerning "what should and shouldn't be a FLIP":
I can understand Chesnay's argument about how some FLIPs,
Hi Aljoscha,
Thanks for bringing up this discussion! :)
+1 for sticking with “lazy majority” of approvals!
At the same time, we should create the FLIP boundary from the new
definition, i.e. which kind of change must create FLIP. The content of the
current [1] description is relatively old. For
The FLIP guidelines disagree with your first point.
The guidelines are a bit contradictory as at some places we say that
FLIPs are for major features, and in other places say they are for any
changes to the public API.
This very point came up in the recent FLIP about standardizing metrics.
Hi All,
When we originally introduced the FLIP process (which is based on the KIP
process from Kafka and refers to the Kafka bylaws for how votes work) voting
was set to be “lazy majority”. This means that a FLIP vote "requires 3 binding
+1 votes and more binding +1 votes than -1 votes”
19 matches
Mail list logo
