Closed
Bug 678168
Opened 13 years ago
Closed 12 years ago
Show different time frames on the dashboards
Categories
(support.mozilla.org :: Knowledge Base Software, task, P2)
support.mozilla.org
Knowledge Base Software
Tracking
(Not tracked)
RESOLVED
FIXED
2012Q1
People
(Reporter: atopal, Assigned: rrosario)
References
Details
(Whiteboard: u=contributor c=wiki s=2012.5 p=1)
Currently we show "this week" and "overall", but there is too much volatility in "this week" and too little in "overall" (+ no one knows what time span overall covers) Instead we should have 3 views: last 7 days, last 30 days, last 3 month and the standard view should be 30 days.
Comment 1•13 years ago
|
||
Yes please! This will be much better for us.
Comment 2•13 years ago
|
||
Erik: do we even have that data from webtrends? I thought the week/overall was because that's what their API gave us.
OS: Mac OS X → All
Hardware: x86 → All
We specify the date range we want so we can ask for whatever we want. I can work with Erik on getting the webtrends queries.
One thing to note is how often do we expect that data to update. Are we doing a webtrends pull every day for "past 7, past 30, past 90" or are we pulling once a week for past 7, once a month for past 30 etc. The latter is much friendlier to webtrends but it's a little confusing.
Reporter | ||
Comment 5•13 years ago
|
||
It should be every day. So we have a rolling period of last 7 days/30days/90days. otherwise it would really be confusing and also not of much use. It's much more useful to know the top 20 for the last 30 days than that of the last full month.
Comment 6•13 years ago
|
||
Yep, we pull every day for every period. This shouldn't be a big deal, except that we should revise the UI.
Reporter | ||
Comment 7•13 years ago
|
||
I guess it would be okay to go with the current UI, since we would only add one additional state. But I agree, in the future that UI should be revised.
Target Milestone: --- → 2011-09-06
Updated•13 years ago
|
Target Milestone: 2011-09-06 → 2011-09-13
Assignee | ||
Updated•13 years ago
|
Target Milestone: 2011-09-13 → 2011-09-20
Comment 8•13 years ago
|
||
Can we have a new target milestone?
Updated•13 years ago
|
Target Milestone: 2011-09-20 → 2011Q4
Reporter | ||
Updated•12 years ago
|
Priority: -- → P2
Whiteboard: u=contributor c=wiki s=2012.5 p=
Assignee | ||
Comment 10•12 years ago
|
||
Quite a bit to do here. Figure out API calls, store the data, update the UI,... Making it a 3pter, but we may want to spin off new bugs once we take a closer look.
Whiteboard: u=contributor c=wiki s=2012.5 p= → u=contributor c=wiki s=2012.5 p=3
Assignee | ||
Comment 11•12 years ago
|
||
Pruning 2012.5 bug list.
Whiteboard: u=contributor c=wiki s=2012.5 p=3 → u=contributor c=wiki s=2012.6 p=3
Assignee | ||
Comment 13•12 years ago
|
||
Revising points based on what I have learned working on l10n coverage metric.
Assignee: nobody → rrosario
Whiteboard: u=contributor c=wiki s=2012.6 p=3 → u=contributor c=wiki p=2
Assignee | ||
Comment 14•12 years ago
|
||
Actually, I need to have this for the l10n coverage calculation (Bug 727084). Moving this to the current sprint.
Blocks: 727084
Whiteboard: u=contributor c=wiki p=2 → u=contributor c=wiki s=2012.5 p=2
Target Milestone: 2012.6 → 2012Q1
Assignee | ||
Comment 15•12 years ago
|
||
Actually, this is pretty easy the way Erik set it up => 1pt
Whiteboard: u=contributor c=wiki s=2012.5 p=2 → u=contributor c=wiki s=2012.5 p=1
Assignee | ||
Comment 16•12 years ago
|
||
Landed on prod: https://github.com/mozilla/kitsune/commit/0fe179b25e6b1dead2c4e1eaf86088db950a3aae Data for the new time frames will be missing until the daily cron job runs.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•