Looking into the discussion and reviewing our membership list, from module experts' distribution perspective, I agree that specific modules can have fewer PMC members overseeing.
According to my experience in the Flink community[1] and the natural that improvement proposals are mainly about development, I suggest we regard committers (PMC members are committers) vote as binding vote for a PIP. In this way, we can trade off the more eye target with frequent development. Best, tison. [1] https://cwiki.apache.org/confluence/display/FLINK/Flink+Bylaws#FlinkBylaws-Actions tison <wander4...@gmail.com> 于2023年6月21日周三 18:41写道： > > mostly part of one enterprise and only their PIP/PRs are moving forward > > No. PIPs are processed in a vendor natural bias. At least the difference > between lazy consensus and at least 3 +1 binding votes won't change it. > > > help other community members to let them contribute to Pulsar so > > I'm doing so and you can do so. As you may know I help with nudging some > of your PRs and send an email about promoting client contribution to the > PMC list in the last day. It's a separate topic that community members can > contribute to. Someone spends time to try to formalize the PIP process and > make these proposals clear and workable. It won't block "help other > community members". If you ask a person _not_ to do A, it doesn't mean they > _will_ do B. > > > there are many examples where PRs are sitting unreviewed for a long > time > > At the end of the last year, there are over 400 open PRs. And now it's > about 250+. I'm actively handling them and with several discussions with > other committers I know it's not easy to _ask_ people to spend time > reviewing others' patches. But following a tit-for-tat strategy I'm now > happy to cooperate with Jiwei, Yunzu, Lari, Michael, Zixuan, and so on. > There should not be a blocker; if so, you can discuss it on the private@ > mailing list - that's a certain issue we should handle for a better > community. > > > indirectly making it difficult for many Pulsar committers and > contributors > > From my observation, Asaf is actively reviewing almost all PIPs following > the rule he proposed so the bandwidth effectively grows instead of > decreases. 3 binding +1 votes are not a far more strict rule than lazy > consensus with any proposer. According to the proposal you made, it > requires spending more time on community traffic to help contributions make > progress and it should be in the same way as the current PIP process > direction (more eyes). "Let's skip voting and let it pass" won't help in > delivering high-quality design implementation which are PIPs aimed at. > > Best, > tison. > > > Asaf Mesika <asaf.mes...@gmail.com> 于2023年6月21日周三 15:59写道： > >> On Wed, Jun 21, 2023 at 10:27 AM Zixuan Liu <node...@gmail.com> wrote: >> >> > I think we can reference https://www.apache.org/foundation/voting.html >> > >> > > Votes on code modifications follow a different model. In this >> scenario, >> > a negative vote constitutes a veto , which the voting group (generally >> the >> > PMC of a project) cannot override. Again, this model may be modified by >> a >> > lazy consensus declaration when the request for a vote is raised, but >> the >> > full-stop nature of a negative vote does not change. Under normal >> (non-lazy >> > consensus) conditions, the proposal requires three positive votes and no >> > negative votes in order to pass; if it fails to garner the requisite >> amount >> > of support, it doesn't. Then the proposer either withdraws the proposal >> or >> > modifies the code and resubmits it, or the proposal simply languishes >> as an >> > open issue until someone gets around to removing it. >> > >> > It seems that there is no need for three binding votes for code >> > modifications. If I am wrong, please point it out. >> > >> > I believe you may be wrong. >> >> Lazy Consensus is described here >> <https://www.apache.org/foundation/voting.html#LazyConsensus> as: >> >> Lazy consensus is simply an announcement of 'silence gives assent.' When >> > someone wants to determine the sense of the community this way, they >> might >> > do so with a mail message such as: >> > "The patch below fixes bug #8271847; if no-one objects within three >> > days, I'll assume lazy consensus and commit it." >> > You cannot apply lazy consensus to code changes when the >> > review-then-commit >> > <https://www.apache.org/foundation/glossary.html#ReviewThenCommit> >> policy >> > is in effect. >> >> >> My understanding is that for the PIP process, we are using a >> review-then-commit policy, which actually means we can't use lazy >> consensus. >> >> The definition of a Lazy Consensus defined here >> <https://www.apache.org/foundation/glossary.html#LazyConsensus> is: >> >> A decision-making policy which assumes general consent if no responses are >> > posted within a defined period. For example, "I'm going to commit this >> by >> > lazy consensus if no-one objects within the next three days." Also see >> Consensus >> > Approval >> > <https://www.apache.org/foundation/glossary.html#ConsensusApproval> , >> Majority >> > Approval >> > <https://www.apache.org/foundation/glossary.html#MajorityApproval> , >> and >> > the description of the voting process >> > <https://www.apache.org/foundation/voting.html>. >> >> >> >> So if I summarize, a PIP needs to follow the "the proposal requires three >> positive votes and no negative votes in order to pass;" >> >> >> > Thanks, >> > Zixuan >> > >> > Asaf Mesika <asaf.mes...@gmail.com> 于2023年6月21日周三 14:59写道： >> > > >> > > I'm not a committer or PMC member, so I can't comment on this. >> > > >> > > I am curious to know the difference between other Apache projects and >> > other >> > > foundation projects, such as CNCF, if you know about it. >> > > Do you think the Apache Foundation's view on individuals, not part of >> a >> > > commercial entity, does not live up to today's state of affairs? >> > > >> > > On Tue, Jun 20, 2023 at 10:40 PM Rajan Dhabalia <rdhaba...@apache.org >> > >> > > wrote: >> > > >> > > > Hi, >> > > > >> > > > > (" a lazy majority of at least 3 binding +1s votes") >> > > > >> > > > I don't think it's fair at this stage where majority Pulsar >> committers >> > are >> > > > mostly part of one enterprise and only their PIP/PRs are moving >> > forward and >> > > > PR/PIP created by other community members get blocked or not >> reviewed >> > > > without any major reasons. I can list down many different examples >> but >> > I >> > > > don't want to start that destructive discussion for now but I >> strongly >> > ask >> > > > to help other community members to let them contribute to Pulsar so, >> > we can >> > > > grow Pulsar community and let Pulsar be at the stage where it has >> > > > committers from various different institutions and we have good >> number >> > of >> > > > reviewers to review PIP/PR on time. >> > > > Right now, there are many examples where PRs are sitting unreviewed >> > for a >> > > > long time and we have to fix it first by encouraging and having more >> > > > committers/reviewers across multiple organizations as a part of the >> > Pulsar >> > > > community. So, this is not the right time to restrict and this is >> > > > indirectly making it difficult for many Pulsar committers and >> > contributors >> > > > who don't belong to specific enterprises. >> > > > >> > > > Thanks, >> > > > Rajan >> > > > >> > > > >> > > > >> > > > >> > > > On Tue, Jun 20, 2023 at 12:14 PM Asaf Mesika <asaf.mes...@gmail.com >> > >> > > > wrote: >> > > > >> > > > > Hi, >> > > > > >> > > > > This is just a reminder that PMC/Committers can only merge the >> PIP PR >> > > > when >> > > > > the vote thread is concluded and in a positive manner, as >> described >> > (" a >> > > > > lazy >> > > > > majority of at least 3 binding +1s votes") >> > > > > >> > > > > So please, before clicking that merge button, double-check those >> two >> > > > > conditions >> > > > > >> > > > > Thanks! >> > > > > >> > > > > Asaf >> > > > > >> > > > >> > >> >
