Agree with all 3 points by Jan. @Chris Brody I think we should make use of Github Milestones to track related issues. On Wed, Aug 8, 2018 at 6:59 AM Jan Piotrowski <piotrow...@gmail.com> wrote: > > Update to my initial email: > > I just noticed we actually _do_ have an issue template in use in the > cordovs-docs repository: > https://github.com/apache/cordova-docs/blob/master/.github/ISSUE_TEMPLATE.md > > J > > 2018-08-07 23:18 GMT+02:00 julio cesar sanchez <jcesarmob...@gmail.com>: > > I think us as committers should decide if the commits make sense to keep > > all of them or squash them into one. But bug fixes should usually be only > > one commit, and major refactors are not usually sent by non committers > > > > El El mar, 7 ago 2018 a las 23:02, Chris Brody <chris.br...@gmail.com> > > escribió: > > > >> > > I would favor a place where a contributor can mark if s/he would > >> > > recommend the committer should *not* use the squash option. > >> > > >> > That of course could be defined in the contributor guidelines or PR > >> > template (although there it might be a bit confusing to new users that > >> > don't know what this is talking about). Do you know how other project > >> > handle that? > >> > >> Haven't seen anything like this before. > >> > >> > In the end it is always the decision of the committer how contributed > >> > code makes it into the code base, so having good guidelines for us > >> > would probably be the best solution, right? > >> > >> Yes. General common sense may prove to be the major principle, as I > >> think it has in the past. For example: > >> * Someone raises a PR with bug fixes and major refactoring in separate > >> commits (should not be squashed) > >> * Someone else raises a PR with a single fix, but with extra commits > >> to fix issues with the first commit (*should* be squashed) > >> > >> I wonder if we can track these discussions in a better way, somehow. I > >> have no time to help with these things right now. I think better > >> tracking could help ensure these important tasks do not get forgotten. > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > >> For additional commands, e-mail: dev-h...@cordova.apache.org > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org >
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
