On Wed, Mar 6, 2024 at 7:02 PM Kalwit S <skalwit...@gmail.com> wrote:
> I know I’m not trying to be disrespectful, but it’s not respectful to be > biased and act like an expert during the reviews, while you’ve contributed > just for documentation PRs. When I talk about experience, I’m talking about > reviewers who don’t contribute to the project, they ask questions to get to > know Pulsar’s internals during the PIP, and then they give judgment based > on their limited understanding, which is rude. Also, Pulsar may have > Since you keep questioning the contribution of various people, can I respectfully ask what you have contributed to the project? *Everyone* has a right to ask questions in a PR or in a PIP review. It is actually encouraged that non-committers/non-pmc member contribute to the project by reviewing code and providing feedback and different perspectives. It is the main reason for why the proposals are discussed in such a transparent manner *No one* has the right to tell someone that they cannot ask questions because "they are not qualified" in your view. I can even cite a few examples from recent times from different users > (PIP-337, PIP-338, PIP-332, PIP-310, etc) to illustrate how some > improvements are simply ignored without discussion, some are without any > conclusion, and some are not given the opportunity to be implemented, which > could have allowed other companies to implement a customized implementation > for their need based on plugged-in approach. Well, I think you've chosen *very* bad examples. In none of these cases the discussion has been ignored. Great feedback was always provided and follow up actions are on the person making the proposal. * PIP-310: https://github.com/apache/pulsar/pull/21399 A very productive series of technical discussions was sparked by this proposal, resulting in an alternative implementation that would satisfy the problem described. * PIP-332: https://github.com/apache/pulsar/pull/21927 The proposal also includes some code changes (while the instructions are clear to first send and discuss a proposal). Not very clear. No tests. Some questions were asked, no answers from the proposer. * PIP-337: https://github.com/apache/pulsar/pull/22016 Very reasonable feedback was provided, it's up to the proposer to follow up on that and eventually to close the discussion and start a vote thread. * PIP-338: https://github.com/apache/pulsar/pull/22039 It looks to me this was provided very thoughtful feedback and that there are still some action items. > There are many examples > (PIP-321) where it was developed by SN contributors, and while there is no > consensus, they will still be a part of the system. Other PR examples show > the same pattern, ignoring the needs of other companies, and merging the PR > of SN contributors on an immediate basis. Consensus does not equate unanimity and the acceptance is ultimately determined by the PMC voting decision. We can discuss for ages about a particular solution, though at some point, a decision has to be taken to go one way or another. No single person has veto power to stop a proposal, same as no single person has a right to bypass the process.
