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
