You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pulsar.apache.org by Asaf Mesika <as...@gmail.com> on 2023/03/30 20:26:47 UTC
[DISCUSS] We must change the way we review PIPs
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?
Re: [DISCUSS] We must change the way we review PIPs
Posted by Christophe Bornet <bo...@gmail.com>.
Big +1 for me
Le jeu. 30 mars 2023 à 22:27, Asaf Mesika <as...@gmail.com> a écrit :
>
> 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?
Re: [DISCUSS] We must change the way we review PIPs
Posted by Girish Sharma <sc...@gmail.com>.
On Fri, Mar 31, 2023 at 7:09 PM Enrico Olivelli <eo...@gmail.com> wrote:
> I agree that we should finally have PIPs committed to git somewhere.
>
> When a PIP is approved it can be committed, but we must run the VOTE
> and wait for 3 binding +1,
> this is hard to do with a PR.
> It already happened a few times that people committed patches related
> to unapproved PIPs.
>
>
Github actually does have ways to allow for this. the PIPs can live in a
separate branch where we set 3 reviews as minimum required and the
CODEOWNERS file can list down usernames of all PMC members who are eligible
for binding votes.
[image: image.png]
Regards
Re: [DISCUSS] We must change the way we review PIPs
Posted by Enrico Olivelli <eo...@gmail.com>.
I agree that we should finally have PIPs committed to git somewhere.
When a PIP is approved it can be committed, but we must run the VOTE
and wait for 3 binding +1,
this is hard to do with a PR.
It already happened a few times that people committed patches related
to unapproved PIPs.
Regarding the discussion:
I still think that we should keep the discussions on the mailing list.
I am not talking about fine grained details that will be discussed on the PR.
I am spending much of my time on Pulsar both for work and for personal fun,
even though I am still overwhelmed by the flow of GH PRs and notifications.
Following the ML is the best way to participate in the discussions.
So I suggest:
1) use GIT to keep the PIP design document
2) run the high level discussion on the ML
3) leverage GH PRs comments for fine grained details both on the PIP
document and on the related PRs
Enrico
Il giorno ven 31 mar 2023 alle ore 12:39 Yu <li...@apache.org> ha scritto:
>
> +1 for allowing collaborators to review, comment, approve, or request
> further changes more conveniently
>
> On Fri, Mar 31, 2023 at 11:26 AM Nitin Goyal <ni...@gmail.com>
> wrote:
>
> > +1 (non-binding)
> >
> > On Fri, 31 Mar, 2023, 08:41 Jun Ma, <mo...@hotmail.com> wrote:
> >
> > > +1.
> > >
> > > Besides using a single source to lift the review efficiency, adding
> > > control over the design documents is also a good practice from the
> > project
> > > management perspective.
> > >
> > >
> > > Best,
> > > Jun
> > > ________________________________
> > > From: Yunze Xu <yz...@streamnative.io.INVALID>
> > > Sent: Friday, March 31, 2023 10:44
> > > To: dev@pulsar.apache.org <de...@pulsar.apache.org>
> > > Subject: Re: [DISCUSS] We must change the way we review PIPs
> > >
> > > +1 to me. Once the discussion thread of a PIP became too long, it
> > > would be hard to continue the discussion.
> > >
> > > Thanks,
> > > Yunze
> > >
> > > On Fri, Mar 31, 2023 at 9:13 AM PengHui Li <pe...@apache.org> wrote:
> > > >
> > > > +1 for creating a folder named "pip" in the main pulsar repo
> > > > So far, it is good enough to solve the problems we've had.
> > > >
> > > > If it is really worth moving to another repo in the future.
> > > > We can move it maybe 3, 5 years later.
> > > >
> > > > Thanks,
> > > > Penghui
> > > >
> > > >
> > > > On Fri, Mar 31, 2023 at 8:29 AM tison <wa...@gmail.com> wrote:
> > > >
> > > > > Hi Asaf,
> > > > >
> > > > > Thanks for starting this thread!
> > > > >
> > > > > I have similar thoughts on using a single source for reviewing PIPs.
> > > GH PRs
> > > > > are good for conversation, although multiple conversations are still
> > > hard
> > > > > to follow (which can be natural)
> > > > >
> > > > > Here is how Rust does it[1] - a self-documented RFC repo + review
> > PRs +
> > > > > tracking issue on the main repo once accepted.
> > > > >
> > > > > Here is what I designed for TiDB[2][3]; proposals are placed in a
> > > folder
> > > > > under the main repo.
> > > > >
> > > > > We don't have to follow other community's ways, but these two
> > practices
> > > > > seem good to read.
> > > > >
> > > > > And, to follow the ASF voting strategy[4][5], we may still need a
> > > standard
> > > > > vote mail thread and document the result on the mailing list.
> > > > >
> > > > > Best,
> > > > > tison.
> > > > >
> > > > > [1] https://github.com/rust-lang/rfcs
> > > > > [2] https://github.com/pingcap/tidb/tree/master/docs/design
> > > > > [3]
> > > > >
> > > > >
> > >
> > https://pingcap.github.io/tidb-dev-guide/contribute-to-tidb/make-a-proposal.html
> > > > > [4] https://www.apache.org/foundation/voting.html
> > > > > [5] https://www.apache.org/dev/pmc.html#mailing-list-naming-policy
> > > > >
> > > > >
> > > > > Girish Sharma <sc...@gmail.com> 于2023年3月31日周五 04:33写道：
> > > > >
> > > > > > +1 (non-binding .. ? )
> > > > > > I've already commented a couple of times (here and there) that the
> > > > > process
> > > > > > needs to be consolidated at a single place. This is a good and
> > > detailed
> > > > > > approach.
> > > > > > Not sure if there is a historical context behind keeping the
> > > discussion
> > > > > in
> > > > > > dev mailing list..
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > > On Fri, Mar 31, 2023 at 1:57 AM Asaf Mesika <asaf.mesika@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?
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Girish Sharma
> > > > > >
> > > > >
> > >
> >
Re: [DISCUSS] We must change the way we review PIPs
Posted by Yu <li...@apache.org>.
+1 for allowing collaborators to review, comment, approve, or request
further changes more conveniently
On Fri, Mar 31, 2023 at 11:26 AM Nitin Goyal <ni...@gmail.com>
wrote:
> +1 (non-binding)
>
> On Fri, 31 Mar, 2023, 08:41 Jun Ma, <mo...@hotmail.com> wrote:
>
> > +1.
> >
> > Besides using a single source to lift the review efficiency, adding
> > control over the design documents is also a good practice from the
> project
> > management perspective.
> >
> >
> > Best,
> > Jun
> > ________________________________
> > From: Yunze Xu <yz...@streamnative.io.INVALID>
> > Sent: Friday, March 31, 2023 10:44
> > To: dev@pulsar.apache.org <de...@pulsar.apache.org>
> > Subject: Re: [DISCUSS] We must change the way we review PIPs
> >
> > +1 to me. Once the discussion thread of a PIP became too long, it
> > would be hard to continue the discussion.
> >
> > Thanks,
> > Yunze
> >
> > On Fri, Mar 31, 2023 at 9:13 AM PengHui Li <pe...@apache.org> wrote:
> > >
> > > +1 for creating a folder named "pip" in the main pulsar repo
> > > So far, it is good enough to solve the problems we've had.
> > >
> > > If it is really worth moving to another repo in the future.
> > > We can move it maybe 3, 5 years later.
> > >
> > > Thanks,
> > > Penghui
> > >
> > >
> > > On Fri, Mar 31, 2023 at 8:29 AM tison <wa...@gmail.com> wrote:
> > >
> > > > Hi Asaf,
> > > >
> > > > Thanks for starting this thread!
> > > >
> > > > I have similar thoughts on using a single source for reviewing PIPs.
> > GH PRs
> > > > are good for conversation, although multiple conversations are still
> > hard
> > > > to follow (which can be natural)
> > > >
> > > > Here is how Rust does it[1] - a self-documented RFC repo + review
> PRs +
> > > > tracking issue on the main repo once accepted.
> > > >
> > > > Here is what I designed for TiDB[2][3]; proposals are placed in a
> > folder
> > > > under the main repo.
> > > >
> > > > We don't have to follow other community's ways, but these two
> practices
> > > > seem good to read.
> > > >
> > > > And, to follow the ASF voting strategy[4][5], we may still need a
> > standard
> > > > vote mail thread and document the result on the mailing list.
> > > >
> > > > Best,
> > > > tison.
> > > >
> > > > [1] https://github.com/rust-lang/rfcs
> > > > [2] https://github.com/pingcap/tidb/tree/master/docs/design
> > > > [3]
> > > >
> > > >
> >
> https://pingcap.github.io/tidb-dev-guide/contribute-to-tidb/make-a-proposal.html
> > > > [4] https://www.apache.org/foundation/voting.html
> > > > [5] https://www.apache.org/dev/pmc.html#mailing-list-naming-policy
> > > >
> > > >
> > > > Girish Sharma <sc...@gmail.com> 于2023年3月31日周五 04:33写道：
> > > >
> > > > > +1 (non-binding .. ? )
> > > > > I've already commented a couple of times (here and there) that the
> > > > process
> > > > > needs to be consolidated at a single place. This is a good and
> > detailed
> > > > > approach.
> > > > > Not sure if there is a historical context behind keeping the
> > discussion
> > > > in
> > > > > dev mailing list..
> > > > >
> > > > > Regards
> > > > >
> > > > > On Fri, Mar 31, 2023 at 1:57 AM Asaf Mesika <asaf.mesika@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?
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Girish Sharma
> > > > >
> > > >
> >
>
Re: [DISCUSS] We must change the way we review PIPs
Posted by Nitin Goyal <ni...@gmail.com>.
+1 (non-binding)
On Fri, 31 Mar, 2023, 08:41 Jun Ma, <mo...@hotmail.com> wrote:
> +1.
>
> Besides using a single source to lift the review efficiency, adding
> control over the design documents is also a good practice from the project
> management perspective.
>
>
> Best,
> Jun
> ________________________________
> From: Yunze Xu <yz...@streamnative.io.INVALID>
> Sent: Friday, March 31, 2023 10:44
> To: dev@pulsar.apache.org <de...@pulsar.apache.org>
> Subject: Re: [DISCUSS] We must change the way we review PIPs
>
> +1 to me. Once the discussion thread of a PIP became too long, it
> would be hard to continue the discussion.
>
> Thanks,
> Yunze
>
> On Fri, Mar 31, 2023 at 9:13 AM PengHui Li <pe...@apache.org> wrote:
> >
> > +1 for creating a folder named "pip" in the main pulsar repo
> > So far, it is good enough to solve the problems we've had.
> >
> > If it is really worth moving to another repo in the future.
> > We can move it maybe 3, 5 years later.
> >
> > Thanks,
> > Penghui
> >
> >
> > On Fri, Mar 31, 2023 at 8:29 AM tison <wa...@gmail.com> wrote:
> >
> > > Hi Asaf,
> > >
> > > Thanks for starting this thread!
> > >
> > > I have similar thoughts on using a single source for reviewing PIPs.
> GH PRs
> > > are good for conversation, although multiple conversations are still
> hard
> > > to follow (which can be natural)
> > >
> > > Here is how Rust does it[1] - a self-documented RFC repo + review PRs +
> > > tracking issue on the main repo once accepted.
> > >
> > > Here is what I designed for TiDB[2][3]; proposals are placed in a
> folder
> > > under the main repo.
> > >
> > > We don't have to follow other community's ways, but these two practices
> > > seem good to read.
> > >
> > > And, to follow the ASF voting strategy[4][5], we may still need a
> standard
> > > vote mail thread and document the result on the mailing list.
> > >
> > > Best,
> > > tison.
> > >
> > > [1] https://github.com/rust-lang/rfcs
> > > [2] https://github.com/pingcap/tidb/tree/master/docs/design
> > > [3]
> > >
> > >
> https://pingcap.github.io/tidb-dev-guide/contribute-to-tidb/make-a-proposal.html
> > > [4] https://www.apache.org/foundation/voting.html
> > > [5] https://www.apache.org/dev/pmc.html#mailing-list-naming-policy
> > >
> > >
> > > Girish Sharma <sc...@gmail.com> 于2023年3月31日周五 04:33写道：
> > >
> > > > +1 (non-binding .. ? )
> > > > I've already commented a couple of times (here and there) that the
> > > process
> > > > needs to be consolidated at a single place. This is a good and
> detailed
> > > > approach.
> > > > Not sure if there is a historical context behind keeping the
> discussion
> > > in
> > > > dev mailing list..
> > > >
> > > > Regards
> > > >
> > > > On Fri, Mar 31, 2023 at 1:57 AM Asaf Mesika <as...@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?
> > > > >
> > > >
> > > >
> > > > --
> > > > Girish Sharma
> > > >
> > >
>
Re: [DISCUSS] We must change the way we review PIPs
Posted by Jun Ma <mo...@hotmail.com>.
+1.
Besides using a single source to lift the review efficiency, adding control over the design documents is also a good practice from the project management perspective.
Best,
Jun
________________________________
From: Yunze Xu <yz...@streamnative.io.INVALID>
Sent: Friday, March 31, 2023 10:44
To: dev@pulsar.apache.org <de...@pulsar.apache.org>
Subject: Re: [DISCUSS] We must change the way we review PIPs
+1 to me. Once the discussion thread of a PIP became too long, it
would be hard to continue the discussion.
Thanks,
Yunze
On Fri, Mar 31, 2023 at 9:13 AM PengHui Li <pe...@apache.org> wrote:
>
> +1 for creating a folder named "pip" in the main pulsar repo
> So far, it is good enough to solve the problems we've had.
>
> If it is really worth moving to another repo in the future.
> We can move it maybe 3, 5 years later.
>
> Thanks,
> Penghui
>
>
> On Fri, Mar 31, 2023 at 8:29 AM tison <wa...@gmail.com> wrote:
>
> > Hi Asaf,
> >
> > Thanks for starting this thread!
> >
> > I have similar thoughts on using a single source for reviewing PIPs. GH PRs
> > are good for conversation, although multiple conversations are still hard
> > to follow (which can be natural)
> >
> > Here is how Rust does it[1] - a self-documented RFC repo + review PRs +
> > tracking issue on the main repo once accepted.
> >
> > Here is what I designed for TiDB[2][3]; proposals are placed in a folder
> > under the main repo.
> >
> > We don't have to follow other community's ways, but these two practices
> > seem good to read.
> >
> > And, to follow the ASF voting strategy[4][5], we may still need a standard
> > vote mail thread and document the result on the mailing list.
> >
> > Best,
> > tison.
> >
> > [1] https://github.com/rust-lang/rfcs
> > [2] https://github.com/pingcap/tidb/tree/master/docs/design
> > [3]
> >
> > https://pingcap.github.io/tidb-dev-guide/contribute-to-tidb/make-a-proposal.html
> > [4] https://www.apache.org/foundation/voting.html
> > [5] https://www.apache.org/dev/pmc.html#mailing-list-naming-policy
> >
> >
> > Girish Sharma <sc...@gmail.com> 于2023年3月31日周五 04:33写道：
> >
> > > +1 (non-binding .. ? )
> > > I've already commented a couple of times (here and there) that the
> > process
> > > needs to be consolidated at a single place. This is a good and detailed
> > > approach.
> > > Not sure if there is a historical context behind keeping the discussion
> > in
> > > dev mailing list..
> > >
> > > Regards
> > >
> > > On Fri, Mar 31, 2023 at 1:57 AM Asaf Mesika <as...@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?
> > > >
> > >
> > >
> > > --
> > > Girish Sharma
> > >
> >
Re: [DISCUSS] We must change the way we review PIPs
Posted by houxiaoyu <an...@gmail.com>.
Big +1(non-binding) to me
Thanks,
Hou Xiaoyu
Yunze Xu <yz...@streamnative.io.invalid> 于2023年3月31日周五 10:45写道：
> +1 to me. Once the discussion thread of a PIP became too long, it
> would be hard to continue the discussion.
>
> Thanks,
> Yunze
>
> On Fri, Mar 31, 2023 at 9:13 AM PengHui Li <pe...@apache.org> wrote:
> >
> > +1 for creating a folder named "pip" in the main pulsar repo
> > So far, it is good enough to solve the problems we've had.
> >
> > If it is really worth moving to another repo in the future.
> > We can move it maybe 3, 5 years later.
> >
> > Thanks,
> > Penghui
> >
> >
> > On Fri, Mar 31, 2023 at 8:29 AM tison <wa...@gmail.com> wrote:
> >
> > > Hi Asaf,
> > >
> > > Thanks for starting this thread!
> > >
> > > I have similar thoughts on using a single source for reviewing PIPs.
> GH PRs
> > > are good for conversation, although multiple conversations are still
> hard
> > > to follow (which can be natural)
> > >
> > > Here is how Rust does it[1] - a self-documented RFC repo + review PRs +
> > > tracking issue on the main repo once accepted.
> > >
> > > Here is what I designed for TiDB[2][3]; proposals are placed in a
> folder
> > > under the main repo.
> > >
> > > We don't have to follow other community's ways, but these two practices
> > > seem good to read.
> > >
> > > And, to follow the ASF voting strategy[4][5], we may still need a
> standard
> > > vote mail thread and document the result on the mailing list.
> > >
> > > Best,
> > > tison.
> > >
> > > [1] https://github.com/rust-lang/rfcs
> > > [2] https://github.com/pingcap/tidb/tree/master/docs/design
> > > [3]
> > >
> > >
> https://pingcap.github.io/tidb-dev-guide/contribute-to-tidb/make-a-proposal.html
> > > [4] https://www.apache.org/foundation/voting.html
> > > [5] https://www.apache.org/dev/pmc.html#mailing-list-naming-policy
> > >
> > >
> > > Girish Sharma <sc...@gmail.com> 于2023年3月31日周五 04:33写道：
> > >
> > > > +1 (non-binding .. ? )
> > > > I've already commented a couple of times (here and there) that the
> > > process
> > > > needs to be consolidated at a single place. This is a good and
> detailed
> > > > approach.
> > > > Not sure if there is a historical context behind keeping the
> discussion
> > > in
> > > > dev mailing list..
> > > >
> > > > Regards
> > > >
> > > > On Fri, Mar 31, 2023 at 1:57 AM Asaf Mesika <as...@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?
> > > > >
> > > >
> > > >
> > > > --
> > > > Girish Sharma
> > > >
> > >
>
Re: [DISCUSS] We must change the way we review PIPs
Posted by Yunze Xu <yz...@streamnative.io.INVALID>.
+1 to me. Once the discussion thread of a PIP became too long, it
would be hard to continue the discussion.
Thanks,
Yunze
On Fri, Mar 31, 2023 at 9:13 AM PengHui Li <pe...@apache.org> wrote:
>
> +1 for creating a folder named "pip" in the main pulsar repo
> So far, it is good enough to solve the problems we've had.
>
> If it is really worth moving to another repo in the future.
> We can move it maybe 3, 5 years later.
>
> Thanks,
> Penghui
>
>
> On Fri, Mar 31, 2023 at 8:29 AM tison <wa...@gmail.com> wrote:
>
> > Hi Asaf,
> >
> > Thanks for starting this thread!
> >
> > I have similar thoughts on using a single source for reviewing PIPs. GH PRs
> > are good for conversation, although multiple conversations are still hard
> > to follow (which can be natural)
> >
> > Here is how Rust does it[1] - a self-documented RFC repo + review PRs +
> > tracking issue on the main repo once accepted.
> >
> > Here is what I designed for TiDB[2][3]; proposals are placed in a folder
> > under the main repo.
> >
> > We don't have to follow other community's ways, but these two practices
> > seem good to read.
> >
> > And, to follow the ASF voting strategy[4][5], we may still need a standard
> > vote mail thread and document the result on the mailing list.
> >
> > Best,
> > tison.
> >
> > [1] https://github.com/rust-lang/rfcs
> > [2] https://github.com/pingcap/tidb/tree/master/docs/design
> > [3]
> >
> > https://pingcap.github.io/tidb-dev-guide/contribute-to-tidb/make-a-proposal.html
> > [4] https://www.apache.org/foundation/voting.html
> > [5] https://www.apache.org/dev/pmc.html#mailing-list-naming-policy
> >
> >
> > Girish Sharma <sc...@gmail.com> 于2023年3月31日周五 04:33写道：
> >
> > > +1 (non-binding .. ? )
> > > I've already commented a couple of times (here and there) that the
> > process
> > > needs to be consolidated at a single place. This is a good and detailed
> > > approach.
> > > Not sure if there is a historical context behind keeping the discussion
> > in
> > > dev mailing list..
> > >
> > > Regards
> > >
> > > On Fri, Mar 31, 2023 at 1:57 AM Asaf Mesika <as...@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?
> > > >
> > >
> > >
> > > --
> > > Girish Sharma
> > >
> >
Re: [DISCUSS] We must change the way we review PIPs
Posted by PengHui Li <pe...@apache.org>.
+1 for creating a folder named "pip" in the main pulsar repo
So far, it is good enough to solve the problems we've had.
If it is really worth moving to another repo in the future.
We can move it maybe 3, 5 years later.
Thanks,
Penghui
On Fri, Mar 31, 2023 at 8:29 AM tison <wa...@gmail.com> wrote:
> Hi Asaf,
>
> Thanks for starting this thread!
>
> I have similar thoughts on using a single source for reviewing PIPs. GH PRs
> are good for conversation, although multiple conversations are still hard
> to follow (which can be natural)
>
> Here is how Rust does it[1] - a self-documented RFC repo + review PRs +
> tracking issue on the main repo once accepted.
>
> Here is what I designed for TiDB[2][3]; proposals are placed in a folder
> under the main repo.
>
> We don't have to follow other community's ways, but these two practices
> seem good to read.
>
> And, to follow the ASF voting strategy[4][5], we may still need a standard
> vote mail thread and document the result on the mailing list.
>
> Best,
> tison.
>
> [1] https://github.com/rust-lang/rfcs
> [2] https://github.com/pingcap/tidb/tree/master/docs/design
> [3]
>
> https://pingcap.github.io/tidb-dev-guide/contribute-to-tidb/make-a-proposal.html
> [4] https://www.apache.org/foundation/voting.html
> [5] https://www.apache.org/dev/pmc.html#mailing-list-naming-policy
>
>
> Girish Sharma <sc...@gmail.com> 于2023年3月31日周五 04:33写道：
>
> > +1 (non-binding .. ? )
> > I've already commented a couple of times (here and there) that the
> process
> > needs to be consolidated at a single place. This is a good and detailed
> > approach.
> > Not sure if there is a historical context behind keeping the discussion
> in
> > dev mailing list..
> >
> > Regards
> >
> > On Fri, Mar 31, 2023 at 1:57 AM Asaf Mesika <as...@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?
> > >
> >
> >
> > --
> > Girish Sharma
> >
>
Re: [DISCUSS] We must change the way we review PIPs
Posted by tison <wa...@gmail.com>.
Hi Asaf,
Thanks for starting this thread!
I have similar thoughts on using a single source for reviewing PIPs. GH PRs
are good for conversation, although multiple conversations are still hard
to follow (which can be natural)
Here is how Rust does it[1] - a self-documented RFC repo + review PRs +
tracking issue on the main repo once accepted.
Here is what I designed for TiDB[2][3]; proposals are placed in a folder
under the main repo.
We don't have to follow other community's ways, but these two practices
seem good to read.
And, to follow the ASF voting strategy[4][5], we may still need a standard
vote mail thread and document the result on the mailing list.
Best,
tison.
[1] https://github.com/rust-lang/rfcs
[2] https://github.com/pingcap/tidb/tree/master/docs/design
[3]
https://pingcap.github.io/tidb-dev-guide/contribute-to-tidb/make-a-proposal.html
[4] https://www.apache.org/foundation/voting.html
[5] https://www.apache.org/dev/pmc.html#mailing-list-naming-policy
Girish Sharma <sc...@gmail.com> 于2023年3月31日周五 04:33写道：
> +1 (non-binding .. ? )
> I've already commented a couple of times (here and there) that the process
> needs to be consolidated at a single place. This is a good and detailed
> approach.
> Not sure if there is a historical context behind keeping the discussion in
> dev mailing list..
>
> Regards
>
> On Fri, Mar 31, 2023 at 1:57 AM Asaf Mesika <as...@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?
> >
>
>
> --
> Girish Sharma
>
Re: [DISCUSS] We must change the way we review PIPs
Posted by Girish Sharma <sc...@gmail.com>.
+1 (non-binding .. ? )
I've already commented a couple of times (here and there) that the process
needs to be consolidated at a single place. This is a good and detailed
approach.
Not sure if there is a historical context behind keeping the discussion in
dev mailing list..
Regards
On Fri, Mar 31, 2023 at 1:57 AM Asaf Mesika <as...@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?
>
--
Girish Sharma
Re: [DISCUSS] We must change the way we review PIPs
Posted by Asaf Mesika <as...@gmail.com>.
I've converted all correspondence here into PIP:
https://github.com/apache/pulsar/issues/20207
Also opened a new email thread on it.
On Mon, Apr 3, 2023 at 12:46 PM Asaf Mesika <as...@gmail.com> wrote:
> One issue will be PIP numbering. If we only merge accepted PIPs, but
>> all PIPs get numbers, we'll have holes in our pip/ directory. It might
>> be worth adding a README.md to the pip directory that both explains
>> the process and enumerates the PIPs (both accepted and rejected).
>>
>
> I'm ok with adding such a file, but I think it will go stale.
> How about I add a README and in it include a link showing all PIPs, and
> explaining PR status is accepted/rejected status?
> Of course I can detail the process.
>
> Is it ok if we won't specify where to have the general discussion, and in
> 20 PIPs from now we'll see how it evolves organically and then specify that
> in the process?
>
> On Mon, Apr 3, 2023 at 6:26 AM Michael Marshall <mm...@apache.org>
> wrote:
>
>> +1
>>
>> I support having the high-level discussion on the ML, but I can see
>> that becoming confusing if there are multiple places to discuss the
>> PIP. In my view, GitHub is great when you want to discuss specific
>> lines in a PR, but general discussion on the PR's main page is
>> essentially the same as a mailing list, except the formatting is
>> generally better.
>>
>> One issue will be PIP numbering. If we only merge accepted PIPs, but
>> all PIPs get numbers, we'll have holes in our pip/ directory. It might
>> be worth adding a README.md to the pip directory that both explains
>> the process and enumerates the PIPs (both accepted and rejected).
>>
>> For historical reference, Christophe proposed this change within this
>> thread: https://lists.apache.org/thread/m8dr0hz7qn7rkd48bcp430lcq2q3674g
>>
>> The primary objection was a concern about losing PIPs and the issue of
>> questions about merges. I think we'll be able to address those
>> concerns.
>>
>> Thanks,
>> Michael
>>
>> On Sun, Apr 2, 2023 at 11:14 AM Dave Fisher <wa...@comcast.net>
>> wrote:
>> >
>> >
>> >
>> > Sent from my iPhone
>> >
>> > > On Apr 2, 2023, at 7:35 AM, Asaf Mesika <as...@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 <lh...@apache.org> wrote:
>> > >>
>> > >> +1
>> > >>
>> > >> Could we consider a separate repository for the PIP files?
>> > >>
>> > >> -Lari
>> > >>
>> > >>> On Thu, 30 Mar 2023, 23.27 Asaf Mesika, <as...@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?
>> > >>>
>> > >
>> >
>>
>
Re: [DISCUSS] We must change the way we review PIPs
Posted by Asaf Mesika <as...@gmail.com>.
>
> One issue will be PIP numbering. If we only merge accepted PIPs, but
> all PIPs get numbers, we'll have holes in our pip/ directory. It might
> be worth adding a README.md to the pip directory that both explains
> the process and enumerates the PIPs (both accepted and rejected).
>
I'm ok with adding such a file, but I think it will go stale.
How about I add a README and in it include a link showing all PIPs, and
explaining PR status is accepted/rejected status?
Of course I can detail the process.
Is it ok if we won't specify where to have the general discussion, and in
20 PIPs from now we'll see how it evolves organically and then specify that
in the process?
On Mon, Apr 3, 2023 at 6:26 AM Michael Marshall <mm...@apache.org>
wrote:
> +1
>
> I support having the high-level discussion on the ML, but I can see
> that becoming confusing if there are multiple places to discuss the
> PIP. In my view, GitHub is great when you want to discuss specific
> lines in a PR, but general discussion on the PR's main page is
> essentially the same as a mailing list, except the formatting is
> generally better.
>
> One issue will be PIP numbering. If we only merge accepted PIPs, but
> all PIPs get numbers, we'll have holes in our pip/ directory. It might
> be worth adding a README.md to the pip directory that both explains
> the process and enumerates the PIPs (both accepted and rejected).
>
> For historical reference, Christophe proposed this change within this
> thread: https://lists.apache.org/thread/m8dr0hz7qn7rkd48bcp430lcq2q3674g
>
> The primary objection was a concern about losing PIPs and the issue of
> questions about merges. I think we'll be able to address those
> concerns.
>
> Thanks,
> Michael
>
> On Sun, Apr 2, 2023 at 11:14 AM Dave Fisher <wa...@comcast.net> wrote:
> >
> >
> >
> > Sent from my iPhone
> >
> > > On Apr 2, 2023, at 7:35 AM, Asaf Mesika <as...@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 <lh...@apache.org> wrote:
> > >>
> > >> +1
> > >>
> > >> Could we consider a separate repository for the PIP files?
> > >>
> > >> -Lari
> > >>
> > >>> On Thu, 30 Mar 2023, 23.27 Asaf Mesika, <as...@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?
> > >>>
> > >
> >
>
Re: [DISCUSS] We must change the way we review PIPs
Posted by Michael Marshall <mm...@apache.org>.
+1
I support having the high-level discussion on the ML, but I can see
that becoming confusing if there are multiple places to discuss the
PIP. In my view, GitHub is great when you want to discuss specific
lines in a PR, but general discussion on the PR's main page is
essentially the same as a mailing list, except the formatting is
generally better.
One issue will be PIP numbering. If we only merge accepted PIPs, but
all PIPs get numbers, we'll have holes in our pip/ directory. It might
be worth adding a README.md to the pip directory that both explains
the process and enumerates the PIPs (both accepted and rejected).
For historical reference, Christophe proposed this change within this
thread: https://lists.apache.org/thread/m8dr0hz7qn7rkd48bcp430lcq2q3674g
The primary objection was a concern about losing PIPs and the issue of
questions about merges. I think we'll be able to address those
concerns.
Thanks,
Michael
On Sun, Apr 2, 2023 at 11:14 AM Dave Fisher <wa...@comcast.net> wrote:
>
>
>
> Sent from my iPhone
>
> > On Apr 2, 2023, at 7:35 AM, Asaf Mesika <as...@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 <lh...@apache.org> wrote:
> >>
> >> +1
> >>
> >> Could we consider a separate repository for the PIP files?
> >>
> >> -Lari
> >>
> >>> On Thu, 30 Mar 2023, 23.27 Asaf Mesika, <as...@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?
> >>>
> >
>
Re: [DISCUSS] We must change the way we review PIPs
Posted by Dave Fisher <wa...@comcast.net>.
Sent from my iPhone
> On Apr 2, 2023, at 7:35 AM, Asaf Mesika <as...@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 <lh...@apache.org> wrote:
>>
>> +1
>>
>> Could we consider a separate repository for the PIP files?
>>
>> -Lari
>>
>>> On Thu, 30 Mar 2023, 23.27 Asaf Mesika, <as...@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?
>>>
>
Re: [DISCUSS] We must change the way we review PIPs
Posted by Asaf Mesika <as...@gmail.com>.
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.
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.
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.
- 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?
> On 31 Mar 2023, at 23:05, Lari Hotari <lh...@apache.org> wrote:
>
> +1
>
> Could we consider a separate repository for the PIP files?
>
> -Lari
>
> On Thu, 30 Mar 2023, 23.27 Asaf Mesika, <as...@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?
>>
Re: [DISCUSS] We must change the way we review PIPs
Posted by Lari Hotari <lh...@apache.org>.
+1
Could we consider a separate repository for the PIP files?
-Lari
On Thu, 30 Mar 2023, 23.27 Asaf Mesika, <as...@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?
>