2018 refactoring proposal about qpp-conversion-tool

[saquino0827]

Converter Endpoint Response:
I like the idea of returning an object containing everything we need. There will be work involving other teams for the UI as well as changes to our own endpoints when we submit validation to the submission validation api. I do not know a use case for references off the top of my head.

Create StandardErrorCodes and StandardWarnings enums:
This looks good.

Refactor data-specific error codes / warnings into date-based packages:
I feel like this also falls under Create encoder/decoder/validation date based pipeline as we would want to keep all code we reuse in one area as well as separate a different yearly validation. But I ultimately like this idea.

Change error code format to use named rather than numeric parameters:
This is a nice refactor but I do not believe it's required. I guess it depends if we're time constrained to do this or not.

[zack-harrison]

@saquino0827 references is so we don't have to link to the IG in the error message. It can also be used by the UI to separate reference links from the message, kind of like how it works on wikipedia.

[JeffBJr56]

After reading through the proposals all of them seem to be fine for HIVVS. The only thing that would need to be put into consideration on our end is added overhead this creates due to the refactoring of test cases for these new changes. So test case creation for new ones may slow down as a result. Besides that all of the proposed changes seem to be within the capabilities of our testing framework.

[sfradkin]

I like this proposal. Let's add stories to the backlog.