7 ms·

Great, a few more decades and it might become a usable bugtracker. What's next on the list? Maybe priority/severity or status/resolution? I helped on a quite

Great, a few more decades and it might become a usable bugtracker. What's next on the list? Maybe priority/severity or status/resolution? I helped on a quite large open source project for some time and loved working with Bugzilla. The announced switch to Github for that project was one reason I lost interest. I even prefer to work with a well administrated(!) Jira over Github issues.

StableAlkyne 2y ago
> Maybe priority/severity or status/resolution? That's already possible with the tag system. At least, that's the most common use I see for repos that decide to use tags. How do you envision this differing?
- akoboldfrying 2y ago
  Are you thinking of labels? I only know GitHub "tags" to be the raw git branch-that-never-moves kind.
  - ffsm8 2y ago
    Totally off topic, but Tags can be moved too. ;) It's mostly a convention that we use annotated tags (a tag that also creates a commit) and don't move them
- smarx007 2y ago
  Sorting by priority?
chrisandchris 2y ago
Transitioned from Jira to Gitlab. Jira has workflows/resolution states. Gitlab only has tags. It's a different mindset and a different way to work. I'm not sure I'm happy with only-tags because it puts the work to the end-user (i regularly need to add tags because someone forgot to add it - could not happen with workflows and proper transitions).
IshKebab 2y ago
> well administrated Jira Based on my experience that doesn't exist. Hell even if it did, Jira is sooooo unbelievably slow I would still take literally anything else. Maybe even Savannah. A colleague joked that we need a "waiting for Jira" Jira task.
- marginalia_nu 2y ago
  I think 99% of the problems with Jira stem from trying to use it for too many things at the same time. If it's used for tracking issues, it's great. If a team just uses it for keeping track of its ongoing work, it ok. If the team also uses it to plan work, it works less well. If management also uses it to keep track of what the team is doing, it works even less well, because now the team needs to put on a show for management with the tool it needs to track and plan its work. Now issues need to be phrased in a way so that they aren't causing outsiders to worry. Maybe don't say "problem" or "bug" so often. Use an euphemism. Can't we word it in a less concerning way? If upper management has a dashboard of all departments' boards, you get nested Potemkin villages where the jira tasks are performative for both middle management, who in turn try to dress things up even more for upper management. At this point, the team (which still needs to track its issues and ongoing work) likely has a secret second issue tracker via post-it notes on a door somewhere.
  - TeMPOraL 2y ago
    > At this point, the team (which still needs to track its issues and ongoing work) likely has a secret second issue tracker via post-it notes on a door somewhere. This. In my case, it was the whiteboard. It was at a place I worked ~decade ago, where everyone was using Jira for the official work management. That included management, but also included everyone in the electronics production and assembly branch of the company, so it was funny to compare our meticulously described sprint items with co-workers burning through dozens of entries a day, named by just long incrementing numbers.
- paulg2222 2y ago
  [dead]
- 2y ago
treyd 2y ago
Yeah I have no confidences in GH to become viable for issue management for large commercial projects. It works fine if you're a group of highly competent and aligned FOSS developers that need it more as a communication tool than a work management tool. But if you get to breaking work down to the level of a few story points it becomes completely unmanageable. The table view turns into a slog if you have more than like 70 tickets.
rbetts 2y ago
Using Github issues as a manager of multiple teams using multiple repos in GitHub has so many gaps, I often wonder if I'm just doing it wrong. The multi-repo issues feature a few years back was a huge step forward but also is very incomplete, still. Multi-repo labels and milestones, for example, are an obvious missing feature.
- lmeyerov 2y ago
  Exactly this, they are so close!
sangeeth96 2y ago
I really feel like GH needs to spin out Projects into a more dedicated, funded team while still maintaining a close sync in order for it to become more viable/interesting. Besides allowing it to grow faster and better, that should also allow for non-dev seat pricing.
bastardoperator 2y ago
They're called issue labels, go read up because your complaint isn't valid.
TeMPOraL 2y ago
IDK, but maybe, for the sake of people working in projects that are managed using Github/Gitlab issues, they'll spin off a separate "Tasks" features and allow to set dependencies on them.
FridgeSeal 2y ago
Jira is so abominably slow, that it should be laughed/shamed out of the room in any discussion of useful software.

StableAlkyne 2y ago

> Maybe priority/severity or status/resolution? That's already possible with the tag system. At least, that's the most common use I see for repos that decide to use tags. How do you envision this differing?

akoboldfrying 2y ago
Are you thinking of labels? I only know GitHub "tags" to be the raw git branch-that-never-moves kind.
- ffsm8 2y ago
  Totally off topic, but Tags can be moved too. ;) It's mostly a convention that we use annotated tags (a tag that also creates a commit) and don't move them
smarx007 2y ago
Sorting by priority?

chrisandchris 2y ago

Transitioned from Jira to Gitlab. Jira has workflows/resolution states. Gitlab only has tags. It's a different mindset and a different way to work. I'm not sure I'm happy with only-tags because it puts the work to the end-user (i regularly need to add tags because someone forgot to add it - could not happen with workflows and proper transitions).

IshKebab 2y ago

> well administrated Jira Based on my experience that doesn't exist. Hell even if it did, Jira is sooooo unbelievably slow I would still take literally anything else. Maybe even Savannah. A colleague joked that we need a "waiting for Jira" Jira task.

marginalia_nu 2y ago
I think 99% of the problems with Jira stem from trying to use it for too many things at the same time. If it's used for tracking issues, it's great. If a team just uses it for keeping track of its ongoing work, it ok. If the team also uses it to plan work, it works less well. If management also uses it to keep track of what the team is doing, it works even less well, because now the team needs to put on a show for management with the tool it needs to track and plan its work. Now issues need to be phrased in a way so that they aren't causing outsiders to worry. Maybe don't say "problem" or "bug" so often. Use an euphemism. Can't we word it in a less concerning way? If upper management has a dashboard of all departments' boards, you get nested Potemkin villages where the jira tasks are performative for both middle management, who in turn try to dress things up even more for upper management. At this point, the team (which still needs to track its issues and ongoing work) likely has a secret second issue tracker via post-it notes on a door somewhere.
- TeMPOraL 2y ago
  > At this point, the team (which still needs to track its issues and ongoing work) likely has a secret second issue tracker via post-it notes on a door somewhere. This. In my case, it was the whiteboard. It was at a place I worked ~decade ago, where everyone was using Jira for the official work management. That included management, but also included everyone in the electronics production and assembly branch of the company, so it was funny to compare our meticulously described sprint items with co-workers burning through dozens of entries a day, named by just long incrementing numbers.
paulg2222 2y ago
[dead]
2y ago

treyd 2y ago

Yeah I have no confidences in GH to become viable for issue management for large commercial projects. It works fine if you're a group of highly competent and aligned FOSS developers that need it more as a communication tool than a work management tool. But if you get to breaking work down to the level of a few story points it becomes completely unmanageable. The table view turns into a slog if you have more than like 70 tickets.

rbetts 2y ago

Using Github issues as a manager of multiple teams using multiple repos in GitHub has so many gaps, I often wonder if I'm just doing it wrong. The multi-repo issues feature a few years back was a huge step forward but also is very incomplete, still. Multi-repo labels and milestones, for example, are an obvious missing feature.

lmeyerov 2y ago
Exactly this, they are so close!

sangeeth96 2y ago

I really feel like GH needs to spin out Projects into a more dedicated, funded team while still maintaining a close sync in order for it to become more viable/interesting. Besides allowing it to grow faster and better, that should also allow for non-dev seat pricing.

bastardoperator 2y ago

They're called issue labels, go read up because your complaint isn't valid.

TeMPOraL 2y ago

IDK, but maybe, for the sake of people working in projects that are managed using Github/Gitlab issues, they'll spin off a separate "Tasks" features and allow to set dependencies on them.

FridgeSeal 2y ago

Jira is so abominably slow, that it should be laughed/shamed out of the room in any discussion of useful software.