Hi Penghui, > IMO, the final status of the proposal should be summarized in the proposal.
Agree. It's not exclusive. What I propose is that if you want to track proposals in a project, track issues. But it seems your opinion is not to do so. Then it's a nonissue. Flink FLIP tracks proposal status with the proposal content and it works well. Although, I'd still highlight that maintainer efforts are required to maintain the metadata. > 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? I don't propose to track the status _within_ the issue. But if you want to track in a project, only committer have the privilege :) > if the discussion of the motivation doesn't have objections and is discussed enough. This is quite vague and hard to follow. Rust RFCs have a nonmandatory pre-RFC stage. I think we can encourage the proposer to discuss on the mailing list or any channel with committers first. But any proposer can take their proposal number once proposed and a committer clicks the merge button. Still, I'm concerned about adding such a step to exclusively allocate a proposal number. I would suggest you collect the suggestions in this discussion thread, and propose a process as shown in * https://github.com/rust-lang/rfcs#readme * https://github.com/pingcap/tidb/tree/master/docs/design#readme So that we can have a vote. Instead of rushing into making several PRs to move content fragmentedly. Best, tison. PengHui Li <peng...@apache.org> 于2022年8月25日周四 10:59写道： > 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. > >>> > >> >
