Bugzilla

Update from comment #3, I've done the following:

1. Done: For annotations, I want to add the list of products that have emitted the annotation in the last 7 days.
2. Done: 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. Done: 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?

These aren't done:

1. 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.
   * This would be great, but I don't have a good idea of how to do this, so I'm going to not do it now.
2. 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?
   * This would be great, but I'm not sure how it should look and it 
3. 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'm going to defer this for now.
4. Redo the tables to use flex or grid or something that'll work with different viewport sizes.
   * We can tackle this when we redo the ui for the site.

Further, I want to add a new item:

1. Fields need to be searchable. There's enough data now that if you're looking for a certain kind of information and don't know the field name, finding it is really hard. Maybe we should add search and filters and tags and such? This needs some thought and we shouldn't do anything unless the data dictionary is being used.

At this point, I think we have a good data dictionary now and I'm going to split off the remaining items we should do into new bugs and then close this bug out.

Update from comment #3, I've done the following:

1. Done: For annotations, I want to add the list of products that have emitted the annotation in the last 7 days.
2. Done: 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. Done: 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?

These aren't done:

1. 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.
   * This would be great, but I don't have a good idea of how to do this, so I'm going to not do it now.
2. 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?
   * This would be great, but I'm not sure how it should look and it overlaps with the super search docs.
3. 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'm going to defer this for now.
4. Redo the tables to use flex or grid or something that'll work with different viewport sizes.
   * We can tackle this when we redo the ui for the site.

Further, I want to add a new item:

1. Fields need to be searchable. There's enough data now that if you're looking for a certain kind of information and don't know the field name, finding it is really hard. Maybe we should add search and filters and tags and such? This needs some thought and we shouldn't do anything unless the data dictionary is being used.

At this point, I think we have a good data dictionary now and I'm going to split off the remaining items we should do into new bugs and then close this bug out.