Re: [DISCUSS] Flink project bylaws
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 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 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 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, 2019 at 1:29 PM Robert Metzger wrote: Hi Becket, I've applied the proposed change to the document: https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=120731026=20=19 I would propose to stop accepting changes to the document now, as it might start a discussion about the validity of the vote and the bylaws itself. Changes to the document require a 2/3 majority. On Tue, Aug 13, 2019 at 12:20 PM Maximilian Michels wrote: 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 Qin wrote: 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 (not counting the vote of the contributor), moving to lazy majority if a -1 is received. Note that this implies that committers can +1 their own commits and merge right away. *However, the committe**rs should use their best judgement to respect the components expertise and ongoing development plan.* This does not really change any of the existing bylaws, just about clarification. If there is no objection to this additional clarification, after the bylaws wiki is updated, I'll send an update notice to the voting thread to inform those who already voted about this addition. Thanks, Jiangjie (Becket) Qin On Mon, Aug 12, 2019 at 11:19 AM Becket Qin < becket@gmail.com> wrote: 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. The way the terms are described in the draft, the consensus is "lazy", i.e. requires only 3 binding votes. I'd suggest renaming it to "Lazy Consensus". This is in line with the other definitions such as "Lazy Majority". It was initially called "lazy consensus", but Robert pointed out that "lazy consensus" actually means something different in ASF term [1]. Here "lazy" pretty much means "assume everyone is +1 unless someone says otherwise". This means any vote that requires a minimum number of +1 is not really a "lazy" vote. Removing a committer / PMC member only requires 3 binding votes. I'd expect an important action like this to require a 2/3 majority. Personally I think consensus is good enough here. PMC members can cast a veto if they disagree about the removal. In some sense, it is more difficult than with 2/3 majority to remove a committer / PMC member. Also, it might be a hard decision for some PMC members if they have never worked with the person in question. That said, I am OK to change it to 2/3 majority as this will happen very rarely. Thanks, Jiangjie (Becket) Qin [1] https://www.apache.org/foundation/voting.html#LazyConsensus On Sun, Aug 11, 2019 at 5:00 PM Maximilian Michels < m...@apache.org> wrote: 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 attempts with at least 7 days between two attempts. 3. If the binding voter being contacted still failed to respond after all the attempts, the binding voter will be considered as inactive for the purpose of this particular voting. Step 2 should include a personal email to the PMC members
Re: [DISCUSS] Flink project bylaws
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) 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 > > 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 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, 2019 at 1:29 PM Robert Metzger > > > wrote: > > > > > > > Hi Becket, > > > > I've applied the proposed change to the document: > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=120731026=20=19 > > > > > > > > I would propose to stop accepting changes to the document now, as it > > > might > > > > start a discussion about the validity of the vote and the bylaws > > itself. > > > > Changes to the document require a 2/3 majority. > > > > > > > > > > > > On Tue, Aug 13, 2019 at 12:20 PM Maximilian Michels > > > > wrote: > > > > > > > > > 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 Qin wrote: > > > > > > 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 (not counting > > the > > > > > vote > > > > > >> of the contributor), moving to lazy majority if a -1 is > received. > > > > > >> > > > > > > > > > > > > > > > > > > Note that this implies that committers can +1 their own commits > and > > > > merge > > > > > >> right away. *However, the committe**rs should use their best > > > judgement > > > > > to > > > > > >> respect the components expertise and ongoing development plan.* > > > > > > > > > > > > > > > > > > This does not really change any of the existing bylaws, just > about > > > > > > clarification. > > > > > > > > > > > > If there is no objection to this additional clarification, after > > the > > > > > bylaws > > > > > > wiki is updated, I'll send an update notice to the voting thread > to > > > > > inform > > > > > > those who already voted about this addition. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Jiangjie (Becket) Qin > > > > > > > > > > > > On Mon, Aug 12, 2019 at 11:19 AM Becket Qin < > becket@gmail.com> > > > > > wrote: > > > > > > > > > > > >> 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. > > > > > >> > > > > > >> The way the terms are described in the draft, the consensus is > > > "lazy", > > > > > >>> i.e. requires only 3 binding votes. I'd suggest renaming it to > > > "Lazy > > > > > >>> Consensus". This is in line with the other definitions such as > > > "Lazy > > > > > >>> Majority". > > > > > >> > > > > > >> It was initially called "lazy consensus", but Robert pointed out > > > that > > > > > >> "lazy consensus" actually means something different in ASF term > > [1]. > > > > > >> Here "lazy" pretty much means "assume everyone is +1 unless > > someone > > > > says > > > > > >> otherwise". This means any vote that requires a minimum number > of > > +1 > > > > is > > > > > not > > > > > >> really a "lazy" vote. > > > > > >> > > > > > >> Removing a committer / PMC member only requires 3 binding votes. > > I'd > > > > > >>> expect an important action like this to require a 2/3 majority. > > > > > >> > > > > > >> Personally I think consensus is good enough here. PMC members > can > > > > cast a > >
Re: [DISCUSS] Flink project bylaws
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 > 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 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, 2019 at 1:29 PM Robert Metzger > > wrote: > > > > > Hi Becket, > > > I've applied the proposed change to the document: > > > > > > > > > https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=120731026=20=19 > > > > > > I would propose to stop accepting changes to the document now, as it > > might > > > start a discussion about the validity of the vote and the bylaws > itself. > > > Changes to the document require a 2/3 majority. > > > > > > > > > On Tue, Aug 13, 2019 at 12:20 PM Maximilian Michels > > > wrote: > > > > > > > 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 Qin wrote: > > > > > 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 (not counting > the > > > > vote > > > > >> of the contributor), moving to lazy majority if a -1 is received. > > > > >> > > > > > > > > > > > > > > > Note that this implies that committers can +1 their own commits and > > > merge > > > > >> right away. *However, the committe**rs should use their best > > judgement > > > > to > > > > >> respect the components expertise and ongoing development plan.* > > > > > > > > > > > > > > > This does not really change any of the existing bylaws, just about > > > > > clarification. > > > > > > > > > > If there is no objection to this additional clarification, after > the > > > > bylaws > > > > > wiki is updated, I'll send an update notice to the voting thread to > > > > inform > > > > > those who already voted about this addition. > > > > > > > > > > Thanks, > > > > > > > > > > Jiangjie (Becket) Qin > > > > > > > > > > On Mon, Aug 12, 2019 at 11:19 AM Becket Qin > > > > wrote: > > > > > > > > > >> 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. > > > > >> > > > > >> The way the terms are described in the draft, the consensus is > > "lazy", > > > > >>> i.e. requires only 3 binding votes. I'd suggest renaming it to > > "Lazy > > > > >>> Consensus". This is in line with the other definitions such as > > "Lazy > > > > >>> Majority". > > > > >> > > > > >> It was initially called "lazy consensus", but Robert pointed out > > that > > > > >> "lazy consensus" actually means something different in ASF term > [1]. > > > > >> Here "lazy" pretty much means "assume everyone is +1 unless > someone > > > says > > > > >> otherwise". This means any vote that requires a minimum number of > +1 > > > is > > > > not > > > > >> really a "lazy" vote. > > > > >> > > > > >> Removing a committer / PMC member only requires 3 binding votes. > I'd > > > > >>> expect an important action like this to require a 2/3 majority. > > > > >> > > > > >> Personally I think consensus is good enough here. PMC members can > > > cast a > > > > >> veto if they disagree about the removal. In some sense, it is more > > > > >> difficult than with 2/3 majority to remove a committer / PMC > member. > > > > Also, > > > > >> it might be a hard decision for some PMC members if they have > never > > > > worked > > > > >> with the person in question. That said, I am OK to change it to > 2/3 > > > > >> majority as this will happen very rarely. > > > > >> > > > > >> Thanks, > > > > >> > > > > >> Jiangjie (Becket) Qin > > > > >> > > > > >> [1]
Re: [DISCUSS] Flink project bylaws
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 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, 2019 at 1:29 PM Robert Metzger > wrote: > > > Hi Becket, > > I've applied the proposed change to the document: > > > > > https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=120731026=20=19 > > > > I would propose to stop accepting changes to the document now, as it > might > > start a discussion about the validity of the vote and the bylaws itself. > > Changes to the document require a 2/3 majority. > > > > > > On Tue, Aug 13, 2019 at 12:20 PM Maximilian Michels > > wrote: > > > > > 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 Qin wrote: > > > > 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 (not counting the > > > vote > > > >> of the contributor), moving to lazy majority if a -1 is received. > > > >> > > > > > > > > > > > > Note that this implies that committers can +1 their own commits and > > merge > > > >> right away. *However, the committe**rs should use their best > judgement > > > to > > > >> respect the components expertise and ongoing development plan.* > > > > > > > > > > > > This does not really change any of the existing bylaws, just about > > > > clarification. > > > > > > > > If there is no objection to this additional clarification, after the > > > bylaws > > > > wiki is updated, I'll send an update notice to the voting thread to > > > inform > > > > those who already voted about this addition. > > > > > > > > Thanks, > > > > > > > > Jiangjie (Becket) Qin > > > > > > > > On Mon, Aug 12, 2019 at 11:19 AM Becket Qin > > > wrote: > > > > > > > >> 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. > > > >> > > > >> The way the terms are described in the draft, the consensus is > "lazy", > > > >>> i.e. requires only 3 binding votes. I'd suggest renaming it to > "Lazy > > > >>> Consensus". This is in line with the other definitions such as > "Lazy > > > >>> Majority". > > > >> > > > >> It was initially called "lazy consensus", but Robert pointed out > that > > > >> "lazy consensus" actually means something different in ASF term [1]. > > > >> Here "lazy" pretty much means "assume everyone is +1 unless someone > > says > > > >> otherwise". This means any vote that requires a minimum number of +1 > > is > > > not > > > >> really a "lazy" vote. > > > >> > > > >> Removing a committer / PMC member only requires 3 binding votes. I'd > > > >>> expect an important action like this to require a 2/3 majority. > > > >> > > > >> Personally I think consensus is good enough here. PMC members can > > cast a > > > >> veto if they disagree about the removal. In some sense, it is more > > > >> difficult than with 2/3 majority to remove a committer / PMC member. > > > Also, > > > >> it might be a hard decision for some PMC members if they have never > > > worked > > > >> with the person in question. That said, I am OK to change it to 2/3 > > > >> majority as this will happen very rarely. > > > >> > > > >> Thanks, > > > >> > > > >> Jiangjie (Becket) Qin > > > >> > > > >> [1] https://www.apache.org/foundation/voting.html#LazyConsensus > > > >> > > > >> On Sun, Aug 11, 2019 at 5:00 PM Maximilian Michels > > > wrote: > > > >> > > > >>> 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 > >
Re: [DISCUSS] Flink project bylaws
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, 2019 at 1:29 PM Robert Metzger wrote: > Hi Becket, > I've applied the proposed change to the document: > > https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=120731026=20=19 > > I would propose to stop accepting changes to the document now, as it might > start a discussion about the validity of the vote and the bylaws itself. > Changes to the document require a 2/3 majority. > > > On Tue, Aug 13, 2019 at 12:20 PM Maximilian Michels > wrote: > > > 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 Qin wrote: > > > 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 (not counting the > > vote > > >> of the contributor), moving to lazy majority if a -1 is received. > > >> > > > > > > > > > Note that this implies that committers can +1 their own commits and > merge > > >> right away. *However, the committe**rs should use their best judgement > > to > > >> respect the components expertise and ongoing development plan.* > > > > > > > > > This does not really change any of the existing bylaws, just about > > > clarification. > > > > > > If there is no objection to this additional clarification, after the > > bylaws > > > wiki is updated, I'll send an update notice to the voting thread to > > inform > > > those who already voted about this addition. > > > > > > Thanks, > > > > > > Jiangjie (Becket) Qin > > > > > > On Mon, Aug 12, 2019 at 11:19 AM Becket Qin > > wrote: > > > > > >> 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. > > >> > > >> The way the terms are described in the draft, the consensus is "lazy", > > >>> i.e. requires only 3 binding votes. I'd suggest renaming it to "Lazy > > >>> Consensus". This is in line with the other definitions such as "Lazy > > >>> Majority". > > >> > > >> It was initially called "lazy consensus", but Robert pointed out that > > >> "lazy consensus" actually means something different in ASF term [1]. > > >> Here "lazy" pretty much means "assume everyone is +1 unless someone > says > > >> otherwise". This means any vote that requires a minimum number of +1 > is > > not > > >> really a "lazy" vote. > > >> > > >> Removing a committer / PMC member only requires 3 binding votes. I'd > > >>> expect an important action like this to require a 2/3 majority. > > >> > > >> Personally I think consensus is good enough here. PMC members can > cast a > > >> veto if they disagree about the removal. In some sense, it is more > > >> difficult than with 2/3 majority to remove a committer / PMC member. > > Also, > > >> it might be a hard decision for some PMC members if they have never > > worked > > >> with the person in question. That said, I am OK to change it to 2/3 > > >> majority as this will happen very rarely. > > >> > > >> Thanks, > > >> > > >> Jiangjie (Becket) Qin > > >> > > >> [1] https://www.apache.org/foundation/voting.html#LazyConsensus > > >> > > >> On Sun, Aug 11, 2019 at 5:00 PM Maximilian Michels > > wrote: > > >> > > >>> 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 attempts with at least 7 days between two > > >>> attempts. > > 3. If the binding voter being contacted still failed to respond > > >>> after all the attempts, the binding voter will be considered as > > inactive > > >>> for the purpose of this particular voting. > > >>> > > >>> 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. > > >>> > > >>> 2) "Consensus" => "Lazy Consensus" > > >>> > > >>> The way the
Re: [DISCUSS] Flink project bylaws
Hi Becket, I've applied the proposed change to the document: https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=120731026=20=19 I would propose to stop accepting changes to the document now, as it might start a discussion about the validity of the vote and the bylaws itself. Changes to the document require a 2/3 majority. On Tue, Aug 13, 2019 at 12:20 PM Maximilian Michels wrote: > 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 Qin wrote: > > 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 (not counting the > vote > >> of the contributor), moving to lazy majority if a -1 is received. > >> > > > > > > Note that this implies that committers can +1 their own commits and merge > >> right away. *However, the committe**rs should use their best judgement > to > >> respect the components expertise and ongoing development plan.* > > > > > > This does not really change any of the existing bylaws, just about > > clarification. > > > > If there is no objection to this additional clarification, after the > bylaws > > wiki is updated, I'll send an update notice to the voting thread to > inform > > those who already voted about this addition. > > > > Thanks, > > > > Jiangjie (Becket) Qin > > > > On Mon, Aug 12, 2019 at 11:19 AM Becket Qin > wrote: > > > >> 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. > >> > >> The way the terms are described in the draft, the consensus is "lazy", > >>> i.e. requires only 3 binding votes. I'd suggest renaming it to "Lazy > >>> Consensus". This is in line with the other definitions such as "Lazy > >>> Majority". > >> > >> It was initially called "lazy consensus", but Robert pointed out that > >> "lazy consensus" actually means something different in ASF term [1]. > >> Here "lazy" pretty much means "assume everyone is +1 unless someone says > >> otherwise". This means any vote that requires a minimum number of +1 is > not > >> really a "lazy" vote. > >> > >> Removing a committer / PMC member only requires 3 binding votes. I'd > >>> expect an important action like this to require a 2/3 majority. > >> > >> Personally I think consensus is good enough here. PMC members can cast a > >> veto if they disagree about the removal. In some sense, it is more > >> difficult than with 2/3 majority to remove a committer / PMC member. > Also, > >> it might be a hard decision for some PMC members if they have never > worked > >> with the person in question. That said, I am OK to change it to 2/3 > >> majority as this will happen very rarely. > >> > >> Thanks, > >> > >> Jiangjie (Becket) Qin > >> > >> [1] https://www.apache.org/foundation/voting.html#LazyConsensus > >> > >> On Sun, Aug 11, 2019 at 5:00 PM Maximilian Michels > wrote: > >> > >>> 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 attempts with at least 7 days between two > >>> attempts. > 3. If the binding voter being contacted still failed to respond > >>> after all the attempts, the binding voter will be considered as > inactive > >>> for the purpose of this particular voting. > >>> > >>> 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. > >>> > >>> 2) "Consensus" => "Lazy Consensus" > >>> > >>> The way the terms are described in the draft, the consensus is "lazy", > >>> i.e. requires only 3 binding votes. I'd suggest renaming it to "Lazy > >>> Consensus". This is in line with the other definitions such as "Lazy > >>> Majority". > >>> > >>> 3) Committer / PMC Removal > >>> > >>> Removing a committer / PMC member only requires 3 binding votes. I'd > >>> expect an important action like this to require a 2/3 majority. > >>> > >>> > >>> Do you think we could incorporate those suggestions? > >>> > >>> Thanks, > >>> Max > >>> > >>> On 11.08.19 10:14, Becket Qin wrote: > Hi folks, > > Thanks
Re: [DISCUSS] Flink project bylaws
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 Qin wrote: > 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 (not counting the vote >> of the contributor), moving to lazy majority if a -1 is received. >> > > > Note that this implies that committers can +1 their own commits and merge >> right away. *However, the committe**rs should use their best judgement to >> respect the components expertise and ongoing development plan.* > > > This does not really change any of the existing bylaws, just about > clarification. > > If there is no objection to this additional clarification, after the bylaws > wiki is updated, I'll send an update notice to the voting thread to inform > those who already voted about this addition. > > Thanks, > > Jiangjie (Becket) Qin > > On Mon, Aug 12, 2019 at 11:19 AM Becket Qin wrote: > >> 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. >> >> The way the terms are described in the draft, the consensus is "lazy", >>> i.e. requires only 3 binding votes. I'd suggest renaming it to "Lazy >>> Consensus". This is in line with the other definitions such as "Lazy >>> Majority". >> >> It was initially called "lazy consensus", but Robert pointed out that >> "lazy consensus" actually means something different in ASF term [1]. >> Here "lazy" pretty much means "assume everyone is +1 unless someone says >> otherwise". This means any vote that requires a minimum number of +1 is not >> really a "lazy" vote. >> >> Removing a committer / PMC member only requires 3 binding votes. I'd >>> expect an important action like this to require a 2/3 majority. >> >> Personally I think consensus is good enough here. PMC members can cast a >> veto if they disagree about the removal. In some sense, it is more >> difficult than with 2/3 majority to remove a committer / PMC member. Also, >> it might be a hard decision for some PMC members if they have never worked >> with the person in question. That said, I am OK to change it to 2/3 >> majority as this will happen very rarely. >> >> Thanks, >> >> Jiangjie (Becket) Qin >> >> [1] https://www.apache.org/foundation/voting.html#LazyConsensus >> >> On Sun, Aug 11, 2019 at 5:00 PM Maximilian Michels wrote: >> >>> 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 attempts with at least 7 days between two >>> attempts. 3. If the binding voter being contacted still failed to respond >>> after all the attempts, the binding voter will be considered as inactive >>> for the purpose of this particular voting. >>> >>> 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. >>> >>> 2) "Consensus" => "Lazy Consensus" >>> >>> The way the terms are described in the draft, the consensus is "lazy", >>> i.e. requires only 3 binding votes. I'd suggest renaming it to "Lazy >>> Consensus". This is in line with the other definitions such as "Lazy >>> Majority". >>> >>> 3) Committer / PMC Removal >>> >>> Removing a committer / PMC member only requires 3 binding votes. I'd >>> expect an important action like this to require a 2/3 majority. >>> >>> >>> Do you think we could incorporate those suggestions? >>> >>> Thanks, >>> Max >>> >>> On 11.08.19 10:14, Becket Qin wrote: 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 update and driving the discussion Becket! > +1 for starting a vote. > > Am Mi., 7. Aug. 2019 um 11:44 Uhr schrieb Becket Qin < >>> becket@gmail.com >> : > >> Thanks Stephan. >> >> I think we have resolved all the comments on the wiki page. There are >>> two >> minor changes made to the bylaws
Re: [DISCUSS] Flink project bylaws
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 (not counting the vote > of the contributor), moving to lazy majority if a -1 is received. > Note that this implies that committers can +1 their own commits and merge > right away. *However, the committe**rs should use their best judgement to > respect the components expertise and ongoing development plan.* This does not really change any of the existing bylaws, just about clarification. If there is no objection to this additional clarification, after the bylaws wiki is updated, I'll send an update notice to the voting thread to inform those who already voted about this addition. Thanks, Jiangjie (Becket) Qin On Mon, Aug 12, 2019 at 11:19 AM Becket Qin wrote: > 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. > > The way the terms are described in the draft, the consensus is "lazy", >> i.e. requires only 3 binding votes. I'd suggest renaming it to "Lazy >> Consensus". This is in line with the other definitions such as "Lazy >> Majority". > > It was initially called "lazy consensus", but Robert pointed out that > "lazy consensus" actually means something different in ASF term [1]. > Here "lazy" pretty much means "assume everyone is +1 unless someone says > otherwise". This means any vote that requires a minimum number of +1 is not > really a "lazy" vote. > > Removing a committer / PMC member only requires 3 binding votes. I'd >> expect an important action like this to require a 2/3 majority. > > Personally I think consensus is good enough here. PMC members can cast a > veto if they disagree about the removal. In some sense, it is more > difficult than with 2/3 majority to remove a committer / PMC member. Also, > it might be a hard decision for some PMC members if they have never worked > with the person in question. That said, I am OK to change it to 2/3 > majority as this will happen very rarely. > > Thanks, > > Jiangjie (Becket) Qin > > [1] https://www.apache.org/foundation/voting.html#LazyConsensus > > On Sun, Aug 11, 2019 at 5:00 PM Maximilian Michels wrote: > >> 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 attempts with at least 7 days between two >> attempts. >> > 3. If the binding voter being contacted still failed to respond >> after all the attempts, the binding voter will be considered as inactive >> for the purpose of this particular voting. >> >> 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. >> >> 2) "Consensus" => "Lazy Consensus" >> >> The way the terms are described in the draft, the consensus is "lazy", >> i.e. requires only 3 binding votes. I'd suggest renaming it to "Lazy >> Consensus". This is in line with the other definitions such as "Lazy >> Majority". >> >> 3) Committer / PMC Removal >> >> Removing a committer / PMC member only requires 3 binding votes. I'd >> expect an important action like this to require a 2/3 majority. >> >> >> Do you think we could incorporate those suggestions? >> >> Thanks, >> Max >> >> On 11.08.19 10:14, Becket Qin wrote: >> > 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 update and driving the discussion Becket! >> >> +1 for starting a vote. >> >> >> >> Am Mi., 7. Aug. 2019 um 11:44 Uhr schrieb Becket Qin < >> becket@gmail.com >> >>> : >> >> >> >>> 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. Clarified what is considered as the adoption of new codebase. >> >>> >> >>> I think we almost reached consensus. I'll start a voting thread in two >> >> days >> >>> if there is no new concerns. >> >>> >> >>> Thanks, >> >>> >> >>> Jiangjie
Re: [DISCUSS] Flink project bylaws
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. The way the terms are described in the draft, the consensus is "lazy", > i.e. requires only 3 binding votes. I'd suggest renaming it to "Lazy > Consensus". This is in line with the other definitions such as "Lazy > Majority". It was initially called "lazy consensus", but Robert pointed out that "lazy consensus" actually means something different in ASF term [1]. Here "lazy" pretty much means "assume everyone is +1 unless someone says otherwise". This means any vote that requires a minimum number of +1 is not really a "lazy" vote. Removing a committer / PMC member only requires 3 binding votes. I'd > expect an important action like this to require a 2/3 majority. Personally I think consensus is good enough here. PMC members can cast a veto if they disagree about the removal. In some sense, it is more difficult than with 2/3 majority to remove a committer / PMC member. Also, it might be a hard decision for some PMC members if they have never worked with the person in question. That said, I am OK to change it to 2/3 majority as this will happen very rarely. Thanks, Jiangjie (Becket) Qin [1] https://www.apache.org/foundation/voting.html#LazyConsensus On Sun, Aug 11, 2019 at 5:00 PM Maximilian Michels wrote: > 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 attempts with at least 7 days between two > attempts. > > 3. If the binding voter being contacted still failed to respond > after all the attempts, the binding voter will be considered as inactive > for the purpose of this particular voting. > > 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. > > 2) "Consensus" => "Lazy Consensus" > > The way the terms are described in the draft, the consensus is "lazy", > i.e. requires only 3 binding votes. I'd suggest renaming it to "Lazy > Consensus". This is in line with the other definitions such as "Lazy > Majority". > > 3) Committer / PMC Removal > > Removing a committer / PMC member only requires 3 binding votes. I'd > expect an important action like this to require a 2/3 majority. > > > Do you think we could incorporate those suggestions? > > Thanks, > Max > > On 11.08.19 10:14, Becket Qin wrote: > > 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 update and driving the discussion Becket! > >> +1 for starting a vote. > >> > >> Am Mi., 7. Aug. 2019 um 11:44 Uhr schrieb Becket Qin < > becket@gmail.com > >>> : > >> > >>> 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. Clarified what is considered as the adoption of new codebase. > >>> > >>> I think we almost reached consensus. I'll start a voting thread in two > >> days > >>> if there is no new concerns. > >>> > >>> Thanks, > >>> > >>> Jiangjie (Becket) Qin > >>> > >>> On Mon, Aug 5, 2019 at 1:09 PM Stephan Ewen wrote: > >>> > 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 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 < > > becket@gmail.com > >> : > > > >> 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
Re: [DISCUSS] Flink project bylaws
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 attempts with at least 7 days between two attempts. > 3. If the binding voter being contacted still failed to respond after all > the attempts, the binding voter will be considered as inactive for the > purpose of this particular voting. 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. 2) "Consensus" => "Lazy Consensus" The way the terms are described in the draft, the consensus is "lazy", i.e. requires only 3 binding votes. I'd suggest renaming it to "Lazy Consensus". This is in line with the other definitions such as "Lazy Majority". 3) Committer / PMC Removal Removing a committer / PMC member only requires 3 binding votes. I'd expect an important action like this to require a 2/3 majority. Do you think we could incorporate those suggestions? Thanks, Max On 11.08.19 10:14, Becket Qin wrote: > 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 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 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. Clarified what is considered as the adoption of new codebase. >>> >>> I think we almost reached consensus. I'll start a voting thread in two >> days >>> if there is no new concerns. >>> >>> Thanks, >>> >>> Jiangjie (Becket) Qin >>> >>> On Mon, Aug 5, 2019 at 1:09 PM Stephan Ewen wrote: >>> 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 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 < > becket@gmail.com >> : > >> 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:49 PM Yu Li wrote: >> >>> 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. 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: 1. Removed the inactivity term for emeritus committers / PMCs. >> A >>> committer / PMC will only be considered emeritus by their own claim. 2. Removed the approval process for reinstatement of the >> emeritus committers / PMCs. An emeritus committer / PMC will be >> reinstated > when >>> they send an email to the priv...@flink.apache.org. 3. Adde the term to ensure 2/3 majority voting is still doable >>> when >> there are non-emeritus committers / PMCs who do not cast the vote. Please let me know if you have any further thoughts. Thanks, Jiangjie (Becket) Qin On Tue, Jul 23, 2019 at 10:18 AM Becket Qin < >>> becket@gmail.com> >>> wrote: > Hi Fabian, > > Thanks for the feedback. > > I agree that if we don't like emeritus
Re: [DISCUSS] Flink project bylaws
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 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 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. Clarified what is considered as the adoption of new codebase. > > > > I think we almost reached consensus. I'll start a voting thread in two > days > > if there is no new concerns. > > > > Thanks, > > > > Jiangjie (Becket) Qin > > > > On Mon, Aug 5, 2019 at 1:09 PM Stephan Ewen wrote: > > > > > 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 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 < > > > > becket@gmail.com > > > > >: > > > > > > > > > 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:49 PM Yu Li wrote: > > > > > > > > > > > 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. > > > > > > > > > > > > > > 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: > > > > > > > > > > > > > > 1. Removed the inactivity term for emeritus committers / PMCs. > A > > > > > > committer > > > > > > > / PMC will only be considered emeritus by their own claim. > > > > > > > 2. Removed the approval process for reinstatement of the > emeritus > > > > > > > committers / PMCs. An emeritus committer / PMC will be > reinstated > > > > when > > > > > > they > > > > > > > send an email to the priv...@flink.apache.org. > > > > > > > 3. Adde the term to ensure 2/3 majority voting is still doable > > when > > > > > there > > > > > > > are non-emeritus committers / PMCs who do not cast the vote. > > > > > > > > > > > > > > Please let me know if you have any further thoughts. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Jiangjie (Becket) Qin > > > > > > > > > > > > > > On Tue, Jul 23, 2019 at 10:18 AM Becket Qin < > > becket@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > > > 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 status is mostly just a > way > > to > > > > > make > > > > > > > 2/3 > > > > > > > > majority possible. As you noticed, since reaching out to > > binding > > > > > voters > > > > > > > who > > > > > > > > have not voted can achieve the same goal, the emeritus status > > is > > > > more > > > > > > of > > > > > > > an > > > > > > > > optimization so we don't have to ping the inactive binding > > voters > > > > > every > > > > > > > > time and wait for long. However, given that 2/3 majority > > votings > > > > are > > > > > > > rare, > > > > > > > > such communication cost is probably OK. So I think we
Re: [DISCUSS] Flink project bylaws
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 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. Clarified what is considered as the adoption of new codebase. > > I think we almost reached consensus. I'll start a voting thread in two days > if there is no new concerns. > > Thanks, > > Jiangjie (Becket) Qin > > On Mon, Aug 5, 2019 at 1:09 PM Stephan Ewen wrote: > > > 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 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 < > > > becket@gmail.com > > > >: > > > > > > > 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:49 PM Yu Li wrote: > > > > > > > > > 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. > > > > > > > > > > > > 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: > > > > > > > > > > > > 1. Removed the inactivity term for emeritus committers / PMCs. A > > > > > committer > > > > > > / PMC will only be considered emeritus by their own claim. > > > > > > 2. Removed the approval process for reinstatement of the emeritus > > > > > > committers / PMCs. An emeritus committer / PMC will be reinstated > > > when > > > > > they > > > > > > send an email to the priv...@flink.apache.org. > > > > > > 3. Adde the term to ensure 2/3 majority voting is still doable > when > > > > there > > > > > > are non-emeritus committers / PMCs who do not cast the vote. > > > > > > > > > > > > Please let me know if you have any further thoughts. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Jiangjie (Becket) Qin > > > > > > > > > > > > On Tue, Jul 23, 2019 at 10:18 AM Becket Qin < > becket@gmail.com> > > > > > wrote: > > > > > > > > > > > > > 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 status is mostly just a way > to > > > > make > > > > > > 2/3 > > > > > > > majority possible. As you noticed, since reaching out to > binding > > > > voters > > > > > > who > > > > > > > have not voted can achieve the same goal, the emeritus status > is > > > more > > > > > of > > > > > > an > > > > > > > optimization so we don't have to ping the inactive binding > voters > > > > every > > > > > > > time and wait for long. However, given that 2/3 majority > votings > > > are > > > > > > rare, > > > > > > > such communication cost is probably OK. So I think we can > remove > > > that > > > > > > > emeritus part from the bylaws. > > > > > > > > > > > > > > 1) We should add to the requirements of the PMC that they need > to > > > > make > > > > > > >> sure the project complies with brand issues and reports misuse > > of > > > > ASF > > > > > > >> brands. > > > > > > > > > > > > > > Good point. Added. > > > > > > > > > > > > > > 2) Do we want to restrict voting days to working days, i.e., a > 3 > > > day > > > > > vote > > > > > > >> that starts on Friday 11:00am ends on Wednesday 11:00am? > > > > > > > > > > > > > > This might be a
Re: [DISCUSS] Flink project bylaws
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. Clarified what is considered as the adoption of new codebase. I think we almost reached consensus. I'll start a voting thread in two days if there is no new concerns. Thanks, Jiangjie (Becket) Qin On Mon, Aug 5, 2019 at 1:09 PM Stephan Ewen wrote: > 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 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 < > > becket@gmail.com > > >: > > > > > 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:49 PM Yu Li wrote: > > > > > > > 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. > > > > > > > > > > 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: > > > > > > > > > > 1. Removed the inactivity term for emeritus committers / PMCs. A > > > > committer > > > > > / PMC will only be considered emeritus by their own claim. > > > > > 2. Removed the approval process for reinstatement of the emeritus > > > > > committers / PMCs. An emeritus committer / PMC will be reinstated > > when > > > > they > > > > > send an email to the priv...@flink.apache.org. > > > > > 3. Adde the term to ensure 2/3 majority voting is still doable when > > > there > > > > > are non-emeritus committers / PMCs who do not cast the vote. > > > > > > > > > > Please let me know if you have any further thoughts. > > > > > > > > > > Thanks, > > > > > > > > > > Jiangjie (Becket) Qin > > > > > > > > > > On Tue, Jul 23, 2019 at 10:18 AM Becket Qin > > > > wrote: > > > > > > > > > > > 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 status is mostly just a way to > > > make > > > > > 2/3 > > > > > > majority possible. As you noticed, since reaching out to binding > > > voters > > > > > who > > > > > > have not voted can achieve the same goal, the emeritus status is > > more > > > > of > > > > > an > > > > > > optimization so we don't have to ping the inactive binding voters > > > every > > > > > > time and wait for long. However, given that 2/3 majority votings > > are > > > > > rare, > > > > > > such communication cost is probably OK. So I think we can remove > > that > > > > > > emeritus part from the bylaws. > > > > > > > > > > > > 1) We should add to the requirements of the PMC that they need to > > > make > > > > > >> sure the project complies with brand issues and reports misuse > of > > > ASF > > > > > >> brands. > > > > > > > > > > > > Good point. Added. > > > > > > > > > > > > 2) Do we want to restrict voting days to working days, i.e., a 3 > > day > > > > vote > > > > > >> that starts on Friday 11:00am ends on Wednesday 11:00am? > > > > > > > > > > > > This might be a little tricky because people are from countries > in > > > > > > different time zones and with different holidays, and so on. If > we > > > are > > > > > > worrying about 3 days minimum length is not enough for those who > > want > > > > to > > > > > > give feedback, we can make it 5 days. > > > > > > > > > > > > 3) Do we need a process do decide about removal of features (like > > the > > > > > >> DataSet API for instance or the legacy DataSet/DataStream Python > > > >
Re: [DISCUSS] Flink project bylaws
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 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 < > becket@gmail.com > >: > > > 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:49 PM Yu Li wrote: > > > > > 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. > > > > > > > > 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: > > > > > > > > 1. Removed the inactivity term for emeritus committers / PMCs. A > > > committer > > > > / PMC will only be considered emeritus by their own claim. > > > > 2. Removed the approval process for reinstatement of the emeritus > > > > committers / PMCs. An emeritus committer / PMC will be reinstated > when > > > they > > > > send an email to the priv...@flink.apache.org. > > > > 3. Adde the term to ensure 2/3 majority voting is still doable when > > there > > > > are non-emeritus committers / PMCs who do not cast the vote. > > > > > > > > Please let me know if you have any further thoughts. > > > > > > > > Thanks, > > > > > > > > Jiangjie (Becket) Qin > > > > > > > > On Tue, Jul 23, 2019 at 10:18 AM Becket Qin > > > wrote: > > > > > > > > > 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 status is mostly just a way to > > make > > > > 2/3 > > > > > majority possible. As you noticed, since reaching out to binding > > voters > > > > who > > > > > have not voted can achieve the same goal, the emeritus status is > more > > > of > > > > an > > > > > optimization so we don't have to ping the inactive binding voters > > every > > > > > time and wait for long. However, given that 2/3 majority votings > are > > > > rare, > > > > > such communication cost is probably OK. So I think we can remove > that > > > > > emeritus part from the bylaws. > > > > > > > > > > 1) We should add to the requirements of the PMC that they need to > > make > > > > >> sure the project complies with brand issues and reports misuse of > > ASF > > > > >> brands. > > > > > > > > > > Good point. Added. > > > > > > > > > > 2) Do we want to restrict voting days to working days, i.e., a 3 > day > > > vote > > > > >> that starts on Friday 11:00am ends on Wednesday 11:00am? > > > > > > > > > > This might be a little tricky because people are from countries in > > > > > different time zones and with different holidays, and so on. If we > > are > > > > > worrying about 3 days minimum length is not enough for those who > want > > > to > > > > > give feedback, we can make it 5 days. > > > > > > > > > > 3) Do we need a process do decide about removal of features (like > the > > > > >> DataSet API for instance or the legacy DataSet/DataStream Python > > > APIs)? > > > > > > > > > > I assume such action should be covered by FLIP as it is a change to > > the > > > > > API and probably needs a migration plan. It would be useful to > have a > > > > > formal deprecation procedure. But that might be better to be put > into > > > > > somewhere else because the bylaws are primarily focusing on the > > > > > non-technical rules, whereas the deprecation seems more on the > > > technical > > > > > side. > > > > > > > > > > Thanks, > > > > > > > > > > Jiangjie (Becket) Qin > > > > > > > > > > On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske > > > > wrote: > > > > > > > > > >> 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 > > > > >>
Re: [DISCUSS] Flink project bylaws
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 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:49 PM Yu Li wrote: > > > 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. > > > > > > 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: > > > > > > 1. Removed the inactivity term for emeritus committers / PMCs. A > > committer > > > / PMC will only be considered emeritus by their own claim. > > > 2. Removed the approval process for reinstatement of the emeritus > > > committers / PMCs. An emeritus committer / PMC will be reinstated when > > they > > > send an email to the priv...@flink.apache.org. > > > 3. Adde the term to ensure 2/3 majority voting is still doable when > there > > > are non-emeritus committers / PMCs who do not cast the vote. > > > > > > Please let me know if you have any further thoughts. > > > > > > Thanks, > > > > > > Jiangjie (Becket) Qin > > > > > > On Tue, Jul 23, 2019 at 10:18 AM Becket Qin > > wrote: > > > > > > > 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 status is mostly just a way to > make > > > 2/3 > > > > majority possible. As you noticed, since reaching out to binding > voters > > > who > > > > have not voted can achieve the same goal, the emeritus status is more > > of > > > an > > > > optimization so we don't have to ping the inactive binding voters > every > > > > time and wait for long. However, given that 2/3 majority votings are > > > rare, > > > > such communication cost is probably OK. So I think we can remove that > > > > emeritus part from the bylaws. > > > > > > > > 1) We should add to the requirements of the PMC that they need to > make > > > >> sure the project complies with brand issues and reports misuse of > ASF > > > >> brands. > > > > > > > > Good point. Added. > > > > > > > > 2) Do we want to restrict voting days to working days, i.e., a 3 day > > vote > > > >> that starts on Friday 11:00am ends on Wednesday 11:00am? > > > > > > > > This might be a little tricky because people are from countries in > > > > different time zones and with different holidays, and so on. If we > are > > > > worrying about 3 days minimum length is not enough for those who want > > to > > > > give feedback, we can make it 5 days. > > > > > > > > 3) Do we need a process do decide about removal of features (like the > > > >> DataSet API for instance or the legacy DataSet/DataStream Python > > APIs)? > > > > > > > > I assume such action should be covered by FLIP as it is a change to > the > > > > API and probably needs a migration plan. It would be useful to have a > > > > formal deprecation procedure. But that might be better to be put into > > > > somewhere else because the bylaws are primarily focusing on the > > > > non-technical rules, whereas the deprecation seems more on the > > technical > > > > side. > > > > > > > > Thanks, > > > > > > > > Jiangjie (Becket) Qin > > > > > > > > On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske > > > wrote: > > > > > > > >> 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 members. > > > >> My foremost concern is that this is not in the spirit of the Apache > > Way > > > >> [1] > > > >> which is (among other things) based on the idea of merit which once > > > >> earned, > > > >> does not go away over time. > > > >> I know other projects like Hadoop and Kafka have similar clauses in > > the > > > >> bylaws but IMO we don't need
Re: [DISCUSS] Flink project bylaws
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:49 PM Yu Li wrote: > 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. > > > > 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: > > > > 1. Removed the inactivity term for emeritus committers / PMCs. A > committer > > / PMC will only be considered emeritus by their own claim. > > 2. Removed the approval process for reinstatement of the emeritus > > committers / PMCs. An emeritus committer / PMC will be reinstated when > they > > send an email to the priv...@flink.apache.org. > > 3. Adde the term to ensure 2/3 majority voting is still doable when there > > are non-emeritus committers / PMCs who do not cast the vote. > > > > Please let me know if you have any further thoughts. > > > > Thanks, > > > > Jiangjie (Becket) Qin > > > > On Tue, Jul 23, 2019 at 10:18 AM Becket Qin > wrote: > > > > > 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 status is mostly just a way to make > > 2/3 > > > majority possible. As you noticed, since reaching out to binding voters > > who > > > have not voted can achieve the same goal, the emeritus status is more > of > > an > > > optimization so we don't have to ping the inactive binding voters every > > > time and wait for long. However, given that 2/3 majority votings are > > rare, > > > such communication cost is probably OK. So I think we can remove that > > > emeritus part from the bylaws. > > > > > > 1) We should add to the requirements of the PMC that they need to make > > >> sure the project complies with brand issues and reports misuse of ASF > > >> brands. > > > > > > Good point. Added. > > > > > > 2) Do we want to restrict voting days to working days, i.e., a 3 day > vote > > >> that starts on Friday 11:00am ends on Wednesday 11:00am? > > > > > > This might be a little tricky because people are from countries in > > > different time zones and with different holidays, and so on. If we are > > > worrying about 3 days minimum length is not enough for those who want > to > > > give feedback, we can make it 5 days. > > > > > > 3) Do we need a process do decide about removal of features (like the > > >> DataSet API for instance or the legacy DataSet/DataStream Python > APIs)? > > > > > > I assume such action should be covered by FLIP as it is a change to the > > > API and probably needs a migration plan. It would be useful to have a > > > formal deprecation procedure. But that might be better to be put into > > > somewhere else because the bylaws are primarily focusing on the > > > non-technical rules, whereas the deprecation seems more on the > technical > > > side. > > > > > > Thanks, > > > > > > Jiangjie (Becket) Qin > > > > > > On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske > > wrote: > > > > > >> 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 members. > > >> My foremost concern is that this is not in the spirit of the Apache > Way > > >> [1] > > >> which is (among other things) based on the idea of merit which once > > >> earned, > > >> does not go away over time. > > >> I know other projects like Hadoop and Kafka have similar clauses in > the > > >> bylaws but IMO we don't need to adopt them if we don't like them. > > >> For example, I don't like the idea that committers or PMC members who > > are > > >> temporarily away from the project (for whatever reason: parental > leave, > > >> sabbatical, health issues, etc.) need the PMC approval to be "active" > > >> again. > > >> As far as I am aware, we have not seen any issues with inactive > members > > in > > >> the past. > > >> Moreover, it would be hard to track whether somebody became inactive > at > > >> some point in time (which we would need to do, if
Re: [DISCUSS] Flink project bylaws
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. > > 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: > > 1. Removed the inactivity term for emeritus committers / PMCs. A committer > / PMC will only be considered emeritus by their own claim. > 2. Removed the approval process for reinstatement of the emeritus > committers / PMCs. An emeritus committer / PMC will be reinstated when they > send an email to the priv...@flink.apache.org. > 3. Adde the term to ensure 2/3 majority voting is still doable when there > are non-emeritus committers / PMCs who do not cast the vote. > > Please let me know if you have any further thoughts. > > Thanks, > > Jiangjie (Becket) Qin > > On Tue, Jul 23, 2019 at 10:18 AM Becket Qin wrote: > > > 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 status is mostly just a way to make > 2/3 > > majority possible. As you noticed, since reaching out to binding voters > who > > have not voted can achieve the same goal, the emeritus status is more of > an > > optimization so we don't have to ping the inactive binding voters every > > time and wait for long. However, given that 2/3 majority votings are > rare, > > such communication cost is probably OK. So I think we can remove that > > emeritus part from the bylaws. > > > > 1) We should add to the requirements of the PMC that they need to make > >> sure the project complies with brand issues and reports misuse of ASF > >> brands. > > > > Good point. Added. > > > > 2) Do we want to restrict voting days to working days, i.e., a 3 day vote > >> that starts on Friday 11:00am ends on Wednesday 11:00am? > > > > This might be a little tricky because people are from countries in > > different time zones and with different holidays, and so on. If we are > > worrying about 3 days minimum length is not enough for those who want to > > give feedback, we can make it 5 days. > > > > 3) Do we need a process do decide about removal of features (like the > >> DataSet API for instance or the legacy DataSet/DataStream Python APIs)? > > > > I assume such action should be covered by FLIP as it is a change to the > > API and probably needs a migration plan. It would be useful to have a > > formal deprecation procedure. But that might be better to be put into > > somewhere else because the bylaws are primarily focusing on the > > non-technical rules, whereas the deprecation seems more on the technical > > side. > > > > Thanks, > > > > Jiangjie (Becket) Qin > > > > On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske > wrote: > > > >> 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 members. > >> My foremost concern is that this is not in the spirit of the Apache Way > >> [1] > >> which is (among other things) based on the idea of merit which once > >> earned, > >> does not go away over time. > >> I know other projects like Hadoop and Kafka have similar clauses in the > >> bylaws but IMO we don't need to adopt them if we don't like them. > >> For example, I don't like the idea that committers or PMC members who > are > >> temporarily away from the project (for whatever reason: parental leave, > >> sabbatical, health issues, etc.) need the PMC approval to be "active" > >> again. > >> As far as I am aware, we have not seen any issues with inactive members > in > >> the past. > >> Moreover, it would be hard to track whether somebody became inactive at > >> some point in time (which we would need to do, if I understand the > >> proposal > >> correctly). > >> With the approach that Becket suggested in his last email (reaching out > to > >> binding voters who haven't voted yet), we could drop the distinction > >> between active and non-active committers and PMC members. > >> > >> I also have a few minor comments: > >> > >> 1) We should add to the requirements of the PMC [2] that they need to > make > >> sure the project complies with brand issues and reports misuse of ASF > >> brands. > >> 2) Do we want to restrict voting days to working days, i.e., a 3 day > vote > >>
Re: [DISCUSS] Flink project bylaws
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: 1. Removed the inactivity term for emeritus committers / PMCs. A committer / PMC will only be considered emeritus by their own claim. 2. Removed the approval process for reinstatement of the emeritus committers / PMCs. An emeritus committer / PMC will be reinstated when they send an email to the priv...@flink.apache.org. 3. Adde the term to ensure 2/3 majority voting is still doable when there are non-emeritus committers / PMCs who do not cast the vote. Please let me know if you have any further thoughts. Thanks, Jiangjie (Becket) Qin On Tue, Jul 23, 2019 at 10:18 AM Becket Qin wrote: > 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 status is mostly just a way to make 2/3 > majority possible. As you noticed, since reaching out to binding voters who > have not voted can achieve the same goal, the emeritus status is more of an > optimization so we don't have to ping the inactive binding voters every > time and wait for long. However, given that 2/3 majority votings are rare, > such communication cost is probably OK. So I think we can remove that > emeritus part from the bylaws. > > 1) We should add to the requirements of the PMC that they need to make >> sure the project complies with brand issues and reports misuse of ASF >> brands. > > Good point. Added. > > 2) Do we want to restrict voting days to working days, i.e., a 3 day vote >> that starts on Friday 11:00am ends on Wednesday 11:00am? > > This might be a little tricky because people are from countries in > different time zones and with different holidays, and so on. If we are > worrying about 3 days minimum length is not enough for those who want to > give feedback, we can make it 5 days. > > 3) Do we need a process do decide about removal of features (like the >> DataSet API for instance or the legacy DataSet/DataStream Python APIs)? > > I assume such action should be covered by FLIP as it is a change to the > API and probably needs a migration plan. It would be useful to have a > formal deprecation procedure. But that might be better to be put into > somewhere else because the bylaws are primarily focusing on the > non-technical rules, whereas the deprecation seems more on the technical > side. > > Thanks, > > Jiangjie (Becket) Qin > > On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske wrote: > >> 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 members. >> My foremost concern is that this is not in the spirit of the Apache Way >> [1] >> which is (among other things) based on the idea of merit which once >> earned, >> does not go away over time. >> I know other projects like Hadoop and Kafka have similar clauses in the >> bylaws but IMO we don't need to adopt them if we don't like them. >> For example, I don't like the idea that committers or PMC members who are >> temporarily away from the project (for whatever reason: parental leave, >> sabbatical, health issues, etc.) need the PMC approval to be "active" >> again. >> As far as I am aware, we have not seen any issues with inactive members in >> the past. >> Moreover, it would be hard to track whether somebody became inactive at >> some point in time (which we would need to do, if I understand the >> proposal >> correctly). >> With the approach that Becket suggested in his last email (reaching out to >> binding voters who haven't voted yet), we could drop the distinction >> between active and non-active committers and PMC members. >> >> I also have a few minor comments: >> >> 1) We should add to the requirements of the PMC [2] that they need to make >> sure the project complies with brand issues and reports misuse of ASF >> brands. >> 2) Do we want to restrict voting days to working days, i.e., a 3 day vote >> that starts on Friday 11:00am ends on Wednesday 11:00am? >> 3) Do we need a process do decide about removal of features (like the >> DataSet API for instance or the legacy DataSet/DataStream Python APIs)? >> >> Thank you, >> Fabian >> >> [1] https://www.apache.org/theapacheway/ >> [2] https://www.apache.org/dev/pmc.html >> >> Am So., 21. Juli 2019 um 13:22 Uhr schrieb Becket Qin < >> becket@gmail.com >> >: >> >> > Hi Hequn, >> > >> > Thanks for sharing your thoughts. Please see
Re: [DISCUSS] Flink project bylaws
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 status is mostly just a way to make 2/3 majority possible. As you noticed, since reaching out to binding voters who have not voted can achieve the same goal, the emeritus status is more of an optimization so we don't have to ping the inactive binding voters every time and wait for long. However, given that 2/3 majority votings are rare, such communication cost is probably OK. So I think we can remove that emeritus part from the bylaws. 1) We should add to the requirements of the PMC that they need to make > sure the project complies with brand issues and reports misuse of ASF > brands. Good point. Added. 2) Do we want to restrict voting days to working days, i.e., a 3 day vote > that starts on Friday 11:00am ends on Wednesday 11:00am? This might be a little tricky because people are from countries in different time zones and with different holidays, and so on. If we are worrying about 3 days minimum length is not enough for those who want to give feedback, we can make it 5 days. 3) Do we need a process do decide about removal of features (like the > DataSet API for instance or the legacy DataSet/DataStream Python APIs)? I assume such action should be covered by FLIP as it is a change to the API and probably needs a migration plan. It would be useful to have a formal deprecation procedure. But that might be better to be put into somewhere else because the bylaws are primarily focusing on the non-technical rules, whereas the deprecation seems more on the technical side. Thanks, Jiangjie (Becket) Qin On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske wrote: > 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 members. > My foremost concern is that this is not in the spirit of the Apache Way [1] > which is (among other things) based on the idea of merit which once earned, > does not go away over time. > I know other projects like Hadoop and Kafka have similar clauses in the > bylaws but IMO we don't need to adopt them if we don't like them. > For example, I don't like the idea that committers or PMC members who are > temporarily away from the project (for whatever reason: parental leave, > sabbatical, health issues, etc.) need the PMC approval to be "active" > again. > As far as I am aware, we have not seen any issues with inactive members in > the past. > Moreover, it would be hard to track whether somebody became inactive at > some point in time (which we would need to do, if I understand the proposal > correctly). > With the approach that Becket suggested in his last email (reaching out to > binding voters who haven't voted yet), we could drop the distinction > between active and non-active committers and PMC members. > > I also have a few minor comments: > > 1) We should add to the requirements of the PMC [2] that they need to make > sure the project complies with brand issues and reports misuse of ASF > brands. > 2) Do we want to restrict voting days to working days, i.e., a 3 day vote > that starts on Friday 11:00am ends on Wednesday 11:00am? > 3) Do we need a process do decide about removal of features (like the > DataSet API for instance or the legacy DataSet/DataStream Python APIs)? > > Thank you, > Fabian > > [1] https://www.apache.org/theapacheway/ > [2] https://www.apache.org/dev/pmc.html > > Am So., 21. Juli 2019 um 13:22 Uhr schrieb Becket Qin < > becket@gmail.com > >: > > > 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 may impacts Flink a lot. Meanwhile, there is no loss of > flexibility > > > as committers also have a chance to vote and participate in it. > > A few concerns of requiring a PMC vote in all FLIPs are the following: > > > > 1. Generally speaking, the PMC's primary responsibility is operating the > > project and deciding what software to release on behalf of ASF. > Committers, > > on the other hand, are responsible for the technical part of the project. > > So for FLIPs, a PMC's vote probably should not outweigh a committer's > vote. > > Besides, I am not sure whether a single PMCs +1 is really convincing > enough > > to decide whether the FLIP is good to go or not. Also, if some committers > > have concern over a FLIP, they could just veto it. To me it
Re: [DISCUSS] Flink project bylaws
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 members. My foremost concern is that this is not in the spirit of the Apache Way [1] which is (among other things) based on the idea of merit which once earned, does not go away over time. I know other projects like Hadoop and Kafka have similar clauses in the bylaws but IMO we don't need to adopt them if we don't like them. For example, I don't like the idea that committers or PMC members who are temporarily away from the project (for whatever reason: parental leave, sabbatical, health issues, etc.) need the PMC approval to be "active" again. As far as I am aware, we have not seen any issues with inactive members in the past. Moreover, it would be hard to track whether somebody became inactive at some point in time (which we would need to do, if I understand the proposal correctly). With the approach that Becket suggested in his last email (reaching out to binding voters who haven't voted yet), we could drop the distinction between active and non-active committers and PMC members. I also have a few minor comments: 1) We should add to the requirements of the PMC [2] that they need to make sure the project complies with brand issues and reports misuse of ASF brands. 2) Do we want to restrict voting days to working days, i.e., a 3 day vote that starts on Friday 11:00am ends on Wednesday 11:00am? 3) Do we need a process do decide about removal of features (like the DataSet API for instance or the legacy DataSet/DataStream Python APIs)? Thank you, Fabian [1] https://www.apache.org/theapacheway/ [2] https://www.apache.org/dev/pmc.html Am So., 21. Juli 2019 um 13:22 Uhr schrieb Becket Qin : > 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 may impacts Flink a lot. Meanwhile, there is no loss of flexibility > > as committers also have a chance to vote and participate in it. > A few concerns of requiring a PMC vote in all FLIPs are the following: > > 1. Generally speaking, the PMC's primary responsibility is operating the > project and deciding what software to release on behalf of ASF. Committers, > on the other hand, are responsible for the technical part of the project. > So for FLIPs, a PMC's vote probably should not outweigh a committer's vote. > Besides, I am not sure whether a single PMCs +1 is really convincing enough > to decide whether the FLIP is good to go or not. Also, if some committers > have concern over a FLIP, they could just veto it. To me it is actually a > more strict requirement to pass a FLIP than asking a PMC to vote. In > practice, people will usually also address the concerns even if they are > not from a PMC/committer before they start the voting process. So I don't > see much benefit of requiring a PMC's vote in this case. > > 2. The at-least-one-PMC-vote requirement makes the votes no longer > independent. Ideally, a vote is either binding or non-binding by itself. If > we have the at-least-one-PMC-vote requirement here, imagine there have been > 3 committers who voted +1. But the FLIP still has not passed, so those > votes are effectively non-binding. Now a PMC votes a +1, those votes > suddenly become binding, which is a little awkward. > > > The lazy 2/3 majority suggestion sounds reasonable to me. Some thoughts on > this: > 1. One reason Hadoop uses lazy 2/3 majority is probably because there are > 104 PMC members[1] for Hadoop which makes the 2/3 majority prohibitively > expensive. In our case, there are only 22 PMCs for Flink[2] and a quick > search shows at most 6 of them have not sent email in the recent 6 months > or so. > > 2. 2/3 majority votes are supposed to be very rare. It is designed in > particular for the cases that broad opinions are important, more > specifically new codebase adoption or modification to the bylaws. Therefore > such vote by its nature favors consensus over convenience. That means any > alternative voting type reducing the coverage worth a careful thinking. > > 3. I do agree that it does not make sense to have 2/3 majority if such > requirement is no-longer doable over time. But I am a little hesitant to > lower the threshold to lazy 2/3 majority in our case. What do you think > about doing the following: > - After the voting started, there will be at least 6 days for people to > cast their votes. > - After 6 days, if the result of the vote is still not determined, the > person who started the vote should reach out to the binding voters who have > not voted yet for at least 3 times and at
Re: [DISCUSS] Flink project bylaws
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 may impacts Flink a lot. Meanwhile, there is no loss of flexibility > as committers also have a chance to vote and participate in it. A few concerns of requiring a PMC vote in all FLIPs are the following: 1. Generally speaking, the PMC's primary responsibility is operating the project and deciding what software to release on behalf of ASF. Committers, on the other hand, are responsible for the technical part of the project. So for FLIPs, a PMC's vote probably should not outweigh a committer's vote. Besides, I am not sure whether a single PMCs +1 is really convincing enough to decide whether the FLIP is good to go or not. Also, if some committers have concern over a FLIP, they could just veto it. To me it is actually a more strict requirement to pass a FLIP than asking a PMC to vote. In practice, people will usually also address the concerns even if they are not from a PMC/committer before they start the voting process. So I don't see much benefit of requiring a PMC's vote in this case. 2. The at-least-one-PMC-vote requirement makes the votes no longer independent. Ideally, a vote is either binding or non-binding by itself. If we have the at-least-one-PMC-vote requirement here, imagine there have been 3 committers who voted +1. But the FLIP still has not passed, so those votes are effectively non-binding. Now a PMC votes a +1, those votes suddenly become binding, which is a little awkward. The lazy 2/3 majority suggestion sounds reasonable to me. Some thoughts on this: 1. One reason Hadoop uses lazy 2/3 majority is probably because there are 104 PMC members[1] for Hadoop which makes the 2/3 majority prohibitively expensive. In our case, there are only 22 PMCs for Flink[2] and a quick search shows at most 6 of them have not sent email in the recent 6 months or so. 2. 2/3 majority votes are supposed to be very rare. It is designed in particular for the cases that broad opinions are important, more specifically new codebase adoption or modification to the bylaws. Therefore such vote by its nature favors consensus over convenience. That means any alternative voting type reducing the coverage worth a careful thinking. 3. I do agree that it does not make sense to have 2/3 majority if such requirement is no-longer doable over time. But I am a little hesitant to lower the threshold to lazy 2/3 majority in our case. What do you think about doing the following: - After the voting started, there will be at least 6 days for people to cast their votes. - After 6 days, if the result of the vote is still not determined, the person who started the vote should reach out to the binding voters who have not voted yet for at least 3 times and at least 7 days between each time. If a binding voter still did not respond, the vote from that voter will be excluded from the 2/3 majority counting. This would ensure the coverage at our best effort while still let the 2/3 majority vote make progress. Thanks, Jiangjie (Becket) Qin [1] https://projects.apache.org/committee.html?hadoop [2] https://projects.apache.org/committee.html?flink On Sun, Jul 21, 2019 at 1:39 PM Xu Forward wrote: > 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 committers and 1 PMC. > > I think this makes sense considering a FLIP could somehow be a big > feature > > which may impacts Flink a lot. Meanwhile, there is no loss of flexibility > > as committers also have a chance to vote and participate in it. > > > > Seperator > > > > For the nice bylaws, I agree with the general idea and most of the > content. > > Only share some thoughts about the "2/3 Majority". The main concern is I > am > > not sure if it is doable in practice. The reasons are: > > > > 1. If we follow the bylaws strictly, it means a committer or a PMC member > > is active if he or she sends one email to the mailing list every 6 > months. > > While the minimum length of the vote is only 6 days. There are chances > that > > during the vote, some of the active members are still offline of the > > community. > > 2. The code of Flink is changing fast and not everyone fully understands > > every part. We don't need to force people to vote if they are not sure > > about it. It may also make the final result less credible. > > > > Given the above reasons, perhaps we can change the 2/3 Majority to lazy > 2/3 > > Majority, just as the Hadoop bylaws[1]. It makes a higher threshold, > > however, more
Re: [DISCUSS] Flink project bylaws
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 committers and 1 PMC. > I think this makes sense considering a FLIP could somehow be a big feature > which may impacts Flink a lot. Meanwhile, there is no loss of flexibility > as committers also have a chance to vote and participate in it. > > Seperator > > For the nice bylaws, I agree with the general idea and most of the content. > Only share some thoughts about the "2/3 Majority". The main concern is I am > not sure if it is doable in practice. The reasons are: > > 1. If we follow the bylaws strictly, it means a committer or a PMC member > is active if he or she sends one email to the mailing list every 6 months. > While the minimum length of the vote is only 6 days. There are chances that > during the vote, some of the active members are still offline of the > community. > 2. The code of Flink is changing fast and not everyone fully understands > every part. We don't need to force people to vote if they are not sure > about it. It may also make the final result less credible. > > Given the above reasons, perhaps we can change the 2/3 Majority to lazy 2/3 > Majority, just as the Hadoop bylaws[1]. It makes a higher threshold, > however, more practical. > > What do you think? > > [1] https://hadoop.apache.org/bylaws.html > > On Sat, Jul 20, 2019 at 12:00 AM Becket Qin wrote: > > > 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 making > > such decisions. > > > > Re: Robert, > > > > I agree we can simply remove the requirement of +1 from a non-author > > committer and revisit it in a bit. After all, it does not make sense to > > have a bylaw that we cannot afford. I have just updated the bylaws wiki. > > > > Thanks, > > > > Jiangjie (Becket) Qin > > > > On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger > > wrote: > > > > > 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 > means > > > some changes. > > > > > > The cross-review requirement is the last big open point in this > > discussion. > > > It seems that a there is a slight tendency in the discussion that this > is > > > not feasible given the current pull request review situation. > > > For the sake of bringing this discussion to a conclusion, I'm fine with > > > leaving this requirement out. As we are currently adding more > committers > > to > > > the project, we might be able to revisit this discussion in 3 - 6 > months. > > > > > > > > > On Thu, Jul 18, 2019 at 4:30 AM jincheng sun > > > > wrote: > > > > > > > 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 beneficial > for > > > > > the quality/uniformity of our codebase and knowledge sharing. > > > > > > > > > > I was just wondering what should be the next step for this? I think > > it > > > > > would make sense to already use those bylaws and put them to PMC > > vote. > > > > > > > > > > Best, > > > > > > > > > > Dawid > > > > > > > > > > On 12/07/2019 13:35, Piotr Nowojski wrote: > > > > > > 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 > > > to > > > > > the > > > > > >>> best judgement of the committer to respect the components > > expertise > > > > and > > > > > >>> ongoing development plans
Re: [DISCUSS] Flink project bylaws
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 big feature which may impacts Flink a lot. Meanwhile, there is no loss of flexibility as committers also have a chance to vote and participate in it. Seperator For the nice bylaws, I agree with the general idea and most of the content. Only share some thoughts about the "2/3 Majority". The main concern is I am not sure if it is doable in practice. The reasons are: 1. If we follow the bylaws strictly, it means a committer or a PMC member is active if he or she sends one email to the mailing list every 6 months. While the minimum length of the vote is only 6 days. There are chances that during the vote, some of the active members are still offline of the community. 2. The code of Flink is changing fast and not everyone fully understands every part. We don't need to force people to vote if they are not sure about it. It may also make the final result less credible. Given the above reasons, perhaps we can change the 2/3 Majority to lazy 2/3 Majority, just as the Hadoop bylaws[1]. It makes a higher threshold, however, more practical. What do you think? [1] https://hadoop.apache.org/bylaws.html On Sat, Jul 20, 2019 at 12:00 AM Becket Qin wrote: > 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 making > such decisions. > > Re: Robert, > > I agree we can simply remove the requirement of +1 from a non-author > committer and revisit it in a bit. After all, it does not make sense to > have a bylaw that we cannot afford. I have just updated the bylaws wiki. > > Thanks, > > Jiangjie (Becket) Qin > > On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger > wrote: > > > 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 means > > some changes. > > > > The cross-review requirement is the last big open point in this > discussion. > > It seems that a there is a slight tendency in the discussion that this is > > not feasible given the current pull request review situation. > > For the sake of bringing this discussion to a conclusion, I'm fine with > > leaving this requirement out. As we are currently adding more committers > to > > the project, we might be able to revisit this discussion in 3 - 6 months. > > > > > > On Thu, Jul 18, 2019 at 4:30 AM jincheng sun > > wrote: > > > > > 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 beneficial for > > > > the quality/uniformity of our codebase and knowledge sharing. > > > > > > > > I was just wondering what should be the next step for this? I think > it > > > > would make sense to already use those bylaws and put them to PMC > vote. > > > > > > > > Best, > > > > > > > > Dawid > > > > > > > > On 12/07/2019 13:35, Piotr Nowojski wrote: > > > > > 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 > > to > > > > the > > > > >>> best judgement of the committer to respect the components > expertise > > > and > > > > >>> ongoing development plans (also the de facto current state). > > > > >> Adding the statement would help clarify the intention, but it may > > be a > > > > >> little difficult to enforce and follow.. > > > > > I would be fine with that, it’s a soft/vague rule anyway, intended > to > > > be > > > > used with your “best judgemenet". I would like to just avoid a > >
Re: [DISCUSS] Flink project bylaws
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 making such decisions. Re: Robert, I agree we can simply remove the requirement of +1 from a non-author committer and revisit it in a bit. After all, it does not make sense to have a bylaw that we cannot afford. I have just updated the bylaws wiki. Thanks, Jiangjie (Becket) Qin On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger wrote: > 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 means > some changes. > > The cross-review requirement is the last big open point in this discussion. > It seems that a there is a slight tendency in the discussion that this is > not feasible given the current pull request review situation. > For the sake of bringing this discussion to a conclusion, I'm fine with > leaving this requirement out. As we are currently adding more committers to > the project, we might be able to revisit this discussion in 3 - 6 months. > > > On Thu, Jul 18, 2019 at 4:30 AM jincheng sun > wrote: > > > 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 beneficial for > > > the quality/uniformity of our codebase and knowledge sharing. > > > > > > I was just wondering what should be the next step for this? I think it > > > would make sense to already use those bylaws and put them to PMC vote. > > > > > > Best, > > > > > > Dawid > > > > > > On 12/07/2019 13:35, Piotr Nowojski wrote: > > > > 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 > to > > > the > > > >>> best judgement of the committer to respect the components expertise > > and > > > >>> ongoing development plans (also the de facto current state). > > > >> Adding the statement would help clarify the intention, but it may > be a > > > >> little difficult to enforce and follow.. > > > > I would be fine with that, it’s a soft/vague rule anyway, intended to > > be > > > used with your “best judgemenet". I would like to just avoid a > situation > > > when someone violates current uncodified state and refers to the bylaws > > > which are saying merging with any committer +1 is always fine (like > mine > > +1 > > > for flink-python or flink-ml). > > > > > > > > Piotrek > > > > > > > >> On 12 Jul 2019, at 11:29, Aljoscha Krettek > > wrote: > > > >> > > > >> @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 > > > any FLIPs pass that formal bar. > > > >> > > > >> According to the recent META-FLIP thread, we want to use "lazy > > > majority" for the FLIP voting process. I think that should be changed > > from > > > “consensus” in the proposed bylaws. > > > >> > > > >> Regarding the current state: do we have a current state that we all > > > agree on? I have the feeling that if we try to come up with something > > that > > > reflects the common state, according to PMCs/commiters, that might > take a > > > very long time. In that case I think it’s better to adopt something > that > > we > > > all like, rather than trying to capture how we do it now. > > > >> > > > >> Aljoscha > > > >> > > > >>> On 12. Jul 2019, at 11:07, Piotr Nowojski > > wrote: > > > >>> > > > >>> 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.
Re: [DISCUSS] Flink project bylaws
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 means some changes. The cross-review requirement is the last big open point in this discussion. It seems that a there is a slight tendency in the discussion that this is not feasible given the current pull request review situation. For the sake of bringing this discussion to a conclusion, I'm fine with leaving this requirement out. As we are currently adding more committers to the project, we might be able to revisit this discussion in 3 - 6 months. On Thu, Jul 18, 2019 at 4:30 AM jincheng sun wrote: > 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 beneficial for > > the quality/uniformity of our codebase and knowledge sharing. > > > > I was just wondering what should be the next step for this? I think it > > would make sense to already use those bylaws and put them to PMC vote. > > > > Best, > > > > Dawid > > > > On 12/07/2019 13:35, Piotr Nowojski wrote: > > > 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 to > > the > > >>> best judgement of the committer to respect the components expertise > and > > >>> ongoing development plans (also the de facto current state). > > >> Adding the statement would help clarify the intention, but it may be a > > >> little difficult to enforce and follow.. > > > I would be fine with that, it’s a soft/vague rule anyway, intended to > be > > used with your “best judgemenet". I would like to just avoid a situation > > when someone violates current uncodified state and refers to the bylaws > > which are saying merging with any committer +1 is always fine (like mine > +1 > > for flink-python or flink-ml). > > > > > > Piotrek > > > > > >> On 12 Jul 2019, at 11:29, Aljoscha Krettek > wrote: > > >> > > >> @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 > > any FLIPs pass that formal bar. > > >> > > >> According to the recent META-FLIP thread, we want to use "lazy > > majority" for the FLIP voting process. I think that should be changed > from > > “consensus” in the proposed bylaws. > > >> > > >> Regarding the current state: do we have a current state that we all > > agree on? I have the feeling that if we try to come up with something > that > > reflects the common state, according to PMCs/commiters, that might take a > > very long time. In that case I think it’s better to adopt something that > we > > all like, rather than trying to capture how we do it now. > > >> > > >> Aljoscha > > >> > > >>> On 12. Jul 2019, at 11:07, Piotr Nowojski > wrote: > > >>> > > >>> 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 committer would slow down > > and put even more strain on the current reviewing bottleneck that we are > > having. Even if the change clear and simple, context switch cost is quite > > high, and that’s just one less PR that the second “cross” committer could > > have reviewed somewhere else in that time. Besides, current setup that we > > have (with no cross +1 from another committer required) works quite well > > and I do not feel that’s causing troubles. On the other hand reviewing > > bottleneck is. > > >>> > > >>> 2. > > >>> > > I think a committer should know when to ask another committer for > > feedback or not. > > >>> I’m missing this stated somewhere clearly. If we are stating that a > > single committers +1 is good enough for code
Re: [DISCUSS] Flink project bylaws
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 beneficial for > the quality/uniformity of our codebase and knowledge sharing. > > I was just wondering what should be the next step for this? I think it > would make sense to already use those bylaws and put them to PMC vote. > > Best, > > Dawid > > On 12/07/2019 13:35, Piotr Nowojski wrote: > > 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 to > the > >>> best judgement of the committer to respect the components expertise and > >>> ongoing development plans (also the de facto current state). > >> Adding the statement would help clarify the intention, but it may be a > >> little difficult to enforce and follow.. > > I would be fine with that, it’s a soft/vague rule anyway, intended to be > used with your “best judgemenet". I would like to just avoid a situation > when someone violates current uncodified state and refers to the bylaws > which are saying merging with any committer +1 is always fine (like mine +1 > for flink-python or flink-ml). > > > > Piotrek > > > >> On 12 Jul 2019, at 11:29, Aljoscha Krettek wrote: > >> > >> @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 > any FLIPs pass that formal bar. > >> > >> According to the recent META-FLIP thread, we want to use "lazy > majority" for the FLIP voting process. I think that should be changed from > “consensus” in the proposed bylaws. > >> > >> Regarding the current state: do we have a current state that we all > agree on? I have the feeling that if we try to come up with something that > reflects the common state, according to PMCs/commiters, that might take a > very long time. In that case I think it’s better to adopt something that we > all like, rather than trying to capture how we do it now. > >> > >> Aljoscha > >> > >>> On 12. Jul 2019, at 11:07, Piotr Nowojski wrote: > >>> > >>> 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 committer would slow down > and put even more strain on the current reviewing bottleneck that we are > having. Even if the change clear and simple, context switch cost is quite > high, and that’s just one less PR that the second “cross” committer could > have reviewed somewhere else in that time. Besides, current setup that we > have (with no cross +1 from another committer required) works quite well > and I do not feel that’s causing troubles. On the other hand reviewing > bottleneck is. > >>> > >>> 2. > >>> > I think a committer should know when to ask another committer for > feedback or not. > >>> 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 to > the best judgement of the committer to respect the components expertise and > ongoing development plans (also the de facto current state). > >>> > >>> 3. > >>> > >>> Minimum length of 3 days for FLIP I think currently might be > problematic/too quick and can lead to problems if respected to the letter. > Again I think it depends highly on whether the committers with highest > expertise in the affected components managed to respond or not. > >>> > >>> Piotrek > >>> > On 12 Jul 2019, at 09:42, Chesnay Schepler > wrote: > > 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, Bowen Li wrote: > > On Thu, Jul 11, 2019 at 10:38 AM
Re: [DISCUSS] Flink project bylaws
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 beneficial for the quality/uniformity of our codebase and knowledge sharing. I was just wondering what should be the next step for this? I think it would make sense to already use those bylaws and put them to PMC vote. Best, Dawid On 12/07/2019 13:35, Piotr Nowojski wrote: > 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 to the >>> best judgement of the committer to respect the components expertise and >>> ongoing development plans (also the de facto current state). >> Adding the statement would help clarify the intention, but it may be a >> little difficult to enforce and follow.. > I would be fine with that, it’s a soft/vague rule anyway, intended to be used > with your “best judgemenet". I would like to just avoid a situation when > someone violates current uncodified state and refers to the bylaws which are > saying merging with any committer +1 is always fine (like mine +1 for > flink-python or flink-ml). > > Piotrek > >> On 12 Jul 2019, at 11:29, Aljoscha Krettek wrote: >> >> @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 >> any FLIPs pass that formal bar. >> >> According to the recent META-FLIP thread, we want to use "lazy majority" for >> the FLIP voting process. I think that should be changed from “consensus” in >> the proposed bylaws. >> >> Regarding the current state: do we have a current state that we all agree >> on? I have the feeling that if we try to come up with something that >> reflects the common state, according to PMCs/commiters, that might take a >> very long time. In that case I think it’s better to adopt something that we >> all like, rather than trying to capture how we do it now. >> >> Aljoscha >> >>> On 12. Jul 2019, at 11:07, Piotr Nowojski wrote: >>> >>> 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 committer would slow down and >>> put even more strain on the current reviewing bottleneck that we are >>> having. Even if the change clear and simple, context switch cost is quite >>> high, and that’s just one less PR that the second “cross” committer could >>> have reviewed somewhere else in that time. Besides, current setup that we >>> have (with no cross +1 from another committer required) works quite well >>> and I do not feel that’s causing troubles. On the other hand reviewing >>> bottleneck is. >>> >>> 2. >>> I think a committer should know when to ask another committer for feedback or not. >>> 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 to the >>> best judgement of the committer to respect the components expertise and >>> ongoing development plans (also the de facto current state). >>> >>> 3. >>> >>> Minimum length of 3 days for FLIP I think currently might be >>> problematic/too quick and can lead to problems if respected to the letter. >>> Again I think it depends highly on whether the committers with highest >>> expertise in the affected components managed to respond or not. >>> >>> Piotrek >>> On 12 Jul 2019, at 09:42, Chesnay Schepler wrote: 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, Bowen Li wrote: > 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" with a reference to the FLIP
Re: [DISCUSS] Flink project bylaws
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 to the >> best judgement of the committer to respect the components expertise and >> ongoing development plans (also the de facto current state). > > Adding the statement would help clarify the intention, but it may be a > little difficult to enforce and follow.. I would be fine with that, it’s a soft/vague rule anyway, intended to be used with your “best judgemenet". I would like to just avoid a situation when someone violates current uncodified state and refers to the bylaws which are saying merging with any committer +1 is always fine (like mine +1 for flink-python or flink-ml). Piotrek > On 12 Jul 2019, at 11:29, Aljoscha Krettek wrote: > > @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 any > FLIPs pass that formal bar. > > According to the recent META-FLIP thread, we want to use "lazy majority" for > the FLIP voting process. I think that should be changed from “consensus” in > the proposed bylaws. > > Regarding the current state: do we have a current state that we all agree on? > I have the feeling that if we try to come up with something that reflects the > common state, according to PMCs/commiters, that might take a very long time. > In that case I think it’s better to adopt something that we all like, rather > than trying to capture how we do it now. > > Aljoscha > >> On 12. Jul 2019, at 11:07, Piotr Nowojski wrote: >> >> 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 committer would slow down and >> put even more strain on the current reviewing bottleneck that we are having. >> Even if the change clear and simple, context switch cost is quite high, and >> that’s just one less PR that the second “cross” committer could have >> reviewed somewhere else in that time. Besides, current setup that we have >> (with no cross +1 from another committer required) works quite well and I do >> not feel that’s causing troubles. On the other hand reviewing bottleneck is. >> >> 2. >> >>> I think a committer should know when to ask another committer for feedback >>> or not. >> >> 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 to the >> best judgement of the committer to respect the components expertise and >> ongoing development plans (also the de facto current state). >> >> 3. >> >> Minimum length of 3 days for FLIP I think currently might be problematic/too >> quick and can lead to problems if respected to the letter. Again I think it >> depends highly on whether the committers with highest expertise in the >> affected components managed to respond or not. >> >> Piotrek >> >>> On 12 Jul 2019, at 09:42, Chesnay Schepler wrote: >>> >>> 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, Bowen Li wrote: 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" with a reference to the FLIP process page. A > FLIP >> will have/does have different rules for approvals, etc. > > Good point. Just added the entry. > > --- > Re: Konstantin > >> * For "Code Change" the draft currently requires "one +1 from a committer >> who has not authored the patch followed by a Lazy approval (not counting >> the vote of the contributor), moving to lazy majority if a -1 is > received". >> 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
Re: [DISCUSS] Flink project bylaws
@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 any FLIPs pass that formal bar. According to the recent META-FLIP thread, we want to use "lazy majority" for the FLIP voting process. I think that should be changed from “consensus” in the proposed bylaws. Regarding the current state: do we have a current state that we all agree on? I have the feeling that if we try to come up with something that reflects the common state, according to PMCs/commiters, that might take a very long time. In that case I think it’s better to adopt something that we all like, rather than trying to capture how we do it now. Aljoscha > On 12. Jul 2019, at 11:07, Piotr Nowojski wrote: > > 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 committer would slow down and put > even more strain on the current reviewing bottleneck that we are having. Even > if the change clear and simple, context switch cost is quite high, and that’s > just one less PR that the second “cross” committer could have reviewed > somewhere else in that time. Besides, current setup that we have (with no > cross +1 from another committer required) works quite well and I do not feel > that’s causing troubles. On the other hand reviewing bottleneck is. > > 2. > >> I think a committer should know when to ask another committer for feedback >> or not. > > 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 to the > best judgement of the committer to respect the components expertise and > ongoing development plans (also the de facto current state). > > 3. > > Minimum length of 3 days for FLIP I think currently might be problematic/too > quick and can lead to problems if respected to the letter. Again I think it > depends highly on whether the committers with highest expertise in the > affected components managed to respond or not. > > Piotrek > >> On 12 Jul 2019, at 09:42, Chesnay Schepler wrote: >> >> 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, Bowen Li wrote: >>> 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" with a reference to the FLIP process page. A FLIP > will have/does have different rules for approvals, etc. Good point. Just added the entry. --- Re: Konstantin > * For "Code Change" the draft currently requires "one +1 from a committer > who has not authored the patch followed by a Lazy approval (not counting > the vote of the contributor), moving to lazy majority if a -1 is received". > 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 authors, contributor reviews & +1s). > I think it is worth thinking about how we can make it easy to follow the > bylaws e.g. by having more Flink-specific Jira workflows and ticket types + > corresponding permissions. While this is certainly "Step 2", I believe, we > really need to make it as easy & transparent as possible, otherwise they > will be unintentionally broken. & Re: Till > For the case of a committer being the author and getting a +1 from a > non-committer: I think a committer should know when to ask another > committer for feedback or not. Hence, I would not enforce that we strictly > need a +1 from a committer if the author is a committer but of course > encourage it if capacities exist. I am with Robert and Aljoscha on this. I completely understand the concern here. TBH, in Kafka occasionally trivial patches from committers are still merged without following the cross-review requirement, but it is rare. That said, I still
Re: [DISCUSS] Flink project bylaws
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 types (maybe just the one type for FLIP) 2. Which vote type should be for a FLIP. 3. Who has binding votes for a FLIP. After these are clarified, we can conclude the FLIP-META discussion to fix the broken FLIP process. The Committer / PMC related discussions may not be that urgent as the current convention, although not clearly defined, seems working fine. Does that make sense? Re Piotr: Thanks for sharing your thoughts. 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 to the > best judgement of the committer to respect the components expertise and > ongoing development plans (also the de facto current state). Adding the statement would help clarify the intention, but it may be a little difficult to enforce and follow... Minimum length of 3 days for FLIP I think currently might be > problematic/too quick and can lead to problems if respected to the letter. > Again I think it depends highly on whether the committers with highest > expertise in the affected components managed to respond or not. > The vote requires a minimum length of 3 days, but it could last longer in order to collect enough binding votes. In most cases, only the committers with enough expertise / interest would vote on the FLIP. Thanks, Jiangjie (Becket) Qin On Fri, Jul 12, 2019 at 5:07 PM Piotr Nowojski wrote: > 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 committer would slow down and > put even more strain on the current reviewing bottleneck that we are > having. Even if the change clear and simple, context switch cost is quite > high, and that’s just one less PR that the second “cross” committer could > have reviewed somewhere else in that time. Besides, current setup that we > have (with no cross +1 from another committer required) works quite well > and I do not feel that’s causing troubles. On the other hand reviewing > bottleneck is. > > 2. > > > I think a committer should know when to ask another committer for > feedback or not. > > 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 to the > best judgement of the committer to respect the components expertise and > ongoing development plans (also the de facto current state). > > 3. > > Minimum length of 3 days for FLIP I think currently might be > problematic/too quick and can lead to problems if respected to the letter. > Again I think it depends highly on whether the committers with highest > expertise in the affected components managed to respond or not. > > Piotrek > > > On 12 Jul 2019, at 09:42, Chesnay Schepler wrote: > > > > 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, Bowen Li wrote: > >> 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" with a reference to the FLIP process page. A > >>> FLIP > will have/does have different rules for approvals, etc. > >>> > >>> Good point. Just added the entry. > >>> > >>> --- > >>> Re: Konstantin > >>> > * For "Code Change" the draft currently requires "one +1 from a > committer > who has not authored the patch followed by a Lazy approval (not > counting > the vote of the contributor), moving to lazy majority if a -1 is > >>> received". > 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 authors, contributor reviews & +1s). > > >>> > >>> I think it is worth thinking about how we can make it easy to follow > the > bylaws e.g. by having more Flink-specific Jira workflows and ticket > >>> types +
Re: [DISCUSS] Flink project bylaws
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 committer would slow down and put even more strain on the current reviewing bottleneck that we are having. Even if the change clear and simple, context switch cost is quite high, and that’s just one less PR that the second “cross” committer could have reviewed somewhere else in that time. Besides, current setup that we have (with no cross +1 from another committer required) works quite well and I do not feel that’s causing troubles. On the other hand reviewing bottleneck is. 2. > I think a committer should know when to ask another committer for feedback or > not. 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 to the best judgement of the committer to respect the components expertise and ongoing development plans (also the de facto current state). 3. Minimum length of 3 days for FLIP I think currently might be problematic/too quick and can lead to problems if respected to the letter. Again I think it depends highly on whether the committers with highest expertise in the affected components managed to respond or not. Piotrek > On 12 Jul 2019, at 09:42, Chesnay Schepler wrote: > > 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, Bowen Li wrote: >> 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" with a reference to the FLIP process page. A >>> FLIP will have/does have different rules for approvals, etc. >>> >>> Good point. Just added the entry. >>> >>> --- >>> Re: Konstantin >>> * For "Code Change" the draft currently requires "one +1 from a committer who has not authored the patch followed by a Lazy approval (not counting the vote of the contributor), moving to lazy majority if a -1 is >>> received". 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 authors, contributor reviews & +1s). >>> >>> I think it is worth thinking about how we can make it easy to follow the bylaws e.g. by having more Flink-specific Jira workflows and ticket >>> types + corresponding permissions. While this is certainly "Step 2", I believe, >>> we really need to make it as easy & transparent as possible, otherwise they will be unintentionally broken. >>> >>> & Re: Till >>> For the case of a committer being the author and getting a +1 from a non-committer: I think a committer should know when to ask another committer for feedback or not. Hence, I would not enforce that we >>> strictly need a +1 from a committer if the author is a committer but of course encourage it if capacities exist. >>> >>> I am with Robert and Aljoscha on this. >>> >>> I completely understand the concern here. TBH, in Kafka occasionally >>> trivial patches from committers are still merged without following the >>> cross-review requirement, but it is rare. That said, I still think an >>> additional committer's review makes sense due to the following reasons: >>> 1. The bottom line here is that we need to make sure every patch is >>> reviewed with a high quality. This is a little difficult to guarantee if >>> the review comes from a contributor for many reasons. In some cases, a >>> contributor may not have enough knowledge about the project to make a good >>> judgement. Also sometimes the contributors are more eagerly to get a >>> particular issue fixed, so they are willing to lower the review bar. >>> 2. One byproduct of such cross review among committers, which I personally >>> feel useful, is that it helps gradually form consistent design principles >>> and code style. This is because the committers will know how the other >>> committers are writing code and learn from each other. So they tend to >>> reach some tacit understanding on how things should be done in general. >>> >>> Another way to think about this is to consider the following two scenarios: >>> 1. Reviewing a committer's patch takes a lot of iterations.
Re: [DISCUSS] Flink project bylaws
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, Bowen Li wrote: 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" with a reference to the FLIP process page. A FLIP will have/does have different rules for approvals, etc. Good point. Just added the entry. --- Re: Konstantin * For "Code Change" the draft currently requires "one +1 from a committer who has not authored the patch followed by a Lazy approval (not counting the vote of the contributor), moving to lazy majority if a -1 is received". 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 authors, contributor reviews & +1s). I think it is worth thinking about how we can make it easy to follow the bylaws e.g. by having more Flink-specific Jira workflows and ticket types + corresponding permissions. While this is certainly "Step 2", I believe, we really need to make it as easy & transparent as possible, otherwise they will be unintentionally broken. & Re: Till For the case of a committer being the author and getting a +1 from a non-committer: I think a committer should know when to ask another committer for feedback or not. Hence, I would not enforce that we strictly need a +1 from a committer if the author is a committer but of course encourage it if capacities exist. I am with Robert and Aljoscha on this. I completely understand the concern here. TBH, in Kafka occasionally trivial patches from committers are still merged without following the cross-review requirement, but it is rare. That said, I still think an additional committer's review makes sense due to the following reasons: 1. The bottom line here is that we need to make sure every patch is reviewed with a high quality. This is a little difficult to guarantee if the review comes from a contributor for many reasons. In some cases, a contributor may not have enough knowledge about the project to make a good judgement. Also sometimes the contributors are more eagerly to get a particular issue fixed, so they are willing to lower the review bar. 2. One byproduct of such cross review among committers, which I personally feel useful, is that it helps gradually form consistent design principles and code style. This is because the committers will know how the other committers are writing code and learn from each other. So they tend to reach some tacit understanding on how things should be done in general. Another way to think about this is to consider the following two scenarios: 1. Reviewing a committer's patch takes a lot of iterations. Then the patch needs to be reviewed even if it takes time because there are things actually needs to be clarified / changed. 2. Reviewing a committer's patch is very smooth and quick, so the patch is merged soon. Then reviewing such a patch does not take much time. Letting another committer review the patch from a committer falls either in case 1 or case 2. The best option here is to review the patch because If it is case 1, the patch actually needs to be reviewed. If it is case 2, the review should not take much time anyways. In the contrast, we will risk encounter case 1 if we skip the cross-review. Re: Robert I replied to your comments in the wiki and made the following modifications to resolve some of your comments: 1. Added a release manager role section. 2. changed the name of "lazy consensus" to "consensus" to align with general definition of Apache glossary and other projects. 3. review board -> pull request - Re: Chesnay The emeritus stuff seems like unnecessary noise. As Till mentioned, this is to make sure 2/3 majority is still feasible in practice. 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. That is a good suggestion. I am not familiar enough with the current Flink convention. Will you help on this? I saw you commented on some part in the wiki. Are those complete? -- Re: Aljoscha 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. Ha, you got me on this. The first version of the draft was almost identical to Kafka. But Robert has already caught a
Re: [DISCUSS] Flink project bylaws
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" with a reference to the FLIP process page. A > FLIP > > will have/does have different rules for approvals, etc. > > > Good point. Just added the entry. > > --- > Re: Konstantin > > > * For "Code Change" the draft currently requires "one +1 from a committer > > who has not authored the patch followed by a Lazy approval (not counting > > the vote of the contributor), moving to lazy majority if a -1 is > received". > > 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 authors, contributor reviews & +1s). > > > > > I think it is worth thinking about how we can make it easy to follow the > > bylaws e.g. by having more Flink-specific Jira workflows and ticket > types + > > corresponding permissions. While this is certainly "Step 2", I believe, > we > > really need to make it as easy & transparent as possible, otherwise they > > will be unintentionally broken. > > > & Re: Till > > > For the case of a committer being the author and getting a +1 from a > > non-committer: I think a committer should know when to ask another > > committer for feedback or not. Hence, I would not enforce that we > strictly > > need a +1 from a committer if the author is a committer but of course > > encourage it if capacities exist. > > > I am with Robert and Aljoscha on this. > > I completely understand the concern here. TBH, in Kafka occasionally > trivial patches from committers are still merged without following the > cross-review requirement, but it is rare. That said, I still think an > additional committer's review makes sense due to the following reasons: > 1. The bottom line here is that we need to make sure every patch is > reviewed with a high quality. This is a little difficult to guarantee if > the review comes from a contributor for many reasons. In some cases, a > contributor may not have enough knowledge about the project to make a good > judgement. Also sometimes the contributors are more eagerly to get a > particular issue fixed, so they are willing to lower the review bar. > 2. One byproduct of such cross review among committers, which I personally > feel useful, is that it helps gradually form consistent design principles > and code style. This is because the committers will know how the other > committers are writing code and learn from each other. So they tend to > reach some tacit understanding on how things should be done in general. > > Another way to think about this is to consider the following two scenarios: > 1. Reviewing a committer's patch takes a lot of iterations. Then the patch > needs to be reviewed even if it takes time because there are things > actually needs to be clarified / changed. > 2. Reviewing a committer's patch is very smooth and quick, so the patch is > merged soon. Then reviewing such a patch does not take much time. > > Letting another committer review the patch from a committer falls either in > case 1 or case 2. The best option here is to review the patch because > If it is case 1, the patch actually needs to be reviewed. > If it is case 2, the review should not take much time anyways. > > In the contrast, we will risk encounter case 1 if we skip the cross-review. > > > Re: Robert > > I replied to your comments in the wiki and made the following modifications > to resolve some of your comments: > 1. Added a release manager role section. > 2. changed the name of "lazy consensus" to "consensus" to align with > general definition of Apache glossary and other projects. > 3. review board -> pull request > > - > Re: Chesnay > > The emeritus stuff seems like unnecessary noise. > > > As Till mentioned, this is to make sure 2/3 majority is still feasible in > practice. > > 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. > > That is a good suggestion. I am not familiar enough with the current Flink > convention. Will you help on this? I saw you commented on some part in the > wiki. Are those complete? > > -- > Re: Aljoscha > > 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. > > Ha, you got me on this. The first version of the draft was almost identical > to Kafka. But Robert has already caught a few inconsistent places. So it > might still worth going through it to make sure we
Re: [DISCUSS] Flink project bylaws
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/does have different rules for approvals, etc. Good point. Just added the entry. --- Re: Konstantin > * For "Code Change" the draft currently requires "one +1 from a committer > who has not authored the patch followed by a Lazy approval (not counting > the vote of the contributor), moving to lazy majority if a -1 is received". > 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 authors, contributor reviews & +1s). > I think it is worth thinking about how we can make it easy to follow the > bylaws e.g. by having more Flink-specific Jira workflows and ticket types + > corresponding permissions. While this is certainly "Step 2", I believe, we > really need to make it as easy & transparent as possible, otherwise they > will be unintentionally broken. & Re: Till > For the case of a committer being the author and getting a +1 from a > non-committer: I think a committer should know when to ask another > committer for feedback or not. Hence, I would not enforce that we strictly > need a +1 from a committer if the author is a committer but of course > encourage it if capacities exist. I am with Robert and Aljoscha on this. I completely understand the concern here. TBH, in Kafka occasionally trivial patches from committers are still merged without following the cross-review requirement, but it is rare. That said, I still think an additional committer's review makes sense due to the following reasons: 1. The bottom line here is that we need to make sure every patch is reviewed with a high quality. This is a little difficult to guarantee if the review comes from a contributor for many reasons. In some cases, a contributor may not have enough knowledge about the project to make a good judgement. Also sometimes the contributors are more eagerly to get a particular issue fixed, so they are willing to lower the review bar. 2. One byproduct of such cross review among committers, which I personally feel useful, is that it helps gradually form consistent design principles and code style. This is because the committers will know how the other committers are writing code and learn from each other. So they tend to reach some tacit understanding on how things should be done in general. Another way to think about this is to consider the following two scenarios: 1. Reviewing a committer's patch takes a lot of iterations. Then the patch needs to be reviewed even if it takes time because there are things actually needs to be clarified / changed. 2. Reviewing a committer's patch is very smooth and quick, so the patch is merged soon. Then reviewing such a patch does not take much time. Letting another committer review the patch from a committer falls either in case 1 or case 2. The best option here is to review the patch because If it is case 1, the patch actually needs to be reviewed. If it is case 2, the review should not take much time anyways. In the contrast, we will risk encounter case 1 if we skip the cross-review. Re: Robert I replied to your comments in the wiki and made the following modifications to resolve some of your comments: 1. Added a release manager role section. 2. changed the name of "lazy consensus" to "consensus" to align with general definition of Apache glossary and other projects. 3. review board -> pull request - Re: Chesnay The emeritus stuff seems like unnecessary noise. > As Till mentioned, this is to make sure 2/3 majority is still feasible in practice. 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. That is a good suggestion. I am not familiar enough with the current Flink convention. Will you help on this? I saw you commented on some part in the wiki. Are those complete? -- Re: Aljoscha 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. Ha, you got me on this. The first version of the draft was almost identical to Kafka. But Robert has already caught a few inconsistent places. So it might still worth going through it to make sure we truly agree on them. Otherwise we may end up modifying them shortly after adoption. Thanks again folks, for all the valuable feedback. These are great discussion. Jiangjie (Becket) Qin On Thu, Jul 11, 2019 at 9:55 PM Aljoscha Krettek wrote: > Big +1 > >
Re: [DISCUSS] Flink project bylaws
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 don’t usually have that now but I would actually be in favour of requiring it, although it might make stuff more complicated. Aljoscha > On 11. Jul 2019, at 15:31, Till Rohrmann wrote: > > 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-committer: I think a committer should know when to ask another > committer for feedback or not. Hence, I would not enforce that we strictly > need a +1 from a committer if the author is a committer but of course > encourage it if capacities exist. > > Cheers, > Till > > On Thu, Jul 11, 2019 at 3:08 PM Chesnay Schepler wrote: > >> 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 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 authors, contributor reviews & +1s). >>> >>> I would agree to add such a bylaw, if we had cases in the past where code >>> was not sufficiently reviewed AND we believe that we have enough capacity >>> to ensure a separate committer's approval. >>> >>> >>> >>> >>> >>> On Thu, Jul 11, 2019 at 9:49 AM Konstantin Knauf < >> konstan...@ververica.com> >>> wrote: >>> 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, etc. * For "Code Change" the draft currently requires "one +1 from a >> committer who has not authored the patch followed by a Lazy approval (not counting the vote of the contributor), moving to lazy majority if a -1 is >> received". 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 authors, contributor reviews & +1s). I think it is worth thinking about how we can make it easy to follow the bylaws e.g. by having more Flink-specific Jira workflows and ticket >> types + corresponding permissions. While this is certainly "Step 2", I believe, >> we really need to make it as easy & transparent as possible, otherwise they will be unintentionally broken. Cheers and thanks, Konstantin On Thu, Jul 11, 2019 at 9:10 AM Becket Qin >> wrote: > 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 drafted a Flink bylaws page and would like to start a discussion > thread on this. > >> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026 > The bylaws will affect everyone in the community. It'll be great to >> hear > your thoughts. > > Thanks, > > Jiangjie (Becket) Qin > > [1] > > >> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-META-FLIP-Sticking-or-not-to-a-strict-FLIP-voting-process-td29978.html#none -- Konstantin Knauf | Solutions Architect +49 160 91394525 Planned Absences: 10.08.2019 - 31.08.2019, 05.09. - 06.09.2010 -- Ververica GmbH | Invalidenstrasse 115, 10115 Berlin, Germany -- Ververica GmbH Registered at Amtsgericht Charlottenburg: HRB 158244 B Managing Directors: Dr. Kostas Tzoumas, Dr. Stephan Ewen >> >>
Re: [DISCUSS] Flink project bylaws
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-committer: I think a committer should know when to ask another committer for feedback or not. Hence, I would not enforce that we strictly need a +1 from a committer if the author is a committer but of course encourage it if capacities exist. Cheers, Till On Thu, Jul 11, 2019 at 3:08 PM Chesnay Schepler wrote: > 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 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 authors, contributor reviews & +1s). > > > > I would agree to add such a bylaw, if we had cases in the past where code > > was not sufficiently reviewed AND we believe that we have enough capacity > > to ensure a separate committer's approval. > > > > > > > > > > > > On Thu, Jul 11, 2019 at 9:49 AM Konstantin Knauf < > konstan...@ververica.com> > > wrote: > > > >> 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, etc. > >> * For "Code Change" the draft currently requires "one +1 from a > committer > >> who has not authored the patch followed by a Lazy approval (not counting > >> the vote of the contributor), moving to lazy majority if a -1 is > received". > >> 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 authors, contributor reviews & +1s). > >> > >> I think it is worth thinking about how we can make it easy to follow the > >> bylaws e.g. by having more Flink-specific Jira workflows and ticket > types + > >> corresponding permissions. While this is certainly "Step 2", I believe, > we > >> really need to make it as easy & transparent as possible, otherwise they > >> will be unintentionally broken. > >> > >> Cheers and thanks, > >> > >> Konstantin > >> > >> > >> > >> On Thu, Jul 11, 2019 at 9:10 AM Becket Qin > wrote: > >> > >>> 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 drafted a Flink bylaws page and would like to start a discussion > >>> thread on this. > >>> > >> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026 > >>> The bylaws will affect everyone in the community. It'll be great to > hear > >>> your thoughts. > >>> > >>> Thanks, > >>> > >>> Jiangjie (Becket) Qin > >>> > >>> [1] > >>> > >>> > >> > http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-META-FLIP-Sticking-or-not-to-a-strict-FLIP-voting-process-td29978.html#none > >> > >> -- > >> > >> Konstantin Knauf | Solutions Architect > >> > >> +49 160 91394525 > >> > >> > >> Planned Absences: 10.08.2019 - 31.08.2019, 05.09. - 06.09.2010 > >> > >> > >> -- > >> > >> Ververica GmbH | Invalidenstrasse 115, 10115 Berlin, Germany > >> > >> -- > >> > >> Ververica GmbH > >> Registered at Amtsgericht Charlottenburg: HRB 158244 B > >> Managing Directors: Dr. Kostas Tzoumas, Dr. Stephan Ewen > >> > >
Re: [DISCUSS] Flink project bylaws
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 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 authors, contributor reviews & +1s). I would agree to add such a bylaw, if we had cases in the past where code was not sufficiently reviewed AND we believe that we have enough capacity to ensure a separate committer's approval. On Thu, Jul 11, 2019 at 9:49 AM Konstantin Knauf wrote: 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, etc. * For "Code Change" the draft currently requires "one +1 from a committer who has not authored the patch followed by a Lazy approval (not counting the vote of the contributor), moving to lazy majority if a -1 is received". 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 authors, contributor reviews & +1s). I think it is worth thinking about how we can make it easy to follow the bylaws e.g. by having more Flink-specific Jira workflows and ticket types + corresponding permissions. While this is certainly "Step 2", I believe, we really need to make it as easy & transparent as possible, otherwise they will be unintentionally broken. Cheers and thanks, Konstantin On Thu, Jul 11, 2019 at 9:10 AM Becket Qin wrote: 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 drafted a Flink bylaws page and would like to start a discussion thread on this. https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026 The bylaws will affect everyone in the community. It'll be great to hear your thoughts. Thanks, Jiangjie (Becket) Qin [1] http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-META-FLIP-Sticking-or-not-to-a-strict-FLIP-voting-process-td29978.html#none -- Konstantin Knauf | Solutions Architect +49 160 91394525 Planned Absences: 10.08.2019 - 31.08.2019, 05.09. - 06.09.2010 -- Ververica GmbH | Invalidenstrasse 115, 10115 Berlin, Germany -- Ververica GmbH Registered at Amtsgericht Charlottenburg: HRB 158244 B Managing Directors: Dr. Kostas Tzoumas, Dr. Stephan Ewen
Re: [DISCUSS] Flink project bylaws
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 authors, contributor reviews & +1s). I would agree to add such a bylaw, if we had cases in the past where code was not sufficiently reviewed AND we believe that we have enough capacity to ensure a separate committer's approval. On Thu, Jul 11, 2019 at 9:49 AM Konstantin Knauf wrote: > 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, etc. > * For "Code Change" the draft currently requires "one +1 from a committer > who has not authored the patch followed by a Lazy approval (not counting > the vote of the contributor), moving to lazy majority if a -1 is received". > 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 authors, contributor reviews & +1s). > > I think it is worth thinking about how we can make it easy to follow the > bylaws e.g. by having more Flink-specific Jira workflows and ticket types + > corresponding permissions. While this is certainly "Step 2", I believe, we > really need to make it as easy & transparent as possible, otherwise they > will be unintentionally broken. > > Cheers and thanks, > > Konstantin > > > > On Thu, Jul 11, 2019 at 9:10 AM Becket Qin wrote: > > > 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 drafted a Flink bylaws page and would like to start a discussion > > thread on this. > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026 > > > > The bylaws will affect everyone in the community. It'll be great to hear > > your thoughts. > > > > Thanks, > > > > Jiangjie (Becket) Qin > > > > [1] > > > > > http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-META-FLIP-Sticking-or-not-to-a-strict-FLIP-voting-process-td29978.html#none > > > > > -- > > Konstantin Knauf | Solutions Architect > > +49 160 91394525 > > > Planned Absences: 10.08.2019 - 31.08.2019, 05.09. - 06.09.2010 > > > -- > > Ververica GmbH | Invalidenstrasse 115, 10115 Berlin, Germany > > -- > > Ververica GmbH > Registered at Amtsgericht Charlottenburg: HRB 158244 B > Managing Directors: Dr. Kostas Tzoumas, Dr. Stephan Ewen >
Re: [DISCUSS] Flink project bylaws
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, etc. * For "Code Change" the draft currently requires "one +1 from a committer who has not authored the patch followed by a Lazy approval (not counting the vote of the contributor), moving to lazy majority if a -1 is received". 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 authors, contributor reviews & +1s). I think it is worth thinking about how we can make it easy to follow the bylaws e.g. by having more Flink-specific Jira workflows and ticket types + corresponding permissions. While this is certainly "Step 2", I believe, we really need to make it as easy & transparent as possible, otherwise they will be unintentionally broken. Cheers and thanks, Konstantin On Thu, Jul 11, 2019 at 9:10 AM Becket Qin wrote: > 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 drafted a Flink bylaws page and would like to start a discussion > thread on this. > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026 > > The bylaws will affect everyone in the community. It'll be great to hear > your thoughts. > > Thanks, > > Jiangjie (Becket) Qin > > [1] > > http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-META-FLIP-Sticking-or-not-to-a-strict-FLIP-voting-process-td29978.html#none > -- Konstantin Knauf | Solutions Architect +49 160 91394525 Planned Absences: 10.08.2019 - 31.08.2019, 05.09. - 06.09.2010 -- Ververica GmbH | Invalidenstrasse 115, 10115 Berlin, Germany -- Ververica GmbH Registered at Amtsgericht Charlottenburg: HRB 158244 B Managing Directors: Dr. Kostas Tzoumas, Dr. Stephan Ewen
[DISCUSS] Flink project bylaws
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 drafted a Flink bylaws page and would like to start a discussion thread on this. https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026 The bylaws will affect everyone in the community. It'll be great to hear your thoughts. Thanks, Jiangjie (Becket) Qin [1] http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-META-FLIP-Sticking-or-not-to-a-strict-FLIP-voting-process-td29978.html#none
