A case repository and an issue tracker each hold a closed list of values for a similar idea, but the lists have different members. How do you map one onto the other?
answer
- two lists, different jobs
- not a rename, a conversion
- member-by-member, agreed by both owners
- the unmapped value decides the design
- loud stand-in beats plausible default
basics
~20 sWrite an explicit member-to-member table, agreed by both sides, and decide in advance what happens to a source value with no counterpart. That fallback is the real design question: refuse the write, or route to a visibly marked value.
solid answer
~50 sTwo closed lists that mean roughly the same thing almost never line up member for member, because they were built for different jobs — one describes how bad a failure is, the other how work should be ranked. So the mapping is an explicit table, member by member, agreed by the people who own each list rather than by whoever wired the integration. The hard part is the **unmapped value**: a member on the source side with no counterpart, or one added to a list months later. You have three choices — fail the write loudly, route to a designated value that is obviously an integration artefact and searchable, or drop the field and let triage set it. Silently defaulting to the mildest or first member is the choice to avoid: it produces a plausible wrong value that nobody can distinguish from a deliberate one, and it makes list drift invisible.
go deeper
Know what a closed list is and that a value can only be written if it is a member of the destination list. Say that a mapping between two such lists has to be written out rather than assumed.
Explain why lists built for impact and lists built for ranking work do not correspond, and describe the member-by-member table plus a stated rule for values with no counterpart.
Demonstrate the production view: which fallback you choose when filing is unattended, why a plausible default poisons filters and counts, and how you notice a list that gained a member.
Own the governance. Decide who signs a conversion between two teams' vocabularies, whether collapsing distinctions is acceptable, and how list changes are communicated across a system boundary.
## Why the lists do not line up A closed list is a fixed set of members that a field will accept, and both systems use them heavily. The trap is assuming that two lists about a similar idea are two spellings of the same list. They are not, because they were designed for different questions: - A repository's list about a failing run usually describes **impact**: how badly the behaviour departs from what was expected. - A tracker's comparable list usually describes **how work should be ranked**: what gets done first, given everything else in the queue. Those are different judgements, made by different people, at different moments. A serious departure from expected behaviour in an area nobody uses is high on one scale and low on the other. So the mapping is never a rename; it is a stated position on how one judgement is converted into another, and it belongs to the people who own each list rather than to whoever configured the connection. ## The table, and who signs it Write the mapping out member by member, in a form a non-engineer can read, and get both owners to agree it. Three properties make it durable: - **Total on the source side.** Every member of the source list appears, including the ones nobody expects to see. - **Explicit about collapsing.** Where several source members map to one destination member, say so, because information is being discarded on purpose and that should be a decision rather than an accident. - **Directional.** A mapping that is correct one way is frequently wrong reversed. If values ever travel back, write the reverse mapping separately instead of inverting the table in your head. ## The unmapped value is the real design question The interesting case is a source value with no counterpart. It arrives in two ways: a member that was always there and simply has nowhere sensible to go, and a member added to either list long after the mapping was agreed. The second is the common one in production, because lists are edited by people who have no idea an integration reads them. Three defensible fallbacks: 1. **Refuse the write and surface it.** The create fails, someone is told, and the mapping gets fixed. Correct when the field genuinely matters and someone is watching. Costly when filing is unattended, because a real defect goes unrecorded over a list mismatch. 2. **Route to a designated, marked value.** Send it to a member that exists so the item can be filed, but choose one that is obviously an integration artefact and that can be searched for afterwards. This keeps the defect from being lost while leaving a trail that says *this value was not chosen, it was defaulted*. 3. **Omit the field entirely** where it is not mandatory, and let triage set it. Honest, and often the best answer: it declines to assert what the filing side does not know. | Fallback | Keeps the item | Leaves a trail | Fails when | |---|---|---|---| | Refuse the write | No | Yes, loudly | Filing is unattended and the failure is unread | | Route to a marked value | Yes | Yes, if the value is searchable | Nobody ever searches for it | | Omit the field | Yes | Only in what is missing | The field is mandatory on the item type | | Default to the mildest member | Yes | No | Always, quietly | ## Why the silent default is the one to avoid Defaulting an unmapped value to the mildest or first member is popular because it makes everything work. Its cost is that the result is **plausible**. A wrong value that looks deliberate is worse than a missing one, because: - it is indistinguishable, later, from a value someone chose; - it biases every filter, view and count that reads the field; - it hides list drift, so the day a new member is added is the day the mapping quietly stops being true and nothing says so; - it usually skews in one direction, so the distortion accumulates rather than averaging out. ## Keeping the mapping alive A value mapping is one of the few pieces of an integration that decays purely from other people's ordinary work. Two habits are worth the effort: - **Detect additions rather than waiting to hit them.** If either list gains a member the table does not mention, that is a fact worth noticing before the next filing, not during it. - **Review the collapsed cases.** Where several members funnel into one, occasionally check that triage is not silently re-editing every filed item, which is the signal that the mapping is lying about a distinction the receiving side still cares about. The rule to carry away is small: **a mapping between closed lists is a stated conversion between two different judgements, and the fallback for an unmapped value is part of the mapping, not an implementation detail.**
- Someone adds a member to the tracker's list without telling you. What breaks, and what does not?Nothing breaks on the way out: the repository still maps its own members onto the destination members it knows. What breaks is the reverse direction and the assumption of completeness — items now exist carrying a value your table has never heard of, and any reading that walks back from the tracker meets an unmapped member. Detecting new members on both lists is what buys the warning.
- Several source members collapse onto one destination member. How do you tell whether that is acceptable?Watch what triage does afterwards. If people routinely re-edit the value on filed items, the collapse is discarding a distinction the receiving side still cares about and the destination list probably needs a member it lacks. If the value is left alone, the collapse matches how they actually work and the lost detail was never used.
Two offices each end their form with a fixed set of tick-boxes. Mapping one onto the other is not translating a sentence — it is deciding in advance which box you tick when the other office simply has no box for what you mean, and whether you would rather tick nothing and be asked than tick the mildest one and be believed.
saying these in an interview costs you the question
- Assumes two similar lists align member for member
- Silently defaults unmapped values to the mildest member
- Treats the mapping as reversible by inverting it
- Lets whoever wired the integration decide the conversion
- Never revisits the table when a list gains members