Updating issues tracking experience

Some of us gathered today to talk about the system we use to track issues (http://project.webplatform.org/). Please review these notes, as we'd like to take action on updating the UI & triaging the bugs — actually, we’ll start triaging bugs after the general meeting tomorrow.


If you can't share your thoughts at the meeting tomorrow, please share via email or IRC as soon as possible, as folks are motivated to rev this system.


In attendance:

Julee

Amelia

Jen

Shepazu

Renoirb


After some discussion on what & who could attack which topics and when, we focused on three use cases:


1. Renoir's experience as someone who resolves issued assigned assigned to him

2. a first-time or casual user of the issues tracker, and

3. someone looking for status on issues (a consumer of reports)


RENOIR'S EXPERIENCE:


Renoir's Filters are at http://project.webplatform.org/issues/saved_search/4/search/1



An on-going issue we looked at was http://project.webplatform.org/infrastructure/issues/INFR-40 This page can be considered a “main issue page” for discussion purposes, below.


Renoir likes these fields:


Assigned to:

Posted by:

Estimated time:

Time spent:


Description: what's needed to be done, has a todo, links to wiki, links to docs of what helped.


Renoir does not like these fields:

"Type of issue"

"Owned by"

"Component"


These fields should be altered:

The types of issues (http://project.webplatform.org/analytics/issues/new) could be reduced.

Bug, Task & Idea: rest could be removed.


Priorities should be simple. Renoir feels like this should be binary: either something is critical or it isn’t. [[JuleeNote: See below about “Severity” field.]]


Status: Too many options Renoir likes postponed, should have Closed, As Designed (FoL)


Status off of the "Resolve Issue" button: this is a different field than the "Status" field on the issue page.


ACTION ITEM: figure out what the Status field in a report maps to: the Status field within the "Resolve Issue" button or the Status field on the bug page.


[[JuleeNote: The fields on Renoir's main issue page do not include the following fields: Severity and Reproducibility. Are these fields required? If so, let's have them on all pages. If not:

* remove reproducibility field on File-a-Bug page [http://project.webplatform.org/analytics/issues/new].

* Priority then bares the qualitative value of severity and cannot be a boolean (critical or not). We do need to indicate whether an issue is critical or an normal bug, and at least a third category: low priority, nice to have. So, if we remove Severity field, we should normalize the Priority field values to speak for severity as well as other factors to: "Critical", "Normal", "Low".

]]


ACTION ITEM: figure out if any of the buttons on the main issue pages provide any functionality that isn’t already there. Specifically of note is closing a bug: does the issue close differently based on whether you close via the “Resolve Issue” button or the close field on the main issue pages?


[[JuleeNote: Really, we should look at all of the buttons: "Investigate Issue", "Confirm Issue", "Reject Issue", "Accept Issue", "Resolve Issue". If the button has redundant fields to the ones on the page, and the fields exposed by the buttons are not exposed in the reports, we should remove the buttons.]]


[[JuleeNote: File-a-Bug page[http://project.webplatform.org/analytics/issues/new]: additional fields at the bottom are not appropriate for an initial filing of a bug. Most of these fields should be set at the time of triaging the bugs. We should remove all of the fields under "Add more information to your issue", specifically:


* Specify milestone: The milestone field here does not reflect all of the milestones listed on a main bug page. So if Renoir is shooting for a sprint and someone files a bug with the milestone of Beta, and Renoir sorts based on his sprint, he won't see the new bug. We should remove it from the bug form.

* Estimate time to fix: The estimated time is rarely set at the time of filing. We should remove it from the bug form.

* Set priority: The priority is rarely set at the time of filing. We should remove it from the bug form.

* Set resolution: The resolution is rarely set at the time of filing. We should remove it from the bug form.

* Set severity: is not a field tracked on all main bug pages. This is a not required field. We should remove it from the bug form.

]]


[[JuleeNote: Actually, a nice-to-have for the File-a-Bug page would be a little template in the "Reproduction steps” field: Steps: 1. …; Actual results: … ; Expected results: … That way, the bug filer would know what is the type of content to put in this field.]]


LANDING PAGE EXPERIENCE:


http://project.webplatform.org/



A lot of projects, with little information. What's the call to action? Which project do I file my bug in?


Use case: After a Doc Sprint, the contributor tried to create a new page and the correct template wasn't listed.


We should be able to simply click a button — I'm having a problem. (As the bug base has an API, we could conceivably create a "file a bug" button on the page.)


Annotations will address this issue on a per page basis, but for something that affect multiple pages (forms, templates…), the contributor needs a simple way to file a bug.


What else do we want to use this system for?

Task as well as bugs?

Do we want to coordinate content projects this way?


Focus on a bug base first, then project management system.


NEW DESIGN:


Simplify landing page: 1 bucket for content bugs, 1 for infrastructure.


INTRO Paragraph: Invites folks to file an issue. What goes in each one. Create an Account.


| CONTENT | INFRASTRUCTURE |


| "Your issues" |


| Latest Project or Campaign |


| Dashboard with some high-level critical info from bug reports: new or critical bugs |


Intro: We do have http://docs.webplatform.org/wiki/WPD:Filing_Bugs Taking some of this content here & putting in on the landing page — and integrating the two.


Latest Project or Content Campaign: When we set up a project or campaign: dashboard widget for that project. Something that says: "We're working on this right now, here's today's status, come do some work on it!"


REPORTING experience:


We need to confirm that by creating sub projects, we have a parent/child relationship where reporting exposes the flows & dependencies between the individual issues.


Some default reports we'd like to have:


* New issues

* Unassigned issues

* Connection between issues: dependency flows

* Task with children

* Roadmap report: logical connections what needs to be done now.


PHASES:

Let’s consider this work phase 1. Phase 2 might include things like using the tracker to track content projects, or adding a tighter coupling with the actual pages where users might find an issue, or integrating any feedback from annotations into the same tracking system.


ACTION ITEMS:


* Triage existing bugs

* Re-org projects into 2 big buckets

* Mock up landing page & reporting pages

* Set up regular triaging meetings.


Next steps:


* Go through current bugs to see how many we can resolve now:

Tuesday 10am PDT triage meeting (Jen & Julee)

Friday 11:30am PDT triage meeting (Amelia, Jen & Julee)

* Confirm config of each project: are they the same? Do we need to resolve fields like "Reproducibility" & "Severity" before moving issues? (Julee)

* Confirm relationship the UI fields (of the same names) have with the fields exposed in reports, and with the system behavior, especially as relates to closing issues. (Julee)


Regards.


Julee

-------------------
Julee Burdekin
Content Strategist
Adobe Web Platform
@adobejulee
julee@adobe.com