>> Since it looks like not all repositories will be migrated where should their issues go? > All repositories will be migrated.
The one I was thinking of was cordova-plugins. Do we want some way to track issues for inactive platforms too or should those be considered permanently closed? >> What about issues for repositories that don’t yet exist > Can you give me an example? For example a new platform or core plugin is created. I'd assume we could create an empty repository, but I'm not sure what the overhead of requesting a new repo is. Experimental plugins or research might fall into this category as well. I guess the more general question is are there any Jira tasks we use that aren't tied to a repo and if so where should track them in Github? >> If we migrate before triaging where will all the un-triaged issues end up? > They would end up in GitHub, at which point we'd triage them within GitHub. Is there going to be a default repository to hold them before they're triaged and organized? On a slightly different note, I'm looking forward to the new PR process. It always felt a little strange in the past. On Wed, Aug 2, 2017 at 9:13 PM, Filip Maj <maj....@gmail.com> wrote: > > Since it looks like not all repositories will be migrated where should > their issues go? > > All repositories will be migrated. > > > What about issues for repositories that don’t yet exist > > Can you give me an example? > > > or cross-cutting issues? > > I think if you absolutely need issues related to multiple repos, you > can always create multiple issues in all relevant repos and > cross-reference them. > > > As a user, I’ll occasionally skim the recently opened bugs in Jira > across the entire project to see if any may affect us. Is there going to be > a way to do this with Github? Subscribing to notifications could be a > work-around but it’s not ideal. > > Good question. I can't really think of a way to do this... > > > Are we going to get more high quality bug reports using Github? This may > not be answerable without trying it out, but making issues easier to create > issues could cause an influx of questions and non-cordova related bugs. > This could add on to the difficulties of triaging and migrating bugs across > repos. > > To be fair, we already get painful triage-work via GitHub just by > opening up Pull Requests to the public. People will use those to post > questions or issues, because they are unaware that there are other > support and issue filing avenues (they will mask them as PRs merging a > release branch into master). At least those people now have a more > obvious place to file issues: the Issues section on GitHub. We already > have a lot of triage work on JIRA as it is. I doubt this will go down. > That said, I don't think that's necessarily bad. Will we have more > work? Probably. Will we be able to more easily identify issues, and > earlier, and generally be also more accessible to our community? I > would think yes. Double-edged sword. I say let's see how it goes. > > > If we migrate before triaging where will all the un-triaged issues end > up? > > They would end up in GitHub, at which point we'd triage them within GitHub. > > > Also if we enable Github issues before phase 2 are we going to be using > both Jira and Github Issues for a period of time? > > Yes. > > Different topic: Shaz, based on your INFRA ticket / phase breakdown, > the implication is that there will be leftover cordova repos in Apache > Git (cordova-medic, weinre, deprecated platforms / plugins). What do > we do with those? Separate discussion? > > On Wed, Aug 2, 2017 at 5:32 PM, Connor Pearson <cjp...@gmail.com> wrote: > > I have a few questions about moving issues to GitHub. I haven’t used > Github > > issues much so these all may be easily solvable. > > > > * Since it looks like not all repositories will be migrated where should > > their issues go? What about issues for repositories that don’t yet exist > or > > cross-cutting issues? > > * As a user, I’ll occasionally skim the recently opened bugs in Jira > across > > the entire project to see if any may affect us. Is there going to be a > way > > to do this with Github? Subscribing to notifications could be a > work-around > > but it’s not ideal. > > * Are we going to get more high quality bug reports using Github? This > may > > not be answerable without trying it out, but making issues easier to > create > > issues could cause an influx of questions and non-cordova related bugs. > > This could add on to the difficulties of triaging and migrating bugs > across > > repos. > > * If we migrate before triaging where will all the un-triaged issues end > > up? Also if we enable Github issues before phase 2 are we going to be > using > > both Jira and Github Issues for a period of time? > > > > -Connor > > > > > > On August 2, 2017 at 7:08:18 PM, Jan Piotrowski (piotrow...@gmail.com) > > wrote: > > > > If people post their issue at the wrong repo (which of course can and > > will happen from time to time), there is a way to move them over with > > minimal loss of information: > > > > https://github.com/ionic-team/ionic/issues/12542 > > https://github.com/ionic-team/ionic-cli/issues/2597 > > > > This works for issues where several people replied already in the > > exact same way: > > > > https://github.com/ionic-team/ionic/issues/11898 > > https://github.com/ionic-team/ionic-cli/issues/2386 > > > > As the original poster of the issue and each reply is @-mentioned they > > are notified about the "new" issue and can continue participating. > > Replying users also can just include the @username in their new > > replies again to make sure people get notified. > > > > -J > > > > > > > > 2017-08-02 21:53 GMT+02:00 Filip Maj <maj....@gmail.com>: > >> I think the ease of use of GitHub issues overcomes potential problems > >> about cross-referencing issues. Worth noting on this topic that GitHub > >> already provides good support for referencing pull requests from > >> issues across repos / orgs. > >> > >> The benefit of having issues and PRs in one place, to me, is a benefit > >> too tasty to pass up. > >> > >> Darryl, do you have examples of issues that you think could be > >> problematic in a GitHub-based world? > >> > >> On Wed, Aug 2, 2017 at 12:43 PM, Darryl Pogue <dar...@dpogue.ca> wrote: > >>> My concern with GitHub issues is that we have a tonne of repos and > > issues > >>> can easily span across them, and we'd lose the one central place for > > issue > >>> tracking and triage. I worry that we'd be inundated with issues on the > >>> wrong repos, or without additional information, and triaging would > > become > >>> an insurmountable chore leading to a worse backlog than we already have > > in > >>> JIRA. > >>> > >>> On 2 August 2017 at 12:38, Shazron <shaz...@apache.org> wrote: > >>> > >>>> Phase 1 of our move to Github is complete, see: > >>>> https://issues.apache.org/jira/browse/INFRA-14347 > >>>> > >>>> We need a migration plan for moving JIRA issues to Github Issues > before > > we > >>>> enable Github Issues on those repos. > >>>> > >>>> Once we figure those out, we can proceed with Phase 2: > >>>> https://issues.apache.org/jira/browse/INFRA-14398 > >>>> > >>>> I'll start it off by saying that ideally we: > >>>> 1. Triage issues > >>>> 2. Automate migration of existing open issues to Github issues > >>>> 3. "Close off" the JIRA issues > >>>> > >>>> The impact of this is, the original reporters will not get notified of > >>>> further updates to the issue except for a link to the new issue on > > Github > >>>> as a JIRA comment (since they will not be subscribed to the Github > > issue). > >>>> > >>>> We could also migrate every open issue first, then triage later in > > Github, > >>>> as well. > >>>> > >> > >> --------------------------------------------------------------------- > >> 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 > >
