I thought about a label, but I think it's probably more productive to just review the change immediately if it really is something trivial. The problem is that labels can only be applied by committers. That's why I suggested asking those who submit PRs to include something in the PR title. If others think a label would help though, I'm not opposed to it. -- Michael Mior [email protected]
Le jeu. 26 sept. 2019 à 07:28, TANG Wen-hui <[email protected]> a écrit : > > I agree that we should accept these small changes but not create JIRA for > them. > In my opinion, maybe we can label the PR of these small changes. And process > them at regular intervals in case of forgetting. > > best, > -- > wenhui > > > > [email protected] > > From: Haisheng Yuan > Date: 2019-09-26 10:17 > To: Francis Chuang; [email protected] ([email protected]) > Subject: Re: Re: [DISCUSS] Small contributions > > 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
