Backfill existing GraphQL types and fields to have a feature_category, and make it required.
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
About
This issue is part of the epic &11407. See that epic description for more context.
In #424538 we added the ability for feature_category metadata to be derived for a field.
This issue is to:
- backfill existing GraphQL types, resolvers and fields to have
feature_categorymetadata. - and to make
feature_categorya required argument for all fields.
Proposal
We'd want to leverage other teams to help this effort as much as possible and centrally coordinate the effort. Exactly how this coordination would happen is TBC.
The simplest way for us to require a feature_category for each field would be to raise a subclass of ArgumentError in BaseField if we can't derive a feature_category for the field.
We can't use static validation for this, as the feature category can be derived from a resolver or type.
To help roll out progressively, there could be an amnesty for existing fields
- Generate a list of all fields (a field being a combination of
type.field, examples:Project.id,Project.title) and save to, say, a YAML file. The format of the YAML to be determined. This will be an amnesty list - In development and test only:
- raise the subclass of
ArgumentError(the action here is the developer to add feature category data) if:- The field does not have a
feature_categoryand - The field is not in the YAML file list (based on its
type.fieldcombination)
- The field does not have a
- raise some error (the action here is the developer should remove the entry/s from the YAML) if:
- The field has a
feature_categoryand - The field is still in the YAML file list
- The field has a
- raise the subclass of
- In production we never raise
As teams add feature_category metadata to types, resolvers, or fields, they remove the entries from the YAML.