81–90 of 223 posts
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.
It floors me that they haven't addressed the underlying architecture issues that made Issues unusable: Issues are only for a single repo. Business users don't (and shouldn't) know what repo to add an Issue to. This is why we moved away from Issues and none of these new visualizations make the product usable until they deliver multi-repo issues.
Even as a developer, I don't always know which repo to file something against. And most "issues" span multiple repositories. Sure, I need to add feature X to repository A and feature Y to repository B (in order to implement some bigger project) but that's not how we plan or assign work.
More importantly, at our daily standup, we need a single view across all of our tasks/work, not the work within a single repository.
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.
Earlier quoted context omitted.
first step of any agile transformation is to get yourself neck deep into atlassian products. 2nd step is to setup complex JIRA workflows and reporting and use it to break all agile principles. third step is for your devs to take none of this seriously and put fake data into JIRA which your middle managers never catch onto. then your engineers who actually want to get shit done leave and you're left only with people w…
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…
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 issues.
One of the things i still notice about the boards is that it is created on the basis of status. Gitlab's boards are created on milestones/status...or LABELS. https://docs.gitlab.com/ee/user/project/issue_board.html#org...
Most importantly, dragging tickets across boards will change the labels. This is far more powerful than just hardcoding them on statuses.
Earlier quoted context omitted.
Maybe Github Issues is not supposed to work as a support ticketing system? You are allowed to move issues between repos, so in theory you could create a dummy repo where users can add issues, and then those issues can be moved to their appropriate repo.
What if I want to define a new feature that has both backend and frontend tasks, and have separate repos for the FE and BE? Which repo do we create the issue in?
If anyone from Github is here, can you please allow attachments of unrecognized file types? You won't let users attach their binary .plist prefs files and this makes Github issues unusable for my project.
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.