Thanks all, but handling the migration of JIRA issues to Github is not really the topic of this discussion. Either use the other "[DISCUSS] [JIRA -> GitHub Issues] The way forward" thread where I had defined this as "d) Define and execute issue migration from JIRA to GitHub" or create a new thread. Thank you.
Any feedback about the 3 topics I mentioned in my initial email in this thread? J 2018-08-07 19:45 GMT+02:00 julio cesar sanchez <jcesarmob...@gmail.com>: > I wouldn't do 2, most people won't create a new issue, but that doesn't > mean the issue doesn't exist. > > Anyway, I think there is another thread about the migration, this is for > the templates. > > > El mar., 7 ago. 2018 a las 19:04, Chris Brody (<chris.br...@gmail.com>) > escribió: > >> Options I can think of: >> >> 1: make and use an auto-migration script >> 2: use quick filters to close issues in bulk with a message that the >> OP should manually raise on GitHub if so desired >> 3: continue with JIRA issues for a while >> >> I would vote for the easiest way possible to end use of JIRA issues >> (probably option 2). >> On Tue, Aug 7, 2018 at 12:59 PM gandhi rajan <gandhiraja...@gmail.com> >> wrote: >> > >> > Hi Jan, >> > >> > I like your suggestions. But curious to understand how to take care of >> > existing issues which are currently available in JIRA? Should it be >> ported >> > to respective git repos or will continue to remain as is till it's >> closed? >> > >> > On Tuesday, August 7, 2018, Jan Piotrowski <piotrow...@gmail.com> wrote: >> > >> > > Now that Github Issues are enabled on all repositories, it makes sense >> > > to create a (or several) new Issue and PR template(s) that doesn't >> > > point to JIRA any more and also uses the current state of the art. >> > > >> > > Current Cordova issue and PR template: >> > > - no issue template >> > > - https://github.com/apache/cordova-android/blob/master/. >> > > github/PULL_REQUEST_TEMPLATE.md >> > > >> > > >> > > 1. Issue template: >> > > >> > > Github supports multiple issue templates for some time now, which >> > > first lets users choose what type of issue they want to create: >> > > >> https://help.github.com/articles/about-issue-and-pull-request-templates/ >> > > >> > > The template selection can look like this: >> > > https://github.com/fastlane/fastlane/issues/new/choose >> > > https://github.com/babel/babel/issues/new/choose >> > > >> > > I think we should definitely use this for Bug Report, Feature Request, >> > > Support Question. What sections should we suggest in our templates? >> > > >> > > Here are some additinal issue templates from around the web: >> > > >> https://github.com/stevemao/github-issue-templates/tree/master/emoji-guide >> > > https://github.com/devspace/awesome-github-templates >> > > >> > > >> > > 2. Pull Request template: >> > > >> > > I think we can drop the JIRA/issue requirement from the checklist >> > > completely - as a PR on Github is always the starting point of code >> > > changes now. If there is an (Github) issue the PR resolves, it should >> > > of course be linked (`closes #123` or similar), but this is not a >> > > requirement. >> > > >> > > Similar about commit message conventions - I don't think we need an >> > > issue ID in there as all code changes will be done via PRs which via >> > > "squash + merge" will include PR ID in the commit message (again >> > > fastlane as an example: >> > > https://github.com/fastlane/fastlane/commits/master) >> > > >> > > I would suggest we use something similar to this, which explicitly >> > > asks for running the tests and writing documentation: >> > > https://github.com/fastlane/fastlane/blob/master/.github/ >> > > PULL_REQUEST_TEMPLATE.md >> > > >> > > What do you think regarding PR template? >> > > >> > > >> > > 3. Merge Conventions / Protected Branch: >> > > >> > > Connected to all that is my suggestion to protect the `master` branch >> > > so that by default nobody can commit there - all changes have to be >> > > made via Pull Requests. Pull Requests are by default merged via the >> > > "Squash + Merge" button / functionality so that all commits are >> > > squashed into one clean commit per change. This also enforces the >> > > commit message structure I posted above. (Of course committers can >> > > choose to _not_ use Squash + Merge if appropriate for the PR - e.g. >> > > when cherry picking commits from a release branch or similar). >> > > >> > > What do you think about this suggestion? >> > > >> > > >> > > Did I miss anything that is connected to these 3 topics? >> > > >> > > -J >> > > >> > > --------------------------------------------------------------------- >> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> > > For additional commands, e-mail: dev-h...@cordova.apache.org >> > > >> > > >> > >> > -- >> > Regards, >> > Gandhi >> > >> > "The best way to find urself is to lose urself in the service of others >> !!!" >> >> --------------------------------------------------------------------- >> 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
