Triage Dashboard

[karlcow]

This is the meta issue for the Triage Dashboard. There is an associated milestone to put all issues related to this project.

"Build a “needstriage” dashboard that displays total count plus count for untriaged bugs older than 48 hours."

• /dashboard/triage with a link from /activity/
• Total count of needstriage issues https://github.com/webcompat/web-bugs/milestones
• Total count of needstriage issues older than 48 hours. (is:issue milestone:needstriage created:<2017-10-30 on 2017-11-01)
• An html table with real data, that we enhance with JS.
• Should have the list of issues to be easily clickable

Optional:

• Archives of previous weeks or days? Number by the end of the day (which timezone for the count).
• Distribution graph of this issues with time?
• Triage speed. Compare the number of new vs triaged issues (that could be a 3rd number which indicate we need more efforts in triaging this day, week.)

Deadline: Q4 2017

[karlcow]

@magsout This is the start of this project we will add issues for each item we want to work on.

I propose we start with developing a very simple HTML page with the information requested for it.
Then we enhance it through JS and CSS. The main goal stated initially are two numbers.

We could share a separate branch merge we can merge the small issues branches like we did for milestones or we could use the master branch as usual. I don't think we will have conflicting interactions.

What do you think?

[miketaylr]

Thanks for filing @karlcow.

For the purposes of Mozilla compat work, I'm most interested in ensuring that incoming issues are triaged in a timely manner. I think we should also consider issues that have a "status-needsinfo" label on them to be sort of triaged, usually that means we're trying to follow up with the reporter. Maybe those are filter options, I don't know.

[karlcow]

@miketaylr Understood. Let me edit the issue #1859

[magsout]

@karlcow

I propose we start with developing a very simple HTML page with the information requested for it.
Then we enhance it through JS and CSS. The main goal stated initially are two numbers.

sounds good.

We could share a separate branch merge we can merge the small issues branches like we did for milestones or we could use the master branch as usual. I don't think we will have conflicting interactions.

IMO a separate branch seems to be a good solution.

[magsout]

@karlcow the dashboard is fully integrated with webcompat ? I mean css component html and js ? Or it's separate ?

[miketaylr]

@karlcow the dashboard is fully integrated with webcompat ? I mean css component html and js ? Or it's separate ?

I was thinking about this. Can you all build it separately at first? (similar to how eric and ola are going to prototype duplicate issue UIs) If we think it's useful to the broader webcompat.com community we can integrate it. But I think a standalone tool would be good. Or, another option is a webcompat.com subdomain (maybe a terrible option, I dunno :p).

Another thing to keep in mind, @zoepage (with others) is going to be working on the front-end redesign/refactor in the coming weeks. Having to re-write it or be blocked seems like a waste of time, especially since we want this ASAP so we can use it to measure things before the end of the quarter.

[karlcow]

I was thinking about this. Can you all build it separately at first?

Hmm it's more work (all the http layers have to be done from scratch). I guess I misunderstood the request.

What is the goal of the dashboard?

I thought it was something @miketaylr wanted

• for a control mechanism on how we perfom
• and a tool to help people doing triage.

I'm happy to create a prototype if it's what you meant, but then I need to refocus a bit the work done already. And Probably there's no need for any design.
so @magsout let's hold on on any work for now.

Or, another option is a webcompat.com subdomain (maybe a terrible option, I dunno :p).

no no no ;)

[karlcow]

Another thing to keep in mind, @zoepage (with others) is going to be working on the front-end redesign/refactor in the coming weeks.

ok maybe this is the part I'm misunderstanding. Because it's not related to the work of @zoepage
It doesn't have to share the same css. Or maybe I'm missing something else.

Having to re-write it or be blocked seems like a waste of time, especially since we want this ASAP so we can use it to measure things before the end of the quarter.

Unrelated. Why would it be blocked in any way? Do you mean for the class names and html templates?

It doesn't have to reuse the same thing. On the other hand benefiting from flask is a time saver.

karlcow@f4b52f5#diff-e0713389ef1501d6c8a09232d1353875
Inside the templates folder

 webcompat/templates/dashboard-triage.html
 webcompat/templates/dashboard/triage.html

I can move everything under

 webcompat/templates/dashboard/

[miketaylr]

What is the goal of the dashboard?

I think your understanding is the same as mine. A tool for us to track how responsive we're being to triage Firefox issues, so we don't miss important regressions landing in Nightly (which might end up shipping to users).

ok maybe this is the part I'm misunderstanding. Because it's not related to the work of @zoepage
It doesn't have to share the same css. Or maybe I'm missing something else.

If you're extending layout.html that that changes in unexpected ways, it creates pain for you.

Why would it be blocked in any way? Do you mean for the class names and html templates?

It's only blocked if you decide to not work on it until the redesign happens. The timeline on that being finished is not clear to me. End of the quarter is the goal @zoepage set though. And yeah, if you're relying on the templates and CSS to achieve a particular design and those change, it creates work.

It doesn't have to reuse the same thing. On the other hand benefiting from flask is a time saver.

Yeah, understood.

so @magsout let's hold on on any work for now.

This is what I don't want to happen. We're nearly half-way through the quarter.

Like I said before, the most important thing is for us to have this tool, wherever it lives. Even if it's ugly (not that you're not an artist @karlcow :)) or doesn't match current or future designs.

Thinking about this more, I would vote that you go ahead with your current plans being mindful that a redesign/refactor might suck or break things?

@zoepage any hard objections?

[karlcow]

Thinking about this more, I would vote that you go ahead with your current plans being mindful that a redesign/refactor might suck or break things?

OK I will arrange things in a way that it doesn't step on @zoepage work and that it is mostly independent.

@miketaylr Thanks for the clarification.
@magsout as a first step we could put all CSS/JS inline. Given they will be only used by this page. If you want them outside, we could create /static/dashboard/ in the project.

[karlcow]

@magsout there is a new branch called dashboard.
That we can use for coding the dashboard project.
I expect to have finished the main feature this week.

[zoepage]

Sorry for the late reply!

+1 on separate folder, also having also the css / js in that folder. So basically treat that feature as a module, as it will make things easier later on to move it to the site itself and refactor code without searching for code snippets.

Thanks for the work @karlcow && @magsout