Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

harmonize terminology across codebase #919

Open
handwerkerd opened this issue Dec 22, 2022 · 0 comments
Open

harmonize terminology across codebase #919

handwerkerd opened this issue Dec 22, 2022 · 0 comments
Labels
effort: medium Theoretically <40h total work impact: low Improving code/documentation cleanliness/clarity, not function priority: low issues that are not urgent refactoring issues proposing/requesting changes to the code which do not impact behavior

Comments

@handwerkerd
Copy link
Member

Summary

Particularly with the addition of the modularization decision tree #756, there are places where similar things are given different names in various parts of the codebase. This might create some unnecessary confusion and risks for typos

Additional Detail

Places for harmonizing terminology includes:

  • using component_table rather than comptable everywhere
      - Decide whether to standardize on d_table_score vs mean_metric_score
  • Have the PCA component table better match the ICA component table (primarily changing from rationale to classification_tags terminology. (This is currently only an issue for the kundu selection process for PCA components.)

Places to reduce typo risks:

  • Make all classification and classification_tag labels either fully case insensitive or changed to match the capitalization of where classification and tag labels are defined.
  • Create a field in the tree json for classification_tag_explanations In it would be a dictionary for each tag in the tree and an explanation for what that tag means. Then explanations for the tags in any given tree would automatically be included in the report rather than having us need to maintain a hard coded list of explanations in the documentation.

Next Steps

  • Wait for [REF] Decision Tree Modularization #756 to merge
  • Since this will require a lot of small changes across the code base, find a time when no one else is making dramatic code edits so that this can happen quickly.
@handwerkerd handwerkerd added priority: low issues that are not urgent refactoring issues proposing/requesting changes to the code which do not impact behavior effort: medium Theoretically <40h total work impact: low Improving code/documentation cleanliness/clarity, not function labels Dec 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort: medium Theoretically <40h total work impact: low Improving code/documentation cleanliness/clarity, not function priority: low issues that are not urgent refactoring issues proposing/requesting changes to the code which do not impact behavior
Projects
None yet
Development

No branches or pull requests

1 participant