4 ms·

What's your take on changing the status quo around unique task/issue ID's?

• eecc 6y ago
  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.
  • derektwong 6y 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?
  • iba99 6y 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.
  • alkonaut 6y 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.
• valcker 6y ago
  Why change something that works? It is much easier/faster to use short IDs than long user story titles.