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 > >
