[VA Benefits Taxonomy] Auto-populate the VA Benefit API ID with camelCase of benefitsName

[FranECross]

Status

[2024-07-29] [Fran] Per Michelle (after talking to Daniel T and Randi H), this will not be part of MVP, and may be revisited as part of a future state, or perhaps even closed at that time. Added to the 'hardening' epic (out of the MVP epic).

Description

As part of Event's v3 MVP, for the initial load of the Benefit Name/VA Benefit API ID, auto-populate it with camelCase.

Of Note:

• that the VA Services taxonomy uses lower camelCase, and we could/should follow suit here. Examples are:
  • caregiverSupport
  • cardiovascularSurgery
  • chiropractic
  • communityEngagement
  • DisabilityClaimAssistance
  • familyPractice
  • VAHomeLoanAssistance
• we don't have the auto-creation yet.

User story

AS AN engineer working on Benefit Taxonomy I WANT the VA Benefit API ID to be easily understood, and in line with what the Service Taxonomy uses SO THAT the ID is consistent and there is no confusion when viewing or searching for an ID

Engineering notes / background

Analytics considerations

Quality / testing notes

Acceptance criteria

• [ ] VA Benefit API ID are in camelCase, and the use of capitalization depends on how many words are in the Benefit Name e.g. (1 word - camel); 2 words - camelCase) (three or more words = ThisIsCamelCase)
• [ ] Public Websites engineers have validated to make sure it makes sense to future developers
• [ ] All Benefit Names/VA Benefit API IDs have been auto-populated

[dsasser]

Engineering Pre-Refinement

Q's:

@FranECross Regarding this AC:

VA Benefit API ID are in camelCase, and the use of capitalization depends on how many words are in the Benefit Name e.g. (1 word - camel); 2 words - camelCase) (three or more words = ThisIsCamelCase)

Since there are yet no consumers of the Benefits API, I'm wondering why this is a requirement? We diverge from a standard camel case into a bisected camel case + pascal case, but it isn't clear what is driving this need.

[davidmpickett]

@dsasser makes a great point. I would extend it even further to questioning if this ticket is necessary to do until we are poised to have an API consumer. Hardcoding logic that we have no users to validate sounds like creating a knot for our future selves to untie.

@mmiddaugh you might want to add this to the list for the 7/24 meeting

[FranECross]

@dsasser Dave C mentioned he thought it appropriate to follow what VA Services Taxonomy did, and thought that is the pattern that was followed. We can always change this AC to match what was implemented for VA Services Taxonomy, OR to whatever makes the best sense going forward. Thanks! cc @mmiddaugh @davidmpickett

[davidmpickett]

This is not automated in the Services Taxonomy. It is still done manually and there is not a consistent pattern.

On that product, these do have a function, because we have to integrate with the Lighthouse API. But that is a set list of legacy API IDs that we enter on the specific services. For Services that don't have a legacy correspondence we're try to come up with a logical label that conveys the core topic but maybe does use all the words.

Service Term name	API ID
Benefit letters and decision letters	BenefitLetters
Complementary and integrative health	complementaryHealth
Careers and employment	EducationAndCareerCounseling
Palliative and hospice care	hospice
Recreation and creative arts therapy	recreationTherapy
Physical therapy, occupational therapy and kinesiotherapy	physicalTherapy

[davidmpickett]

The terms that have been drafted for the Benefit taxonomy so far also show the value of editorial discretion:

Marine Gunnery Sergeant John David Fry Scholarship has been shortened to fryScholarship which mirrors one of the Alternate benefit names

Edith Nourse Rogers Science Technology Engineering Math Scholarship has edithNourseSTEMScholarship which is midway between the Alternative benefit names Rogers STEM Scholarship and Edith Nourse Rogers STEM Scholarship

[FranECross]

I've added this to the Product Sync agenda for 7/22 to discuss with Michelle.

[mmiddaugh]

Added to agenda for discussion with Danielle @FranECross

[mmiddaugh]

@FranECross @davidmpickett Danielle and Randi agree with Daniel's assessment that the logic for this does not need to be locked down for MVP and can be revisited in a future iteration if needed.

[davidmpickett]

I am removing this ticket from the Benefits Taxonomy MVP Epic since it is for a future iteration.

@FranECross Up to you if this should be closed as not planned or iceboxed