Recently I started to notice that we somehow have resolved more tickets than we've created. Since it seems paradoxical I can only come to two conclusions:
There is a bug in JIRA.
I don't understand what it is actually graphing.
…or both, I suppose. Here is a screenshot of a graph from this morning:
(The filter that is being graphed is a custom filter. I don't know if that's relevant.)
Is there an explanation for this beyond just "lol JIRA"?
This chart shows that your project has
71 issues that are unresolved and have a creation date within the given time period
79 issues that are resolved and have a resolved date within the given time period
It tells you that your stock of unresolved Issues has decreased by 8 between 22 Mar and 1 Apr.
Non-cumulative would show you a non-zero value only for the days where at least one issue has been created (red) or resolved (green).
From my point-of-view nothing to worry about. Projects mostly start with more issues created than resolved and work themselves into a good balance. Having resolved more than being created just means you have fixed several open issues and either not found new errors while testing or have not tested at all.
Related
I wanna display the time spent per issue in a specific timeframe. Creating a rich filter that shows time spent is very straight forward, however, selecting the right timeframe is tricky.
Possibility #1:
resolved > -12w
That selects issues resolved within the last quarter, but then all time is displayed, even when the issue is is much older and a lot of time has been booked more than 12 weeks ago.
Possibility #2:
created > -12w
That selects issues created within the last quarter, and automatically excludes issues that are still being worked on but are older
Possibility #3
created > -12w and resolved < -4w
That selects issues created and resolved and disregards issues going between timeframe boundaries.
Possibility #4
worklogdate > -12w and worklogdate < -4w
That would select only issues with correct worklog dates, i.e., issues that REALLY have been worked on in that timeframe, but when I then analyze worklogtime or time spent, that is still all the time worked on the issue, not just the time within the specified timeframe.
Any idea how I could achieve showing the time spent per issue of a very specific timeframe?
In JIRA has three fields (https://jira.atlassian.com/browse/TRANS-1861?jql=)
1. Created
2. Updated
3. Resolved
We can calculate bug fixing time in two ways
1. Bug fixing time= Resolved -Created
2. Bug fixing time=Updated-Created
After fixing the bug, fixing code is tested by tester. If the tester pass the fixing then the bug is closed. Otherwise, developers modify the code and try to fix again. In that case, there is a gap between resolved and closed date. The problem of updated field is the field updated every time someone work on the bug report.
So, I need to know how long time takes a developer to fix a particular bug. If I calculate by this equation (Bug fixing time= Resolved -Created) is it OK?
There are many ways to calculate the bug fixing time, it depends on what are you trying to do and your process. Here are some consideration:
When the bug is reported, when/how do you triage it? Not every bug
reported is a real bug, there are cases where it is work as
designed, training issue or simply enhancement request.
When the bug is assigned, when does the developer start working on
it. Does your developer change the status from New to Working when
they start working on it?
Once the bug fixes is done, how does it being tested? If the test
pass, will the status be changed to Ready?
Once the bug fixes is deployed and validated on production, does the
issue status change to Closed?
To look at the detail of the status changes, you can use the expand=changelog parameter via the REST API and iterate thru the changes to calculate the time in each state. Here is an example:
https://jira.atlassian.com/rest/api/2/issue/TRANS-1861?expand=changelog
I have been developing an iOS app that utilizes the CloudKit feature available for Apple Developers. I've found it to be a wonderful resource, especially since the very day I started designing my backend, the service I was intending to use (Parse) announced it was shutting down. It's very appealing due to it's small learning curve, but I'm starting to notice some annoying little issues here and there so I'm seeking out some experts for advice and help. I posted another CloudKit question a couple days ago, which is still occurring: CloudKit Delete Self Option Not Working. But I want to limit this to a different issue that may be related.
Problem ~ Ever since I started using CloudKit I have noticed that whenever I manually try to edit (delete an entry, remove or add part of a list, even add a DeleteSelf option to a CKReference after creation), and then try to save the change, I get an error message and cannot proceed. Here is a screenshot of the error window that appears:
It's frustrating because anytime I want to manipulate a record to perform some sort of test, I either have to go do it through my app, or just delete the record entirely and create a new one (that I am able to do without issue). I have been just working around this issue for over a month now because it wasn't fatal to my progress. However, I am starting to think that this could be related to my other CloudKit issues, and maybe if I could get some advice on how to fix it I could also solve my other problems. I have file numerous bug reports with Apple, but haven't received a response or seen any changes.
I'd also like to mention that for a very long time now (at least a few days), I've noticed down in the bottom left hand corner of my Dashboard that it is consistently saying that it's "Reindexing Development Data". I remember at first that wasn't an issue, I would get that notification after making a change but it'd go away after the operation is complete. Now it seems to be stuck somewhere inside the process. And this is a chronic issue, it's saying this all the time, even right when I log into my dashboard.
Here is what I'm talking about:
As time goes on I find more small issues with CloudKit, I'm concerned that once I go into production more problems could start manifesting and then I could have a serious issue. I'd love to stick with CloudKit and avoid the learning curve of a different service like Amazon Web Services, but I also don't want to set myself up for failure.
Can anyone help me with this issue, or has anyone else experienced it on a regular basis? Thanks for the advice and help!
Pierce,
I found myself in a similar situation; the issue seemed to be linked to Assets; I had an Asset in my record definition. I and several other I noted reported the re-indexing issue on the apple support website and after about a month it eventually disappeared.
Have you tried resting your database schema completely, snapshot the definition; since you zap it completely and than reset, see inset.
Ultimately I simply created a new project, linked it to cloud kit and use the new container in my original app.
JIRA's time spent calculation seems to be adding quite a few hours to actual time spent.
If I add up the columns I get a much different result than when JIRA adds up the columns.
My question: How does JIRA arrive at this amount of time tpent in the default time tracking report?
Edit: Maybe a JIRA "day" is 8 hours? That seems silly to me...
It turns out that by default 1d is not a real day, but it's a Jira day, which is 8 hours apparently.
1 day is one working day, of course. This is an issue tracking and project planning system what else could "a day"?
Also this is configurable in JIRA...
This has been asked a lot, but I'm still facing some issues with it.
I have date I receive and was storing as Date. I need to query on Greater Than and Less than, so I changed it to Time, tried it again, but I'm getting weird results.
I'm doing this
Class.where(:event_date.gt => Time.parse(Date.today))
and I'm getting old records, 1940s, 1960s and others. I tried converting time by adding .utc at the end, comparing against Date.today only, but nothing sovled the problem so far. This is the selector being generated by Mongoid
selector: {:date_utc=>{"$gte"=>Sat Sep 10 21:00:00 UTC 2011}},
I receive the date in this format "2011-09-11" and store it in the Time field. Tried parsing that as Time utc as well, no luck.
Any idea? I'm using Mongoid 2.0.2. Later versions seem incompatible with other extensions I'm using.
[UPDATE]
So the problem is with the old dates before 1970 apparently. How do I deal with them is the question now.
This is a known bug in Mongo. See ISSUE 405
The reason is that Mongo uses an unsigned number to store dates, so anything before the epoch rolls over far into the future.
Affortunately this issue has been fixed for stable version 2.0 released today. Upgrading to this version should solve your problem.