> 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?
Possibly. I think we will still have JIRA around w/ deprecated components, maybe? I'm not sure. Shaz? > 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? To create new repos, we will have to go through Infra anyways. Experimental code in cordova has gone into branches in the cordova-labs repo in the past. > Is there going to be a default repository to hold them before they're > triaged and organized? Oh I think I see what you mean now. As in, what do we do with JIRA issues without an assigned component that does maps to one of the new GH repos, what do we do with those? That's a good question. Perhaps that points to us doing a big JIRA issue cleanup before we undergo a migration. FWIW I did a couple weeks back already and am fairly confident most relevant issues have an assigned component. On Wed, Aug 2, 2017 at 6:51 PM, Connor Pearson <cjp...@gmail.com> wrote: >>> 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
