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.
