> On Aug 23, 2022, at 10:22 AM, Rajan Dhabalia <dhabalia...@gmail.com> wrote: > > Hi, > >>>> I think we can move all the PIPs to the codebase and the new proposal > and proposal without any reviews should happen with a PR first. So that we > can review and comment easily. > > I didn't understand this part. You want one to create a PR before > submitting a proposal? That's clearly not a good idea because if the PIP > approach will change then the entire development effort will be wasted and > that's the whole purpose of PIP. I guess creating PIP into an issue and > discussing the issue is definitely working and it's an easier way to > discuss quickly rather than discussing over email threads. > > Let's not change this practice without good discussion and agreement from > the community.
Agreed let’s have a PIP Discussion here to carefully outline how the PIP process will change. I don’t think that a new PIP should be overly planned or implemented before the idea is more fully discussed and accepted. The Apache Way always works best with small incremental and reversible steps. Let’s outline how PIPs are currently working and then discuss changes. I’m not sure what is meant by putting the PIP into the “codebase”. Is the proposal to create PIPs here? https://github.com/apache/pulsar/tree/master/wiki I think that a directory structure / convention could be used for pip status: 1. /wiki/pip/discussion - for PIPs being discussed and specified. 2. /wiki/pip/proposed - for PIPs ready to be formally DISCUSSED and VOTED 3. /wiki/pip/accepted - for PIPs that have been accepted and are works in progress 4. /wiki/pip/complete - for PIPs that have been completed. 5. /wiki/pip/rejected - for PIPs that were proposed, but then rejected or abandoned. Regards, Dave > > Thanks, > Rajan > > On Thu, Aug 18, 2022 at 8:27 AM PengHui Li <peng...@apache.org> wrote: > >> Hi all, >> >> Currently, the new proposal will be added to the issue list and then shared >> link in the email >> to request the proposal review. It's really hard to review a long proposal >> if you want to comment >> in detail. >> >> Here is an example: >> https://github.com/apache/pulsar/issues/16763#issuecomment-1219606491 >> This seems very unintuitive. >> >> I think we can move all the PIPs to the codebase and the new proposal and >> proposal without >> any reviews should happen with a PR first. So that we can review and >> comment easily. >> Certainly, all the votes should happen on the mailing list. And we can also >> discuss the >> proposal on the mailing list. >> >> Following this way, we don't need to sync the PIPs from the issue to the >> wiki page. >> We can just add a link that points to the PIPs dir to the contribution >> guide or README. >> >> We have another pain point about the duplicated PIP number. We can maintain >> a file, a list of >> all the proposal contains the approved, in-review, drafting. Before >> creating a proposal, we should >> have a discussion first on the mailing list, just get feedback on the >> motivation. If there are no objections, >> the proposal owner can add a line to the file with the PIP number through a >> PR, like PIP-123: xxx (Under Discussion). >> So that we can prevent the duplicated PIP number(which will conflict if >> someone merged first). >> After the PR is merged, we can send out a new PR to add the proposal. >> >> Thanks, >> Penghui >>
