I think the web interface is a good idea. It might help triage as well if you're able to search and filter issues across the entire project. I think it might need to have some mechanism for excluding or grouping migrated issues too.
On Thu, Aug 3, 2017 at 5:55 AM, julio cesar sanchez <jcesarmob...@gmail.com> wrote: > What about security issues? > > El 3 ago. 2017 4:53 a. m., "Jan Piotrowski" <piotrow...@gmail.com> > escribió: > > > >> 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... > > > > Github doesn't offer this out of the box (besides watching all repos > > yourself, which comes with its own challenges). But Github has an API, > > I am pretty sure someone already wrote something that combines issues > > of several repos into one interface to look at, then links to the > > individual issues (If not, it wouldn't be too much work to create > > something like that) (Could become the new issues.cordova.io maybe?). > > Would this fulfill your use case? > > > > -J > > > > 2017-08-03 3:13 GMT+02:00 Filip Maj <maj....@gmail.com>: > > >> 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 > > > > >
