5 ms·

- FAST web interface, being able to go from issue ID to browsing it, to replying in less than a second. - Dense, text-centric web interface. Whoever will use

by q3k 6y ago

- FAST web interface, being able to go from issue ID to browsing it, to replying in less than a second. - Dense, text-centric web interface. Whoever will use the tool will use it often enough that the UI should value utility over style. - Fast, rich search, with fuzzy full text search and key:value syntax (eg.: author:foo, status:closed, etc). - Single, flat namespace of issue IDs, preferably numeric, and the ability to follow a single issue ID as it's moved across boards/categories. - Low friction update/create UX. Users should file issues early and often. - First class email integration - replying to issues via email should be as good as replying via web UI. No 'write above this line', make it smart. The issue tracker should basically eradicate the need to have private email conversations. - Unopinionated hierarchical category/component system, with per category customization of authentication. No fixed project -> board -> epic -> story -> task nonsense, let me adapt the tracker to my flow, not the other way around. And especially no fixed code repository / category relationship. And finally, no, tags are not a replacement for this. - High quality API for automation. Features like kanban boards and other 'higher level' constructs for managers should be implemented using this API, so that users can modify and implement their own 'views' as needed, instead of relying on some fixed functionality. - On premise, cloud-native deployment, eg. backed in cockroachdb. Cross-region failover/sync for geo redundancy. (context: I hope to have time to finish https://github.com/q3k/bugless https://github.com/q3k/bugless some day, or that someone just beats me to it)

selfhoster11 6y ago
> Single, flat namespace of issue IDs, preferably numeric, This has always annoyed me about existing open source alternatives to Jira. I actually like ticket numbers with a project slug, because they add far more context. A five-digit number is far less readable than ABC-123, because you know it associates with project ABC.
- 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.
- kevincox 6y ago
  My major issue is that tickets move between projects or affect multiple projects so you get the situation where this slug is often correct, but often isn't. Or worse you move the ticket between projects and the slug changes, breaking links.
  - aYsY4dDQ2NrcNzA 6y ago
    100 times this.
  - selfhoster11 6y ago
    Ideally, moving a ticket from one project to another means that the old slug is just the alias for the new one. If that's the case, the link would remain unbroken if the redirection was transparent (ideally with an info message to inform the user that the ticket now has a new slug).
pradeep_srajan 6y ago
Looked at bugless, it is wonderful you started it but bummed that it needs more. The list you have is good and we are attempting to make things simple with https://bugasura.io https://bugasura.io Unlike bugless, it ain't open source but nevertheless, we should look deeper into your work, get inspired, borrow some stuff and pass on some credits to you.
johnx123-up 6y ago
FWIW, your repo screenshot is 404
- q3k 6y ago
  Yeah, whoops, fixed now. I decomissioned that machine a while back but never fully moved the content :).
michaelmure 6y ago
I feel like those goals align pretty well with https://github.com/MichaelMure/git-bug https://github.com/MichaelMure/git-bug, and many are already there. If you feel like pushing your own project is too much to bear, maybe consider contributing to git-bug to make it your own?
- q3k 6y ago
  I know of git-bug, it's a great idea and I watch its development carefully, but I'm explicitly looking to leverage benefits of a centralized system with bugless. I'm not targeting open source software projects that need a decentralized system that works well with an existing Git repository, but communities and organizations that already run infrastructure, including SSO/authz. What I want, for example, that would be difficult/impossible to achieve with git-bug's current distributed model (if I understand it correctly): per-issue/component authorization (secrecy!), ease of access to non-git users, history rewriting/sanitizing, built-in large attachment hosting, gigabytes of issue data and generally large scale deployments for large organizations.
  - michaelmure 6y ago
    Let see: -- per-issue/component authorization (secrecy!): git-bug already support internally to attach crypto keypair to an identity and sign/verify the created commits. What's missing is proper tooling around that, ACLs and a way to configure them (a project settings datastructure), possibly a way to encrypt entirely the stored data. It's planned for the most part, good to have otherwise. -- ease of access to non-git users: the goal is to have the webui to act as the public portal with external auth (github or your company SSO). I definitely agree that a bugtracker should not be just on the dev computer and should not require special tooling. -- history rewriting/sanitizing: not so sure what you really want here. Editing comments is already possible. Otherwise, it's still possible to just delete a bug or add more concepts in the data model (archive, delete comment ...). -- built-in large attachment hosting: Definitely planned. The data model already support that, it's just a matter of exposing it in the different user interfaces. Now for the storage usage, see below. -- gigabytes of issue data and generally large scale deployments for large organizations: The funny thing when you put all the data in git is that the problem becomes "how to host git at scale", which is a sort of solved problem already. On top of the obvious, there is solutions like git LFS if you don't want to retrieve all the potentially large attachments. Also, as each bug is independent from each other, you can also shard a repo or just retrieve the bugs you care about with some filter.
vander_elst 6y ago
This seems inspired by buganizer https://developers.google.com/issue-tracker https://developers.google.com/issue-tracker
- q3k 6y ago
  Perhaps :)

by q3k 6y ago

selfhoster11 6y ago

> Single, flat namespace of issue IDs, preferably numeric, This has always annoyed me about existing open source alternatives to Jira. I actually like ticket numbers with a project slug, because they add far more context. A five-digit number is far less readable than ABC-123, because you know it associates with project ABC.

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.
kevincox 6y ago
My major issue is that tickets move between projects or affect multiple projects so you get the situation where this slug is often correct, but often isn't. Or worse you move the ticket between projects and the slug changes, breaking links.
- aYsY4dDQ2NrcNzA 6y ago
  100 times this.
- selfhoster11 6y ago
  Ideally, moving a ticket from one project to another means that the old slug is just the alias for the new one. If that's the case, the link would remain unbroken if the redirection was transparent (ideally with an info message to inform the user that the ticket now has a new slug).

pradeep_srajan 6y ago

Looked at bugless, it is wonderful you started it but bummed that it needs more. The list you have is good and we are attempting to make things simple with https://bugasura.io https://bugasura.io Unlike bugless, it ain't open source but nevertheless, we should look deeper into your work, get inspired, borrow some stuff and pass on some credits to you.

johnx123-up 6y ago

FWIW, your repo screenshot is 404

q3k 6y ago
Yeah, whoops, fixed now. I decomissioned that machine a while back but never fully moved the content :).

michaelmure 6y ago

I feel like those goals align pretty well with https://github.com/MichaelMure/git-bug https://github.com/MichaelMure/git-bug, and many are already there. If you feel like pushing your own project is too much to bear, maybe consider contributing to git-bug to make it your own?

q3k 6y ago
I know of git-bug, it's a great idea and I watch its development carefully, but I'm explicitly looking to leverage benefits of a centralized system with bugless. I'm not targeting open source software projects that need a decentralized system that works well with an existing Git repository, but communities and organizations that already run infrastructure, including SSO/authz. What I want, for example, that would be difficult/impossible to achieve with git-bug's current distributed model (if I understand it correctly): per-issue/component authorization (secrecy!), ease of access to non-git users, history rewriting/sanitizing, built-in large attachment hosting, gigabytes of issue data and generally large scale deployments for large organizations.
- michaelmure 6y ago
  Let see: -- per-issue/component authorization (secrecy!): git-bug already support internally to attach crypto keypair to an identity and sign/verify the created commits. What's missing is proper tooling around that, ACLs and a way to configure them (a project settings datastructure), possibly a way to encrypt entirely the stored data. It's planned for the most part, good to have otherwise. -- ease of access to non-git users: the goal is to have the webui to act as the public portal with external auth (github or your company SSO). I definitely agree that a bugtracker should not be just on the dev computer and should not require special tooling. -- history rewriting/sanitizing: not so sure what you really want here. Editing comments is already possible. Otherwise, it's still possible to just delete a bug or add more concepts in the data model (archive, delete comment ...). -- built-in large attachment hosting: Definitely planned. The data model already support that, it's just a matter of exposing it in the different user interfaces. Now for the storage usage, see below. -- gigabytes of issue data and generally large scale deployments for large organizations: The funny thing when you put all the data in git is that the problem becomes "how to host git at scale", which is a sort of solved problem already. On top of the obvious, there is solutions like git LFS if you don't want to retrieve all the potentially large attachments. Also, as each bug is independent from each other, you can also shard a repo or just retrieve the bugs you care about with some filter.

vander_elst 6y ago

This seems inspired by buganizer https://developers.google.com/issue-tracker https://developers.google.com/issue-tracker

q3k 6y ago
Perhaps :)