111–120 of 223 posts
I don't use GitHub Issues [much] because I was under the impression that issues are not themselves stored as a git repo, but rather they are some kind of proprietary database GitHub maintains. Thus they create lockin for GitHub. Am I wrong about this?
I don't use GitHub Issues [much] because I was under the impression that issues are not themselves stored as a git repo, but rather they are some kind of proprietary database GitHub maintains. Thus they create lockin for GitHub. Am I wrong about this?
I don't use GitHub Issues [much] because I was under the impression that issues are not themselves stored as a git repo, but rather they are some kind of proprietary database GitHub maintains. Thus they create lockin for GitHub. Am I wrong about this?
I don't use GitHub Issues [much] because I was under the impression that issues are not themselves stored as a git repo, but rather they are some kind of proprietary database GitHub maintains. Thus they create lockin for GitHub. Am I wrong about this?
I mean, isn't that the case for practically any issue tracking system? Which ones store their issue (and comments, etc) within the repo?
if someone from github is looking at this, can u please include Gitlab's "Scoped Labels" in this - https://docs.gitlab.com/ee/user/project/labels.html#scoped-l... it seems that the new issues are going to operate on the basis of labels (as it should). Scoped/Nested labels are a godsend. For example, I can tag an issue with a label "UI::App::Android" and i should be able to filter on the basis of "UI::App" and get all…
Earlier quoted context omitted.
I think too many places try to treat their tickets system as a source of truth, rather than simply a work management system. * A task with a title that can be understood in context (by the implementer/stakeholder) is sufficient. * Pointing/effort estimate is even better. Ideally, everything should have points because it helps the team manage workflow and set expectations. * A description is nice, but often completely…
Trying to use one tool as both a reporting-to-management system and a communication medium for the people actually doing the work, is a great way to make it fucking useless for both purposes. And yet, that's the norm with ticketing systems.
I wonder how tense things are over at Atlassian right now. Jira seems so universally hated that it feels like any competition that ticks a few basic needs could start hurting them.
I wonder how tense things are over at Atlassian right now. Jira seems so universally hated that it feels like any competition that ticks a few basic needs could start hurting them.
> Jira seems so universally hated that it feels like any competition that ticks a few basic needs could start hurting them. I regularly meet with tech companies in the 2~10 person dev team range and easily 70%+ still use Jira. These co's have the choice of choosing Jira (i.e. it isn't being jammed down on them by a corporate overlord) yet there's still hate? I don't get it. I'm beginning to think the Jira hate is sim…
Stock Jira is not substantially worse than any other bug tracking system, other than being proprietary.
However, Jira is incredibly customizable, and if your organization adds a dozen mandatory custom fields, Jira can become horrific to use.
Workflow customization is one of Jira's selling points, and also one of its biggest dangers.
There's some value in a system that doesn't allow that level of workflow customization, and instead forces everything into a fairly simple and lightweight issue-tracking framework.
I personally am hopeful about this GitHub feature, but I do think there's a real danger of losing usability here.