Sent from my iPhone
> On Apr 2, 2023, at 7:35 AM, Asaf Mesika <asaf.mes...@gmail.com> wrote:
>
> Summarizing so far:
>
> Non-binding: Girish Sharma, Nitin Goyal
> Binding: Christophe Bornet, Penghui Li, Jun Ma, Yu Liu, Lari
>
> Questions:
> 1. Girish - Why do we need to keep the voting in the mailng list?
>
> Since it’s mandatory by ASF.
> Also, I prefer to change the process step by step. This is a big change as it
> is.
Voting on PIPs is something that this PMC decided to do. The ASF mandatory dev
list voting is for RELEASES. (and privately for committers and PMC members)
I also agree that it is a big change and let’s keep changes minimal.
>
> 2. Tison - Do we keep the voting in the mailing list?
>
> Yes
>
> 3. Enrico: Discussion on high level details should remain in the mailing list.
>
> Judging from PIPs I read, I would say the majority of the feedback is not in
> the scope of the PIP, but in the scope certain section / part of the PIP. if
> 90% of the comments already transpire in the PR, I don’t think it will
> benefit for the mere 10%.
> Also, human beings are hard at using two systems at the same time :)
>
> A big plus for discussions on PR is that it’s public and everybody can pitch
> in (For example, Eron Wright was invited to help on a PIP for Open ID Connect
> (Michael) by team members. If the barrier was: joing the mailing list, we
> wouldn’t get it.
Subscribing to the mailing list is not a barrier. Simply send an email. The
only delay is waiting for a moderator to let in through. I know because I’m
likely the one who will do this. (The job is mostly ignoring spam.)
It is easy to review emails on https://lists.Apache.org and you can start a
reply there.
>
> If it’s very critical for you, we can just leave it open, and let people
> decide where to comment. WDYT?
>
> 4. Lari - can we consider separate repo.
>
> It’s possible of course, but I fear the following:
> - It’s yet another repo to clone and search. Majority of PIPs are Pulsar
> related and majority of Pulsar contributors have that cloned, used and up to
> date weekly / daily. It’s would create less friction if it is on main repo.
> You need to search? Pulsar is already there, ready.
Not all PIPs are necessarily about the main repository. Since we publish pips
in the website doing these PRs in the pulsar-site repository might be a good
option.
> - Previous discussion long time ago had many decision points which eventually
> “klled” the initiative.
>
> We can always move it if it really causes a pain point to many people.
>
> WDYT?
Thanks for your initiative!
Best,
Dave
>
>
>
>
>
>
>
>
>> On 31 Mar 2023, at 23:05, Lari Hotari <lhot...@apache.org> wrote:
>>
>> +1
>>
>> Could we consider a separate repository for the PIP files?
>>
>> -Lari
>>
>>> On Thu, 30 Mar 2023, 23.27 Asaf Mesika, <asaf.mes...@gmail.com> wrote:
>>>
>>> Hi all,
>>>
>>> In the last 2 months, I've increased my PIP review time (I do it in
>>> cycles), and reviewed quite a few PIPs.
>>>
>>> My conclusion as a result of that:
>>>
>>> It's nearly impossible to review PIPs using a mailing list.
>>> We must fix it soon.
>>>
>>> *Why?*
>>> 1. Let's say you review the PIP and find 10 issues. Once you quote and
>>> comment on those ten points, you basically started 10 threads of
>>> conversations.
>>> After 2-3 ping pongs with quotes of quotes of quotes, it takes you forever
>>> to read each thread properly. You find your CTRL-F to search to find your
>>> original quote, and reply. Load it up again in your head, switching to the
>>> PIP tab to read it again.
>>> After 10 ping pongs, it becomes almost an impossible mission.
>>>
>>> I can say I'm 75% tired just from the process, not from the review itself.
>>>
>>> 2. It's non collaborative by design.
>>> After 10 ping pongs, the ability of someone to come and join the discussion
>>> is 0. They need to go through so many replies, which are half quotes, find
>>> the original reply, and browse to the PIP.
>>> It's no wonder people drop off the PIP review once we cross 5-6 replies.
>>> It's no wonder, nobody joins after 10 replies.
>>>
>>> 3. It's not open to the public. Non collaborative.
>>> You can't just get a link, and join the review. Not only because of (1) and
>>> (2). You need to join the mailing list. You don't get the past emails to
>>> reply. Just joining the list is a high enough bar for many people.
>>> I personally participated in review of proposals in OpenTelemetry in the
>>> last 6 months, even though I'm just an occasional user. Why? They were
>>> conducted on GitHub PR , so it was easy for me - click a link and reply.
>>>
>>> 4. All over the place
>>> Sometimes people comment on the GitHub issue.
>>> Sometimes on the mailing list.
>>> Not a single place.
>>>
>>> 5. No history.
>>> Ok, finally the author was convinced. I can't see just the changes. They
>>> need to explicitly tell me something was changed.
>>>
>>> 6. Delete All.
>>> They can go crazy, after 1 year, edit the GitHub issue , delete all the
>>> text and write "Kafka is the king". No history, nobody can stop them. It's
>>> their issue.
>>>
>>> 7. Show me all the approved PIPs
>>> Hard to track it today, hard to maintain it updated.
>>>
>>> 8. Resolved comments
>>> Even though you managed to read all 35 replies so far, in reply 36 you see
>>> the author agreed to all 8 out of 10 suggestions. You have no idea of
>>> knowing that in advance. You just wasted 1 hour.
>>>
>>>
>>> *What do I suggest?*
>>>
>>> PR is the main tool we have that allows multiple threaded discussion.
>>> Git provides history. You can't delete it without approval from PMC
>>> members.
>>>
>>> 1. We'll create a folder named "pip" in the pulsar main repo. It will
>>> contain one markdown file for each PIP. The file will be named
>>> "pip-xxx.md".I will write below how to obtain XXX before you start.
>>> 2. To create a PIP, you grab "pip/template.md" and use it to compose your
>>> file in the pip folder.
>>> 3. You submit this file as a PR named "PIP-xxx: short description".
>>> 4. You create "[DISCUSS] PIP-xxx: short description" in the DEV mailing
>>> list and refer people to your PR, with short text explaining the gist of
>>> it.
>>> 5. People discuss using PR comments, each is its own threaded comment.
>>> 6. Comment was done discussion? They resolve it. This way you see what the
>>> pending discussions are at a glance.
>>> 7. Reached consensus? Good. Send "[VOTE] PIP-xxx: short description" on DEV
>>> mailing list.
>>> 8. PIP approved? Awesome. Push commit with link to vote.
>>> A PMC member will merge it.
>>> Merge == approved.
>>> PMC members can add a PIP label.
>>> 9. Rejected? All good. Close the PR.
>>> Closed == Rejected.
>>> It can't be deleted. All comments are still here.
>>>
>>> Before you start, you search Pull Requests with label PIP in GitHub (`is:pr
>>> "PIP-" in:title`)
>>> Take the biggest number and add 1.
>>> It is super rare to have two people create PR at the same time.
>>>
>>> *Show me all approved PIPs:*
>>> Search merged PRs labeled PIP.
>>> Look at "pip" folder
>>>
>>> *Show me rejected PIPs:*
>>> Search closed PRs with "PIP-" in title, or labeled PIP.
>>>
>>>
>>> This is very similar to how Apache BK works.
>>>
>>> WDYT?
>>>
>
