First pass looks good. Future work, I'm mulling over: 1. For annotations, I want to add the list of products that have emitted the annotation in the last 7 days. 2. For annotations for which there's a processed crash field with a source_annotation, we can add a link to the processed crash field. 3. Some processed crash fields specify a `source_annotation` and are normalized, validated, and copied over to the processed crash using the `CopyFromRawCrashRule` processor rule. For the fields that are derived from annotations or are a little more complex so they need a special rule, there's no source annotation so the data dictionary can't document where the field data comes from. It'd be great if we could figure out something that doesn't require manual bookkeeping here. 4. Some processed crash fields are objects and those are effectively not documented at all, yet. How do we want to document them? For example `breadcrumbs`, `java_exception`, `memory_report`, `json_dump` and friends, etc. Maybe we display a "friendly" version of the schema? 5. The super search query type is opaque--it's not clear what it means. Should we add details about how you search with the field? 6. There are some Socorro-y fields that probably aren't usable by other people. Should we show them in the data dictionary? For example, the collector_notes. I think I'll split some/most of those and whatever other ideas come up from feedback next week.
Bug 1803558 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Everything so far was pushed to production just now in bug #1803661. First pass looks good. Future work, I'm mulling over: 1. For annotations, I want to add the list of products that have emitted the annotation in the last 7 days. 2. For annotations for which there's a processed crash field with a source_annotation, we can add a link to the processed crash field. 3. Some processed crash fields specify a `source_annotation` and are normalized, validated, and copied over to the processed crash using the `CopyFromRawCrashRule` processor rule. For the fields that are derived from annotations or are a little more complex so they need a special rule, there's no source annotation so the data dictionary can't document where the field data comes from. It'd be great if we could figure out something that doesn't require manual bookkeeping here. 4. Some processed crash fields are objects and those are effectively not documented at all, yet. How do we want to document them? For example `breadcrumbs`, `java_exception`, `memory_report`, `json_dump` and friends, etc. Maybe we display a "friendly" version of the schema? 5. The super search query type is opaque--it's not clear what it means. Should we add details about how you search with the field? 6. There are some Socorro-y fields that probably aren't usable by other people. Should we show them in the data dictionary? For example, the collector_notes. I think I'll split some/most of those and whatever other ideas come up from feedback next week.