6 ms·

I've been using the issue key prefix for years now and I never thought about this aspect. If a board gets archived, for example, those issues need to remain av

I've been using the issue key prefix for years now and I never thought about this aspect. If a board gets archived, for example, those issues need to remain available. You're also just tied to that tool like you mentioned. It would probably be good practice then to also include a blurb in the PR description so that never gets lost.

hmeh 3y ago
Point of order, PRs get lost too. Git repositories can be moved from GitHub to GitLab, or tar'd up and sent in an email when a project gets handed off to its new maintainers. We try to keep things that matter in text files in repositories. We will always own those. Tools are just tools for transient activities (work items in our task tracker are just placeholders for conversations).
- geraldwhen 3y ago
  Or even the most mundane: corporate mandates that your project name change because of RULE with new access requirements. You get a new repo in GitHub, and all GitHub activity is lost for REASON. Tools never persist. I’d even say that ticket numbers in commit messages is harmful since it makes it much easier for the committer to be sloppy and write “Fix bug for JIRA123”. You can say “that’s a people problem”, but with a growing team I can either fix that people problem over and over, or I can ask for no external ticket ids in commit messages
  - hmeh 3y ago
    Very much agree. I've seen it leak into conversation in slack too... "Hey, I have a question about JIRA123, should we use blue for the button?". There's no greater way to tell someone you don't care about their time than presuming to force them to look up work items every time you want to refer to something. I believe that if teams look hard into the reasons they think that that practice is valuable, they will uncover even greater culture and process problems to address. Once they are addressed, they will no longer need them, and they'll even start to see the harm in them. Most teams won't do that, however, and I will be dragged out to the town square for even suggesting it's possible (even though our team operates extremely well without this practice or anything resembling it).

hmeh 3y ago

Point of order, PRs get lost too. Git repositories can be moved from GitHub to GitLab, or tar'd up and sent in an email when a project gets handed off to its new maintainers. We try to keep things that matter in text files in repositories. We will always own those. Tools are just tools for transient activities (work items in our task tracker are just placeholders for conversations).

geraldwhen 3y ago
Or even the most mundane: corporate mandates that your project name change because of RULE with new access requirements. You get a new repo in GitHub, and all GitHub activity is lost for REASON. Tools never persist. I’d even say that ticket numbers in commit messages is harmful since it makes it much easier for the committer to be sloppy and write “Fix bug for JIRA123”. You can say “that’s a people problem”, but with a growing team I can either fix that people problem over and over, or I can ask for no external ticket ids in commit messages
- hmeh 3y ago
  Very much agree. I've seen it leak into conversation in slack too... "Hey, I have a question about JIRA123, should we use blue for the button?". There's no greater way to tell someone you don't care about their time than presuming to force them to look up work items every time you want to refer to something. I believe that if teams look hard into the reasons they think that that practice is valuable, they will uncover even greater culture and process problems to address. Once they are addressed, they will no longer need them, and they'll even start to see the harm in them. Most teams won't do that, however, and I will be dragged out to the town square for even suggesting it's possible (even though our team operates extremely well without this practice or anything resembling it).