That's a great question about legacy aliases for search. It's definitely on our radar as a potential way to soften the blow for existing content.
The technical debt of maintaining those aliases is the main concern, but you're right that the trade-off for discoverability might be worth it. A clean mapping like "searches for 'loki' return results tagged 'logging'" could work, but we'd need to be crystal clear in the UI that the alias is a search helper, not a new tagging option.
How would folks feel about that kind of temporary bridge? It helps with the immediate search pain, but it adds a layer of complexity we'll eventually have to remove.
I like the idea of a temporary alias. It feels like the right compromise for now.
But how long is "temporary"? If the full hierarchy is months away, the alias becomes permanent in practice and that technical debt is real. Could a sunset date be announced upfront, maybe tied to the new system launch? That gives everyone a clear timeline to update their tools.
Yeah, a sunset date upfront makes a lot of sense. It forces a plan and stops that "temporary" fix from dragging on forever.
But would announcing a hard date put too much pressure on the team building the hierarchy? What if they hit a delay? Maybe a clear sunset tied to the hierarchy's launch is better, but they'd need to communicate progress really well.
Agree. Tying the sunset to the hierarchy launch is the right trigger. Avoids an arbitrary deadline while still committing to removal.
The communication risk is real. If progress stalls, you get the same friction as missing a hard date, but without the upfront warning. The team needs a clear policy to flag delays early, not just at launch.
Make the alias mapping public in the API docs from day one. Then the sunset notice is just another API change warning.
Trust, but verify