undefined | Better HN

0 pointseecc5y ago0 comments

Can't say anything more than: it depends.

To its essence, an ID allows interested parties to track something over time.

If you add additional meanings to an ID - e.g. the parent project as Jira does, or the kind as in ServiceNow - these can become outdated over time, and deceiving.

I'd say it's ok to change the "external name" as this other metadata changes over time (project name, bug, task, story, whatever...) but make the obsolete synonyms redirect to the currently active name.

0 comments

3 comments · 3 top-level

alkonaut5y ago

The prefix is just a project name though? It's no different from a convention saying that IDs 1000XXX are for project A and IDs for 2000XXX are for project B, it's just easier to read and distinguish like PROJA-0001 and PROJB-0001.

Obviously, you wouldn't want to have things migrating between projects - but if that is even concievable for an issue to do, then the division in 2 projects was probably not correct and it should perhaps have been a single project. That is: the PROJA-0001 is as immutable and unchanging as 1000001 is.

A thing changing "kind" (e.g. a bug to a feature) doesn't seem far fetched, and I'd be reluctant (Meaning I think it would be a flawed design) to use that as the public identifier prefix for a feature.

derektwong5y ago

Curious, do you mean: if a task was part of project ABC, with an ID of ABC-123, then if someone moved it into project DEF, its ID is now changed to DEF-621, those two should be linked, right?

iba995y ago

One way we've tried to fix this is with our slack integration. Using the task URL, or ID, the integration quickly unfurls context in the task (showing story info) and allows quick actions. Same process with requirements/epics.

URL unfurling was shipped today with the slack app, and quick actions are coming in a few weeks.

j / k navigate · click thread line to collapse