+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 > > >
