A few points. I don’t like the term “hot fix”. A hot fix has an existing meaning[1] - it is a patch you apply to your binaries. Let’s not use that term.
Let’s define “small contributions” as contributions that do not modify code and therefore will not break anything, do not need a test or documentation change, and do not need a CI run. I am in favor of accepting small contributions. I wasn’t previously. We can have guidelines about how to label these small contributions (e.g. git labels, certain words in the commit message or PR description). But we shouldn’t expect or require contributors to follow those guidelines. By their nature, these contributors have not had time to read all of our policy documents. Reviewers must know what our policy is, and should massage commit messages tot conform to policy. These kinds of changes are, by definition, very small and simple. A committer can review, approve, fix up, and push to master, and close the PR in one go. Five minutes. If the PR requires a back-and-forth then it is not a “simple” change. We should not require a JIRA case. We not apply the usual policy of appending the contributor’s name to the commit message. A typical commit message would be “Fix a comment”. Release manager should remove these kinds of trivial changes from the release notes. They add nothing to the release notes. These kinds of changes do earn “merit” - the basis on which we make people committers - but they earn less merit than a bug fix, a new feature, a detailed response to a question on the dev list, or a conference talk. I don’t want people to believe that they can earn committership by fixing 100 typos. There can be problems if a community over-relies on small PRs. In particular, there is a project in the Incubator that has only one or two regular developers but receives hundreds of contributions a few lines long via PRs. The discussion occurs in the PRs, and contributors rarely make more than 1 or 2 contributions. The problem for the project is that there is no emergent “community”. This is a serious problem for that project, and obviously we do not have that problem. Still, there is a side effect to the back-and-forth discussion to get a change accepted, namely that the individuals get to know each other. We don’t want to lose that. Julian [1] https://en.wikipedia.org/wiki/Hotfix <https://en.wikipedia.org/wiki/Hotfix> > On Sep 26, 2019, at 5:17 AM, Michael Mior <[email protected]> wrote: > > 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
