[go: nahoru, domu]

Closed Bug 1275799 Opened 8 years ago Closed 8 years ago

Add descriptions to crash report fields

Categories

(Socorro :: Webapp, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: n.nethercote, Assigned: adrian)

References

Details

Attachments

(1 file, 1 obsolete file)

When viewing a single crash report, the "Details" and "Metadata" tabs have a lot of fields: Signature, UUID, Date Processed, etc. The meaning of some of these is obvious, but for some it is much less obvious ("EMCheckCompatibility", anyone?). As a result, there are documents explaining some of these fields, such as: https://support.mozilla.org/en-US/kb/contributors-crash-course#w_how-to-read-httpscrash-stats-mozilla-com https://support.mozilla.org/en-US/kb/helping-crashes#w_other-helpful-parts-of-a-crash-report Much better would be if crash-stats itself had descriptions. Tooltips are one possible way of doing this. The description would describe what the field contains, and when appropriate, also extra information about how it can be used. The tooltips in Firefox's about:memory page would serve as a good model here. I'm happy to write the descriptions, but I don't know the first thing about crash-stats' code so I'll likely need some help getting the descriptions into the code.
(There's also a lot of field shown in both the "Details" and "Metadata" tab for no obvious reason. Can we remove the duplication, or combine the two tabs into one? I can file a new bug if this is a reasonable idea...)
Assignee: server-ops-webops → nobody
Component: WebOps: Socorro → Webapp
Product: Infrastructure & Operations → Socorro
QA Contact: smani
Summary: When viewing a crash report, add explanations of field meanings via tooltips → Add descriptions to crash report fields
peterbe, does this sound like a reasonable idea to you?
Flags: needinfo?(peterbe)
Two things going on here... A) about the descriptions for each field. I think that's a great idea! We have an open bug about needing those descriptions for something else. Adrian is taking a lead on that. But if we can make it so that people like you can help it would be awesome. B) The second tab, "Metadata" was added much later than the "Details" tab. There was a time when the Details tab didn't change very much but eventually it got too tedious to keep up so we made the Metadata tab which just lists ALL keys. We COULD just merge them and list all. Certain keys need custom presentation. For example, that additional message that appears next to the URL and Email values. We could also have the ordering be custom. Certain few ones get elevated and the rest just follows. What do you think?
Flags: needinfo?(peterbe)
I've got my hands on the Socorro source code now. I see how the "Details" tab is a bespoke presentation while "Metadata" is just a dump of everything. Which means: - Just adding descriptions for "Details" fields in the "Details" tab is easy. - Adding descriptions for "Metadata" fields is harder. - Adding custom presentation for "Metadata" fields is harder. - Combining "Details" and "Metadata" in a nice way is harder. > There was a time when the Details tab didn't change very much but eventually it got > too tedious to keep up so we made the Metadata tab which just lists ALL keys Ok. From a user's point of view, the nicest thing would probably be to have a single tab with all fields, in a nice order, with custom presentation as necessary, and descriptions. Sounds like the main obstacle preventing that is potential maintenance hassle if the fields change a lot. So... how often do they change?
Flags: needinfo?(peterbe)
(In reply to Nicholas Nethercote [:njn] from comment #4) > I've got my hands on the Socorro source code now. I see how the "Details" > tab is a bespoke presentation while "Metadata" is just a dump of everything. > Which means: > > - Just adding descriptions for "Details" fields in the "Details" tab is easy. > - Adding descriptions for "Metadata" fields is harder. > - Adding custom presentation for "Metadata" fields is harder. > - Combining "Details" and "Metadata" in a nice way is harder. > > > There was a time when the Details tab didn't change very much but eventually it got > > too tedious to keep up so we made the Metadata tab which just lists ALL keys > > Ok. From a user's point of view, the nicest thing would probably be to have > a single tab with all fields, in a nice order, with custom presentation as > necessary, and descriptions. Sounds like the main obstacle preventing that > is potential maintenance hassle if the fields change a lot. So... how often > do they change? They change about 1-2 new fields per month.
Flags: needinfo?(peterbe)
(In reply to Nicholas Nethercote [:njn] from comment #4) > I've got my hands on the Socorro source code now. I see how the "Details" > tab is a bespoke presentation while "Metadata" is just a dump of everything. > Which means: > > - Just adding descriptions for "Details" fields in the "Details" tab is easy. > - Adding descriptions for "Metadata" fields is harder. > - Adding custom presentation for "Metadata" fields is harder. > - Combining "Details" and "Metadata" in a nice way is harder. I'll just start with the first of these for now. Others can be potential follow-ups. I found that a couple of the fields already have descriptions: > <tr> > <th title="Notes added by the application's code during crash" scope="row">App Notes</th> > <td> > <pre>{{ report.app_notes }}</pre> > </td> > </tr> > {% endif %} > {% if report.processor_notes %} > <tr> > <th title="Notes added by Socorro when accepting the crash report" scope="row">Processor Notes</th> > <td> > <code>{{ report.processor_notes }}</code> > </td> > </tr> So I can do likewise. My only remaining question: some of these descriptions might be relatively long, e.g. multiple sentences. Is there a better way to do it than just putting it all on a single very long line? (Also, what's the preferred way to receive Socorro patches? Do you use Bugzilla or GitHub?)
Flags: needinfo?(peterbe)
Ok, I've done a first pass at this. I made a PR at https://github.com/mozilla/socorro/pull/3360. How do I make an attachment that links to the PR? (Like the one in bug 803779, for example.) I'm not entirely sure who is best to review this, so I'm needinfo'ing a few people who might be interested. I apologize in advance for not knowing how to handle Socorro bugs/PRs properly. Thank you.
Flags: needinfo?(ted)
Flags: needinfo?(dbaron)
Flags: needinfo?(benjamin)
Attached file Link to PR (obsolete) —
Nicholas, this is great! I think we should merge our parallel efforts on this matter (documenting crash data), as I am working on something very similar in bug 1275482. I would take a different approach to this bug. I think we should make our Super Search Fields list our source of truth for crash documentation. The advantage of that is that it's all in database (no need to make a full deploy to update a description), and it is available through our public API. It would also make the code easier to maintain, as adding the descriptions would be automated with some templating sugar. My proposition is to move all your descriptions into our database, then rework that patch to pull the data from it instead. I can take it from there if you'd like.
(In reply to Adrian Gaudebert [:adrian] from comment #9) > Nicholas, this is great! I think we should merge our parallel efforts on > this matter (documenting crash data), as I am working on something very > similar in bug 1275482. I see; apologies for the duplication of effort. I didn't properly comprehend what you were doing in that bug. > I would take a different approach to this bug. I think we should make our > Super Search Fields list our source of truth for crash documentation. The > advantage of that is that it's all in database (no need to make a full > deploy to update a description), and it is available through our public API. > It would also make the code easier to maintain, as adding the descriptions > would be automated with some templating sugar. > > My proposition is to move all your descriptions into our database, then > rework that patch to pull the data from it instead. I can take it from there > if you'd like. That sounds good. I think this means that we could get tooltips in both the "Details" and "Metadata" tabs, correct? This bug should remain open, for the addition of the tooltips (sourced from the database), and the various presentation tweaks that I've made. But I can wait until bug 1275482 is finished before doing that.
Flags: needinfo?(ted)
Flags: needinfo?(peterbe)
Flags: needinfo?(dbaron)
Flags: needinfo?(benjamin)
Great work Nicholas. But I have to agree with Adrian, "I think we should make our Super Search Fields list our source of truth for crash documentation.". If we have the descriptions written down properly in our database we can insert them into the HTML on-the-fly. Your PR has great value in terms of the content, but I think I'd rather let Adrian invite you into the participation of typing that into the Super Search Fields database.
Assignee: nobody → adrian
Status: NEW → ASSIGNED
Attachment #8759037 - Attachment is obsolete: true
Commit pushed to master at https://github.com/mozilla/socorro https://github.com/mozilla/socorro/commit/efdc7aa3e0782572e1e2524f791da9539702441c Fixes bug 1275799 - Added a title with a description of each field in report/index/. (#3368) * Fixes bug 1275799 - Added a title with a description of each field in report/index/. * review
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Blocks: 1289675
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: