+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 <y...@streamnative.io.INVALID> Sent: Friday, March 31, 2023 10:44 To: dev@pulsar.apache.org <dev@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 <peng...@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 <wander4...@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 <scrapmachi...@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.mes...@gmail.com> > > wrote: > > > > > > > Hi all, > > > > > > > > In the last 2 months, I've increased my PIP review time (I do it in > > > > cycles), and reviewed quite a few PIPs. > > > > > > > > My conclusion as a result of that: > > > > > > > > It's nearly impossible to review PIPs using a mailing list. > > > > We must fix it soon. > > > > > > > > *Why?* > > > > 1. Let's say you review the PIP and find 10 issues. Once you quote and > > > > comment on those ten points, you basically started 10 threads of > > > > conversations. > > > > After 2-3 ping pongs with quotes of quotes of quotes, it takes you > > > forever > > > > to read each thread properly. You find your CTRL-F to search to find > > your > > > > original quote, and reply. Load it up again in your head, switching to > > > the > > > > PIP tab to read it again. > > > > After 10 ping pongs, it becomes almost an impossible mission. > > > > > > > > I can say I'm 75% tired just from the process, not from the review > > > itself. > > > > > > > > 2. It's non collaborative by design. > > > > After 10 ping pongs, the ability of someone to come and join the > > > discussion > > > > is 0. They need to go through so many replies, which are half quotes, > > > find > > > > the original reply, and browse to the PIP. > > > > It's no wonder people drop off the PIP review once we cross 5-6 > > replies. > > > > It's no wonder, nobody joins after 10 replies. > > > > > > > > 3. It's not open to the public. Non collaborative. > > > > You can't just get a link, and join the review. Not only because of (1) > > > and > > > > (2). You need to join the mailing list. You don't get the past emails > > to > > > > reply. Just joining the list is a high enough bar for many people. > > > > I personally participated in review of proposals in OpenTelemetry in > > the > > > > last 6 months, even though I'm just an occasional user. Why? They were > > > > conducted on GitHub PR , so it was easy for me - click a link and > > reply. > > > > > > > > 4. All over the place > > > > Sometimes people comment on the GitHub issue. > > > > Sometimes on the mailing list. > > > > Not a single place. > > > > > > > > 5. No history. > > > > Ok, finally the author was convinced. I can't see just the changes. > > They > > > > need to explicitly tell me something was changed. > > > > > > > > 6. Delete All. > > > > They can go crazy, after 1 year, edit the GitHub issue , delete all the > > > > text and write "Kafka is the king". No history, nobody can stop them. > > > It's > > > > their issue. > > > > > > > > 7. Show me all the approved PIPs > > > > Hard to track it today, hard to maintain it updated. > > > > > > > > 8. Resolved comments > > > > Even though you managed to read all 35 replies so far, in reply 36 you > > > see > > > > the author agreed to all 8 out of 10 suggestions. You have no idea of > > > > knowing that in advance. You just wasted 1 hour. > > > > > > > > > > > > *What do I suggest?* > > > > > > > > PR is the main tool we have that allows multiple threaded discussion. > > > > Git provides history. You can't delete it without approval from PMC > > > > members. > > > > > > > > 1. We'll create a folder named "pip" in the pulsar main repo. It will > > > > contain one markdown file for each PIP. The file will be named > > > > "pip-xxx.md".I will write below how to obtain XXX before you start. > > > > 2. To create a PIP, you grab "pip/template.md" and use it to compose > > your > > > > file in the pip folder. > > > > 3. You submit this file as a PR named "PIP-xxx: short description". > > > > 4. You create "[DISCUSS] PIP-xxx: short description" in the DEV mailing > > > > list and refer people to your PR, with short text explaining the gist > > of > > > > it. > > > > 5. People discuss using PR comments, each is its own threaded comment. > > > > 6. Comment was done discussion? They resolve it. This way you see what > > > the > > > > pending discussions are at a glance. > > > > 7. Reached consensus? Good. Send "[VOTE] PIP-xxx: short description" on > > > DEV > > > > mailing list. > > > > 8. PIP approved? Awesome. Push commit with link to vote. > > > > A PMC member will merge it. > > > > Merge == approved. > > > > PMC members can add a PIP label. > > > > 9. Rejected? All good. Close the PR. > > > > Closed == Rejected. > > > > It can't be deleted. All comments are still here. > > > > > > > > Before you start, you search Pull Requests with label PIP in GitHub > > > (`is:pr > > > > "PIP-" in:title`) > > > > Take the biggest number and add 1. > > > > It is super rare to have two people create PR at the same time. > > > > > > > > *Show me all approved PIPs:* > > > > Search merged PRs labeled PIP. > > > > Look at "pip" folder > > > > > > > > *Show me rejected PIPs:* > > > > Search closed PRs with "PIP-" in title, or labeled PIP. > > > > > > > > > > > > This is very similar to how Apache BK works. > > > > > > > > WDYT? > > > > > > > > > > > > > -- > > > Girish Sharma > > > > >
