Context-dependent entity metadata (`foo` vs `foo_issues` problem)

[SachaG]

Originally my thinking was that if we code React pain points as just react, we won't be able to change the description. Because it we changed it to something like "Issues with React", then that would also appear as the canonical description for React everywhere else even for charts that have nothing to do with pain points.

So my solution was to create separate foo_issues-type codes for the pain points so that they can have their own descriptions or other metadata.

But the downsides are:

1. This makes our codebooks larger
2. Pain point charts lose access to all existing react metadata (link to homepage, github, npm , etc.) unless we duplicate it to react_issues, which is not practical.

So the solution I now favor is:

• Only have react
• Find another way to have context-dependent metadata. See below.

Context-dependant metadata

Examples:

- id: react
  name: React
  overrides:
    - questionIds: [front_end_framework_pain_points]
       name: React issues
       description: Issues with React

Or:

- id: i18n_issues
  name: Internationalization
  patterns:
    - translation
    - locali(z|s)ation
  overrides:
    - id: web_components_common_pain_points
      name: Web Components Internationalization
      patterns:
        - i18n

Or:

- id: react
  name: React
  overrides:
    - idMatch: *pain_points*
       name: React issues
       description: Issues with React

[SachaG]

The two exceptions to this are:

1. Cases where there is no corresponding "canonical" code. For something like animations_issues, there isn't really an animations code outside of the context of pain points. So I think here it's probably ok to leave it as it is, at least for now.
2. Cases where there is a corresponding code, but it means something different. For example, we want to keep motion (referring to the motion js library) and motion_issues (referring to e.g. motion sickness) separate.