Re: [DISCUSS] META-FLIP: Sticking (or not) to a strict FLIP voting process

[Chesnay Schepler]

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. 
Metrics are somewhat part of the public API, and thus you can interpret 
the guidelines to say that you need a FLIP. But in terms of scope, I 
believed it to not be sufficiently large to justify a FLIP.


Overall I'm very much in favor of sticking to the lazy majority voting 
scheme and enforcing it,
but I do think we have to reevaluate what changes require a FLIP and 
which don't.


On 26/06/2019 11:37, Aljoscha Krettek wrote:

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” [1][2]. Currently, we treat FLIP votes more 
like “lazy Approval”, i.e. if there are no -1 votes FLIP are often accepted, if 
there is a VOTE thread at all.

I propose that we stick to the original process or update our FLIP document to 
a voting scheme that we agree on. I’m in favour of sticking with “lazy 
majority”, for these reasons:

1. FLIPs should typically be used for deeper changes of Flink. 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 think that therefore FLIP 
votes are even move important than release votes, because they steer the long 
time direction of Flink.

2. Requiring at least 3 +1 votes means that there is more work needed for 
getting a FLIP accepted. I think this is a good thing because it will require 
people to be more involved in the direction of the project. And if there are 
not enough +1 votes on a FLIP, this is a signal that there is not enough 
interest in the feature or that there is not enough bandwidth for working on a 
feature.

3. This is more an “optics” thing, but I think having clear rules and sticking 
to them makes it easier for an international community (like the Apache Flink 
community) to work together and collaborate. If there is preferential treatment 
for certain parts of the community that makes it hard for other parts to 
participate and get into the community and understand the workings of it.

As a side note, I like the FLIP process because they are a place where we can 
keep track of important decisions and they are a place that we can point to 
when there is uncertainty about a certain feature in the future. For example 
FLIP-28 [3] (which is now discarded) would be a place where we record the 
decision that we want Flink to be Scala free in the long term. We could then 
point to this in the future. There are some decisions in Flink that are 
somewhat hidden in ML discussions or Jira issues, and therefore hard to find, 
for example the decision to eventually phase out the DataSet API, or the 
decision to drop the older Python APIs, or the semantics of savepoints and 
checkpoints. Some FLIPs might not be about implementing a certain feature but 
just a general direction that we want to take. I think we should have more of 
these.

What do you think?

Best,
Aljoscha

[1] 
https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals
[2] https://cwiki.apache.org/confluence/display/KAFKA/Bylaws#Bylaws-Approvals
[3] 
https://cwiki.apache.org/confluence/display/FLINK/FLIP-28%3A+Long-term+goal+of+making+flink-table+Scala-free

Re: [DISCUSS] META-FLIP: Sticking (or not) to a strict FLIP voting process

[jincheng sun]

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 example, the changes of the
Table API/ML API have not included in the creation of FLIP the scope.

What do you think?

Cheers,
Jincheng

[1]
https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals


Chesnay Schepler  于2019年6月26日周三 下午5:49写道：

> 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.
> Metrics are somewhat part of the public API, and thus you can interpret
> the guidelines to say that you need a FLIP. But in terms of scope, I
> believed it to not be sufficiently large to justify a FLIP.
>
> Overall I'm very much in favor of sticking to the lazy majority voting
> scheme and enforcing it,
> but I do think we have to reevaluate what changes require a FLIP and
> which don't.
>
> On 26/06/2019 11:37, Aljoscha Krettek wrote:
> > 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” [1][2].
> Currently, we treat FLIP votes more like “lazy Approval”, i.e. if there are
> no -1 votes FLIP are often accepted, if there is a VOTE thread at all.
> >
> > I propose that we stick to the original process or update our FLIP
> document to a voting scheme that we agree on. I’m in favour of sticking
> with “lazy majority”, for these reasons:
> >
> > 1. FLIPs should typically be used for deeper changes of Flink. 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 think that
> therefore FLIP votes are even move important than release votes, because
> they steer the long time direction of Flink.
> >
> > 2. Requiring at least 3 +1 votes means that there is more work needed
> for getting a FLIP accepted. I think this is a good thing because it will
> require people to be more involved in the direction of the project. And if
> there are not enough +1 votes on a FLIP, this is a signal that there is not
> enough interest in the feature or that there is not enough bandwidth for
> working on a feature.
> >
> > 3. This is more an “optics” thing, but I think having clear rules and
> sticking to them makes it easier for an international community (like the
> Apache Flink community) to work together and collaborate. If there is
> preferential treatment for certain parts of the community that makes it
> hard for other parts to participate and get into the community and
> understand the workings of it.
> >
> > As a side note, I like the FLIP process because they are a place where
> we can keep track of important decisions and they are a place that we can
> point to when there is uncertainty about a certain feature in the future.
> For example FLIP-28 [3] (which is now discarded) would be a place where we
> record the decision that we want Flink to be Scala free in the long term.
> We could then point to this in the future. There are some decisions in
> Flink that are somewhat hidden in ML discussions or Jira issues, and
> therefore hard to find, for example the decision to eventually phase out
> the DataSet API, or the decision to drop the older Python APIs, or the
> semantics of savepoints and checkpoints. Some FLIPs might not be about
> implementing a certain feature but just a general direction that we want to
> take. I think we should have more of these.
> >
> > What do you think?
> >
> > Best,
> > Aljoscha
> >
> > [1]
> https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals
> > [2]
> https://cwiki.apache.org/confluence/display/KAFKA/Bylaws#Bylaws-Approvals
> > [3]
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-28%3A+Long-term+goal+of+making+flink-table+Scala-free
>
>
>

Re: [DISCUSS] META-FLIP: Sticking (or not) to a strict FLIP voting process

[Tzu-Li (Gordon) Tai]

+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, while meeting the
criteria defined by the FLIP guidelines, feel to not be sufficiently large
to justify a FLIP.
As a matter of fact, the FLIP guidelines explicitly mention that "Exposed
Monitoring Information" is considered public interface; I guess that was
why this FLIP came around in the first place.
I was also hesitant in whether or not the recent FLIP about keyed state
snapshot binary format unification (FLIP-41) deserves to be a FLIP, since
the complexity of the change is rather small.

However, with the fact that these changes indeed touch the general public
interface of Flink, the scope (including all potential 3rd party projects)
is strictly speaking hard to define.
Outcomes of such changes, even if the complexity of the change is rather
trivial, can still stick around for quite a while.
In this case, IMO the value of proposing a FLIP for such a change is less
about discussing design or implementation details, and more on the fact
that said change requires an official vote for approval from the community.

Best,
Gordon

On Wed, Jun 26, 2019 at 5:50 PM Chesnay Schepler  wrote:

> 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.
> Metrics are somewhat part of the public API, and thus you can interpret
> the guidelines to say that you need a FLIP. But in terms of scope, I
> believed it to not be sufficiently large to justify a FLIP.
>
> Overall I'm very much in favor of sticking to the lazy majority voting
> scheme and enforcing it,
> but I do think we have to reevaluate what changes require a FLIP and
> which don't.
>
> On 26/06/2019 11:37, Aljoscha Krettek wrote:
> > 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” [1][2].
> Currently, we treat FLIP votes more like “lazy Approval”, i.e. if there are
> no -1 votes FLIP are often accepted, if there is a VOTE thread at all.
> >
> > I propose that we stick to the original process or update our FLIP
> document to a voting scheme that we agree on. I’m in favour of sticking
> with “lazy majority”, for these reasons:
> >
> > 1. FLIPs should typically be used for deeper changes of Flink. 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 think that
> therefore FLIP votes are even move important than release votes, because
> they steer the long time direction of Flink.
> >
> > 2. Requiring at least 3 +1 votes means that there is more work needed
> for getting a FLIP accepted. I think this is a good thing because it will
> require people to be more involved in the direction of the project. And if
> there are not enough +1 votes on a FLIP, this is a signal that there is not
> enough interest in the feature or that there is not enough bandwidth for
> working on a feature.
> >
> > 3. This is more an “optics” thing, but I think having clear rules and
> sticking to them makes it easier for an international community (like the
> Apache Flink community) to work together and collaborate. If there is
> preferential treatment for certain parts of the community that makes it
> hard for other parts to participate and get into the community and
> understand the workings of it.
> >
> > As a side note, I like the FLIP process because they are a place where
> we can keep track of important decisions and they are a place that we can
> point to when there is uncertainty about a certain feature in the future.
> For example FLIP-28 [3] (which is now discarded) would be a place where we
> record the decision that we want Flink to be Scala free in the long term.
> We could then point to this in the future. There are some decisions in
> Flink that are somewhat hidden in ML discussions or Jira issues, and
> therefore hard to find, for example the decision to eventually phase out
> the DataSet API, or the decision to drop the older Python APIs, or the
> semantics of savepoints and checkpoints. Some FLIPs might not be about
> implementing a certain feature but just a general direction that we want to
> take. I think we should have more of these.
> >
> > What do you think?
> >
> > Best,
> > Aljoscha
> >
> > [1]
> https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals
> > [2]
> https://cwi

Re: [DISCUSS] META-FLIP: Sticking (or not) to a strict FLIP voting process

[Jark Wu]

+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 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, while meeting the
> criteria defined by the FLIP guidelines, feel to not be sufficiently large
> to justify a FLIP.
> As a matter of fact, the FLIP guidelines explicitly mention that "Exposed
> Monitoring Information" is considered public interface; I guess that was
> why this FLIP came around in the first place.
> I was also hesitant in whether or not the recent FLIP about keyed state
> snapshot binary format unification (FLIP-41) deserves to be a FLIP, since
> the complexity of the change is rather small.
>
> However, with the fact that these changes indeed touch the general public
> interface of Flink, the scope (including all potential 3rd party projects)
> is strictly speaking hard to define.
> Outcomes of such changes, even if the complexity of the change is rather
> trivial, can still stick around for quite a while.
> In this case, IMO the value of proposing a FLIP for such a change is less
> about discussing design or implementation details, and more on the fact
> that said change requires an official vote for approval from the community.
>
> Best,
> Gordon
>
> On Wed, Jun 26, 2019 at 5:50 PM Chesnay Schepler 
> wrote:
>
> > 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.
> > Metrics are somewhat part of the public API, and thus you can interpret
> > the guidelines to say that you need a FLIP. But in terms of scope, I
> > believed it to not be sufficiently large to justify a FLIP.
> >
> > Overall I'm very much in favor of sticking to the lazy majority voting
> > scheme and enforcing it,
> > but I do think we have to reevaluate what changes require a FLIP and
> > which don't.
> >
> > On 26/06/2019 11:37, Aljoscha Krettek wrote:
> > > 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” [1][2].
> > Currently, we treat FLIP votes more like “lazy Approval”, i.e. if there
> are
> > no -1 votes FLIP are often accepted, if there is a VOTE thread at all.
> > >
> > > I propose that we stick to the original process or update our FLIP
> > document to a voting scheme that we agree on. I’m in favour of sticking
> > with “lazy majority”, for these reasons:
> > >
> > > 1. FLIPs should typically be used for deeper changes of Flink. 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 think that
> > therefore FLIP votes are even move important than release votes, because
> > they steer the long time direction of Flink.
> > >
> > > 2. Requiring at least 3 +1 votes means that there is more work needed
> > for getting a FLIP accepted. I think this is a good thing because it will
> > require people to be more involved in the direction of the project. And
> if
> > there are not enough +1 votes on a FLIP, this is a signal that there is
> not
> > enough interest in the feature or that there is not enough bandwidth for
> > working on a feature.
> > >
> > > 3. This is more an “optics” thing, but I think having clear rules and
> > sticking to them makes it easier for an international community (like the
> > Apache Flink community) to work together and collaborate. If there is
> > preferential treatment for certain parts of the community that makes it
> > hard for other parts to participate and get into the community and
> > understand the workings of it.
> > >
> > > As a side note, I like the FLIP process because they are a place where
> > we can keep track of important decisions and they are a place that we can
> > point to when there is uncertainty about a certain feature in the future.
> > For example FLIP-28 [3] (which is now discarded) would be a place where
> we
> > record the decision that we want Flink to be Scala free in the long term.
> > We could then point to this in the future. There are some decisions in
> > Flink that are somewhat hidden in ML discussions or Jira issues, and
> > therefore hard to find, for example the decision to eventually phase out
> > the D

Re: [DISCUSS] META-FLIP: Sticking (or not) to a strict FLIP voting process

[Kurt Young]

+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 scope of the FLIP but I'm sure the
issue should be *important* enough
to be as a FLIP. This actually leads to my another question and thought:

Do we have to make sure that some committers should be volunteered to be
the sheepherder of the FLIP
if the author himself is not? The committer can help with discussion,
review the changes, and help to reach out other
committers if himself is not sure or familiar with all the changes. I think
it will be very good experience for the contributor.

In a short word: We should be *strict* for accepting new FLIPs, but once a
FLIP is accepted, we also need to make
sure the FLIP is been taken good care of.

Best,
Kurt


On Thu, Jun 27, 2019 at 10:15 AM Jark Wu  wrote:

> +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 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, while meeting
> the
> > criteria defined by the FLIP guidelines, feel to not be sufficiently
> large
> > to justify a FLIP.
> > As a matter of fact, the FLIP guidelines explicitly mention that "Exposed
> > Monitoring Information" is considered public interface; I guess that was
> > why this FLIP came around in the first place.
> > I was also hesitant in whether or not the recent FLIP about keyed state
> > snapshot binary format unification (FLIP-41) deserves to be a FLIP, since
> > the complexity of the change is rather small.
> >
> > However, with the fact that these changes indeed touch the general public
> > interface of Flink, the scope (including all potential 3rd party
> projects)
> > is strictly speaking hard to define.
> > Outcomes of such changes, even if the complexity of the change is rather
> > trivial, can still stick around for quite a while.
> > In this case, IMO the value of proposing a FLIP for such a change is less
> > about discussing design or implementation details, and more on the fact
> > that said change requires an official vote for approval from the
> community.
> >
> > Best,
> > Gordon
> >
> > On Wed, Jun 26, 2019 at 5:50 PM Chesnay Schepler 
> > wrote:
> >
> > > 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.
> > > Metrics are somewhat part of the public API, and thus you can interpret
> > > the guidelines to say that you need a FLIP. But in terms of scope, I
> > > believed it to not be sufficiently large to justify a FLIP.
> > >
> > > Overall I'm very much in favor of sticking to the lazy majority voting
> > > scheme and enforcing it,
> > > but I do think we have to reevaluate what changes require a FLIP and
> > > which don't.
> > >
> > > On 26/06/2019 11:37, Aljoscha Krettek wrote:
> > > > 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” [1][2].
> > > Currently, we treat FLIP votes more like “lazy Approval”, i.e. if there
> > are
> > > no -1 votes FLIP are often accepted, if there is a VOTE thread at all.
> > > >
> > > > I propose that we stick to the original process or update our FLIP
> > > document to a voting scheme that we agree on. I’m in favour of sticking
> > > with “lazy majority”, for these reasons:
> > > >
> > > > 1. FLIPs should typically be used for deeper changes of Flink. 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 think that
> > > therefore FLIP votes are even move important than release votes,
> because
> > > they steer the long time direction of Flink.
> > > >
> > > > 2. Requiring at least 3 +1 votes means that there is more work needed
> > > for getting a FLIP accepted. I think this is a good thing because it
> will
> > > require people to be more involved in the direction of the project. And
> > if
> > > there are not enough +1 votes on a F

Re: [DISCUSS] META-FLIP: Sticking (or not) to a strict FLIP voting process

[Dawid Wysakowicz]

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 think that 
therefore FLIP votes are even move important than release votes, because they 
steer the long time direction of Flink.

Therefore I think we should enforce following the lazy majority
approach. I will probably just repeat what was already said, but I do
think this would make the decisions more visible, easier to reference in
case of related decisions, and also this would show if the community has
capacity to implement the FLIP. Nowadays, even if a FLIP is "accepted"
it might be just stale because there are no committers that have the
capacity to help with the changes.

Another, maybe an orthogonal issue, is that we could maybe use this
process for agreeing on a scope of a release. I think it might make
sense to construct a release plan of an accepted FLIPs. This would
enforce better scoping of FLIPs, as they would have to fit into a single
release. In my opinion FLIPs that spawn multiple releases(thus even over
multiple years) are rarely relevant in the future anymore, as the
project evolves and it usually makes sense to revisit the original
proposal anyway. This would have the benefits that:

  * we have a clear scope for a release rather than just a vague list of
features that we want to have.
  * the whole community is on the same page what a certain feature means
  * the scope does not change drastically during the development period

As for what should and what should not deserve a FLIP, I actually quite
like the definition in the FLIPs page[1]. I think it does make sense to
have a FLIP, and as a result a voting process, for any *public* or major
change. I agree with Gordon. Even if the change is trivial it might
affect external systems/users and it is also a commitment from the
community. Therefore I think they deserve a vote.

Lastly, I think Jark raised a valid point. We should have a clear
understanding what binding votes in this case mean. I think it makes
sense to consider PMC's and committers' votes as binding for FLIPs
voting. Otherwise we would lose the aspect of committing to help with
getting the FLIP into the codebase.

To sum up I would opt for enforcing the lazy majority. I would suggest
to consider constructing a release plan with a list of accepted FLIPs.

Best,

Dawid


[1]
https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals#FlinkImprovementProposals-Whatisconsidereda%22majorchange%22thatneedsaFLIP?

On 27/06/2019 04:15, Jark Wu wrote:
> +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 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, while meeting the
>> criteria defined by the FLIP guidelines, feel to not be sufficiently large
>> to justify a FLIP.
>> As a matter of fact, the FLIP guidelines explicitly mention that "Exposed
>> Monitoring Information" is considered public interface; I guess that was
>> why this FLIP came around in the first place.
>> I was also hesitant in whether or not the recent FLIP about keyed state
>> snapshot binary format unification (FLIP-41) deserves to be a FLIP, since
>> the complexity of the change is rather small.
>>
>> However, with the fact that these changes indeed touch the general public
>> interface of Flink, the scope (including all potential 3rd party projects)
>> is strictly speaking hard to define.
>> Outcomes of such changes, even if the complexity of the change is rather
>> trivial, can still stick around for quite a while.
>> In this case, IMO the value of proposing a FLIP for such a change is less
>> about discussing design or implementation details, and more on the fact
>> that said change requires an official vote for approval from the community.
>>
>> Best,
>> Gordon
>>
>> On Wed, Jun 26, 2019 at 5:50 PM Chesnay Schepler 
>> wrote:
>>
>>> 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.
>>> Metrics are somewhat part of the public API, and thus you can interpret
>>> the guidelines to say that you need a FLIP. But in terms of scope, I
>>> believed it to not be sufficiently large 

Re: [DISCUSS] META-FLIP: Sticking (or not) to a strict FLIP voting process

[Biao Liu]

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 given a good suggestion. Since the community is growing
bigger and bigger, maybe we need some volunteers to host the progress of
FLIP. Like start a discussion/voting in ML or update the sheet of FLIP
document [1].

1.
https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals



Dawid Wysakowicz  于2019年6月27日周四 下午2:56写道：

> 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 think that 
> therefore FLIP votes are even move important than release votes, because they 
> steer the long time direction of Flink.
>
>
> Therefore I think we should enforce following the lazy majority approach.
> I will probably just repeat what was already said, but I do think this
> would make the decisions more visible, easier to reference in case of
> related decisions, and also this would show if the community has capacity
> to implement the FLIP. Nowadays, even if a FLIP is "accepted" it might be
> just stale because there are no committers that have the capacity to help
> with the changes.
>
> Another, maybe an orthogonal issue, is that we could maybe use this
> process for agreeing on a scope of a release. I think it might make sense
> to construct a release plan of an accepted FLIPs. This would enforce better
> scoping of FLIPs, as they would have to fit into a single release. In my
> opinion FLIPs that spawn multiple releases(thus even over multiple years)
> are rarely relevant in the future anymore, as the project evolves and it
> usually makes sense to revisit the original proposal anyway. This would
> have the benefits that:
>
>- we have a clear scope for a release rather than just a vague list of
>features that we want to have.
>- the whole community is on the same page what a certain feature means
>- the scope does not change drastically during the development period
>
> As for what should and what should not deserve a FLIP, I actually quite
> like the definition in the FLIPs page[1]. I think it does make sense to
> have a FLIP, and as a result a voting process, for any *public* or major
> change. I agree with Gordon. Even if the change is trivial it might affect
> external systems/users and it is also a commitment from the community.
> Therefore I think they deserve a vote.
>
> Lastly, I think Jark raised a valid point. We should have a clear
> understanding what binding votes in this case mean. I think it makes sense
> to consider PMC's and committers' votes as binding for FLIPs voting.
> Otherwise we would lose the aspect of committing to help with getting the
> FLIP into the codebase.
>
> To sum up I would opt for enforcing the lazy majority. I would suggest to
> consider constructing a release plan with a list of accepted FLIPs.
>
> Best,
>
> Dawid
>
>
> [1]
> https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals#FlinkImprovementProposals-Whatisconsidereda%22majorchange%22thatneedsaFLIP
> ?
> On 27/06/2019 04:15, Jark Wu wrote:
>
> +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 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, while meeting the
> criteria defined by the FLIP guidelines, feel to not be sufficiently large
> to justify a FLIP.
> As a matter of fact, the FLIP guidelines explicitly mention that "Exposed
> Monitoring Information" is considered public interface; I guess that was
> why this FLIP came around in the first place.
> I was also hesitant in whether or not the recent FLIP about keyed state
> snapshot binary format unification (FLIP-41) deserves to be a FLIP, since
> the complexity of the change is rather small.
>
> However, with the fact that these changes indeed touch the general public
> interface of Flink, the scope (including all potential 3rd party projects)
> is strictly speaking hard to define.
> Outcomes of such changes, even if the complexity of the change is rather
> trivial, can still stick around for quite a while.
> In this case, IMO the value of proposing a FLIP for such a change is less
> about discussing design or i

Re: [DISCUSS] META-FLIP: Sticking (or not) to a strict FLIP voting process

[Hequn Cheng]

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 hand, I think we can also define some scope that which should
*not* be a FLIP.
Sometimes it is easier for us to list a blacklist.

Best, Hequn

On Thu, Jun 27, 2019 at 5:27 PM Biao Liu  wrote:

> 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 given a good suggestion. Since the community is growing
> bigger and bigger, maybe we need some volunteers to host the progress of
> FLIP. Like start a discussion/voting in ML or update the sheet of FLIP
> document [1].
>
> 1.
>
> https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals
>
>
>
> Dawid Wysakowicz  于2019年6月27日周四 下午2:56写道：
>
> > 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 think
> that therefore FLIP votes are even move important than release votes,
> because they steer the long time direction of Flink.
> >
> >
> > Therefore I think we should enforce following the lazy majority approach.
> > I will probably just repeat what was already said, but I do think this
> > would make the decisions more visible, easier to reference in case of
> > related decisions, and also this would show if the community has capacity
> > to implement the FLIP. Nowadays, even if a FLIP is "accepted" it might be
> > just stale because there are no committers that have the capacity to help
> > with the changes.
> >
> > Another, maybe an orthogonal issue, is that we could maybe use this
> > process for agreeing on a scope of a release. I think it might make sense
> > to construct a release plan of an accepted FLIPs. This would enforce
> better
> > scoping of FLIPs, as they would have to fit into a single release. In my
> > opinion FLIPs that spawn multiple releases(thus even over multiple years)
> > are rarely relevant in the future anymore, as the project evolves and it
> > usually makes sense to revisit the original proposal anyway. This would
> > have the benefits that:
> >
> >- we have a clear scope for a release rather than just a vague list of
> >features that we want to have.
> >- the whole community is on the same page what a certain feature means
> >- the scope does not change drastically during the development period
> >
> > As for what should and what should not deserve a FLIP, I actually quite
> > like the definition in the FLIPs page[1]. I think it does make sense to
> > have a FLIP, and as a result a voting process, for any *public* or major
> > change. I agree with Gordon. Even if the change is trivial it might
> affect
> > external systems/users and it is also a commitment from the community.
> > Therefore I think they deserve a vote.
> >
> > Lastly, I think Jark raised a valid point. We should have a clear
> > understanding what binding votes in this case mean. I think it makes
> sense
> > to consider PMC's and committers' votes as binding for FLIPs voting.
> > Otherwise we would lose the aspect of committing to help with getting the
> > FLIP into the codebase.
> >
> > To sum up I would opt for enforcing the lazy majority. I would suggest to
> > consider constructing a release plan with a list of accepted FLIPs.
> >
> > Best,
> >
> > Dawid
> >
> >
> > [1]
> >
> https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals#FlinkImprovementProposals-Whatisconsidereda%22majorchange%22thatneedsaFLIP
> > ?
> > On 27/06/2019 04:15, Jark Wu wrote:
> >
> > +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 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, while meeting
> the
> > criteria defined by the FLIP guidelines, feel to not be sufficiently
> large
> > to justify a FLIP.
> > As a matter of fact, the FLIP guidelines explicitly mention that "Exposed
> > Monitoring Information" is considered public

Re: [DISCUSS] META-FLIP: Sticking (or not) to a strict FLIP voting process

[Stephan Ewen]

+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 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 hand, I think we can also define some scope that which should
> *not* be a FLIP.
> Sometimes it is easier for us to list a blacklist.
>
> Best, Hequn
>
> On Thu, Jun 27, 2019 at 5:27 PM Biao Liu  wrote:
>
> > 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 given a good suggestion. Since the community is growing
> > bigger and bigger, maybe we need some volunteers to host the progress of
> > FLIP. Like start a discussion/voting in ML or update the sheet of FLIP
> > document [1].
> >
> > 1.
> >
> >
> https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals
> >
> >
> >
> > Dawid Wysakowicz  于2019年6月27日周四 下午2:56写道：
> >
> > > 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 think
> > that therefore FLIP votes are even move important than release votes,
> > because they steer the long time direction of Flink.
> > >
> > >
> > > Therefore I think we should enforce following the lazy majority
> approach.
> > > I will probably just repeat what was already said, but I do think this
> > > would make the decisions more visible, easier to reference in case of
> > > related decisions, and also this would show if the community has
> capacity
> > > to implement the FLIP. Nowadays, even if a FLIP is "accepted" it might
> be
> > > just stale because there are no committers that have the capacity to
> help
> > > with the changes.
> > >
> > > Another, maybe an orthogonal issue, is that we could maybe use this
> > > process for agreeing on a scope of a release. I think it might make
> sense
> > > to construct a release plan of an accepted FLIPs. This would enforce
> > better
> > > scoping of FLIPs, as they would have to fit into a single release. In
> my
> > > opinion FLIPs that spawn multiple releases(thus even over multiple
> years)
> > > are rarely relevant in the future anymore, as the project evolves and
> it
> > > usually makes sense to revisit the original proposal anyway. This would
> > > have the benefits that:
> > >
> > >- we have a clear scope for a release rather than just a vague list
> of
> > >features that we want to have.
> > >- the whole community is on the same page what a certain feature
> means
> > >- the scope does not change drastically during the development
> period
> > >
> > > As for what should and what should not deserve a FLIP, I actually quite
> > > like the definition in the FLIPs page[1]. I think it does make sense to
> > > have a FLIP, and as a result a voting process, for any *public* or
> major
> > > change. I agree with Gordon. Even if the change is trivial it might
> > affect
> > > external systems/users and it is also a commitment from the community.
> > > Therefore I think they deserve a vote.
> > >
> > > Lastly, I think Jark raised a valid point. We should have a clear
> > > understanding what binding votes in this case mean. I think it makes
> > sense
> > > to consider PMC's and committers' votes as binding for FLIPs voting.
> > > Otherwise we would lose the aspect of committing to help with getting
> the
> > > FLIP into the codebase.
> > >
> > > To sum up I would opt for enforcing the lazy majority. I would suggest
> to
> > > consider constructing a release plan with a list of accepted FLIPs.
> > >
> > > Best,
> > >
> > > Dawid
> > >
> > >
> > > [1]
> > >
> >
> https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals#FlinkImprovementProposals-Whatisconsidereda%22majorchange%22thatneedsaFLIP
> > > ?
> > > On 27/06/2019 04:15, Jark Wu wrote:
> > >
> > > +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 FL

Re: [DISCUSS] META-FLIP: Sticking (or not) to a strict FLIP voting process

[Becket Qin]

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

gives
only 3 FLIPs with voting thread, and unfortunately none of them has met the
lazy majority requirements, which needs 3 binding votes. However, we have
11 adopted-but-unreleased FLIPs and 16 released FLIPs.
Even though we claimed *"These proposals are more serious than code changes
and more serious even than release votes.", *we did not really treat them
seriously. The missing voting process effectively put the efforts of FLIP
in vain. This leads to a few consequences:
a) The conclusion of the FLIP is never really finalized. People may change
the FLIP at wish during the implementation.
b) Some "adopted" FLIPs only have conceptual ideas instead of necessary
concrete interfaces, which leaves a lot of problems in the implementation
phase.
c) New contributors are completely confused on how to contribute. The
voting threads seems died, and magically someone else's code got checked in
without a passed FLIP. These "good citizens" may feel excluded and simply
leave the chaos.
d) API changes / user sensible behavior changes may be checked in without
being carefully inspected. To fix them, hacky tricks has to be made in
order to keep backwards compatibility.

So a huge +1 to stick to the FLIP voting process.

2. Stick to the definition of major changes. Generally speaking any user
sensible changes should go through a FLIP.
- Some changes may be small from the size of patch perspective, but the
impact could be huge. Take metric as an example, imagine a cloud service
provider who relies on a metric to do alerting or bill their customer. Any
change to such metrics will have huge impact on them.
- Sometimes there might be no "interface" change per se, but the
behavior of a method is slightly changed. Even that can be very annoying to
some users. So I think any user sensible changes should go through a FLIP.

3. Generally speaking, make each FLIP completable in a reasonable amount of
time. Some large changes may need multiple FLIPs.
   - I agree with David that a long lasting FLIP can be problematic as it
could become obsolete before the work is done. And might need to make
changes to the original proposal multiple times. It might be a little
difficult to have a standard to say what kind of FLIP is a long lasting
FLIP.
   - Sometimes long lasting FLIP may be necessary, e.g. a big new module /
functionality, etc. Those FLIPs are rare and usually more independent. We
may need to treat them case by case.

4. Take the votes from both committers and PMCs as binding.


In addition, I'd like to propose the following:

1. Always discuss the FLIP based on a FLIP wiki page instead of a Google
doc. It is perfectly fine to use google doc to explain stuff, but the FLIP
wiki page is the official source for the proposal. The discussion and vote
needs to be based on that.

According to the process of FLIP
,
one should create a FLIP wiki page "before" starting a discussion ML
thread. The discussion is supposed to be happen in ML but based on the FLIP
wiki. This process has some benefits:
a) Since all the FLIP proposals must give necessary information such as
public interface change / behavior change / migration plan and such, the
authors are enforced to think about them.
b) Even if a FLIP is finally rejected, we have all the history of it.
These are valuable assets of the project and would give a good reference
for later contributors.

However, in practice, what people usually do is to have a Google doc for
discussion and only create a FLIP wiki page after that idea is accepted by
the community. There might be a few caveats in this:
a) The Google docs may be organized in various ways and something important
might be missing. This sometimes harms the review efficiency as people
might have to ask some basic questions.
b) More importantly, the rejected proposals will be silently lost without
any history - later contributors will not be able to know what happened
before, and there is no guarantee that the google docs will always be
accessible.
c) From process perspective, one may be confused on whether a discussion
thread on the FLIP wiki is still needed if people have agreed on the google
doc. (At least I always feel a little awkward after the google doc has been
agreed upon)

2. The public interface change proposal should be concrete in each FLIP,
instead of conceptual. This avoids surprises in the implementation phase.

3. Adopted FLIP should mostly be "immutable". Any change to an adopted FLIP
requires a new voting process. For minor changes, a Lazy Approval 

Re: [DISCUSS] META-FLIP: Sticking (or not) to a strict FLIP voting process

[Congxian Qiu]

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 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
> <
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/template/NamlServlet.jtp?macro=search_page&node=1&query=subject%3AVOTE%2CFLIP&days=0
> >
> gives
> only 3 FLIPs with voting thread, and unfortunately none of them has met the
> lazy majority requirements, which needs 3 binding votes. However, we have
> 11 adopted-but-unreleased FLIPs and 16 released FLIPs.
> Even though we claimed *"These proposals are more serious than code changes
> and more serious even than release votes.", *we did not really treat them
> seriously. The missing voting process effectively put the efforts of FLIP
> in vain. This leads to a few consequences:
> a) The conclusion of the FLIP is never really finalized. People may change
> the FLIP at wish during the implementation.
> b) Some "adopted" FLIPs only have conceptual ideas instead of necessary
> concrete interfaces, which leaves a lot of problems in the implementation
> phase.
> c) New contributors are completely confused on how to contribute. The
> voting threads seems died, and magically someone else's code got checked in
> without a passed FLIP. These "good citizens" may feel excluded and simply
> leave the chaos.
> d) API changes / user sensible behavior changes may be checked in without
> being carefully inspected. To fix them, hacky tricks has to be made in
> order to keep backwards compatibility.
>
> So a huge +1 to stick to the FLIP voting process.
>
> 2. Stick to the definition of major changes. Generally speaking any user
> sensible changes should go through a FLIP.
> - Some changes may be small from the size of patch perspective, but the
> impact could be huge. Take metric as an example, imagine a cloud service
> provider who relies on a metric to do alerting or bill their customer. Any
> change to such metrics will have huge impact on them.
> - Sometimes there might be no "interface" change per se, but the
> behavior of a method is slightly changed. Even that can be very annoying to
> some users. So I think any user sensible changes should go through a FLIP.
>
> 3. Generally speaking, make each FLIP completable in a reasonable amount of
> time. Some large changes may need multiple FLIPs.
>- I agree with David that a long lasting FLIP can be problematic as it
> could become obsolete before the work is done. And might need to make
> changes to the original proposal multiple times. It might be a little
> difficult to have a standard to say what kind of FLIP is a long lasting
> FLIP.
>- Sometimes long lasting FLIP may be necessary, e.g. a big new module /
> functionality, etc. Those FLIPs are rare and usually more independent. We
> may need to treat them case by case.
>
> 4. Take the votes from both committers and PMCs as binding.
>
>
> In addition, I'd like to propose the following:
>
> 1. Always discuss the FLIP based on a FLIP wiki page instead of a Google
> doc. It is perfectly fine to use google doc to explain stuff, but the FLIP
> wiki page is the official source for the proposal. The discussion and vote
> needs to be based on that.
>
> According to the process of FLIP
> <
> https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals#FlinkImprovementProposals-Process
> >,
> one should create a FLIP wiki page "before" starting a discussion ML
> thread. The discussion is supposed to be happen in ML but based on the FLIP
> wiki. This process has some benefits:
> a) Since all the FLIP proposals must give necessary information such as
> public interface change / behavior change / migration plan and such, the
> authors are enforced to think about them.
> b) Even if a FLIP is finally rejected, we have all the history of it.
> These are valuable assets of the project and would give a good reference
> for later contributors.
>
> However, in practice, what people usually do is to have a Google doc for
> discussion and only create a FLIP wiki page after that idea is accepted by
> the community. There might be a few caveats in this:
> a) The Google docs may be organized in various ways and something important
> might be missing. This sometimes harms the review efficiency as people
> might have to ask some basic questions.
> b) More importantly, the rejected proposals will be silently lost without
> any history - later contributors will not be able to know what happened
> before, and there is no guarantee that the google docs will always be
> accessible.
> c) From process perspective, one may be confused on whether a discussion
> thread on th

Re: [DISCUSS] META-FLIP: Sticking (or not) to a strict FLIP voting process

[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 definition of major changes.
2. Committers have binding votes on FLIPs.
3. In general FLIPs should be completed in a reasonable amount of time,
rather than lasting for many releases.
4. Always discuss FLIPs based on FLIP wiki page. Google docs can be used as
handy tools to explain ideas, but FLIP ideas should always be documented as
a FLIP wiki, regardless whether they are accepted or not.
5. FLIPs should be immutable. Changes to FLIPs need a new vote processes.
6. FLIPs should be concrete in terms of interfaces, semantic and behaviors,
rather than conceptual.

It'll be good to hear what do people think. If there is no further
objection, I'd suggest to conclude this discussion in 72 hours and move to
a lazy majority voting. (For decisions like this, maybe only votes from
PMCs should be considered as binding?)

Thanks,

Jiangjie (Becket) Qin

On Fri, Jun 28, 2019 at 10:33 AM Congxian Qiu 
wrote:

> 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 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
> > <
> >
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/template/NamlServlet.jtp?macro=search_page&node=1&query=subject%3AVOTE%2CFLIP&days=0
> > >
> > gives
> > only 3 FLIPs with voting thread, and unfortunately none of them has met
> the
> > lazy majority requirements, which needs 3 binding votes. However, we have
> > 11 adopted-but-unreleased FLIPs and 16 released FLIPs.
> > Even though we claimed *"These proposals are more serious than code
> changes
> > and more serious even than release votes.", *we did not really treat them
> > seriously. The missing voting process effectively put the efforts of FLIP
> > in vain. This leads to a few consequences:
> > a) The conclusion of the FLIP is never really finalized. People may
> change
> > the FLIP at wish during the implementation.
> > b) Some "adopted" FLIPs only have conceptual ideas instead of necessary
> > concrete interfaces, which leaves a lot of problems in the implementation
> > phase.
> > c) New contributors are completely confused on how to contribute. The
> > voting threads seems died, and magically someone else's code got checked
> in
> > without a passed FLIP. These "good citizens" may feel excluded and simply
> > leave the chaos.
> > d) API changes / user sensible behavior changes may be checked in without
> > being carefully inspected. To fix them, hacky tricks has to be made in
> > order to keep backwards compatibility.
> >
> > So a huge +1 to stick to the FLIP voting process.
> >
> > 2. Stick to the definition of major changes. Generally speaking any user
> > sensible changes should go through a FLIP.
> > - Some changes may be small from the size of patch perspective, but
> the
> > impact could be huge. Take metric as an example, imagine a cloud service
> > provider who relies on a metric to do alerting or bill their customer.
> Any
> > change to such metrics will have huge impact on them.
> > - Sometimes there might be no "interface" change per se, but the
> > behavior of a method is slightly changed. Even that can be very annoying
> to
> > some users. So I think any user sensible changes should go through a
> FLIP.
> >
> > 3. Generally speaking, make each FLIP completable in a reasonable amount
> of
> > time. Some large changes may need multiple FLIPs.
> >- I agree with David that a long lasting FLIP can be problematic as it
> > could become obsolete before the work is done. And might need to make
> > changes to the original proposal multiple times. It might be a little
> > difficult to have a standard to say what kind of FLIP is a long lasting
> > FLIP.
> >- Sometimes long lasting FLIP may be necessary, e.g. a big new module
> /
> > functionality, etc. Those FLIPs are rare and usually more independent. We
> > may need to treat them case by case.
> >
> > 4. Take the votes from both committers and PMCs as binding.
> >
> >
> > In addition, I'd like to propose the following:
> >
> > 1. Always discuss the FLIP based on a FLIP wiki page instead of a Google
> > doc. It is perfectly fine to use google doc to explain stuff, but the
> FLIP
> > wiki page is the official source for the proposal. The discussion and
> vote
> > needs to be based on that.
> >
> > According to the process of FLIP
> > <
> >
> https://cwiki.apach

Re: [DISCUSS] META-FLIP: Sticking (or not) to a strict FLIP voting process

[Aljoscha Krettek]

+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  wrote:
> 
> 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 definition of major changes.
> 2. Committers have binding votes on FLIPs.
> 3. In general FLIPs should be completed in a reasonable amount of time,
> rather than lasting for many releases.
> 4. Always discuss FLIPs based on FLIP wiki page. Google docs can be used as
> handy tools to explain ideas, but FLIP ideas should always be documented as
> a FLIP wiki, regardless whether they are accepted or not.
> 5. FLIPs should be immutable. Changes to FLIPs need a new vote processes.
> 6. FLIPs should be concrete in terms of interfaces, semantic and behaviors,
> rather than conceptual.
> 
> It'll be good to hear what do people think. If there is no further
> objection, I'd suggest to conclude this discussion in 72 hours and move to
> a lazy majority voting. (For decisions like this, maybe only votes from
> PMCs should be considered as binding?)
> 
> Thanks,
> 
> Jiangjie (Becket) Qin
> 
> On Fri, Jun 28, 2019 at 10:33 AM Congxian Qiu 
> wrote:
> 
>> 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 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
>>> <
>>> 
>> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/template/NamlServlet.jtp?macro=search_page&node=1&query=subject%3AVOTE%2CFLIP&days=0
 
>>> gives
>>> only 3 FLIPs with voting thread, and unfortunately none of them has met
>> the
>>> lazy majority requirements, which needs 3 binding votes. However, we have
>>> 11 adopted-but-unreleased FLIPs and 16 released FLIPs.
>>> Even though we claimed *"These proposals are more serious than code
>> changes
>>> and more serious even than release votes.", *we did not really treat them
>>> seriously. The missing voting process effectively put the efforts of FLIP
>>> in vain. This leads to a few consequences:
>>> a) The conclusion of the FLIP is never really finalized. People may
>> change
>>> the FLIP at wish during the implementation.
>>> b) Some "adopted" FLIPs only have conceptual ideas instead of necessary
>>> concrete interfaces, which leaves a lot of problems in the implementation
>>> phase.
>>> c) New contributors are completely confused on how to contribute. The
>>> voting threads seems died, and magically someone else's code got checked
>> in
>>> without a passed FLIP. These "good citizens" may feel excluded and simply
>>> leave the chaos.
>>> d) API changes / user sensible behavior changes may be checked in without
>>> being carefully inspected. To fix them, hacky tricks has to be made in
>>> order to keep backwards compatibility.
>>> 
>>> So a huge +1 to stick to the FLIP voting process.
>>> 
>>> 2. Stick to the definition of major changes. Generally speaking any user
>>> sensible changes should go through a FLIP.
>>>- Some changes may be small from the size of patch perspective, but
>> the
>>> impact could be huge. Take metric as an example, imagine a cloud service
>>> provider who relies on a metric to do alerting or bill their customer.
>> Any
>>> change to such metrics will have huge impact on them.
>>>- Sometimes there might be no "interface" change per se, but the
>>> behavior of a method is slightly changed. Even that can be very annoying
>> to
>>> some users. So I think any user sensible changes should go through a
>> FLIP.
>>> 
>>> 3. Generally speaking, make each FLIP completable in a reasonable amount
>> of
>>> time. Some large changes may need multiple FLIPs.
>>>   - I agree with David that a long lasting FLIP can be problematic as it
>>> could become obsolete before the work is done. And might need to make
>>> changes to the original proposal multiple times. It might be a little
>>> difficult to have a standard to say what kind of FLIP is a long lasting
>>> FLIP.
>>>   - Sometimes long lasting FLIP may be necessary, e.g. a big new module
>> /
>>> functionality, etc. Those FLIPs are rare and usually more independent. We
>>> may need to treat them case by case.
>>> 
>>> 4. Take the votes from both committers and PMCs as binding.
>>> 
>>>

Re: [DISCUSS] META-FLIP: Sticking (or not) to a strict FLIP voting process

[Becket Qin]

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 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  wrote:
> >
> > 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 definition of major changes.
> > 2. Committers have binding votes on FLIPs.
> > 3. In general FLIPs should be completed in a reasonable amount of time,
> > rather than lasting for many releases.
> > 4. Always discuss FLIPs based on FLIP wiki page. Google docs can be used
> as
> > handy tools to explain ideas, but FLIP ideas should always be documented
> as
> > a FLIP wiki, regardless whether they are accepted or not.
> > 5. FLIPs should be immutable. Changes to FLIPs need a new vote processes.
> > 6. FLIPs should be concrete in terms of interfaces, semantic and
> behaviors,
> > rather than conceptual.
> >
> > It'll be good to hear what do people think. If there is no further
> > objection, I'd suggest to conclude this discussion in 72 hours and move
> to
> > a lazy majority voting. (For decisions like this, maybe only votes from
> > PMCs should be considered as binding?)
> >
> > Thanks,
> >
> > Jiangjie (Becket) Qin
> >
> > On Fri, Jun 28, 2019 at 10:33 AM Congxian Qiu 
> > wrote:
> >
> >> 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 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
> >>> <
> >>>
> >>
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/template/NamlServlet.jtp?macro=search_page&node=1&query=subject%3AVOTE%2CFLIP&days=0
> 
> >>> gives
> >>> only 3 FLIPs with voting thread, and unfortunately none of them has met
> >> the
> >>> lazy majority requirements, which needs 3 binding votes. However, we
> have
> >>> 11 adopted-but-unreleased FLIPs and 16 released FLIPs.
> >>> Even though we claimed *"These proposals are more serious than code
> >> changes
> >>> and more serious even than release votes.", *we did not really treat
> them
> >>> seriously. The missing voting process effectively put the efforts of
> FLIP
> >>> in vain. This leads to a few consequences:
> >>> a) The conclusion of the FLIP is never really finalized. People may
> >> change
> >>> the FLIP at wish during the implementation.
> >>> b) Some "adopted" FLIPs only have conceptual ideas instead of necessary
> >>> concrete interfaces, which leaves a lot of problems in the
> implementation
> >>> phase.
> >>> c) New contributors are completely confused on how to contribute. The
> >>> voting threads seems died, and magically someone else's code got
> checked
> >> in
> >>> without a passed FLIP. These "good citizens" may feel excluded and
> simply
> >>> leave the chaos.
> >>> d) API changes / user sensible behavior changes may be checked in
> without
> >>> being carefully inspected. To fix them, hacky tricks has to be made in
> >>> order to keep backwards compatibility.
> >>>
> >>> So a huge +1 to stick to the FLIP voting process.
> >>>
> >>> 2. Stick to the definition of major changes. Generally speaking any
> user
> >>> sensible changes should go through a FLIP.
> >>>- Some changes may be small from the size of patch perspective, but
> >> the
> >>> impact could be huge. Take metric as an example, imagine a cloud
> service
> >>> provider who relies on a metric to do alerting or bill their customer.
> >> Any
> >>> change to such metrics will have huge impact on them.
> >>>- Sometimes there might be no "interface" change per se, but the
> >>> behavior of a method is slightly changed. Even that can be very
> annoying
> >> to
> >>> some users. So I think any user sensible changes should go through a
> >> FLIP.
> >>>
> >>> 3. Generally speaking, make each FLIP completable in a reasonable
> amount
> >> of
> >>> time. Some large changes may need multiple FLIPs.
> >>>   - I agree with David that a long lasting FLIP can be problematic as
> it
> >>> could become obsolete before the work is d

Re: [DISCUSS] META-FLIP: Sticking (or not) to a strict FLIP voting process

[Robert Metzger]

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
contributors.
But we should try to make the process (FLIP) and rules (bylaws) as visible
as possible. Future (and probably even current) contributors will not be
aware of this discussion, so we need to make the results more prominent.



On Tue, Jul 9, 2019 at 4:29 PM Becket Qin  wrote:

> 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 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  wrote:
> > >
> > > 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 definition of major changes.
> > > 2. Committers have binding votes on FLIPs.
> > > 3. In general FLIPs should be completed in a reasonable amount of time,
> > > rather than lasting for many releases.
> > > 4. Always discuss FLIPs based on FLIP wiki page. Google docs can be
> used
> > as
> > > handy tools to explain ideas, but FLIP ideas should always be
> documented
> > as
> > > a FLIP wiki, regardless whether they are accepted or not.
> > > 5. FLIPs should be immutable. Changes to FLIPs need a new vote
> processes.
> > > 6. FLIPs should be concrete in terms of interfaces, semantic and
> > behaviors,
> > > rather than conceptual.
> > >
> > > It'll be good to hear what do people think. If there is no further
> > > objection, I'd suggest to conclude this discussion in 72 hours and move
> > to
> > > a lazy majority voting. (For decisions like this, maybe only votes from
> > > PMCs should be considered as binding?)
> > >
> > > Thanks,
> > >
> > > Jiangjie (Becket) Qin
> > >
> > > On Fri, Jun 28, 2019 at 10:33 AM Congxian Qiu 
> > > wrote:
> > >
> > >> 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 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
> > >>> <
> > >>>
> > >>
> >
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/template/NamlServlet.jtp?macro=search_page&node=1&query=subject%3AVOTE%2CFLIP&days=0
> > 
> > >>> gives
> > >>> only 3 FLIPs with voting thread, and unfortunately none of them has
> met
> > >> the
> > >>> lazy majority requirements, which needs 3 binding votes. However, we
> > have
> > >>> 11 adopted-but-unreleased FLIPs and 16 released FLIPs.
> > >>> Even though we claimed *"These proposals are more serious than code
> > >> changes
> > >>> and more serious even than release votes.", *we did not really treat
> > them
> > >>> seriously. The missing voting process effectively put the efforts of
> > FLIP
> > >>> in vain. This leads to a few consequences:
> > >>> a) The conclusion of the FLIP is never really finalized. People may
> > >> change
> > >>> the FLIP at wish during the implementation.
> > >>> b) Some "adopted" FLIPs only have conceptual ideas instead of
> necessary
> > >>> concrete interfaces, which leaves a lot of problems in the
> > implementation
> > >>> phase.
> > >>> c) New contributors are completely confused on how to contribute. The
> > >>> voting threads seems died, and magically someone else's code got
> > checked
> > >> in
> > >>> without a passed FLIP. These "good citizens" may feel excluded and
> > simply
> > >>> leave the chaos.
> > >>> d) API changes / user sensible behavior changes may be checked in
> > without
> > >>> being carefully inspected. To fix them, hacky tricks has to be made
> in
> > >>> order to keep backwards compatibility.
> > >>>
> > >>> So a huge +1 to stick to the FLIP voting process.
> > >>>
> > >>> 2. Stick to the definition of major changes. Generally speaking any
> > user
> > >>> sensible changes should go through a FLIP.
> > >>>- Some 

Re: [DISCUSS] META-FLIP: Sticking (or not) to a strict FLIP voting process

[Becket Qin]

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 use that as a base version and
make revisions if needed. I can create a bylaws wiki page as a base version
for discussion. We may highlight and link to it on the "How to contribute"
page after that is finalized. Every time when we grant permission to new
contributors, we should refer them to that page.

The FLIP process itself seems clear enough to me. Once we have our bylaws,
we probably just need more attention on the execution side. Usually what
happens is that someone proposes an idea either in a Jira ticket / mailing
list. Those who are familiar with the process will simply ask for a FLIP if
needed.

Thanks,

Jiangjie (Becket) Qin



On Wed, Jul 10, 2019 at 11:55 PM Robert Metzger  wrote:

> 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
> contributors.
> But we should try to make the process (FLIP) and rules (bylaws) as visible
> as possible. Future (and probably even current) contributors will not be
> aware of this discussion, so we need to make the results more prominent.
>
>
>
> On Tue, Jul 9, 2019 at 4:29 PM Becket Qin  wrote:
>
> > 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 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  wrote:
> > > >
> > > > 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 definition of major changes.
> > > > 2. Committers have binding votes on FLIPs.
> > > > 3. In general FLIPs should be completed in a reasonable amount of
> time,
> > > > rather than lasting for many releases.
> > > > 4. Always discuss FLIPs based on FLIP wiki page. Google docs can be
> > used
> > > as
> > > > handy tools to explain ideas, but FLIP ideas should always be
> > documented
> > > as
> > > > a FLIP wiki, regardless whether they are accepted or not.
> > > > 5. FLIPs should be immutable. Changes to FLIPs need a new vote
> > processes.
> > > > 6. FLIPs should be concrete in terms of interfaces, semantic and
> > > behaviors,
> > > > rather than conceptual.
> > > >
> > > > It'll be good to hear what do people think. If there is no further
> > > > objection, I'd suggest to conclude this discussion in 72 hours and
> move
> > > to
> > > > a lazy majority voting. (For decisions like this, maybe only votes
> from
> > > > PMCs should be considered as binding?)
> > > >
> > > > Thanks,
> > > >
> > > > Jiangjie (Becket) Qin
> > > >
> > > > On Fri, Jun 28, 2019 at 10:33 AM Congxian Qiu <
> qcx978132...@gmail.com>
> > > > wrote:
> > > >
> > > >> 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 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
> > > >>> <
> > > >>>
> > > >>
> > >
> >
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/template/NamlServlet.jtp?macro=search_page&node=1&query=subject%3AVOTE%2CFLIP&days=0
> > > 
> > > >>> gives
> > > >>> only 3 FLIPs with voting thread, and unfortunately none of them has
> > met
> > > >> the
> > > >>> lazy majority requirements, which needs 3 binding votes. However,
> we
> > > have
> > > >>> 11 adopted-but-unreleased FLIPs and 16 released FLIPs.
> > > >>> Even though we claimed *"These proposals are more serious than code
> > > >> changes
> > > >>> and 

Re: [DISCUSS] META-FLIP: Sticking (or not) to a strict FLIP voting process

[Yu Li]

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 conclude the thread:

The very initial one:
* Stick voting process for FLIP
   - Definition of a passing vote: lazy majority (more than 3 binding +1s)
rather than lazy consensus @Aljosha (all others agreed)
   - Whose votings are counted as "binding": from both PMCs and
committers @Jark @Stephan @David
(My 2 cents around this topic: I suggest to encourage more non-binding
votes to supply more inputs to our PMCs/committers and prevent the binding
votes only representing a small group, although non-binding votes don't
count)

The extended ones:
* The standard of FLIP (definition, scope, etc.)
   - Definition: does the long-existing standard still stands or need some
update? should we have a blacklist about what's NOT a FLIP? @Chesnay
@jincheng @Gordon @Hequn
   - Timeline Scope: should the FLIP be scoped to fit into a single
release? @David @Becket
   - Dos and Don'ts: FLIP should be concrete in terms of interfaces,
semantic and behaviors, not conceptual. FLIP should become immutable after
voting, and change it requiring a new iteration of the
process @Becket @Aljoscha
   - We'd better explicitly write down our Flink bylaw @Robert @Becket

* How to better follow up a FLIP
   - Should a committer be assigned to shepherd the FLIP if it's created by
a contributor? @Kurt @Biao
   - There must be a wiki for a FLIP no matter it's accepted or not, for
later tracking and future discussion @Aljoscha @Becket

FWIW, there should be no doubt to conclude the initial proposal on stick
voting process for FLIP, while I'm not sure whether we could also conclude
the other two in this single thread or they worth new separate discuss
threads? Thanks.

Best Regards,
Yu


On Thu, 11 Jul 2019 at 09:33, Becket Qin  wrote:

> 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 use that as a base version and
> make revisions if needed. I can create a bylaws wiki page as a base version
> for discussion. We may highlight and link to it on the "How to contribute"
> page after that is finalized. Every time when we grant permission to new
> contributors, we should refer them to that page.
>
> The FLIP process itself seems clear enough to me. Once we have our bylaws,
> we probably just need more attention on the execution side. Usually what
> happens is that someone proposes an idea either in a Jira ticket / mailing
> list. Those who are familiar with the process will simply ask for a FLIP if
> needed.
>
> Thanks,
>
> Jiangjie (Becket) Qin
>
>
>
> On Wed, Jul 10, 2019 at 11:55 PM Robert Metzger 
> wrote:
>
> > 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
> > contributors.
> > But we should try to make the process (FLIP) and rules (bylaws) as
> visible
> > as possible. Future (and probably even current) contributors will not be
> > aware of this discussion, so we need to make the results more prominent.
> >
> >
> >
> > On Tue, Jul 9, 2019 at 4:29 PM Becket Qin  wrote:
> >
> > > 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 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  wrote:
> > > > >
> > > > > 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 definition of major changes.
> > > > > 2. Committers have binding votes on FLIPs.
> > > > > 3. In general FLIPs should be completed in a reasonable amount of
> > time,
> > > > > rather than lasting for many releases.
> > > >

Re: [DISCUSS] META-FLIP: Sticking (or not) to a strict FLIP voting process

[Becket Qin]

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 be completed in a reasonable amount of time,
rather than lasting for many releases.
2. FLIPs should be immutable. Changes to FLIPs need a new vote processes.
3. FLIPs should be concrete in terms of interfaces, semantic and
behaviours, rather than conceptual.
4. At least one committer should shepherd a FLIP. By default that will be
the author him/herself if the author is a committer. Otherwise, that will
be one of the committer who voted +1 on the FLIP.

For the last point, I am not quite sure about how this Shepherding is
related to the FLIP voting. Or should shepherding be a necessary thing in
order to start the voting process. Any idea on how to make this work?

Thanks,

Jiangjie (Becket) Qin


On Thu, Jul 11, 2019 at 12:29 PM Yu Li  wrote:

> 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 conclude the thread:
>
> The very initial one:
> * Stick voting process for FLIP
>- Definition of a passing vote: lazy majority (more than 3 binding +1s)
> rather than lazy consensus @Aljosha (all others agreed)
>- Whose votings are counted as "binding": from both PMCs and
> committers @Jark @Stephan @David
> (My 2 cents around this topic: I suggest to encourage more non-binding
> votes to supply more inputs to our PMCs/committers and prevent the binding
> votes only representing a small group, although non-binding votes don't
> count)
>
> The extended ones:
> * The standard of FLIP (definition, scope, etc.)
>- Definition: does the long-existing standard still stands or need some
> update? should we have a blacklist about what's NOT a FLIP? @Chesnay
> @jincheng @Gordon @Hequn
>- Timeline Scope: should the FLIP be scoped to fit into a single
> release? @David @Becket
>- Dos and Don'ts: FLIP should be concrete in terms of interfaces,
> semantic and behaviors, not conceptual. FLIP should become immutable after
> voting, and change it requiring a new iteration of the
> process @Becket @Aljoscha
>- We'd better explicitly write down our Flink bylaw @Robert @Becket
>
> * How to better follow up a FLIP
>- Should a committer be assigned to shepherd the FLIP if it's created by
> a contributor? @Kurt @Biao
>- There must be a wiki for a FLIP no matter it's accepted or not, for
> later tracking and future discussion @Aljoscha @Becket
>
> FWIW, there should be no doubt to conclude the initial proposal on stick
> voting process for FLIP, while I'm not sure whether we could also conclude
> the other two in this single thread or they worth new separate discuss
> threads? Thanks.
>
> Best Regards,
> Yu
>
>
> On Thu, 11 Jul 2019 at 09:33, Becket Qin  wrote:
>
> > 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 use that as a base version and
> > make revisions if needed. I can create a bylaws wiki page as a base
> version
> > for discussion. We may highlight and link to it on the "How to
> contribute"
> > page after that is finalized. Every time when we grant permission to new
> > contributors, we should refer them to that page.
> >
> > The FLIP process itself seems clear enough to me. Once we have our
> bylaws,
> > we probably just need more attention on the execution side. Usually what
> > happens is that someone proposes an idea either in a Jira ticket /
> mailing
> > list. Those who are familiar with the process will simply ask for a FLIP
> if
> > needed.
> >
> > Thanks,
> >
> > Jiangjie (Becket) Qin
> >
> >
> >
> > On Wed, Jul 10, 2019 at 11:55 PM Robert Metzger 
> > wrote:
> >
> > > 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
> > > contributors.
> > > But we should try to make the process (FLIP) and rules (bylaws) as
> > visible
> > > as possible. Future (and probably even current) contributors will not
> be
> > > aware of this discussion, so we need to make the results more
> prominent.
> > >
> > >
> > >
> > > On Tue, Jul 9, 2019 at 4:29 PM Becket Qin 
> wrote:
> > >
> > > > Hi Aljoscha,
> > > >
> > > > Thanks f