• phtrivier 11 days ago

    Something that does not try to treat each "issue" the same way.

    Bug ? You want to enforce "Steps / Seen /Expected" structure". And maybe hint that people should estimate the severity / criticity / cost to fix.

    Feature ? You want to optimize for people discussing the spec, and make it damn easy to know which decisions have been made. Bonus point for baking the "five why" in.

    Task ? For developpers, Optimize for splitting the task in smaller chunks, and make it very easy to give dependencies between tasks.

    For managers ? Optimize for letting the developpers rank the risk of each task to make it possible to estimate the overall risk of a set of features.

    Product Owner ? Aggregate features / tasks into roadmap that compute the percentage of each billable feature that is actually done. Associate a risk to selling something that is in the roadmap, but done done yet. Make it harder fo sales to still sell a feature that had knowingly 2% chance of being done by demo day.

    Sales ? Optimize for knowing the assumptions under which they can sell the stuff. Maintain a FAQ and list of caveats for your product ("does it work in China ? How much x do we support ? Etc...)

    See a pattern here : every user of a task system expect different things, and it's hard to make a system that transition from a role to another.

    Much easier to make another to do list on steroid with a poor text editor, a poor forum, and poor gant chart, etc...

  • geoelectric 11 days ago

    That's pretty much how JIRA works--based on issue type, you can define "screens" that expose different workflows and data.

    It's nice if you have a very clear idea of what you want your workflow to be, but can be a bit overwhelming to set up if you don't. Doesn't help they have a lot of different issue types though. It's a kitchen sink implementation for sure.

  • eterm 11 days ago

    One trouble with JIRA is that it doesn't come opinionated, this often means that if one team starts tweaking it, another team gets presented with 30 fields and no idea what to do with them all.

    Or you get one location who try to use it while simulataneously another location might use it in a completely different way, and then it becomes even harder to really keep a grip on what's going on.

    You also get fights over whether tickets should represent overall state (So they move from TODO/INPROG/DONE) or represent the next step needed (So they move from TODO/IN DEV/IN QA/TO DEPLOY) etc.

    Or you try to do both of those and have a state explosion and no clear idea of actual throughput.

    After using too many badly run JIRA instances I'd actually like a simpler system to come along and say this is how you use this tool, it's OK if you don't want to use it this way, there are other tools for that.

  • jasonpeacock 11 days ago

    This is a JIRA management failure - why is the same workflow being imposed on different teams?

    Either the company has agreed that all teams will follow the same workflow, then you do as described above, or each team owns their own workflow definitions.

  • cybrexalpha 11 days ago

    >each team owns their own workflow definitions

    JIRA actively makes this hard. To modify a workflow a user has to be a Global JIRA Administrator.

    The whole design of JIRA is based around management. It's not really for developers, as much at is is for your boss. This explains why Atlassian can get away with the user experience being so bad - it doesn't matter because developers aren't the ones choosing it.

  • mwarkentin 11 days ago

    I think the “new” JIRA project is more self management focused. Of course it only supports a small subset of overall features right now.

  • mcphage 11 days ago

    - it wouldn't assume that problems map 1-to-1 with solutions. A reported problem might require several things to solve, and a solution might handle multiple problems.

    - it would make it easier to collaborate. Most issue trackers have a single person assigned to a ticket, but I would want multiple: the person working on it, the person testing it. Other people brought in to answer a single question. A person brought in to do code review. Playing pass-the-baton about who's currently assigned to the ticket is frustrating.

    - it would have a more loose issue life cycle. Sometimes a ticket is in a clean state—in progress, finished, deployed. Sometimes it's not. Maybe it got deployed then reverted. Maybe it's waiting on something else. Maybe it's in branch somewhere. Most systems either offer nothing, or require you to set up a rigid set of states and transitions.

  • alangibson 11 days ago

    > Most issue trackers have a single person assigned to a ticket, but I would want multiple

    Totally agree here. Having a single assignee is total nonsense. Makes you wonder if the people building the tool use it.

    > rigid set of states and transitions

    I think the whole idea of a set workflow is a relic from the 90's that has little basis in reality, especially in an agile development team.

  • Karunamon 11 days ago

    I have to disagree with multiple assignees here for two reasons:

    - Accountability. If it’s everyone’s job, it’s nobody’s job. This is project management 101, every task needs a single person who is responsible for ensuring that task is done.

    - Scope. If you feel like you need multiple assignees, this can be a signal that your task is too high-level and needs broken down into smaller units of work (which will generally have one assigned). Something like Jira offers epics, stories, and any other custom issue type you can imagine for doing this.

  • mcphage 10 days ago

    > every task needs a single person who is responsible for ensuring that task is done.

    Indeed. But "done" means different things to different people—to the developer, to QA, to deploy engineers, to devops, to the stakeholder. And more goes into a ticket than done/not done, that needs other people to chime in.

  • cimmanom 11 days ago

    We just add fields to the ticket in Jira to track those various responsibilities and use a hook to auto-update them as part of status transitions.

  • CoolGuySteve 11 days ago

    A native desktop client would be nice. It's really the only thing I miss about Apple's issue tracker, Radar.

    The main thing a native client can do well that a web client cannot without extraordinary wizardry, is handle click and drag, list views, and multiple windows properly instead of highlighting a bunch of random text.

    Radar was based around 2 kinds of windows, a list of issues, and a particular issue's details. It could do stuff like "shift select many issues, drag the whole block to another project or parent issue", "ctrl-click multiple unrelated issues, right click, open selected issues in new window, select all, change priority, add parent issue", "drag issue from list view and drop in duplicate issues pane of current window".

    Despite being ugly and filled with a million textboxes, using Radar was a breeze compared to JIRA or Github.

  • Sir_Cmpwn 11 days ago

    Working on a ticket tracker myself. Taking notes...

    Some of my key design decisions are:

    Implement internal features like moving tickets between queues in an abstract way which can be leveraged for custom workflows via the API. For example, if you write a git commit which references a ticket, the "Joe Bloe referenced this in a [commit](link)" note which gets added to the ticket is implemented to leverage an API that you can leverage as well, to add any kind of notes on tickets. This works backwards, too, you can annotate commits with arbitrary information.

    Implementing other workflows on top of more fundamental features also addresses a lot of things. An agile/kanban-style queue of pending, in-progress, completed tickets, for example, (will be) implemented with a generic queueing mechanism, which you can use to implement any other kind of queues. Someone mentioned emailing someone when a ticket enters one queue, notifying Slack on another queue, etc - easily done with webhooks and a generic task dispatcher I'm working on, which is also where the code that links tickets to commits lives.

    Someone else mentioned being flexible about state transitions and such, which really annoys me about Jira (we use it at $dayjob). My ticket system accordingly treats the humans as smarter than it and lets you do any state changes you want, whereas Jira will get pissed with me if I try to move a ticket backwards in the lifecycle.

    Also, Jira is slow as hell. My software is much faster and requires no JavaScript. Someone also mentioned multiple assignees: check.

    https://sr.ht

  • parallel_item 11 days ago

    Context: I am a data analyst who previously was an auditor. JIRA was a game changer for me and I would have loved to have used it during my Audit career. As such, I want an Issue Tracker that works for technical and non-technical individuals.

    I would want my Issue tracker to be deeply integrated with the company's Shared File System and Developer tools so all team members have a place to share their work. The Task page would be a place where all the work done could be shared in a clean way and even serve as a quasi-wiki. Like a Jupyter Notebook, I would love to include Markdown and Code along with attachments, analyses, and opinions. Everything would be included, not just the final relevant pieces. Side-analyses stemming from anomalies and potential issues would be hidden but there for those who need them. If something changed in an attachment like an Excel file, these changes would be reflected. Adding dependencies on files and the information contained within them could be linked so that if Account Manager A changes File B, I know that my work on Ticker 123 is now potentially conflicted.

  • alangibson 11 days ago

    > The Task page would be a place where all the work done could be shared in a clean way and even serve as a quasi-wiki.

    This is something sorely missing from Jira. There's Confluence, but why should you have to create a wiki page to repeat a modified version of what you already have in a ticket.

  • cryptonector 11 days ago

    I'd like somewhat less emphasis on closing tickets and more on a big picture.

    Not everything is best represented as a ticket, but JIRA has tended to make management think it can get useful data from it, and that the useful data is "tickets closed" or "time logged". Then employees just optimize for that...

    Now, one can have tickets open for the purpose only of tracking work towards larger goals -umbrella tickets if you wish- and structure as much work as possible this way. This is cultural, not so much about the technology, but it needs to be widely adopted. Then you can have task, trouble, bug, etc. tickets that you fit (or don't) into these structures.

    Customization of various things is important, most notably ticket status. JIRA does have that, but it'd be even better if it came with good statuses to begin with.

    CLIs please. REST JSON APIs please. Email->ticket->email please.

  • jasonpeacock 11 days ago

    ^this. You get what you measure.

    To design a better issue tracker, figure out what you need to measure for success and then design a tool to measure that track changes that drive improvements in those metrics.

    For example, "feature completeness". When you achieve N of M features complete then you have an Alpha release - now build something to track the progress of those features.

    The same for bugs - they're really an aspect of your overall product quality. Figure out what quality metrics are important and build something to track the progress of improving those metrics.

  • smt88 12 days ago

    The problem with Jira is not that it's slow or crusty. It's not slow anymore, and any crustiness is hidden under the hood.

    Its real problems are a polarizing UI (I like it, others hate it) and flexibility that leans toward bloatware-level complexity. But you can configure it to look/feel as simple as Trello, of course.

    To beat Jira for me, you'd have to do something revolutionary, like having the entire issue tracker hosted/versioned in git (so issues are inherently tied to code in some way).

    I haven't thought that concept all the way through, but it seems like the only way Jira fails me -- when I need to manually tie issues to commits (even though it can be as easy as using a hashtag).

  • alangibson 11 days ago

    > entire issue tracker hosted/versioned in git

    I've been mulling over something like that. I don't see why issue tracker, documentation store (wiki, etc), and source code repo need to be separate. Seems more like path dependency more than reasoned choice.

  • myownlittlworld 11 days ago

    I wish there was some way to modify fossil data from within the repository itself. Like, if fossil's bug list were duplicated as files in the issues/ folder, and I could edit the bugs individually as files.

    Yeah, if there were some way to combine fossil and org-mode, that would be perfect. As it is, fossil by itself comes pretty darn close for me.

  • michaelmure 11 days ago

    https://github.com/MichaelMure/git-bug

    I very much welcome any help to make that happen :-)

  • merlincorey 11 days ago

    Maybe you would like bugseverywhere[0] for some inspiration, at least.

    [0] http://www.bugseverywhere.org/

  • liveoneggs 11 days ago

    fossil does this integration

  • fusiongyro 11 days ago

    The main problem with issue trackers is similar to the problem of programming forums before Stack Overflow. Issue trackers become a chronological pile-up of crap. Stack Overflow is an incredible leap from earlier programming forums because it isolated what was valuable (questions, answers) and moved the chaff out of the way (comments, revising the question).

    JIRA is basically the most sophisticated programming forum, for issue tracking. What we need is the Stack Overflow of issue tracking, that figures out what the real entities and actions are and eliminates the chronological pile-up.

  • PaulHoule 11 days ago

    Funny, I thought Stack Overflow was a spam site.

    Frequently I have to barge through ten screenfuls of code that don't work before I finally get to a correct answer.

    To add insult to injury SO doesn't allow questions about many important topics such as "how do I eliminate the wheat from the chaff for all the libraries I could possibly use to do this?"

    It might be 2035 when they finally add parenthesis to all the Python code examples so they work in Python 3.

  • ludwigvan 11 days ago

    Well, the idea that most people forgot or didn't realize (including me) is actually StackOverflow is a wiki so you can edit and fix other people's answers. You might need some reputations points before you can do that though.

    The idea was to get the definitive answer as in Wikipedia. It was a good time when SO came out, afterwards it degraded in quality like anything else in universe.

  • explainplease 11 days ago

    > StackOverflow is a wiki so you can edit and fix other people's answers.

        Your edit was rejected because:
    
        [x] It deviates from the original intent of the post
        [x] It doesn't preserve the goals of the post's owner
    
    That's what I got for updating an answer that was 3 years out-of-date. I had to post mine as a separate answer. That was 3 years ago, so my answer is now 3 years old (still accurate) and the original is now 6 years old. It has more than twice as many upvotes as mine, which languishes at the bottom of the page.

    I have better things to do than labor for the wonks-run-wild at StackOverflow.

  • fusiongyro 11 days ago

    It's fine if you don't agree with my analogy or don't like S.O. but I don't think this contributes much to the discussion of how to make issue trackers.

  • Maro 11 days ago

    It'd be cool if you could extract from bug reports (or test runs) when an "issue" occurs, and count that as an upvote. I've seen sth like that that up on dashboards at a company, they had an in-house test cluster that was continually running the think, counting exceptions, and showing the leaderboard of exceptions up on a big screen.

  • alangibson 11 days ago

    That's an interesting take. How would it work in practice? I would think that most teams want direct control what gets surfaced via severity, due date, etc. Or at least that's what they're used to...

  • fusiongyro 11 days ago

    I don't know exactly how it would work. But if I wanted to figure it out, I would start by taking a fairly large project's ticket tracker and sort through every reply on every ticket and try to categorize them into buckets.

    For instance, I'd expect you to find "me too" comments, and those should be eliminated, just as "me too" "answers" on S.O. are eliminated.

    I'd expect you to find status-update queries and replies. So that suggests you need a mechanism for pinging for an update that doesn't require a bunch of text from user and developer, or else some mechanism by which the freshness of a ticket becomes irrelevant.add new answers to old questions.)

    I'd expect you to find people posting workarounds, which would suggest that you want workarounds to be a different "type" than regular commentary, and you probably want them called out separately somehow. It sucks to have to read through three pages of identical me-too complaints to find a workaround and then read through another two pages of people thanking the workaround author for the workaround, as frequently happens on the Ubuntu tracker.

    I'm not sure if these are helpful examples or not, but I think when you see a pile of messages that you have to read through to extract content, you are looking at an opportunity to work out the hidden semantics of the thing, and turn those hidden semantics into first-class entities and actions, to make a more structured environment that will save people time.

    I have seen too many JIRA deployments where the only plan was, make the state machine larger and require more separate fields from everybody. But those fields and states really just represent the hope that you might not have to read that pile of comments. In practice, most of those fields wind up empty, most of those states wind up skipped over, and you still have to read the whole ticket. Why? Because a JIRA ticket is still fundamentally a chronologically-sorted forum thread.

  • michaelmure 11 days ago

    Shameless plug: I'm building an issue tracker integrated in your git repository, decentralized, fully working offline and from your terminal/web browser.

    If you want to join the fun, feel free :-)

    https://github.com/MichaelMure/git-bug

  • DizzyDoo 11 days ago

    I really like the idea of building an issue tracker into the Git file storage! Would you recommend it for use in real life projects yet?

  • michaelmure 11 days ago

    It might still be a little too early, I might still make non-compatible changes in the data model. But that's not too far.

    I plan to eventually have the ability to keep reading older version of the data, but it's not there yet.

  • ykevinator 11 days ago

    How are you doing offline on browser?

  • michaelmure 11 days ago

    Yes. `git bug webui` will start a local web server to serve a js app and a GraphQL API as a backend.

  • ken 11 days ago

    Two things I always want, which I'm amazed aren't commonplace yet:

    1. One of the fundamental operations, for all of software development, is taking a big task and dividing it into smaller tasks. The smaller tasks should inherit the relevant fields (e.g., assignee, and target milestone) from the original one, and the original issue should aggregate the relevant fields (e.g., sum the time estimates, and let me see one mega-diff of all the constituent changesets) of all of its sub-issues. Of course, sub-issues in turn need to be able to be broken down further.

    Most bug trackers are able to create dependencies between issues, so it's possible to create such a thing out of a dependency tree, but I've never used a system that made it easy.

    2. It should be Git-based. The state of the issue tracker is just data, and I should be able to work on that without a special web-only interface that requires me to be online (though it should still have a web UI). I want to use my own tools -- I would have saved a ton of time over the years if I could have just grepped the whole issue database for what I was looking for. This would also make it easy to write programs to operate on the issue data -- I don't want to learn your issue tracker's special API. Or do the same thing to 20 issues by having to click 200 times.

    On GitHub, everything is a repo (source code, project wikis) except the issue tracker. So close! It's almost like they were intentionally trying to make this one type of data difficult to work with.

  • noir_lord 12 days ago

    Pure API with a trello like level of attention to the API (there API is fabulous).

    Give devs the primitives to build their own without starting from scratch, my problem (me as sole programmer supporting software that 70 people use) is not the same as yours.

  • alangibson 12 days ago

    I like the idea of letting people roll their own with a set of primitives, but I'm not convinced that people really want that when it gets down to it. Devs like the freedom to change their tools, but wouldn't most rather be getting real work done than iterating on their issue tracker?

  • noir_lord 11 days ago

    I don't know, I've not seen it tried.

    However of the bug trackers I've used they all make it hard to set up custom workflows because the UI is a poor 'DSL'.

  • 11 days ago
    [deleted]
  • zAy0LfpBZLC8mAC 11 days ago

    It should have a proper bidirectional email interface.

    I guess you were more thinking about the view of a developer of the product or project, but what I hate with a passion is when other people expect that I create an account on their issue tracker and then use their user interface for what for all intents and purposes is writing them an email. Even more fun when that includes the need to enter into a contract with a third party (like GitHub) and you would have to read pages and pages of legalese first.

    If you want to have some UI for managing bug metadata, great, I don't mind, but don't expect me to use your UI. A bug tracker in some regards is a sort of specialized electronic messaging program. If you use Thunderbird, you don't ask me to "create an account with Thunderbird" or to install Thunderbird, you simply hand me your email address, and I use my MUA to send you an email--which you can read and archive and whatever in whatever MUA you prefer. It makes no sense to handle issue trackers fundamentally differently.

    But the same at least to a degree also applies for the developer side of things. While some of the issue tracker functionality probably is not a good fit for email, a lot of the day to day stuff very much is, and that even includes some of the management of metadata, so a good issue tracker should also have at the very least a bidirectional email interface, optimally with the possibility to manipulate bug meta data via email as well--see the Debian bug tracker for an example of a very powerful email issue tracker interface.

    An issue is essentially a thread, and as such, it should be mapped to an email thread, where you can reply to previous messages just as you can to any other email, without the need to switch to a different user interface.

  • alangibson 11 days ago

    > proper bidirectional email interface

    This reminds me somewhat of a helpdesk trouble-ticketing system. I wonder if the reason issue trackers don't tend to support email gateways is to increase engagement with the tool, or if they just aren't talking to their customers' external collaborators.

  • iamdeedubs 12 days ago

    I'd like to have cli be a first class experience. Work offline. GUI for the pointy hairs.

  • porphyrogene 12 days ago

    I wonder of people who work in sales say things like “CLI for the neckbeards.”

  • F-0X 11 days ago

    Absolutely, I think this would be a huge improvement. The ability to easily extract plaintext data locally would be a huge help with my personal organisation and planning.

  • binarymax 11 days ago

    Yes, something that interacts directly with git and its associated workflow

  • hairui 11 days ago

    phabricator does this pretty well

  • Maro 11 days ago

    Like "git for issues"?

  • parf02 11 days ago

    what's the pointy hair reference?

  • cco 11 days ago

    To elaborate, Dilbert's boss has pointy hair so it references "management".

  • xinsight 11 days ago

    dilbert

  • parf02 11 days ago

    thanks!

  • contingencies 11 days ago

    The main problem with issue trackers is they treat everything the same way (bug/issue, task, goal, project, milestone, team, etc.). Where they break out of the one size fits all mold their abstractions generally start to break down and using them requires mental hoop jumping and too many clicks.

    Key feature: Disparate views. View as self. View as department. View as project. View as team. View as team member. All views should work across an arbitrary number of repos.

    As a manager I frequently have to context switch like this and I want to see three things: what's being worked on, what has changed, and where we are headed. For the latter, a clear distinction between abstract/relative prioritization between tasks and a timeline view (GANTT or critical path or inter-project/inter-issue relations) would be good.

    The ability to summarize what's gone on today/this week (visually), eg. send me roughly what each team member achieved, status of their goals, what is blocking them, and what they're refocused on, where the time and money went. Critical when I am out of the office and don't want to spend time re-interpreting git commits across 10s of repos.

    Basically keep the need for human effort out of the loop wherever possible - remove the reporting cycle, just use git history, any other system history (wiki, issues, etc.) and auto-compile a comprehensive view.

    The fact that github only recently added beta org dashboards and they still have a long way to come shows there is demand here. However, you are effectively racing against github.

    Also, we do hardware so ordering or acquiring parts is a huge issue that affects speed of iteration. I would want connectivity to accounting, purchase order, order tracking and inventory management systems. The key feature there is order status transparency, largely driven by third party platform order identification and subsequent logistics provider tracking number lookup integration for realistic ETA.

  • ludwigvan 11 days ago

    - Editor integration. VS Code integration is easiest nowadays I guess.

    Most programmers hate leaving their editors and dealing with text entry boxes on browsers.

    In my projects, we have a wiki and a knowledge_base.md Guess which one I put random tips.

    - Separating data entry from data organization.

    This is the fatal mistake every web site does, confusing data entry with organization. Data entry should be free, organization should come later. That's a key reason Excel is so popular, you are free to write to any cell. None of the draconian things of forms where you are forced to think in preset boxes.

    (somewhat related: compare this with the lambda/kappa architecture and event sourcing vs relational databases)

  • retzkek 11 days ago

    > Most programmers hate leaving their editors and dealing with text entry boxes on browsers.

    The "Edit with Emacs" extension was a game-changer for me. https://github.com/stsquad/emacs_chrome

  • vec 11 days ago

    It should be as invisible as possible.

    I discuss an issue with someone on Slack or over email or whatever. I can invoke some magic command in band to capture the surrounding conversation and create a reference number. I can then cite that reference in code comments or commit messages. When my CI server deploys the fix, it automatically informs the other participants in the same channel the issue was created from.

    The last thing I want is yet another browser tab with another separate inbox to maintain. Interact with me entirely over the channels that I already budget attention to.

  • alangibson 11 days ago

    > I can invoke some magic command in band to capture the surrounding conversation

    I just read about a tool that does this for documentation. I really wonder how this would work in reality because the information you want in the issue will probably be spread across dozens of messages.

  • vec 11 days ago

    So capture dozens of messages. Better yet, capture dozens of symlinks to make it trivial for me to review the messages in the original context.

    The point is, I've already had a long, sprawling, disjointed conversation with the interested party. Don't expect someone to do manual data entry that will never actually be kept current enough to be useful, and don't force me to have the same conversation twice.

  • hakfoo 11 days ago

    To me, it would look a lot like Basecamp with tickets.

    You'd open a thread like a typical nested message board-- say "Red Widgets Project -> 2019 release 2 -> [Maintenance Team] Support Blue Widgets". There would be a series of posts, probably the first one being "We need blue widget support for customer xyz". At the bottom of the post would be links to one or more tickets for the described task. Then there'd be followup messages, discussing the feasibility of blue widgets, clarifying what blue widgets need different, or noting things they discovered in the process. Maybe late in the process, they add other tickets for "fix blue widgets turning yelliw" or "prevent SQL injection on the blueness value", and each one appears at the bottom of the message that spawned it.

    The tickets can have individual lifecycles, but the discussion threads would move back and forth based on activity like message boards do. Importantly, they remain both browsable and searchable, even if you have to click through a bunch of pagination. Maybe the threads can be flagged as "task complete" or other statuses to improve searchability.

    The discussion that goes around a ticket-- how to reproduce, the decision making process, context associated with the issue-- has long term value. In a ticket-centric system, this all gets attached to the ticket, which disappears into the void when it's marked complete. This model leaves i intact, and treats the tickets as decoration.

  • 11 days ago
    [deleted]
  • megous 12 days ago

    No one size fits all and there's no ideal. Choice is necessary.

    There are some universals though. Fast. I hate waiting 10s for page loads in Jira or anything really, if I'm searching for something.

    Good data export. Jira is very good with this. You can get XML with all the information, IDs, relationships between things, comments, etc in a single call.

    With this I can create a tool personalized for my particular use of the issue tracker, and only go to the issue tracker's website for non-routine tasks.

  • alangibson 12 days ago

    Totally agree on Jira's speed. Watching it creep toward a fully rendered page is what got me thinking about this.

    I also find customization to be way more trouble than it should be. You basically have to hack it to add a template to the description field.

  • iamdeedubs 12 days ago

    Yeah the customization options on JIRA kill me. I have an old joke I always reference when I join a new team

    > When your team grows to 25 devs, its an almost certainty that at any point of the day, one of them is adjusting a JIRA workflow

    - https://twitter.com/deedubs/status/880819973488340992

  • brayhite 12 days ago

    Our team has been pondering a move from Github’s issue tracking and projects to JIRA, and taking a peak at it has given me similar impressions; incredibly powerful but ultimately too large of an app for its own good. The paid integrations are also a frustrating reality to live with.

  • alangibson 12 days ago

    It's really capable, but you can feel it getting ready to collapse under its own weight. Same goes for Confluence.

  • 11 days ago
    [deleted]
  • larkost 11 days ago

    My biggest problem has been with connections to automated testing systems. Specifically in the ability to keep the two in sync. My professional work in the last decade has mostly been on those automated systems, so I have a somewhat unique view. But here is what I see as missing in most (but hvae seen good parts of at some internal systems):

    1. The automated system works on testing multiple configs on multiple branches. When problems arise they are marked in the testing system.

    2. In the really good ones a bug can then be filed in the issue tracker that includes one or more "rules". These "rules" cover the failures discoverd in the testing system, with limits on the matrix of configs, branches, and time ranges.

    3. So back in the testing system you can distinguish between "covered" and "new" bugs. You also can immediately see when a bug has been fixed, as the system then points out tests that were expected to fail that are not suceeding (flaky tests are a really nasty problem in this).

    4. In an ideal system (I was working on this part at one point) the failures would not simply be of the "it failed" variety, but rather look for a fingerprint (e.g.: patterns in the logged output, or in the stack-traces). Then you could see when another bug encoches on the first (sadly common in really large systems), or when two bugs happen to hit the same tests on different configs at about the same time (again, sadly common), and even have the system suggest when old problems re-emmerge to expand the rule coverage.

    Sadly there are no testing systems out there (that I have found) that can really support the "configs" model to make this really worth it. Filling that hole is what I would probably do if I won the lottery... but since I have to make a living...

  • 11 days ago
    [deleted]
  • porphyrogene 12 days ago

    GitHub Issues is nice and simple with sufficient tools to assign and categorize issues. Many similar tools are built on top of GitHub Issues and if they work independently they usually do so with an API that is a carbon copy of GitHub Issues’. If you commit to using GitHub then you can always build your own GUI or let people use Trello on top of it if they choose to do so.

  • LaundroMat 11 days ago

    Just a side note, but one way of sifting through the features commenters have been suggesting and prioritizing them should you be wanting to create a product out of this is the Kano model. (I'm not affiliated, but here's a great guide to the model: https://foldingburritos.com/kano-model/)

    I just wanted to share this because I've only discovered it recently (although it's been around quite some time already) and because it's been very helpful to me. I did a quick write-up of one project on Medium: https://medium.com/@monsieurthieu/before-spending-any-money-...)

  • alangibson 11 days ago

    Thanks for the links. I'm not planning on building anything right now, but the frustration that lead to me starting this thread might push me in to it one day.

    As for the Kano model, I'd take it further and do what I call the Buffer model: price people want something by collecting payment details before you even start building the product.

  • CuriousSkeptic 11 days ago

    I’ve always wanted something with a unified tag,list,tree,status approach. In one view I might want to represent an issue status as a kanban. In another the same status is an icon, color, size, checkbox, progress bar or what have you.

    F.ex let’s say I want to do a quick t-shirt sizing of a large set of issues. A quick way to do that in a workshop is a mute mapping into size bins.

    Also quick an free hierarchies are important. Workflowy style outlining, perhaps again with some additional labeling assistance depending on nesting level. F.ex if you want to structure things with impact mapping or story mapping and the whole ATDD thing.

    If I’m completely free to dream I’d much rather work with real pens, papers and walls though. So the dream is to simply fix the annoying physical limitations of that. Can I have unlimited, indexed wall space please? Also make it easy to rearrange groups of cards.

  • TXV 10 days ago

    I'm using Nulab's Backlog. This is sort of a shameless plug since I work for that company. However I must say that after several years of clunky issue trackers, this one feels very very refreshing. I won't waste your time with marketing speech, which you can find plenty of on the official website. But actually easiness of use and moderate configurability, plus a decent-looking UI, are the points our advocates praise most often.

    The company is very strong in Japan, where it was founded, but rather low-key in the rest of the world. I never heard of it myself before I joined, but after starting to actually use the product, I really wish I had.

  • jesterson 9 days ago

    I switched to Backlog too. Despite it being rigid (wee, being japanese product says for itself) and having small issues here and there, I can't complain much.

    Most important points for me with backlog are:

    - impossible to define task/issue additional states. - email notifications are not working sometimes

  • zzo38computer 11 days ago

    Currently I use Fossil (which is not bad, but there could be a better way (possibly even modifying Fossil to support such thing), I think).

    If it is on a remote server, support using a SQLite virtual table to access it (this does not mean the server needs to use SQLite to store the database, but only that it supports the equivalent of xBestIndex) (for local data you can just use a SQLite database without a virtual table), then you can make up your own queries (although you may need authorization to post messages, to view them shouldn't need authorization). A command-line interface to file issues (as well as to view/download them) is also helpful, and perhaps a HTML interface too. Use whichever interface works best for your use, or all of them, if needed.

  • sshb 11 days ago

    It should have basic concept of “queues with stuff” which can be integrated with anything.

    Examples:

    1. Website form → queue with requests from website → human/machine handling them

    2. App error happens → queue of errors → developer sees them in queue

    3. Something gets inserted to the queue → someone gets called

    All this should have some ui above it

  • bluGill 12 days ago

    Simple to figure out how to fill in all the fields, but not let me get by without adding all the required information.

    This does not exist and I've concluded it cannot exist. There is too much information that needed that has to be collected for simple to be possible.

  • alangibson 11 days ago

    I'd like to see a system that is modeled around freetext documents rather than forms. You could start with prose, and add in more controlled data via things like hashtags, @-ing other users, etc.

  • bluGill 11 days ago

    The problem is if I allow freetext someone will forget critically important information - like what product they were having problems with. Not to mention version numbers, and other details of their setup that are important.

  • alangibson 11 days ago

    Yea, you would probably have to have a sieve that only allowed issues with the minimal required data to transition into 'in progress' or something.

  • mcphage 11 days ago

    > modeled around freetext documents

    Are "freetext documents" a specific thing here?

  • alangibson 11 days ago

    No, just unstructured text. The idea is to start out with prose to encourage creative thought (as opposed to robotically clicking at a form) and then enrich it with more structured data later.

  • mcphage 11 days ago

    Ah, gotcha. I’ve seen a system like that at my doctor’s office, it always seems really clever. You just type whatever in, and if it means something, the system will link it up or help you complete the value or whatever. That would be much better than Jira’s strict fields.

  • apendleton 11 days ago

    I'd want issue state to be tied to branch state. I want an issue to be able to capture that it's fixed in branch A but not branch B, and if I merge A into B, it recognizes that it's now fixed in B as well.

    Some systems have very rudimentary versions of this: an issue is globally open or globally closed, but gets auto-closed when a commit is merged into one specific branch (master or whatever), but I'd want this to be much more generalized: fixed in a feature branch but still broken in dev and master, then fixed in dev once the feature branch gets merged, then fixed in master once the dev branch gets merged, etc.

  • vidanay 11 days ago

    Fogbugz/Kiln had a variation of this. You could easily see which branches a particular commit was in and it was tied back to the ticket as well. It didn't influence ticket state, but it was easily cross-referenceable.

  • alangibson 11 days ago

    Have you used Fogbugz? If so, what's your opinion of it?

  • vidanay 11 days ago

    I loved it! Unfortunately, I was overruled about three years ago and against (quite strong) protesting on my part, we left it for Easy Redmine (strong dislike).

    I have no idea what it is like anymore since it is no longer under to stewardship of Joel, and it's been quite a while since I used it.

  • slantyyz 11 days ago

    Fogbugz, now known as Manuscript, is pretty good. It is somewhere between overly simple (Github Issues) and overly complicated (JIRA).

    I like it way better than JIRA (having said that, I haven't used JIRA in years).

    If you're a startup, you used to be able to get a two-user account for free -- not sure if they still do it, as Manuscript/Fogbugz got acquired by another company recently.

  • SamWhited 11 days ago

    I basically want something that's not associated with any service (eg. I shouldn't have to create a Git repo on GitHub just to use their simple issue tracker), is easy to use for non-devs, and doesn't have any complexity: I want a form (possibly with some templates) where I can type text, the ability to comment, and maybe labels for organization and search. I've actually been working on something like that, but it's not quite ready for prime time; even if I never launch it as a stand alone product I'll hopefully keep it around for my own issues.

  • nurettin 11 days ago

    you mean like taskwarrior?

  • SamWhited 9 days ago

    I also want it synced across all of my machines, so probably with some sort of cloud service, and want to be able to share it with other people (so as much as I like a good TUI, I probably can't convince my coworkers in marketing or sales to use it); but that does look really nice still.

  • nurettin 9 days ago

    I use it with a self-hosted nextcloud. Integrated with jira so I can open issues really fast (thanks to pro: flag) boss is happy and collegues have no idea how I use jira so efficiently.

  • nwmcsween 11 days ago

    Git with:

        // [tag]: for inline issues and 
        .issue/issues/issue-slug-name.{md,adoc,rst,etc}, 
        .issue/tags/tag/issue-slug-name -> ../../issues/issue- 
        slug-name
        .issue/tags/tag/file#lineno -> 
        ../../../some/tree/file/with/tag
    
    For something advanced I would want a language like Gherkin but for bugs so users/developers could easily show the issue given some sort of state in a declarative language
  • simplecomplex 11 days ago

    It would look like: My manager emails me something to do. I respond to that email to update them. I can easily search, tag, star, and export/backup our “tasks”. It loads instantly, and everybody has access to email everywhere they go, on any device. There’s an archive of communication, it supports attachments, multiple languages, and screen readers. It also has the best uptime.

    So my ideal issue tracker is email. I haven’t used anything better.

  • alangibson 11 days ago

    Email is a nearly ideal version of a surprising number of things. The only places it really falls apart is with hierarchy (i.e. epics which contain issues which contain tasks) and in generating reports.

  • matfil 11 days ago

    I'd argue that "generating reports" is quite possibly an anti-feature in an issue tracker. It's a strong indication that whoever is building this thing is on the side of the managers, not the doers.

  • whalesalad 12 days ago

    I think it's Trello with an automation and management layer on top. Templates for preconfigured boards, workflows to add custom actions to a list or card, such as 'archive list to xyz board and rename to foo'.

    Then combine that with some kind of inception where a card itself can be a board that you can "enter". This way when a single card gets too heavy, it becomes a board without all of the ceremony around that.

  • alangibson 12 days ago

    I love the card-to-board idea. I don't know why more tools don't have a way to 'drill in'. Workflowy is basically built around the idea.

  • matfil 11 days ago

    Titles, optional brief descriptions, and an absolute minimum of other stuff. Not lots of structured fields. Definitely not custom states and flow-charts. If there's extensively discussion to be had, put that elsewhere. Ideally, e-mail.

    I just want a TODO list to glance over occasionally, not a system that can turn into full-time job in its own right.

  • edoceo 11 days ago

    We use one system for triage, others for tracking. Support phone, email and social drop in there, mostly closed right away, others then route to the proper system GitHub Issue, Trello, etc. Triage was our biggest pain point. And i wish for a system that forced WIP limits and only one P1

  • alangibson 11 days ago

    You make a good point about the need for triage. One of the things that In or just setup at work, all bugs get the bug label and a severity, even if someone just saw something odd and we're not even sure if it's a bug. Since everything goes on the same pile, you end up with a lot of junk mixed with the important stuff

  • brayhite 12 days ago

    A tool that all teams involved can effectively work in, or at least every stakeholder from each team can work in. Communication is incredibly vital, and if a tool gets in the way of that, or creates friction in clearly documenting what the next step is, it’s not worth the money or time.

  • alangibson 11 days ago

    That sounds like a vote for simplicity and an out of the box configuration that most won't feel the need to customize.

  • laurynas-s 11 days ago

    Moved away from Jira to GitLab and it is almost perfect.

    Some features are missing, but I hope the GitLab team will add sooner or later.

    In Jira, there was too much customisation which made it difficult to configure properly and as many times I tried to come up with perfect workflow, I have failed to do.

  • mdaniel 11 days ago

    For my curiosity, do you have one issue repo, or are the issues split up by repo?

    We have the latter, and it's monster annoying to try and discover in which repo folks filed tickets, because there's nothing in GitLab that validates the ticket belongs in the repo.

    Given a magic wand, I would actually just switch off the issue tracker for every repo we have, and create `the-org/issues` or maybe even `the-org/the-org` so I can have `the-org/the-org/wiki` and `the-org/the-org/issues`

  • dsumenkovic 10 days ago

    Hey laurynas, we'd love to hear what features you are missing. Is there already a feature proposal? If not, feel free to raise one over at https://gitlab.com/gitlab-org/gitlab-ce/issues.

  • pbedat 11 days ago

    There is a really neat JIRA plugin called "structure". That allows you to put issues into a hierarchy. We use these a lot to create roadmap, or breaking down very complex use cases and track the big picture. Would be a first class citizen in my ideal issue tracker.

  • sneak 11 days ago

    A definable FSM with a fixed set of transitions. Webhooks for each. Tagging, integrated or not into the state machine. Integration with branches and commit messages. GitHub issues is close.

    Ideally the whole thing is in git or sqlite or json.

  • bryan2 11 days ago

    Two thing. 1) native supported cli. Something like terjira but it hooks in natively and it should be supported by who-ever makes it. 2) All data in an easy to read format for easy migrations, searching, etc

  • alexchamberlain 11 days ago

    I'd like a system that can track things on different levels. Whether it be the business plan or the sprint stories, it's the same thing at a different level and translating between them can be tough.

  • PaulHoule 11 days ago

    The scary thing is that there are so many issue trackers out there and they are all bad. If you want to start a new one you'd better have a plan to avoid the traps that everyone seems to get stuck in.

  • krupan 12 days ago

    It would look a lot like Emacs org-mode

  • anotheryou 11 days ago

    The basics should be simple enough to sync cleanly to org-mode and it should have the api for it at least!

    Kanban, assigne (maybe as tag), tags, custom text-fields, custom date fields and that should be it.

    I'm slave to atlassian, but for you trello folks: https://github.com/org-trello/org-trello

  • rtitle 11 days ago

    A whiteboard.

    If you have more open bugs than can be listed on a whiteboard, you are in trouble anyway.

  • rammy1234 11 days ago

    a simple wiki would be my kind of issue tracker. But some simple email when your name is mentioned or your team name mentioned will be something of an simple but effective issue tracker

  • carter_harwood 12 days ago

    Addition of offline/sync support would be great.

  • sashk 12 days ago

    Fast, good search and stable UI.

  • kyberias 11 days ago

    It would be empty.

  • iblaine 11 days ago

    Not pivotal

  • 11 days ago
    [deleted]
  • 12 days ago
    [deleted]
  • throwaway2021 11 days ago

    One that forbids asking questions like "How is it going?" every 5 minutes.

  • tql 11 days ago

    My ideal issue tracker would be able to generate all pages in <1 sec

  • Sir_Cmpwn 11 days ago

    You would like mine :)

    https://todo.sr.ht/~sircmpwn/todo.sr.ht

    Most pages weigh <10 KiB on a warm cache, <30 KiB cold.

  • alangibson 11 days ago

    It says a lot about the state of the art that sub second rendering times is a big ask.