Yes, I'd also link it in the wiki.
On 28/08/2019 15:27, Robert Metzger wrote:
Thanks a lot for running the vote Becket!
I have removed the "(draft)" from the wiki page :)
Should we link the bylaws also from the Flink website?
On Thu, Aug 22, 2019 at 6:23 PM Becket Qin wrote:
Thanks for col
Thanks a lot for running the vote Becket!
I have removed the "(draft)" from the wiki page :)
Should we link the bylaws also from the Flink website?
On Thu, Aug 22, 2019 at 6:23 PM Becket Qin wrote:
> Thanks for collecting the ideas of Bylaws changes. It is a good idea!
>
> Jiangjie (Becket) Qi
Thanks for collecting the ideas of Bylaws changes. It is a good idea!
Jiangjie (Becket) Qin
On Thu, Aug 22, 2019 at 12:11 PM Robert Metzger wrote:
> I have started a Wiki page (editable by all) for collecting ideas for
> Bylaws changes, so that we can batch changes together and then vote on
> t
I have started a Wiki page (editable by all) for collecting ideas for
Bylaws changes, so that we can batch changes together and then vote on
them:
https://cwiki.apache.org/confluence/display/FLINK/Ideas+for+Bylaw+changes
On Tue, Aug 13, 2019 at 1:41 PM Becket Qin wrote:
> Hi Robert,
>
> Thanks f
Hi Robert,
Thanks for help apply the changes. I agree we should freeze the change to
the bylaws page starting from now. For this particular addition of
clarification, I'll send a notice in the voting thread to let who have
already voted to know.
Thanks,
Jiangjie (Becket) Qin
On Tue, Aug 13, 201
Hi Becket,
I've applied the proposed change to the document:
https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=120731026&selectedPageVersions=20&selectedPageVersions=19
I would propose to stop accepting changes to the document now, as it might
start a discussion about the
Hi Becket,
Thanks for clarifying and updating the draft. The changes look good to me.
I don't feel strong about a 2/3 majority in case of committer/PMC
removal. Like you pointed out, both provide a significant hurdle due to
possible vetos or a 2/3 majority.
Thanks,
Max
On 13.08.19 10:36, Becket
Piotr just reminded me that there was a previous suggestion to clarify a
committer's responsibility when commit his/her own patch. So I'd like to
incorporate that in the bylaws. The additional clarification is following
in bold and italic font.
one +1 from a committer followed by a Lazy approval (
Hi Maximillian,
Thanks for the feedback. Please see the reply below:
Step 2 should include a personal email to the PMC members in question.
I'm afraid reminders inside the vote thread could be overlooked easily.
This is exactly what I meant to say by "reach out" :) I just made it more
explicit
I'm a bit late to the discussion here. Three suggestions:
1) Procedure for "insufficient active binding voters to reach 2/3 majority
> 1. Wait until the minimum length of the voting passes.
> 2. Publicly reach out to the remaining binding voters in the voting mail
> thread for at least 2
Hi folks,
Thanks for all the discussion and support. I have started the voting thread.
http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/VOTE-Flink-Project-Bylaws-td31558.html
Thanks,
Jiangjie (Becket) Qin
On Thu, Aug 8, 2019 at 2:56 PM Fabian Hueske wrote:
> Thanks for the upda
Thanks for the update and driving the discussion Becket!
+1 for starting a vote.
Am Mi., 7. Aug. 2019 um 11:44 Uhr schrieb Becket Qin :
> Thanks Stephan.
>
> I think we have resolved all the comments on the wiki page. There are two
> minor changes made to the bylaws since last week.
> 1. For 2/3
Thanks Stephan.
I think we have resolved all the comments on the wiki page. There are two
minor changes made to the bylaws since last week.
1. For 2/3 majority, the required attempts to reach out to binding voters
is reduced from 3 to 2. This helps shorten the voting process a little bit.
2. Clari
I added a clarification to the table, clarifying that the current phrasing
means that committers do not need another +1 for their commits.
On Mon, Jul 29, 2019 at 2:11 PM Fabian Hueske wrote:
> Hi Becket,
>
> Thanks a lot for pushing this forward and addressing the feedback.
> I'm very happy wit
Hi Becket,
Thanks a lot for pushing this forward and addressing the feedback.
I'm very happy with the current state of the bylaws.
+1 to wait until Friday before starting a vote.
Best, Fabian
Am Mo., 29. Juli 2019 um 13:47 Uhr schrieb Becket Qin :
> Hi Everyone,
>
> Thanks for all the discussio
Hi Everyone,
Thanks for all the discussion and feedback.
It seems that we have almost reached consensus. I'll leave the discussion
thread open until this Friday. If there is no more concerns raised, I'll
start a voting thread after that.
Thanks,
Jiangjie (Becket) Qin
On Fri, Jul 26, 2019 at 6:
Hi Becket,
Thanks for noticing and resolving my comment around PMC removal and ASF
rules of PMC membership change process, which you seem to neglect in the
summary of updates (smile).
Best Regards,
Yu
On Wed, 24 Jul 2019 at 04:32, Becket Qin wrote:
> Hi folks,
>
> Thanks for all the feedback.
Hi folks,
Thanks for all the feedback.
It seems that there are a few concerns over the emeritus status after 6
months of inactivity. Given that the main purpose is just to make sure 2/3
majority can pass and we sort of have a solution for that, I just updated
the draft with the following changes:
Hi Fabian,
Thanks for the feedback.
I agree that if we don't like emeritus committers / PMCs, we don't have to
do it. That said, emeritus status simply means whether an individual is
active / inactive in the community. It does not make the merits earned to
go away. For our purpose, emeritus statu
Hi all,
First of all thank you very much Becket for starting this discussion!
I think it is a very good idea and overdue to formally define some of our
community processes.
Similar to Chesnay, I have concerns about the distinction between active
and non-active / emeritus committers and PMC member
Hi Hequn,
Thanks for sharing your thoughts. Please see the reply below:
> Perhaps what Jincheng means is to hold at least one PMC in the 3 binding
> votes? i.e, the vote could have 2 binding committers and 1 PMC.
> I think this makes sense considering a FLIP could somehow be a big feature
> which
Big +1 on this.
best
forward
Hequn Cheng 于2019年7月21日周日 下午1:30写道：
> Hi Becket,
>
> Big +1 on this.
>
> > Regarding the vote of FLIP, preferably at least includes a PMC vote.
> Perhaps what Jincheng means is to hold at least one PMC in the 3 binding
> votes? i.e, the vote could have 2 binding c
Hi Becket,
Big +1 on this.
> Regarding the vote of FLIP, preferably at least includes a PMC vote.
Perhaps what Jincheng means is to hold at least one PMC in the 3 binding
votes? i.e, the vote could have 2 binding committers and 1 PMC.
I think this makes sense considering a FLIP could somehow be a
Hi Jincheng,
Thanks for the comments. I replied on the wiki page. Just a brief summary,
the current bylaws do require some of the FLIPs to get PMC approval if
their impact is big enough. But it leaves majority of the technical
decisions to the committers who are supposed to be responsible for maki
Hi all,
I agree with Aljoscha that trying to reflect the current status in the
bylaws, and then implementing changes one by one is a very involved task.
Unless there's somebody who's really eager to drive this, I would stick to
Becket's initiative to come up with Bylaws for Flink, even if this mean
Hi Becket,
Thanks for the proposal.
Regarding the vote of FLIP, preferably at least includes a PMC vote.
Because FLIP is usually a big change or affects the user's interface
changes. What do you think? (I leave the comment in the wiki.)
Best,
Jincheng
Dawid Wysakowicz 于2019年7月17日周三 下午9:12写道：
Hi all,
Sorry for joining late. I just wanted to say that I really like the
proposed bylaws!
One comment, I also have the same concerns as expressed by few people
before that the "committer +1" on code change might be hard to achieve
currently. On the other hand I would say this would be benefici
Hi Aljoscha and Becket
Right, 3 days for FLIP voting is fine I think.
>> I’m missing this stated somewhere clearly. If we are stating that a single
>> committers +1 is good enough for code review, with 0 hours delay (de facto
>> the current state), we should also write down that this is subject t
@Piotr regarding the 3 days voting on the FLIP. This is just about the voting,
before that there needs to be the discussion thread. If three days have passed
on a vote and there is consensus (i.e. 3 committers/PMCs have voted +1) that
seems a high enough bar for me. So far, we have rarely see an
Hi Chesnay,
We could do that. This might actually help unblock other things such as
META-FLIP discussion quicker. Will you or someone familiar enough with the
current state to write it down?
If we are going to have an itemized discussion, I think the parts need
immediate attention are:
1. Vote typ
Hi,
Thanks for the proposal. Generally speaking +1 from my side to the general idea
and most of the content. I also see merit to the Chesney's proposal to start
from the current state. I think either would be fine for me.
Couple of comments:
1.
I also think that requiring +1 from another com
I'm wondering whether we shouldn't first write down Bylaws that reflect
the current state, and then have separate discussions for individual
amendments. My gut feeling is that this discussion will quickly become a
chaotic mess with plenty points being discussed at once.
On 11/07/2019 20:03, Bo
On Thu, Jul 11, 2019 at 10:38 AM Becket Qin wrote:
> Thanks everyone for all the comments and feedback. Please see the replies
> below:
>
>
> Re: Konstantin
>
> > * In addition to a simple "Code Change" we could also add a row for "Code
> > Change requiring a FLIP
Thanks everyone for all the comments and feedback. Please see the replies
below:
Re: Konstantin
> * In addition to a simple "Code Change" we could also add a row for "Code
> Change requiring a FLIP" with a reference to the FLIP process page. A FLIP
> will have/doe
Big +1
How different is this from the Kafka bylaws? I’m asking because I quite like
them and wouldn’t mind essentially adopting the Kafka bylaws. I mean, it’s open
source, and we don’t have to try to re-invent the wheel here.
I think it’s worthwhile to discuss the “committer +1” requirement. We
Thanks a lot for creating this draft Becket.
I think without the notion of emeritus (or active vs. inactive), it won't
be possible to have a 2/3 majority vote because we already have too many
inactive PMCs/committers.
For the case of a committer being the author and getting a +1 from a
non-commit
The emeritus stuff seems like unnecessary noise.
There's a bunch of subtle changes in the draft compared to existing
"conventions"; we should find a way to highlight these and discuss them
one by one.
On 11/07/2019 14:29, Robert Metzger wrote:
Thank you Becket for kicking off this discussion
Thank you Becket for kicking off this discussion and creating a draft in
the Wiki.
I left some comments in the wiki.
In my understanding this means, that a committer always needs a review and
> +1 from another committer. As far as I know this is currently not always
> the case (often committer au
Hi all,
thanks a lot for driving this, Becket. I have two remarks regarding the
"Actions" section:
* In addition to a simple "Code Change" we could also add a row for "Code
Change requiring a FLIP" with a reference to the FLIP process page. A FLIP
will have/does have different rules for approvals
Hi all,
As it was raised in the FLIP process discussion thread [1], currently Flink
does not have official bylaws to govern the operation of the project. Such
bylaws are critical for the community to coordinate and contribute
together. It is also the basis of other processes such as FLIP.
I have
40 matches
Mail list logo
