[
https://issues.apache.org/jira/browse/CB-12670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15976962#comment-15976962
]
Kerri Shotts edited comment on CB-12670 at 4/20/17 4:01 PM:
------------------------------------------------------------
So, a few things:
# Wow; those timings are atrocious. Here in the USA, with caches disabled, I
come in at just under 3 seconds, and most of the times, it's around 2s. That
depends on which page I'm using, of course, but I typically am using the Issues
list and associated pages and the Agile boards. Because we are but a tenant in
a larger JIRA instance, there's little we can do about the instance itself. One
could file an INFRA ticket, I guess, but I'm not sure that they can do much
since there can be so much variability between ISPs and such.
# Those items in the header do relate to Cordova for those of us who manage and
work on fixing bugs. I use those menus quite often (except for service desk).
Users who need to search for bugs should probably use the Search box (although
they may need to eliminate projects other than Cordova). There is an option in
JIRA to create issue collectors, but not sure how much use that would be since
users would still need to search for issues in the first place. It might not
hurt to add additional documentation to the Cordova website on how best to
search for issues, either.
# There was a time when versions were unambiguous because everything was
synced. When component versions were desynced that's when the version numbers
became a bit... messy. Ideally, I guess, version numbers would include the
component (a bit like platforms are doing, e.g., cordova-ios@4.3.1), but all of
this assumes that reporters would actually use it (most reporters are going to
expect a version of the form X.Y.Z, not component@X.Y.Z). Regardless, not my
call to make. I don't see any way to change what JIRA displays on the pages you
mentioned, though, so although the categories may not be terribly useful, I
don't see a way to change the display either. Side note: You can create your
own dashboard to see what is important to you, which I've done. New users
aren't apt to do that, granted, so it's of little benefit to them.
Ultimately, I'm with you: I'd much prefer GitHub issues. We'd have more control
and, I think, more engagement. But thus far that has proved elusive, and so we
can only do with what we have. If there were more time and volunteers, some
things could be cleaned up, but I think we would need more people to commit to
that. Most of us are fighting other fires elsewhere.
(Oh, and honestly: thank you for taking the time to report your findings. If
you have more suggestions, please add them; even if we can't do anything about
them, at least we have something to point to that says "these are pain points
for our users" and work to ease the pain where we can.)
was (Author: kerrishotts):
So, a few things:
# Wow; those timings are atrocious. Here in the USA, with caches disabled, I
come in at just under 3 seconds, and most of the times, it's around 2s. That
depends on which page I'm using, of course, but I typically am using the Issues
list and associated pages and the Agile boards. Because we are but a tenant in
a larger JIRA instance, there's little we can do about the instance itself. One
could file an INFRA ticket, I guess, but I'm not sure that they can do much
since there can be so much variability between ISPs and such.
# Those items in the header do relate to Cordova for those of us who manage and
work on fixing bugs. I use those menus quite often (except for service desk).
Users who need to search for bugs should probably use the Search box (although
they may need to eliminate projects other than Cordova). There is an option in
JIRA to create issue collectors, but not sure how much use that would be since
users would still need to search for issues in the first place. It might not
hurt to add additional documentation to the Cordova website on how best to
search for issues, either.
# There was a time when versions were unambiguous because everything was
synced. When component versions were desynced that's when the version numbers
became a bit... messy. Ideally, I guess, version numbers would include the
component (a bit like platforms are doing, e.g., cordova-ios@4.3.1), but all of
this assumes that reporters would actually use it (most reporters are going to
expect a version of the form X.Y.Z, not component@X.Y.Z). Regardless, not my
call to make. I don't see any way to change what JIRA displays on the pages you
mentioned, though, so although the categories may not be terribly useful, I
don't see a way to change the display either. Side note: You can create your
own dashboard to see what is important to you, which I've done. New users
aren't apt to do that, granted, so it's of little benefit to them.
Ultimately, I'm with you: I'd much prefer GitHub issues. We'd have more control
and, I think, more engagement. But thus far that has proved elusive, and so we
can only do with what we have. If there were more time and volunteers, some
things could be cleaned up, but I think we would need more people to commit to
that. Most of us are fighting other fires elsewhere.
(Oh, and honestly: thank you for taking the time to report your findings. If
you have more suggestions, please add them; even if we can't do anything about
them, at least we have something to point to that says "these are pain points
for our users" and work to ease the pain where we can.)
> Clean up Apache Cordova JIRA
> ----------------------------
>
> Key: CB-12670
> URL: https://issues.apache.org/jira/browse/CB-12670
> Project: Apache Cordova
> Issue Type: Wish
> Components: AllComponents
> Reporter: Jan Piotrowski
> Priority: Minor
> Labels: jira
>
> or: Make Apache Cordova JIRA usable again!
> I was complaining about the Cordova JIRA on Slack today, wondering how great
> the world would be if Cordova used GitHub issues. Then I noticed that this
> was not very productive as it seems there is no way to achieve this.
> So I actually looked at the Cordova JIRA a bit and tried to find ways how it
> could actually be improved:
> *Speed*
> - Why is everything so slow? Any way to speed it up?
> *Menu: Summary*
> https://issues.apache.org/jira/browse/CB/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel
> - Remove or update versions if not used
> *Menu: Issues*
> https://issues.apache.org/jira/browse/CB/?selectedItem=com.atlassian.jirafisheyeplugin:fisheye-projectpanel&mode=statistics&selectedTab=com.atlassian.jira.jira-projects-plugin:issues-panel
> - Declutter "Unresolved: By Assignee" by unassigning Issues with no updates
> in last 6 months
> - "Unresolved: By Version" is pretty useless because of plugin versions
> (1.4.0 of what?)
> *Menu: Roadmap*
> https://issues.apache.org/jira/browse/CB/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel
> https://issues.apache.org/jira/browse
> Menu: Changelogs
> /CB/?selectedTab=com.atlassian.jira.jira-projects-plugin:changelog-panel
> - Remove or update versions
> - If versions, roadmap or changelogs are not used, remove menu link
> completely (Same for Component overview pages)
> *Menu: Versions*
> https://issues.apache.org/jira/browse/CB?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel&subset=-1
> - Sorting?
> - Missing descriptions
> - Missing release dates for so many versions
> - Unclear names
> *Menu: Components*
> https://issues.apache.org/jira/browse/CB/?selectedTab=com.atlassian.jira.jira-projects-plugin:components-panel&subset=-1
> - Missing descriptions
> *Header*
> - Why all this unrelevant (to Cordova) stuff?
> - Getting from an issue to the Project summary is... "easy" but unexpected if
> you don't know yet.
> Any way to help?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
