The discussion has been open for quite some time and there seems not to be
more inputs.
Thanks all for the discussion. I have updated the Flink Improvement
Proposals wiki page [1] with the discussed conventions.
Best,
Xintong
[1]
https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvem
Thanks all for the feedback.
@Dong,
I fully agree that we should document the agreements on wiki. However, I'd
hesitate about the MUST / SHOULD phrasing. I personally would consider
these conventions, except for the one quoted from the ASF policy, as
empirical inputs for individual judgements, w
Thanks all for the valuable information. It is a great step to make the
FLIP running more smoothly.
I'd like to share two additional suggestions:
1. Veto with care - Voter should present her-/him-self and give a veto with
her/his own technical justification. No veto is allowed only based on
someo
Thanks Xintong for summarizing the PMC discussion here. I agree that
working on trust instead of imposing more rules is the right thing to do.
But I see Dong's point on documenting such an agreement in some way to give
guidance to new contributors.
One thing that I think might be helpful to includ
Thanks Xintong for initiating and sharing the discussion!
The agreement described in the summary looks pretty good. In particular, it
is great to know that ASF already has guidance requiring "voter must
provide with the veto a technical justification showing why the change is
bad". This is exactly
Thank Xintong for starting the discussion in PMC and bringing the summary
here.
The summary looks good to me. Unresponsive reviewing has happened numerous
times in the previous FLIPs. I think the conventions are very valuable for
the community
to move forward efficiently and avoid potential confli
Hi devs,
Recently, a discussion about how to drive FLIPs towards consensus has taken
place on the private@ mailing list. While many PMC members have already
shared their opinions, we believe for this topic the opinions of other
committers / contributors are equally important. Therefore, we are mov
