Comment by swanson | Hacker News Reader

Comment by swanson | Hacker News Reader

I kind of wish that software issue trackers/ALM/SCM/whatever-the-fuck-its-called-today would be a bit more opinionated and enforce some set of practices. I think some people are looking to these tools for help building an effective software workflow and are left with a configurable product that can work great -- if you've run projects effectively before. But if you haven't it turns into a nightmare.

I know that workflow, work item types, how to transition between states is kind of a deeply personal thing -- but often I wish I could just eliminate the mental overhead of trying to figure out how this project, manager, and team are using Jira/Rally/TFS/Trello/Pivotal and what state I need to put something at what time and which fields need to filled out and if we are using tags and why adding this critical bug to the current sprint is giving me a big scary warning and are we calling this a feature or a story or an epic or an enhancement or a task or a subtask and if I want to be looking at what this tool is calling a burndown chart or if its really the milestone progress chart in this project and what was that filter you used to see bugs that were open and also defined because I'm not seeing the bug that my customer is asking about and are we supposed to put new information as a comment or in the description or is it a new linked issue or a new child task or a new child bug or a link to the integrated wiki page...

(maybe I'm just the only one with these scars...)

I very much agree. We have a workflow we really like that we'll be blogging about, and Ship is optimized to support it.

It's nothing novel, but it works well for us and we think will work well for other teams, even large ones.

These highly customizable products should have "workflow settings" that change a large group of settings to optimize a specific work flow. That and give an explanation/demo of the flow so that the user knows what to do.

That way if you don't want to figure out what works best for you and want to be told what to do, you can just set one of these workflows and disseminate that information to the people who will be using it.

https://confluence.atlassian.com/jira/configuring-workflow-1...

I find that Pivotal is pretty opinionated with the workflow you use. Specifically, it is meant for an agile process that is exactly that Pivotal (the consulting group) uses to develop their client products.

Pivotal is extremely opinionated. Seems like people love it or hate it. JIRA is totally unopinionated and is what you make of it. I've had awful JIRA workflows imposed on me and it's the worst. My current company is generous with admin rights so we pick the flow we want for every project and it's great.

Some nitpicks:

* Pivotal Tracker is the SaaS software you're thinking of.

* Pivotal Labs is the agile and lean engineering/design/product/data science consultancy, from which Pivotal Tracker first emerged as a product.

* Pivotal is the parent company formed from Pivotal Labs and other products (notably Cloud Foundry, Spring, Greenplum, Gemfire) several years ago.

Disclaimer: I'm work at Pivotal Labs.

Yeah, Googled and ended up on the main site. Thought they were doing a _really_ bad job of explaining their software for a bit.

Calling Tracker "Pivotal" is pretty common.

My first thought is we should add a "did you mean Tracker?" link somewhere, but that's got problems too. We work on a lot of software.

Disclaimer should of course say "I work at Pivotal Labs".

This is what I get for not pair-posting.

I don't know much about carpentry, but I've seen that they often build custom patterns and guides to make the work on a particular job easier. Maybe they need to cut the same angle or size or shape many times, or drill perfectly aligned holes, whatever. They don't go out and buy tools that specifically match the requirements of that job, because that would be silly. Who would make such a thing, and what do you do if it's not quite perfect? Instead they use the materials around them to create helpers and guides and patterns.

It sounds like you could use the same kind of thing. Someone entering an issue doesn't need to be presented with a JIRA server and told to go at it. A tool like JIRA has some tools for guiding users (e.g. embeddable, customizable javascript forms). And where JIRA isn't cutting it, any self-respecting tool has an API that gives you all the power in the world. You want a dashboard that shows you just the charts you want, and clearly explains what they're showing? There's a lot of material all around you to make building that for yourself easy. Wishing for an opinionated and rigid solution that happens to match what a project of nontrivial complexity needs is not realistic.

I guess tags/status/naming hasd a function similar to interpunction: It can guide the consumer of the info in how to relate the items together. Some structure the blurp does not hurt ;)

(I very much agree with your point)

See zube.io (kanban-like board for github).

Waffle.io and ZenHub are also similar for GitHub

But "peer review" stage is missed in these tools. It is essential for me.

in that case, you add https://reviewable.io into the mix. now you have GitHub issues managed via a kanban like board, and peer review with everything going through pull requests.

the pull request is blocked until review is complete, and tickets are automatically closed with pull requests. it's a pretty great workflow

Totally agree with you on this.

JIRA does this now.

When I see the above definition of mental overhead associated with these tools I immediately think "JIRA" because it can literally be configured in millions of different ways, and people seem to like to configure the hell out of it.

Unless by JIRA does this now you mean, "JIRA allows for a many confusing setups, leading to the above situation more often than not" I have to disagree here.

What JIRA 6.4 does is suggest preconfigured workflow templates. What JIRA 7 does is, separate software tracking (with Agile boards, Git branches, code reviews and builds) from service desk or basic ticket management.

What it doesn't do is require a workflow. It is possible to start with a Scrum wf, then progressively change it into a waterfall hyena with cumbersome required fields and impossible permission-based transitions. In fact, I've met many people who have the opinion that JIRA is cumbersome, just to discover that their sysadmin is a knee-jerk person who blocks any initiative within their entreprise using misconfigured software.

JIRA isn't opinionated in the sense of OP. OP suggests that saying "We use [Bug tracker name]" is equivalent to saying "We're Scrum with branch tracking and timetracking", because the bugtracker would enforce checks and a layout without much possible configuration.

For example, Trello or Bitbucket Issues are quite opinionated bugtrackers.

For me, being a useful piece of opinionated software means "hey, we want you to do things this way."

Then rely on the users being smart enough to not hang themselves with the rope given.

What you're talking about is, as you said, bad management. The reason opinionated software comes and goes, and JIRA stays is specifically because just like you can build sync on top of async, you can build opinionated on top of flexible, but not vice versa.

Reply on news.ycombinator.com