I was under the impression that JIRA was already locked down for everyone
but PMC members. But yesterday I received a comment on an old JIRA issue.
Under these circumstances, I see the benefits of bulk-closing all JIRA
issues.

Nevertheless, I would really like to

   1. have a two way link between corresponding GH and JIRA issues
   2. be able to distinguish between these issue types on JIRA
      1. Bulk-closed with appeal to re-file on GH
      2. Bulk-closed and re-filed on GH
      3. Bulk-closed and actually fixed after the fact

1. would require the users to include some recognizable string in the GH
issue, preferably as a link to the original issue. For example "Migrate
CB-XXXX".

2.1 can be achieved by labeling during bulk-close

2.2 depends on 1. working. We would then have to link to the GH issue from
the JIRA issue and update the labels there (would be nice if that was done
automatically).

For 2.3 I suggest we apply a suitable resolution to the bulk-closed JIRA
issues (could be "Migration Requested"). If the issue is actually fixed,
the resolution can be changed to "Fixed".
Again, automatically doing this for fixed GH-issues would be nice.

I know it's not realistic to keep JIRA entirely up-to-date. But we can at
least try.

Am Fr., 24. Aug. 2018 um 05:08 Uhr schrieb Bryan Ellis <
ellis.br...@gmail.com>:

> Auto-correction sorry!
>
> Anyways, I also agree with *Shazron's* point of view on this and will also
> > go with the consensus.
>
>
>
> On Fri, Aug 24, 2018 at 12:06 PM Bryan Ellis <ellis.br...@gmail.com>
> wrote:
>
> > Personally, I am also in favor for the issue bankruptcy.
> >
> >
> > I use the LIFO method more when deciding tickets; so looking at JIRA
> might
> > become less over time as GH issues grow.
> >
> >
> > I know that there can be relevant tickets, but someone will have to spend
> > time determining that.
> >
> >
> >
> >    -
> >
> >    Sort out tickets that are support vs actually issues/feature related
> >    to our tooling, platforms, plugins.
> >    -
> >
> >    Close out tickets that actually had PRs submitted and merged but not
> >    closed. Seen a few of these
> >    -
> >
> >    Test if a report is still valid, and I mean really sit down and try to
> >    reproduce.
> >    -
> >
> >    …
> >
> >
> > Anyways, I also agree with Sharon point of view on this and will also go
> > with the consensus.
> >
> >
> >
> >
> > On Fri, Aug 24, 2018 at 11:29 AM Shazron <shaz...@gmail.com> wrote:
> >
> >> I think we have to take a look at whether we actually *will* look at
> >> GH Issues *and* JIRA. This assumes that us, with limited time and
> >> resources will actually do it.
> >> I don't think I will, tbh. The issues are not lost, they are still in
> >> JIRA for reference when the user wants to take it up again.
> >>
> >> This is just declaring issue bankruptcy (a detached break, Cortés
> >> burning his ships) and requiring the user to re-file if still relevant
> >> (they get an email notification), and puts the onus on the user, for
> >> them to have a stake in issues they have so that they can get
> >> resolved. They must be part of this and care also, we can't babysit
> >> everything. We are a technically a volunteer operation here, I think
> >> it's too much for us to maintain two sources of issues. We already
> >> have a lot on our plate already, IMO.
> >>
> >> That being said, I will go with the consensus on this list (if we
> >> believe we have consensus), and I will bring it up again in a few
> >> months time to see where we are with JIRA, and I will do my best with
> >> bridging the two personally.
> >> On Thu, Aug 23, 2018 at 5:56 PM julio cesar sanchez
> >> <jcesarmob...@gmail.com> wrote:
> >> >
> >> > Realistically, if they created an issue more than 6 months ago and
> >> nobody
> >> > looked at it in that time, they wouldn't bother to recreate. So we
> would
> >> > lose ~1700 issues.
> >> >
> >> > I agree with Raphael, if options are bulk close and ask for migration
> or
> >> > keep them open, I vote for keeping them open.
> >> >
> >> > If somebody creates a new issue that is already in JIRA and we notice
> >> it,
> >> > we can close the JIRA one as duplicate of the github one. (it has
> >> already
> >> > happened in at least one issue that I have noticed)
> >> >
> >> > El jue., 23 ago. 2018 a las 11:42, Shazron (<shaz...@gmail.com>)
> >> escribió:
> >> >
> >> > > Back of the napkin calculation... if we took 5 mins (which is quite
> >> > > conservative) to migrate one by one, 1,811*5 = 9,055 minutes (or ~19
> >> > > days of 8 hours a day full time). That's about a month of work for
> one
> >> > > person (not including weekends), but realistically it will be
> greater
> >> > > than this of course, definitely a few months. (of course the work
> can
> >> > > be run in parallel with more people...)
> >> > > On Thu, Aug 23, 2018 at 5:34 PM Shazron <shaz...@gmail.com> wrote:
> >> > > >
> >> > > > Realistically doing it one by one will take a very long time, nor
> is
> >> > > > it necessary -- as a volunteer or if you were paid by your
> employer.
> >> > > > Some of these issues might be not relevant anymore. If it was
> >> > > > relevant, they can re-file in GH. I really don't want this to drag
> >> out
> >> > > > for another year.
> >> > > >
> >> > > > In my proposal - nothing will be moved, everything will be closed,
> >> > > > with a note to re-file in GH if relevant. There will be no
> >> "dangling"
> >> > > > issues - it's like what you've seen in some open sourced projects,
> >> > > > "Closing this stale issue. Re-open if still relevant" (but we say
> >> > > > re-file).
> >> > > > On Thu, Aug 23, 2018 at 5:19 PM julio cesar sanchez
> >> > > > <jcesarmob...@gmail.com> wrote:
> >> > > > >
> >> > > > > I wouldn't do a bulk close neither, I think we should migrate
> >> them one
> >> > > by
> >> > > > > one to the respective github repo, even using same JIRA id so
> they
> >> > > still
> >> > > > > get linked, and then manually close as duplicate of the new
> >> github one.
> >> > > > >
> >> > > > > It's going to be a lot of work, but we don't need to do it right
> >> away,
> >> > > we
> >> > > > > can start by the latest ones and migrate a few every day until
> we
> >> > > finish.
> >> > > > > Would be good to actually try to reproduce them before
> migrating,
> >> so we
> >> > > > > make sure it's still an issue, but as this will take even more
> >> time,
> >> > > > > wouldn't make it mandatory.
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > El jue., 23 ago. 2018 a las 11:06, Shazron (<shaz...@gmail.com
> >)
> >> > > escribió:
> >> > > > >
> >> > > > > > Thanks Jan - I will hold off until we are ready of course.
> >> > > > > >
> >> > > > > > Raphael - close as in there can not be any more comments added
> >> or
> >> > > > > > additions to the issue, not deletion. They will still exist
> and
> >> be
> >> > > > > > searchable. We definitely can add a label when we close them.
> >> > > > > > On Thu, Aug 23, 2018 at 5:01 PM Jan Piotrowski <
> >> piotrow...@gmail.com
> >> > > >
> >> > > > > > wrote:
> >> > > > > > >
> >> > > > > > > Just a note to make sure: Please do not proceed with this
> >> before
> >> > > issue
> >> > > > > > > and PR templates are in place, labels are unified etc -
> >> meaning:
> >> > > > > > > GitHub repos are ready.
> >> > > > > > > (Working on this right now)
> >> > > > > > > Am Do., 23. Aug. 2018 um 10:53 Uhr schrieb Shazron <
> >> > > shaz...@gmail.com>:
> >> > > > > > > >
> >> > > > > > > > I've done this for our JIRA:
> >> > > > > > > > - I've changed "Resolved" issues to "Closed" (about 8000+
> of
> >> > > them)
> >> > > > > > > > - I've changed issues with "No Component" to the relevant
> >> > > component
> >> > > > > > > >
> >> > > > > > > > What's left:
> >> > > > > > > > - We have 1881 Open, Reopened or In Progress issues
> >> > > > > > > >     - 474 were created in the last year (52 weeks)
> >> > > > > > > >         - thus 1,407 were created more than a year ago
> >> > > > > > > >     - 199 were created in the last 6 months (26 weeks)
> >> > > > > > > >
> >> > > > > > > > What's next:
> >> > > > > > > > 1. I can Bulk Resolve all issues with a comment so the
> >> reporters
> >> > > will
> >> > > > > > > > know where to re-file, with instructions, and point them
> to
> >> > > > > > > > issues.cordova.io [FAST]
> >> > > > > > > > OR
> >> > > > > > > > 2. I can Bulk Resolve issues by component, and point them
> >> to the
> >> > > right
> >> > > > > > > > GH repo to file the new issue [SLOW]
> >> > > > > > > >
> >> > > > > > > > Since this is a bulk operation, if we still need to keep
> >> some
> >> > > issues
> >> > > > > > > > open in JIRA, we need to tag with a label so I can skip
> >> those.
> >> > > > > > > >
> >> > > > > > > > On Wed, Aug 8, 2018 at 4:36 PM Jan Piotrowski <
> >> > > piotrow...@gmail.com>
> >> > > > > > wrote:
> >> > > > > > > > >
> >> > > > > > > > > > 1. Should we just disable those then? One other way is
> >> to
> >> > > add in
> >> > > > > > bold
> >> > > > > > > > > > big letters about the deprecation in the New Issue
> >> template
> >> > > > > > > > >
> >> > > > > > > > > We should probably "just" define our deprecation and
> >> archival
> >> > > policy
> >> > > > > > > > > (see other active thread). Depending on that, we can
> >> create
> >> > > another
> >> > > > > > > > > INFRA issue to get taken care of that. There is no flood
> >> of
> >> > > Github
> >> > > > > > > > > issues for these repos right now, so no harm done.
> >> > > > > > > > >
> >> > > > > > > > > > 2. These links are super useful. Perhaps they should
> be
> >> on
> >> > > the
> >> > > > > > > > > > website, what do you all think? Not sure if the
> >> scripting
> >> > > for the
> >> > > > > > > > > > second link is server side or it could be client side
> as
> >> > > well (via
> >> > > > > > > > > > JavaScript). Perhaps on the
> >> > > https://cordova.apache.org/contribute/
> >> > > > > > > > > > (contribute.cordova.io) page. That massive github
> link
> >> > > could also
> >> > > > > > be
> >> > > > > > > > > > auto-generated as well on that page, somehow. Let me
> >> know
> >> > > how I can
> >> > > > > > > > > > help.
> >> > > > > > > > >
> >> > > > > > > > > Yes, I think those could very well be on the Cordova web
> >> site
> >> > > as
> >> > > > > > well.
> >> > > > > > > > > http://cordova.betamo.de/ is built with PHP, I will put
> >> its
> >> > > source
> >> > > > > > up
> >> > > > > > > > > on Github later so someone can rebuild it with JS if
> >> > > needed/wanted.
> >> > > > > > > > > For now it is just a solution for us committers (and
> >> especially
> >> > > > > > > > > myself).
> >> > > > > > > > >
> >> > > > > > > > > -J
> >> > > > > > > > >
> >> > > > > > > > > 2018-08-08 5:34 GMT+02:00 Shazron <shaz...@gmail.com>:
> >> > > > > > > > > > Thanks Jan!
> >> > > > > > > > > >
> >> > > > > > > > > > 1. Should we just disable those then? One other way is
> >> to
> >> > > add in
> >> > > > > > bold
> >> > > > > > > > > > big letters about the deprecation in the New Issue
> >> template
> >> > > > > > > > > > 2. These links are super useful. Perhaps they should
> be
> >> on
> >> > > the
> >> > > > > > > > > > website, what do you all think? Not sure if the
> >> scripting
> >> > > for the
> >> > > > > > > > > > second link is server side or it could be client side
> as
> >> > > well (via
> >> > > > > > > > > > JavaScript). Perhaps on the
> >> > > https://cordova.apache.org/contribute/
> >> > > > > > > > > > (contribute.cordova.io) page. That massive github
> link
> >> > > could also
> >> > > > > > be
> >> > > > > > > > > > auto-generated as well on that page, somehow. Let me
> >> know
> >> > > how I can
> >> > > > > > > > > > help.
> >> > > > > > > > > > On Tue, Aug 7, 2018 at 11:01 PM Jan Piotrowski <
> >> > > > > > piotrow...@gmail.com> wrote:
> >> > > > > > > > > >>
> >> > > > > > > > > >> You may have noticed the first issues coming in on
> some
> >> > > > > > repositories.
> >> > > > > > > > > >>
> >> > > > > > > > > >> 1. In hindsight enabling issues for deprecated
> >> platforms,
> >> > > plugins
> >> > > > > > etc
> >> > > > > > > > > >> may not have been the smartest decision. We will have
> >> to
> >> > > find out
> >> > > > > > how
> >> > > > > > > > > >> to handle this - we should probably write down a
> >> > > "deprecation /
> >> > > > > > > > > >> archivation policy" anyway.
> >> > > > > > > > > >>
> >> > > > > > > > > >> 2. Some people are missing the "all tickets in one
> >> view"
> >> > > > > > interface. I
> >> > > > > > > > > >> quickly built http://cordova.betamo.de/ as a
> >> workaround.
> >> > > > > > > > > >> The second link on there generates a few prepared
> >> Github
> >> > > search
> >> > > > > > links,
> >> > > > > > > > > >> including one that is valid for _all_ Cordova
> >> repositories:
> >> > > > > > > > > >>
> >> > > > > >
> >> > >
> >>
> https://github.com/issues?q=type%3Aissue+repo%3Aapache%2Fcordova-android+repo%3Aapache%2Fcordova-ios+repo%3Aapache%2Fcordova-windows+repo%3Aapache%2Fcordova-browser+repo%3Aapache%2Fcordova-osx+repo%3Aapache%2Fcordova-test-platform+repo%3Aapache%2Fcordova-electron+repo%3Aapache%2Fcordova-blackberry+repo%3Aapache%2Fcordova-firefoxos+repo%3Aapache%2Fcordova-ubuntu+repo%3Aapache%2Fcordova-wp8+repo%3Aapache%2Fcordova-tizen+repo%3Aapache%2Fcordova-qt+repo%3Aapache%2Fcordova-webos+repo%3Aapache%2Fcordova-amazon-fireos+repo%3Aapache%2Fcordova-wp7+repo%3Aapache%2Fcordova-bada+repo%3Aapache%2Fcordova-bada-wac+repo%3Aapache%2Fcordova-plugin-battery-status+repo%3Aapache%2Fcordova-plugin-camera+repo%3Aapache%2Fcordova-plugin-device+repo%3Aapache%2Fcordova-plugin-dialogs+repo%3Aapache%2Fcordova-plugin-file+repo%3Aapache%2Fcordova-plugin-geolocation+repo%3Aapache%2Fcordova-plugin-inappbrowser+repo%3Aapache%2Fcordova-plugin-media+repo%3Aapache%2Fcordova-plugin-media-capture+repo%3Aapache%2Fcordova-plugin-network-information+repo%3Aapache%2Fcordova-plugin-screen-orientation+repo%3Aapache%2Fcordova-plugin-splashscreen+repo%3Aapache%2Fcordova-plugin-statusbar+repo%3Aapache%2Fcordova-plugin-vibration+repo%3Aapache%2Fcordova-plugin-whitelist+repo%3Aapache%2Fcordova-plugin-wkwebview-engine+repo%3Aapache%2Fcordova-plugins+repo%3Aapache%2Fcordova-plugin-console+repo%3Aapache%2Fcordova-plugin-contacts+repo%3Aapache%2Fcordova-plugin-device-motion+repo%3Aapache%2Fcordova-plugin-device-orientation+repo%3Aapache%2Fcordova-plugin-file-transfer+repo%3Aapache%2Fcordova-plugin-globalization+repo%3Aapache%2Fcordova-plugin-legacy-whitelist+repo%3Aapache%2Fcordova-cli+repo%3Aapache%2Fcordova-plugman+repo%3Aapache%2Fcordova-coho+repo%3Aapache%2Fcordova-js+repo%3Aapache%2Fcordova-lib+repo%3Aapache%2Fcordova-common+repo%3Aapache%2Fcordova-create+repo%3Aapache%2Fcordova-fetch+repo%3Aapache%2Fcordova-serve+repo%3Aapache%2Fcordova-plugin-test-framework+repo%3Aapache%2Fcordova-paramedic+repo%3Aapache%2Fcordova-mobile-spec+repo%3Aapache%2Fcordova-app-hello-world+repo%3Aapache%2Fcordova-template-reference+repo%3Aapache%2Fcordova-docs+repo%3Aapache%2Fcordova-status+repo%3Aapache%2Fcordova-discuss+repo%3Aapache%2Fcordova-apache-board-reports+repo%3Aapache%2Fcordova-new-committer-and-pmc+repo%3Aapache%2Fcordova-node-xcode+repo%3Aapache%2Fcordova-medic+repo%3Aapache%2Fcordova-labs+repo%3Aapache%2Fcordova-weinre+repo%3Aapache%2Fcordova-app-harness+repo%3Aapache%2Fcordova-plugin-compat+repo%3Aapache%2Fcordova-registry-web+repo%3Aapache%2Fcordova-registry+repo%3Aapache%2Fcordova-fauxton-server&s=created&type=Issues
> >> > > > > > > > > >> Nice, isn't it?
> >> > > > > > > > > >> Do you have any specific requests for filters or
> >> interface
> >> > > you
> >> > > > > > need or
> >> > > > > > > > > >> want? What did you use in JIRA that you couldn't find
> >> for
> >> > > Github?
> >> > > > > > > > > >> Shouldn't be too hard to whip something up.
> >> > > > > > > > > >>
> >> > > > > > > > > >> -J
> >> > > > > > > > > >>
> >> > > > > > > > > >>
> >> > > > > > > > > >>
> >> > > > > > > > > >>
> >> > > > > > > > > >> 2018-08-06 16:05 GMT+02:00 Jan Piotrowski <
> >> > > piotrow...@gmail.com>:
> >> > > > > > > > > >> > That worked, the ticket was just resolved and
> issues
> >> are
> >> > > now
> >> > > > > > enabled
> >> > > > > > > > > >> > for all repos (beside cordova-weinre which is
> >> archived):
> >> > > > > > > > > >> >
> >> > > > > > > > > >> > https://github.com/apache/cordova-android/issues
> >> > > > > > > > > >> > https://github.com/apache/cordova-ios/issues
> >> > > > > > > > > >> >
> >> > > https://github.com/apache/cordova-plugin-inappbrowser/issues
> >> > > > > > > > > >> > ...
> >> > > > > > > > > >> >
> >> > > > > > > > > >> > On to b), c) etc.
> >> > > > > > > > > >> >
> >> > > > > > > > > >> > 2018-08-06 13:09 GMT+02:00 Chris Brody <
> >> > > chris.br...@gmail.com>:
> >> > > > > > > > > >> >> On Mon, Aug 6, 2018 at 6:48 AM Jan Piotrowski <
> >> > > > > > piotrow...@gmail.com> wrote:
> >> > > > > > > > > >> >>>
> >> > > > > > > > > >> >>> Created INFRA issue at
> >> > > > > > https://issues.apache.org/jira/browse/INFRA-16876
> >> > > > > > > > > >> >>
> >> > > > > > > > > >> >> +100
> >> > > > > > > > > >> >>
> >> > > > > > > > > >> >>
> >> > > > > >
> >> ---------------------------------------------------------------------
> >> > > > > > > > > >> >> 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
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > > >
> >> > >
> ---------------------------------------------------------------------
> >> > > > > > > > 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
> >> > >
> >> > >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> For additional commands, e-mail: dev-h...@cordova.apache.org
> >>
> >>
>

Reply via email to