Hi Michael, > This raises the question of how to handle historical PIPs. We could do some work to move PIPs out of the wiki and out of issues into the code base. The wiki is just another git repo, so any committer should be able to help migrate PIPs in the wiki to the apache/pulsar git repo. This might also be an opportunity to double check the status on old PIPs.
Yes, I think it's a good idea. IMO, we can migrate them one by one. To provide more context for each one like the discussion email, vote email , and the approvals (Of course, very early proposals did not require approval). So that all the contributors can help with the migration process. I think I can move [0] [1] to the codebase first. [0] https://github.com/apache/pulsar/wiki/Pulsar-Improvement-Proposal-Template [1] https://github.com/apache/pulsar/wiki/Pulsar-Improvement-Proposal-%28PIP%29 So that we can review the details and improve these 2 documents (I see the last update for these two documents are 2021 and 2020) Thanks, Penghui On Thu, Aug 25, 2022 at 9:44 AM tison <wander4...@gmail.com> wrote: > Hi Penghui, > > Thanks for starting this discussion! +1 for holding PIPs in the codebase. > > I'd like to share some experience working on open-source projects holding > proposals as code. > > 1. Rust RFCs: codebase https://github.com/rust-lang/rfcs > 2. TiDB Proposals: > https://github.com/pingcap/tidb/tree/master/docs/design#readme > > Reflect on topics in this thread: > > > any reviews should happen with a PR first > > The experience should be similar to reviewing on Google Docs while keeping > all conversations on GitHub and thus synced on the mailing list. You can > preview can some examples: > > * https://github.com/pingcap/tidb/pull/23673 > * https://github.com/rust-lang/rfcs/pull/42 > > Furthermore, continuous follow-up like PIP-198 can discuss implementation > details and update the proposal content one PR by another. The downside is > that even trivial typo fixes should go through a PR. > > > Certainly, all the votes should happen on the mailing list. > > Yes. We should have an explicit [VOTE] and [RESULT][VOTE] thread on the > mailing list while keeping a reference within the proposal content. We can > port the current PIP issue template to a proposal template as Rust RFCs to > highlight it. > > > We can just add a link that points to the PIPs dir to the contribution > guide > or README. > > Rust RFCs hold in a separate repo so that they can use the PR number as the > proposal number to prevent duplicates. It's a bit overhead for Pulsar to > hold a separate repo. So I'd prefer to hold proposals in the same repo > under the dev/proposals folder and resolve the PR number duplicates issue > as described above. Although, it can still be a bit awkward. But at least > we can quickly notice duplicate numbers and resolve them. Using the PR > number as the proposal number keeps it unique, but the number will be > discontinuous. Especially if we're proposing in the main repo, the number > will grow quickly. > > > Should we track the status of PIPs as a project? > > In this direction, we can associate a proposal with a tracking issue and > manipulate the proposal status represented by their tracking issue. It > doesn't mean we keep the current issue discussion process. You can regard > it as an umbrella ticket for the proposal. See > https://github.com/pingcap/tidb/issues/26022 as an example. > > In this direction, we should always ensure that there're several eyes on > the project. Otherwise, we can easily end up with an out-of-sync project. > > To @Rajan @Penghui > > It seems the confusion comes from we have to merge one PR first to prevent > duplicate numbers. If it's a certain concern, see also my comment above > using the PR number as the proposal, or even host a separate proposal repo > as rust-lang/rfcs does and keep the number growing normally. I can provide > experience to maintain this sort of resource. > > > Best, > tison. >
