Agree with Francis's point: people are likely to move on than accumulating enough to have a larger PR to merge, which does not help improve Calcite's codebase. I understand it would increase the workload on Calcite committers (more PRs to review), so at least code reviewers can always encourage people to have a larger PR in the future, but not block existing LGTM ones.
- Rui On Wed, Sep 25, 2019 at 7:17 PM Haisheng Yuan <[email protected]> wrote: > > most of the time, the author of the fix would have moved on and have > forgotten about it, resulting in the improvement falling through the > cracks. > > Make sense. I think our current position worth reconsidering and I > agree with Francis. > > - Haisheng > > ------------------------------------------------------------------ > 发件人：Francis Chuang<[email protected]> > 日 期：2019年09月26日 09:20:49 > 收件人：<[email protected]> > 主 题：Re: [DISCUSS] Small contributions > > From personal experience, I think we should accept these small changes. > I have had lots of cases where I am reading code or documentation on > Github and found small errors or typos that are easy to fix, so I'd edit > directly in Github and open a PR. These changes do improve the codebase > and fix errors that could be misleading or confuse future maintainers > and users. > > It might be easy to say that we want to combine all these small changes > into a bigger change, but most of the time, the author of the fix would > have moved on and have forgotten about it, resulting in the improvement > falling through the cracks. It also makes the amount of effort required > to start contributing to the project a bit higher. > > With Github integration, trivial fixes like this should be easy to merge > with a click of a button and a quick glance at the diff on Github is > usually sufficient for review. > > I agree with Michael's suggestion that a JIRA should not be created for > cases like this. They are also low-hanging fruit to improve the > code-base and not accepting them seems like a missed opportunity to me. > > Francis > > On 26/09/2019 10:46 am, Michael Mior wrote: > > I have mixed feelings about this, because on one hand, I'd like to > > have these things corrected but on the other hand, we're already > > bogged down with PRs. Perhaps a good compromise is to make it clear > > that a JIRA should not be created and have some type of tag indicated > > in the title of the PR. This might be a good time to create a pull > > request template for GitHub that explains some of the policies (e.g. > > making sure that non-trivial changes DO have a JIRA case). > > -- > > Michael Mior > > [email protected] > > > > Le mer. 25 sept. 2019 à 20:42, Julian Hyde <[email protected]> a écrit : > >> > >> I noticed this exchange in https://github.com/apache/calcite/pull/1475: > <https://github.com/apache/calcite/pull/1475:> > >> > >> > >>> Q. Just curious, does Calcite accept hotfix style PR that fixes typos, > comments, etc.? > >> > >>> A. As long as they are large enough. But for 1 line typo fix, it is > not worth a specific patch, we prefer to accumulate them together. > >> > >> This is indeed our current position. And the reason we have given is > that it takes considerable effort to review and commit a pull request, even > a small one. > >> > >> Should we reconsider this position? > >> > >> Julian >
