> 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 > > > > > > > > > > > >
