Matteo, 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. -- 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> > > >
