> > I have selected these examples from the most recent discussions and they > may not be the best examples to fully illustrate the point.
You should respect people's time by taking the time to craft your replies in this discussion. >From my experience, I've been contributing a lot in recent years to OpenTelemetry, and sometimes it takes me a few good hours, even a day to write a good reply: I research the proposed idea, research the discussions or issues sent to me and only then craft the reply. I can tell you from my experience working on OpenTelemetry, that the way you describe is practically how Open Source works - and OpenTelemetry is the 2nd biggest project in CNCF! * I wrote a proposal and it was ignored. * I joined the weekly community meeting. Pitched my idea and then I had to ping the people replying to me in that Zoom, a good few times on Slack, to get a reply. After many days and sometimes weeks waiting between replies, I scheduled a Zoom call with two of them to get their ideas and mine sync. * I revised my proposal - and what do you think happened? I had to ping them AGAIN, and yes, wait sometimes a week for a reply. In reality, you have to constantly push your proposal, idea, and PR forward. Today it's so much easier for me in OpenTelemetry. After so many contributions ranging from specification changes, proposal, documentation changes and code PRs, the feedback is much more prompt. You know why? Personal relationship - you build it over time. If I would act your way, I would never have gotten anything in OpenTelemtry. Regarding the criteria for accepting a committer. Your response clearly shows you were not part of the community these past 2 years, otherwise you would notice the contribution I've made to Apache Pulsar. The PMC members have noticed hence the invitation to join as committer. Feel free to browse the mailing list archives to see it and GitHub issues/PRs/Discussions and Slack. I can tell you personally that one of my goals when I started reviewing PIPs in Pulsar roughly 2 years ago, was to "raise the bar" of the quality of Pulsar. For me, it starts with exceptional design documents. I stated it multiple times in the mailing list, and it came to manifest itself also in the new PIP template I proposed and is now used: One should be able to grasp the PIP from start to bottom without any prior background knowledge. One of the key reasons for Pulsar's biggest points for improvements is the documentation: It's a big encyclopedia with a lot of information missing. Same goes with architecture of the code - many are not documented. As the person who writes the design already takes the time to research the code quite well before writing the design, it makes sense to write it in a concise manner in the PIP. The good PIPs have that. Since the introduction of the template, and reviewing many PIPs and also writing a few as "show by example" it finally reached that state in Pulsar. Those high quality PIPs in my opinion will lead Pulsar to be of higher quality. By the way: can you share a personal open source contribution experience which was vastly different from what you or I described? I personally only experienced that or worse :) Cheers, Asaf On Fri, Mar 8, 2024 at 12:55 AM Kalwit S <skalwit...@gmail.com> wrote: > >> If you check the votes and the participation in discussion of PIPs it is > *always* involving contributions of >3 different companies. > >> Well, I think you've chosen *very* bad examples. In none of these cases > the discussion > I have selected these examples from the most recent discussions and they > may not be the best examples to fully illustrate the point. However, there > are several things to note with most of these examples that are still open > PIPs and do not have closure after a couple of months. Also, you do not see > non provider company reviews and VOTE in the majority of the discussion, > which leads me to believe that you cannot move forward without relying on > the provider’s mercy (same as Confluent). > > > >> > BTW, if your team is really tired of managing a stable Pulsar, > StreamNative > > can help you :) > >> And so can DataStax ;-) > I will take this as a conclusion to run a stable Pulsar release. > > > On Thu, Mar 7, 2024 at 5:09 AM Dave Fisher <w...@apache.org> wrote: > > > > > > > > On Mar 7, 2024, at 4:20 AM, Neng Lu <nl...@apache.org> wrote: > > > > > > BTW, if your team is really tired of managing a stable Pulsar, > > StreamNative > > > can help you :) > > > > And so can DataStax ;-) >
