Hi Tison, > 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.
Here is the previous discussion https://lists.apache.org/thread/vw25onjyo18trfysd7x9k9wrs2tyqfok about this part. Without the request, approval steps for the PIP number. I didn't think of any other better way to help us manage the proposal number better. The proposal number should be solemn and not very casual. > I would suggest you collect the suggestions in this discussion thread Yes, I agree. This is exactly what I'm currently doing. Sorry, the PR https://github.com/apache/pulsar/pull/17270 introduced the confusion. Have this one just for that we are able to review detailed changes based on the old one. So I pushed the PR. Best, Penghui On Thu, Aug 25, 2022 at 2:22 PM PengHui Li <peng...@apache.org> wrote: > Hi all, > > I have pushed out a PR https://github.com/apache/pulsar/pull/17270 > which wants to copy the PIP and proposal template to the codebase. > > The PR doesn't want to make some changes to the proposal process > before we have approval. Since we will make some changes to the > current PIP process, I want to copy the old one to the codebase so that > all the subsequent updates will have historical records. > > Finally, the PIP process changes should be done with a new VOTE email. > With https://github.com/apache/pulsar/pull/17270, we can have a PR to show > all the details which can help the reviewer to easily review. > > Thanks, > Penghui > > > On Thu, Aug 25, 2022 at 12:57 PM tison <wander4...@gmail.com> wrote: > >> 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. >> > >>> >> > >> >> > >> >
