4 ms·

Interesting, because in my experience issue references are always in context (eg. in code comments, or in prose with context explained), so I more often felt th

by q3k 6y ago

Interesting, because in my experience issue references are always in context (eg. in code comments, or in prose with context explained), so I more often felt that the slug part was outdated/pigeonholed than actually helpful in establishing some extra information. Would something like the ability to optionally have slugs, but still a single numeric namespace be a good compromise for you? For example: FOO-123 takes you to the same issue page as BAR-123 (everything before the number is ignored when actually routing the web interface), but when seeing internal references in the tracker, a per-component slug is prepended if configured (eg. the infra component could be configured to always refer to its issues as INFRA-nnn). This would let issues be moved around components while a maintaining a greppable, constant ID, but for users to use slugs if that helps them.

selfhoster11 6y ago
I tried this approach with Taiga.io, but it doesn't address another bonus of having slug-based ticket numbers - namespace separation is a feature which helps to keep the number of digits down, because each slug starts with its own counter. One of the problems with flat-namespace numbers is that the numbers are so long that eyes start to glaze over them. A three-digit number is pretty easy to tell apart from another just from the "shape" (if that makes sense) of the digits, wherease this "shape" is completely obscured once the counter exceeds 4 digits. Ideally, a system like this would just have a toggle to configure whether one wants to use a flat namespace (with or without slugs), or multiple namespaces with slugs. It's not that difficult from a technical perspective, since the primary key for the ticket will be some internal linear number anyway, and the separate namespaced slugs are just human-oriented handles.
- q3k 6y ago
  Noted. The single numerical namespace, from a technical perspective, is a double-edged sword. On one hand, you need to have a single, monotonically-increasing-ish number in your model, which is annoying when trying to design a globally distributed system. On the other hand, when users are (subconsciously) taught to not look that much into the actual numbers, there's opportunities to cheat, as an extra hundred here and a few missed numbers there won't be noticed but help with technical implementation details (you can pre-allocate number ranges, encode some technical details in the number, even just use snowflake ids, etc). With namespaced 'small numbers', as you said, per-slug numbers will be scrutinized by users - if they file FOO-223 now and FOO-105 later, they will notice and they will be confused / surprised / unhappy. However, with per-namespace numbers you're at least given an opportunity to shard and have a less contested model. Approaching this as optional handles is probably a good future extension and would fit in the existing model. I'll keep this in mind when I get back to developing bugless. Thanks for your input!
- kevincox 6y ago
  > namespace separation is a feature which helps to keep the number of digits down I'm probably a minority as I think I have pretty bad memory but as soon as your tickets hit double digits I am failing to remember which ticket is which. So I don't really care if it is 3 digits or 7 digits. If I am trying to remember I'll probably just look at the last 2 digits anyways.

by q3k 6y ago

selfhoster11 6y ago

I tried this approach with Taiga.io, but it doesn't address another bonus of having slug-based ticket numbers - namespace separation is a feature which helps to keep the number of digits down, because each slug starts with its own counter. One of the problems with flat-namespace numbers is that the numbers are so long that eyes start to glaze over them. A three-digit number is pretty easy to tell apart from another just from the "shape" (if that makes sense) of the digits, wherease this "shape" is completely obscured once the counter exceeds 4 digits. Ideally, a system like this would just have a toggle to configure whether one wants to use a flat namespace (with or without slugs), or multiple namespaces with slugs. It's not that difficult from a technical perspective, since the primary key for the ticket will be some internal linear number anyway, and the separate namespaced slugs are just human-oriented handles.

q3k 6y ago
Noted. The single numerical namespace, from a technical perspective, is a double-edged sword. On one hand, you need to have a single, monotonically-increasing-ish number in your model, which is annoying when trying to design a globally distributed system. On the other hand, when users are (subconsciously) taught to not look that much into the actual numbers, there's opportunities to cheat, as an extra hundred here and a few missed numbers there won't be noticed but help with technical implementation details (you can pre-allocate number ranges, encode some technical details in the number, even just use snowflake ids, etc). With namespaced 'small numbers', as you said, per-slug numbers will be scrutinized by users - if they file FOO-223 now and FOO-105 later, they will notice and they will be confused / surprised / unhappy. However, with per-namespace numbers you're at least given an opportunity to shard and have a less contested model. Approaching this as optional handles is probably a good future extension and would fit in the existing model. I'll keep this in mind when I get back to developing bugless. Thanks for your input!
kevincox 6y ago
> namespace separation is a feature which helps to keep the number of digits down I'm probably a minority as I think I have pretty bad memory but as soon as your tickets hit double digits I am failing to remember which ticket is which. So I don't really care if it is 3 digits or 7 digits. If I am trying to remember I'll probably just look at the last 2 digits anyways.