> Thanks for working on this. I've been wondering about this for a while now.
>
> Is the expectation that a PR with proposed changes must already be created
> before a PIP is added to the Wiki? I've felt a little confused about this
> in the past when trying to start discussions or get feedback on potential
> features. It seems like most of the time, when someone proposes a PIP,
> they've already written the code in a PR and just want to get final
> thoughts from the community. My luck with doing that hasn't been as good,
> so I often prefer getting feedback before spending the time to write the
> code (so it's less likely to get scrapped), but I'm wondering what others
> think about that.
Thanks Devin, this is a good point. Since it is indeed confusing, I
guess we'll need to add specific wording in the text.
To summarize my opinion here:
* In general case, a PR should be created after the proposal was
discussed. This to spare the author from doing work that might need to
be changed after the discussion.
* I can see how it could beneficial to create a PR at the same time
of submitting a proposal
- Help to showcase larger code examples/APIs
- In case of smaller changes, it could speed up the turnaround to
have the PR merged.
In any case:
* A PR is *not* required when creating a proposal
* The PR should not be merged until the proposal is formally accepted
>
> --
> Devin G. Bost
>
> On Thu, Aug 19, 2021, 7:08 PM Hang Chen <chenh...@apache.org> wrote:
>
> > +1, This proposal looks good to me!
> >
> > Thanks,
> > Hang
> >
> > Matteo Merli <mme...@apache.org> 于2021年8月20日周五 上午3:50写道：
> >
> > > On Thu, Aug 19, 2021 at 6:29 AM Ivan Kelly <iv...@apache.org> wrote:
> > > >
> > > > > My two cents as a mere contributor who once wrote a PIP. I would love
> > > to
> > > > > see PIPs as a versioned document in git instead of the Wiki. This
> > would
> > > > > provide history and context, make it easy to comment and propose
> > fixes
> > > and
> > > > > enhancements which is currently not possible with the Wiki. The PMC
> > > would
> > > > > still have the possibility to accept or reject PIPs by merging or not
> > > to
> > > > > master with the usual and well-known PR review process.
> > > >
> > > > +1 on this. Wikis, despite being collaborative, often end up being
> > > > write-once-and-forget. If the PIP is a PR into the repo, it'll hang
> > > > around like a bad smell until accepted or rejected.
> > > >
> > > > -Ivan
> > >
> > > Ivan / Cristophe,
> > >
> > > I'm actually proposing to use GitHub issues instead of Wiki from now on.
> > >
> > > In my opinion, the problems with using Pull Requests for this scope are:
> > > * It blurs the line of what the approval and merging of the PR and
> > > the approval of the proposal, which I believe should still be done on
> > > the ML.
> > > * We shouldn't discard proposals that are rejected, instead it would
> > > be very good to keep them, and the context of the discussion that
> > > happened, for reference. (eg. a new proposal might come up with a
> > > different way to solve a problem that was already discussed).
> > >
> > > GitHub issues are not perfect, for example they lack the versioning of
> > > the content, but have some good parts:
> > > * Anyone can create issues (not only committers like it's the case for
> > > wiki)
> > > * We can attach labels to issues
> > > * Users can comment on the issues, so even people that are not on the
> > > dev@ list will be able to add their feedback
> > > * We can still keep an index of all the proposals in the Wiki
> > > (curated by committers group)
> > >
> > > It was also raised by Lari that if we allow edits to the issue
> > > description we need a way to ensure the vote is done on a specific
> > > version.
> > > For that, we could ask to paste the "final" markdown in the vote email
> > > thread.
> > >
> > > There might still be minor adjustments allowed after the vote (eg: to
> > > reflect correctly the reality of the implementation vs the initial
> > > design).
> > >
> > >
> > > Matteo
> > >
> > > --
> > > Matteo Merli
> > > <mme...@apache.org>
> > >
> >
