6 ms·

> JIRA was replaced by GitHub issues This is absolutely... not the case. Sure, for some kinds of projects Github Issues might do, but for anything "real" Gith

> JIRA was replaced by GitHub issues This is absolutely... not the case. Sure, for some kinds of projects Github Issues might do, but for anything "real" Github's issue and project management is a serious regression. --- These tools are not replacing anything, but addressing broader and broader markets. They lower the barrier to entry and bring more people into the fold (perhaps at the expense at having a lower ceiling of functionality).

typeofnandev 6y ago
If only it _was_ the case!
- madeofpalk 6y ago
  Sliding in here with the hot take, but Jira can actually be pretty good! Github is terrible at project management. The problem with Jira (or at least used to) is that it has so much complexities that let people make it overly complicated.
  - typeofnandev 6y ago
    >The problem with Jira (or at least used to) is that it has so much complexities that let people make it overly complicated. I actually really like this take, because a lot of the times it feels like a tool's complexity is from what it lets you do. I feel like if Jira was "dumber" (i.e., less feature "rich") it'd be so much better.
    - steveklabnik 6y ago
      This is why I prefer Issues. The lack of features is a feature.
    - madeofpalk 6y ago
      To be clear - you have to go in and actively make Jira worse to make it bad. If you stick to the modern defaults and don't add in additional workflows you'll be fine. It's certainly an indictment of Jira and it's technical legacy that it lets to make it bad.
      - aunty_helen 6y ago
        I worked at a company that created a team of people to go in and actively make jira worse. Of course that's not what it was envisioned as, their actual job was to make jira fit the stakeholders requirements and buiness processes we had. However, sometimes your crappy 60 person company doesn't know what's best. If jira didn't have the ability to make it crap it would be a better product and people would update their processes or maybe just try not to smush existing ms CRM workflows into a tool for devs.
        dragonwriter 6y ago
        > If jira didn't have the ability to make it crap Then your managers would buy a tool that did instead. > maybe just try not to smush existing ms CRM workflows into a tool for devs. If your employer wants a tool into which those workflows can be smushed and wants devs integrated into those flows, that’s what they’ll get. Blaming a tool for supporting your management’s desires is...missing the people obviously responsible for the working conditions that are frustrating you.
        aunty_helen 6y ago
        Jira existed as a better product before this and gained popularity without this functionality. I used and championed old jira in this business but hadn't used it for some time. A better realisation would have been that one tool isn't going to integrate everything in your business from developing software to dealing with customers billing.
        dragonwriter 6y ago
        > A better realisation would have been that one tool isn't going to integrate everything in your business from developing software to dealing with customers billing. The trend (e.g., ERP and BMS) is definitely toward that in a much deeper way than broad use of JIRA alone represents. The “better realization” is probably more subtle, and involves more respect for the line workers in defining how their work is done and what the requirements are for the components of a broad enterprise-wide automation system that they interact with are, and balancing that with the information preferences at higher levels so that the latter are satisfied (and maybe compromised in some ways) in a way which preserves the ability of the line workers to deliver business value. But, in either case, not having that realization is management issue, not a tool vendor issue.
    - gregmac 6y ago
      I was previously a JIRA admin, and what I very quickly found was making the workflows the least restrictive possible was the most effective. JIRA itself is quite feature rich and that can be abused, but using it to make your configuration relatively "dumb" makes the actual user experience a lot better. I very actively pushed back on any requests to add additional states, but nonetheless there were several of them though mainly to facilitate kanban columns and way our dev and QA people worked together. I think the biggest thing is I ended up adding a ton of transitions between workflow states. Eg: "QA in progress" straight to "Dev in progress" was allowed, as was pretty much any state to "Closed" (so long as resolution was wontfix/invalid/etc). It took lots of time to get that setup properly and ensure transition states had the right name (so the button in the UI had a logical label), but it was well worth it. The only real workflow restriction we had was that to set an item to "closed" with status="resolved" it had to have a fixVersion assigned. This was a trivial thing to deal with day-to-day but made the list of closed tickets immeasurably better (eg, building release notes, or tracking down what versions a bug affects based on when the feature causing it was originally introduced). Comparatively, I've used JIRA in a massively locked-down state -- where there are tons of required fields, very prescriptive workflow that often requires 3-6 transitions to get from one state to another, specific roles required to do transitions -- and it sucks. It makes the ticket content and statuses worse (not better) simply because everyone hates using it. If people aren't following the team's process (such as devs clicking "QA passed" without doing QA), that's a people problem, and it isn't going to be solved in the JIRA workflow editor.
  - dleslie 6y ago
    I happen to agree. I miss the data analysis tools Jira had at its disposal, and the ability to create home pages with all sorts of graphs, todo lists, and so forth. Since last using Jira I've never felt nearly as aware of the state of a project as when I did.
    - porker 6y ago
      Yes, dashboards are underrated by those who haven't used them. The data analysis tools did cause problems at one company I worked at. They had a very locked down JIRA install and management were in thrall to the burn-down chart. If you got behind you were hauled over the coals. The burndown chart only considered the rate tickets were closed. So developers started creating extra tickets at the start of a project, so that when they got behind on a larger issue they could closed off some of the small tickets and the chart would stay on track. Management never spotted.
      - Talanes 6y ago
        For some reason, plenty of people in management don't seem to realize that raking people over the coals over individual data-points just incentives your workers to avoid giving up data.
      - dleslie 6y ago
        Ha! I was a team lead at a company where something similar happened. Management was obsessed with the burn down chart and equated total completed with productivity. So I told my team to make tasks as atomic as possible. If it can describe two meaningful changes then it should be two tasks. I actually preferred this outcome. Instead of a large task for a feature, we had hundreds of tiny tasks that culminated in a feature. It was far easier to get a handle on what was getting done and what was the impediments.
  - deleted 6y ago
    [deleted]
  - eyelidlessness 6y ago
    I hate that I agree with this but... I soured on Jira because my first experience with it was a horrible Rube Goldberg configuration on a self hosted instance. Years passed, I tried a bunch of different ways to use GH Issues as a primary tracking tool. It works but it’s... blah. It’s a good outward facing tool, it’s not good for tracking internal work. Because there’s no organizing principle. My last job forced me to use Jira again and, don’t get me wrong! It’s still bad. But given the nature of my role in that job I ended up setting up a new board and I was pretty amazed to discover that you could set up a new project with relatively sane defaults. And you can turn most of the complexity off and get almost bare bones Trello. The only thing I couldn’t sort out to make it habitable: I really wanted to disable the “sprint” concept and have a single board without gymnastics. I don’t know if that’s just baked in or something the company configured. In any case, that bare bones Jira setup was basically functionally equivalent to GitHub Projects, and surprisingly a better UX. Neither are great, this isn’t praise for either. But I’m just owning my bullshit and admitting I was surprised that the (now year old) modern Jira UX surprisingly didn’t torture me as much as I expected.
    - CRConrad 5y ago
      > The only thing I couldn’t sort out to make it habitable: I really wanted to disable the “sprint” concept and have a single board without gymnastics. I don’t know if that’s just baked in or something the company configured. FWIW: We have sprints in JIRA at work -- but at my previous job we didn't. I doubt they've been added to the product in the couple of years since I left my previous employment, so I'll guess it was configured not to use sprints there, and still could be now.
      - eyelidlessness 5y ago
        We must have missed each other on passing trains. My experience was that sprints are not just built in but required. I set up my last project with a catch all “active” sprint that never ends, and a catch-all “later” sprint that also doesn’t end for stuff that’s not being actively worked on or considered.
        5y ago
breakfastduck 6y ago
I'm lost now when it comes to project / dev / story etc management tools. No idea what the best option is, any recommendations for tools developers will actually use or do you just need to do a custom integration with github issues?
- deleted 6y ago
  [deleted]
- burlesona 6y ago
  I switched from Jira to Linear and am very happy with it. Just the right mix of power, completeness, and customization, without any fussy fiddling. It’s also blazing fast.
  - breakfastduck 6y ago
    We're running Monday. Has to be used by approx 60-80 users mix of dev / old school projects & support. I'll check out Linear. Been looking at Clubhouse too.
    - design-material 6y ago
      What's wrong with Monday?
      - breakfastduck 6y ago
        Honest truth - our developers don't like it. Very DIY. You can build great workflows if you put the effort in. Brilliant reporting, main reason we adopted. Clubhouse for example gives the agile structure (epics, stories etc) by default and you conform to it. Minimal setup effort. From a 'management' perspective I actually like monday, by the actual end users don't seem to like it. Getting a true hierarchy and relationships requires similar thought to setting up a SQL DB. Powerful, but I don't think we have the resource to really build upon and support stuff.
        6y ago
steveklabnik 6y ago
I mean, it’s all very opinionated. I think at this point I am borderline “I would rather have no bug tracker than Jira.” Issues isn’t perfect but it’s the best I’ve ever used.
- greatgoat420 6y ago
  I have never used Jira, could you say more about your feelings towards it? Currently we use an old in-house solution and are thinking of shifting.
  - AlotOfReading 6y ago
    The biggest issue by far is how slow it is. I don't mean bubble sort slow, I mean deliberately engineered quantum bogosort. A cache-less refresh for me on a blazing fast dev machine takes between 3-10 minutes on a normal day, though it might only take 1m if the internet gods are feeling particularly merciful. That leads to all sorts of avoidance because using it for anything takes long enough to be worth documenting as a ticket in its own right. Compounding this issue is how many clicks even "simple" tasks take because of their bizarre choices. Basic necessities like changing ticket status can't be done without opening separate pages, etc. One you've actually managed to create a ticket and assign status, good luck finding it later. Backlogs inevitably evolve into infinite swamps that no one knows the full contents of. Not helping is the fact that the search is terrible. I often vaguely recollect some detail or test procedure that someone helpfully mentioned/documented in a ticket somewhere before closing. I successfully find maybe a third or less of those. Also it's highly customizable, so any skills or knowledge from one company don't apply to the installation at any other.
    - greatgoat420 6y ago
      Thanks for replying, I think I get it now. We use SharePoint which has very similar issues.
    - watwut 6y ago
      I don't know how you have it configured, but I have to say, we dont have these problems.
thrower123 6y ago
I desperately just want something like Trello boards in Azure Devops... There are boards, but they are so unwieldy. Just put all the work items on a board and let me drag them around and see everything at a glance. Everything else with the source control and build pipelines and wikis is so good, this weakness is glaring.
moksly 6y ago
I’m not sure I agree, I think things like GitHub issues are actually replacing Jira for a lot of companies who either aren’t yet, or not too heavily invested in the atlassian approach. We did a comparison program with a sister city who uses Jira for their entire process because it had been a good time-tracking system at the time, and we found that their project managers and developers spend around 5 hours a week on something that ours spend on average 35 minutes on. This is anecdotal and we’re not exactly real “software development” cases as we are small helper functions in major enter organisations, but it does speak volumes as to why using Jira in our little anecdotal setting seems terrible. This doesn’t mean our sister city will change their ways though, they won’t. So in a sense you’re right that jira isn’t getting replaced at their place, but it does mean we won’t consider it and will instead look to other tools.
- kwertyoowiyop 6y ago
  Jira is so horrid that I actually might turn down a job offer from a company that used it.
- madeofpalk 5y ago
  I work on a large open source commercially funded project, where we more or less have to use Github Issues in one way or another, because that's where community report issues, and I find it very difficult to plan projects on Github. Github Issues/Projects falls down in a bunch of small and minor UI issues. It's things like being able to have a seperate list of "these are issues for our project, and these are the ones we've prioritised/organised/committed to" (having a backlog) or just easier filtering and sorting. What I think Jira is really good at is having a backlog, and a project board, and being able to drag things between. It's such a simple set of features I used from Jira that I find valuable but is missing in Github Issues.
plorkyeran 6y ago
Jira is an amazing argument for the idea that having too many features is itself an anti-feature, and github issues' second biggest strength compared to it (behind the integration with github) is specifically that it doesn't try to do everything.
- cryptonector 6y ago
  Or an argument for doing it right. It's got a query language that looks a bit like SQL, just... not SQL. It's got an ugly but responsive UI. It's easy to over-customize. The real problem is that it gets over-customized, and as with all databases, schema is forever, so after enough years of using it you have: ugly remnants of how you used to do things mixed with the ugly new things you're doing, and a devops team dedicated to maintaining and further over-over-customizing your JIRA instance.
selfhoster11 5y ago
Github issues work well for simple needs and for issues that don't cross the boundaries of a single repo/don't refer to non-code activities. If even one of those is violated, you're much better off with Jira.

typeofnandev 6y ago

If only it _was_ the case!

madeofpalk 6y ago
Sliding in here with the hot take, but Jira can actually be pretty good! Github is terrible at project management. The problem with Jira (or at least used to) is that it has so much complexities that let people make it overly complicated.
- typeofnandev 6y ago
  >The problem with Jira (or at least used to) is that it has so much complexities that let people make it overly complicated. I actually really like this take, because a lot of the times it feels like a tool's complexity is from what it lets you do. I feel like if Jira was "dumber" (i.e., less feature "rich") it'd be so much better.
  - steveklabnik 6y ago
    This is why I prefer Issues. The lack of features is a feature.
  - madeofpalk 6y ago
    To be clear - you have to go in and actively make Jira worse to make it bad. If you stick to the modern defaults and don't add in additional workflows you'll be fine. It's certainly an indictment of Jira and it's technical legacy that it lets to make it bad.
    - aunty_helen 6y ago
      I worked at a company that created a team of people to go in and actively make jira worse. Of course that's not what it was envisioned as, their actual job was to make jira fit the stakeholders requirements and buiness processes we had. However, sometimes your crappy 60 person company doesn't know what's best. If jira didn't have the ability to make it crap it would be a better product and people would update their processes or maybe just try not to smush existing ms CRM workflows into a tool for devs.
      - dragonwriter 6y ago
        > If jira didn't have the ability to make it crap Then your managers would buy a tool that did instead. > maybe just try not to smush existing ms CRM workflows into a tool for devs. If your employer wants a tool into which those workflows can be smushed and wants devs integrated into those flows, that’s what they’ll get. Blaming a tool for supporting your management’s desires is...missing the people obviously responsible for the working conditions that are frustrating you.
        aunty_helen 6y ago
        Jira existed as a better product before this and gained popularity without this functionality. I used and championed old jira in this business but hadn't used it for some time. A better realisation would have been that one tool isn't going to integrate everything in your business from developing software to dealing with customers billing.
        dragonwriter 6y ago
        > A better realisation would have been that one tool isn't going to integrate everything in your business from developing software to dealing with customers billing. The trend (e.g., ERP and BMS) is definitely toward that in a much deeper way than broad use of JIRA alone represents. The “better realization” is probably more subtle, and involves more respect for the line workers in defining how their work is done and what the requirements are for the components of a broad enterprise-wide automation system that they interact with are, and balancing that with the information preferences at higher levels so that the latter are satisfied (and maybe compromised in some ways) in a way which preserves the ability of the line workers to deliver business value. But, in either case, not having that realization is management issue, not a tool vendor issue.
  - gregmac 6y ago
    I was previously a JIRA admin, and what I very quickly found was making the workflows the least restrictive possible was the most effective. JIRA itself is quite feature rich and that can be abused, but using it to make your configuration relatively "dumb" makes the actual user experience a lot better. I very actively pushed back on any requests to add additional states, but nonetheless there were several of them though mainly to facilitate kanban columns and way our dev and QA people worked together. I think the biggest thing is I ended up adding a ton of transitions between workflow states. Eg: "QA in progress" straight to "Dev in progress" was allowed, as was pretty much any state to "Closed" (so long as resolution was wontfix/invalid/etc). It took lots of time to get that setup properly and ensure transition states had the right name (so the button in the UI had a logical label), but it was well worth it. The only real workflow restriction we had was that to set an item to "closed" with status="resolved" it had to have a fixVersion assigned. This was a trivial thing to deal with day-to-day but made the list of closed tickets immeasurably better (eg, building release notes, or tracking down what versions a bug affects based on when the feature causing it was originally introduced). Comparatively, I've used JIRA in a massively locked-down state -- where there are tons of required fields, very prescriptive workflow that often requires 3-6 transitions to get from one state to another, specific roles required to do transitions -- and it sucks. It makes the ticket content and statuses worse (not better) simply because everyone hates using it. If people aren't following the team's process (such as devs clicking "QA passed" without doing QA), that's a people problem, and it isn't going to be solved in the JIRA workflow editor.
- dleslie 6y ago
  I happen to agree. I miss the data analysis tools Jira had at its disposal, and the ability to create home pages with all sorts of graphs, todo lists, and so forth. Since last using Jira I've never felt nearly as aware of the state of a project as when I did.
  - porker 6y ago
    Yes, dashboards are underrated by those who haven't used them. The data analysis tools did cause problems at one company I worked at. They had a very locked down JIRA install and management were in thrall to the burn-down chart. If you got behind you were hauled over the coals. The burndown chart only considered the rate tickets were closed. So developers started creating extra tickets at the start of a project, so that when they got behind on a larger issue they could closed off some of the small tickets and the chart would stay on track. Management never spotted.
    - Talanes 6y ago
      For some reason, plenty of people in management don't seem to realize that raking people over the coals over individual data-points just incentives your workers to avoid giving up data.
    - dleslie 6y ago
      Ha! I was a team lead at a company where something similar happened. Management was obsessed with the burn down chart and equated total completed with productivity. So I told my team to make tasks as atomic as possible. If it can describe two meaningful changes then it should be two tasks. I actually preferred this outcome. Instead of a large task for a feature, we had hundreds of tiny tasks that culminated in a feature. It was far easier to get a handle on what was getting done and what was the impediments.
- deleted 6y ago
  [deleted]
- eyelidlessness 6y ago
  I hate that I agree with this but... I soured on Jira because my first experience with it was a horrible Rube Goldberg configuration on a self hosted instance. Years passed, I tried a bunch of different ways to use GH Issues as a primary tracking tool. It works but it’s... blah. It’s a good outward facing tool, it’s not good for tracking internal work. Because there’s no organizing principle. My last job forced me to use Jira again and, don’t get me wrong! It’s still bad. But given the nature of my role in that job I ended up setting up a new board and I was pretty amazed to discover that you could set up a new project with relatively sane defaults. And you can turn most of the complexity off and get almost bare bones Trello. The only thing I couldn’t sort out to make it habitable: I really wanted to disable the “sprint” concept and have a single board without gymnastics. I don’t know if that’s just baked in or something the company configured. In any case, that bare bones Jira setup was basically functionally equivalent to GitHub Projects, and surprisingly a better UX. Neither are great, this isn’t praise for either. But I’m just owning my bullshit and admitting I was surprised that the (now year old) modern Jira UX surprisingly didn’t torture me as much as I expected.
  - CRConrad 5y ago
    > The only thing I couldn’t sort out to make it habitable: I really wanted to disable the “sprint” concept and have a single board without gymnastics. I don’t know if that’s just baked in or something the company configured. FWIW: We have sprints in JIRA at work -- but at my previous job we didn't. I doubt they've been added to the product in the couple of years since I left my previous employment, so I'll guess it was configured not to use sprints there, and still could be now.
    - eyelidlessness 5y ago
      We must have missed each other on passing trains. My experience was that sprints are not just built in but required. I set up my last project with a catch all “active” sprint that never ends, and a catch-all “later” sprint that also doesn’t end for stuff that’s not being actively worked on or considered.
      - 5y ago

breakfastduck 6y ago

I'm lost now when it comes to project / dev / story etc management tools. No idea what the best option is, any recommendations for tools developers will actually use or do you just need to do a custom integration with github issues?

deleted 6y ago
[deleted]
burlesona 6y ago
I switched from Jira to Linear and am very happy with it. Just the right mix of power, completeness, and customization, without any fussy fiddling. It’s also blazing fast.
- breakfastduck 6y ago
  We're running Monday. Has to be used by approx 60-80 users mix of dev / old school projects & support. I'll check out Linear. Been looking at Clubhouse too.
  - design-material 6y ago
    What's wrong with Monday?
    - breakfastduck 6y ago
      Honest truth - our developers don't like it. Very DIY. You can build great workflows if you put the effort in. Brilliant reporting, main reason we adopted. Clubhouse for example gives the agile structure (epics, stories etc) by default and you conform to it. Minimal setup effort. From a 'management' perspective I actually like monday, by the actual end users don't seem to like it. Getting a true hierarchy and relationships requires similar thought to setting up a SQL DB. Powerful, but I don't think we have the resource to really build upon and support stuff.
      - 6y ago

steveklabnik 6y ago

I mean, it’s all very opinionated. I think at this point I am borderline “I would rather have no bug tracker than Jira.” Issues isn’t perfect but it’s the best I’ve ever used.

greatgoat420 6y ago
I have never used Jira, could you say more about your feelings towards it? Currently we use an old in-house solution and are thinking of shifting.
- AlotOfReading 6y ago
  The biggest issue by far is how slow it is. I don't mean bubble sort slow, I mean deliberately engineered quantum bogosort. A cache-less refresh for me on a blazing fast dev machine takes between 3-10 minutes on a normal day, though it might only take 1m if the internet gods are feeling particularly merciful. That leads to all sorts of avoidance because using it for anything takes long enough to be worth documenting as a ticket in its own right. Compounding this issue is how many clicks even "simple" tasks take because of their bizarre choices. Basic necessities like changing ticket status can't be done without opening separate pages, etc. One you've actually managed to create a ticket and assign status, good luck finding it later. Backlogs inevitably evolve into infinite swamps that no one knows the full contents of. Not helping is the fact that the search is terrible. I often vaguely recollect some detail or test procedure that someone helpfully mentioned/documented in a ticket somewhere before closing. I successfully find maybe a third or less of those. Also it's highly customizable, so any skills or knowledge from one company don't apply to the installation at any other.
  - greatgoat420 6y ago
    Thanks for replying, I think I get it now. We use SharePoint which has very similar issues.
  - watwut 6y ago
    I don't know how you have it configured, but I have to say, we dont have these problems.

thrower123 6y ago

I desperately just want something like Trello boards in Azure Devops... There are boards, but they are so unwieldy. Just put all the work items on a board and let me drag them around and see everything at a glance. Everything else with the source control and build pipelines and wikis is so good, this weakness is glaring.

moksly 6y ago

I’m not sure I agree, I think things like GitHub issues are actually replacing Jira for a lot of companies who either aren’t yet, or not too heavily invested in the atlassian approach. We did a comparison program with a sister city who uses Jira for their entire process because it had been a good time-tracking system at the time, and we found that their project managers and developers spend around 5 hours a week on something that ours spend on average 35 minutes on. This is anecdotal and we’re not exactly real “software development” cases as we are small helper functions in major enter organisations, but it does speak volumes as to why using Jira in our little anecdotal setting seems terrible. This doesn’t mean our sister city will change their ways though, they won’t. So in a sense you’re right that jira isn’t getting replaced at their place, but it does mean we won’t consider it and will instead look to other tools.

kwertyoowiyop 6y ago
Jira is so horrid that I actually might turn down a job offer from a company that used it.
madeofpalk 5y ago
I work on a large open source commercially funded project, where we more or less have to use Github Issues in one way or another, because that's where community report issues, and I find it very difficult to plan projects on Github. Github Issues/Projects falls down in a bunch of small and minor UI issues. It's things like being able to have a seperate list of "these are issues for our project, and these are the ones we've prioritised/organised/committed to" (having a backlog) or just easier filtering and sorting. What I think Jira is really good at is having a backlog, and a project board, and being able to drag things between. It's such a simple set of features I used from Jira that I find valuable but is missing in Github Issues.

plorkyeran 6y ago

Jira is an amazing argument for the idea that having too many features is itself an anti-feature, and github issues' second biggest strength compared to it (behind the integration with github) is specifically that it doesn't try to do everything.

cryptonector 6y ago
Or an argument for doing it right. It's got a query language that looks a bit like SQL, just... not SQL. It's got an ugly but responsive UI. It's easy to over-customize. The real problem is that it gets over-customized, and as with all databases, schema is forever, so after enough years of using it you have: ugly remnants of how you used to do things mixed with the ugly new things you're doing, and a devops team dedicated to maintaining and further over-over-customizing your JIRA instance.

selfhoster11 5y ago

Github issues work well for simple needs and for issues that don't cross the boundaries of a single repo/don't refer to non-code activities. If even one of those is violated, you're much better off with Jira.