Hi Tison, Thanks for providing more context.
> 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. The PR number can provide unique numbers. Everyone can create PRs, maybe not related to PIP, but we are not able to revert it. > 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. IMO, the final status of the proposal should be summarized in the proposal. We can have some metadata for md file which allow us to have a page that can show all the proposals like the bookkeeper does https://bookkeeper.apache.org/community/bookkeeper-proposals >From my personal view, I prefer this way of the bookkeeper. This will allow all the users find the proposals on the website, instead of going to search in the issue list. And the md file is the source of the truth. I think we can only provide one way to update the proposal status (from a PR). So that all the contributors can contribute. As I know, if we have an issue tracking all the proposal status, not all the contributors make contributions. Only the committers and the author? Maybe the author can change the policy but still can't involve more people to review. > 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. Yes, it looks to request a PIP number through a PR. IMO, it is necessary. The reviewer can only merge the PR (request the PIP number) if the discussion of the motivation doesn't have objections and is discussed enough. Without this step, maybe only the author thinks that "I can create a proposal for now" (maybe no response on the mailing list). Best, Penghui On Thu, Aug 25, 2022 at 10:31 AM PengHui Li <peng...@apache.org> wrote: > > 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) > > Sorry, I think it's not a good idea. > We should move to the codebase 100% the same as the original documentation. > And use another PR to make improvements for it. If it is needed, we should > start with an email. > We need to have historical records. > > Penghui > > > On Thu, Aug 25, 2022 at 10:28 AM PengHui Li <peng...@apache.org> wrote: > >> 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. >>> >>
