Comment by q3k | Hacker News Reader

Comment by q3k | Hacker News Reader

  - 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 some day, or that someone just beats me to it)

> 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.

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.

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.

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!

> 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.

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.

100 times this.

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).

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

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.

I feel like those goals align pretty well with 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?

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.

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.

For secrecy and access, just relying on end-user keys and encryption is not good enough for me - e2e encryption UX is tricky (key management, backup, access from multiple devices, onboarding), and tends to turn less technically minded users away (or they lock themselves out by not properly backing things up).

For history rewriting and sanitizing: I mean, someone posted something that needs to be removed before it's seen by a wider audience. I don't know, customer PII in the wrong component, abusive content (eg. dox) on a public tracker or internally by a disgruntled employee, server logs in an attachment that should be removed a year after having been posted (in accordance with a privacy policy), etc. I want to ensure that content can be nuked, and access to sensitive data revoked. This is also another reason why secrecy via e2e encryption in a fully decentralized system doesn't work for me: if a user's key gets compromised, all secret data that this user had access to is forever accessible to the attacker. With server-side access, it can be revoked, which helps if the data has not yet been downloaded. Plus you can keep an audit trail to detect any attempts at data exfiltration, while data exfiltrated by key compromise might never be detected.

That's fair, those are indeed hard to do right or impossible (although I hope we can collectively solve the "people use crypto keys properly" problem at some point).

Just a note though, you could centralize git-bug. Standardize/build on what git-bug is doing, and just don't expose the bug data in the same repo as the code. You then just need the extra bits of centralized administration.

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

Perhaps :)

FWIW, your repo screenshot is 404

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

Reply on news.ycombinator.com