~starbreaker commented:
Nothing wrong with the ticket system that can't be fixed with the judicious application of high explosives.
gemini://midnight.pub/replies/3540
Yes well. While I'm not qualified to handle explosives, a brave
rm -fr /path/to/jira/database
would probably do.
This is going to be a nasty rant. If you are not in the mood of rants, leave now. If you are not willing to accept, that none of this computy stuff is neither intuitive nor self-explaining, then think twice about leaving now. I don't care if anyone is reading this, let alone if anyone agrees. You have been warned.
At dayjob we use Atlassian Jira (after having tried redmine and trac before). Once in a while I am forced to deal with the mess called tickets, excuse me "Tasks", or worse the backlog of said items. To exactly noones surprise these days make me angry fast[a].
Ok, I admit, I'm a little opinionated here: as a person with a doctorate degree in physics, I have spent a bit of time thinking about the relevance of a concept (like electrons, say) to real life (do these electrons really exist?). To make it short, a concept is a concept. And real life doesn't care a whee bit about my or our or someone elses concepts. Thus I conclude: electrons are a concept, they exist only in our mind. The concept is a somewhat successful attempt to summarize a set of observations. Electrons do not exist, they only exist in our minds.
That being said: The tickets in any old ticket system are tickets. Their content may summarize certain aspects of (technical im my case) real life. Their success wildly varies, but it's never better than say 20% or so. Real life is much too complex to be condensed into a bloody Jira Task.
Yes. I don't. I personally do not need these tickets. Why? Easy. I have emacs and org-mode and I keep a list of TODOs in a file called 1_todo.org. This file is structured, TODOs go into categories, e.g. into a specific project, which corresponds to a given target hardware. The project may be renamed any old time, the target hardware stays. Its hardware, after all. We might not have it available any more in production, however, it continues to exists at customers site[b].
So I have a "shadow-Jira" in emacs. The whole world of emacs possibilities at my finger tips. Rarely a need to grab the mouse. Large enough monospaced font everywhere. A bit of coloring (think font-lock) goes a long way[c]. Free form text, any language I prefer, rough, with edges, including a set of obscure jokes, inexplicable references, you name it. And the unwritten assumption, that /any/ of the written words may be wrong, always or since some time. This is my documentation for my brain. And as I have written elsewhere, my brain dump journal at day job has accumulated >250000 lines (>10 MB) in 5 years[d].
This is the interesting point. If I don't need them Tasks, who does? Well, those poor souls called project managers, they need them. Their perspective on real life is totally different from mine. For them the mile-high pile of funny and not so funny details about my portion of real life is ... invisible. They know to some extent, that this pile exists, but not more. These poor souls are unable to survive dayjob without the perspective that these tickets hold. Fair enough.
From my egoistical point of view Tickets are pretty much a SEP (somebody elses problem, thanks Douglas). Before you ask: I'm not against documentation, I do use Atlassian Confluence for that. The main work is to create a structure, that is navigateble, including links to other documentation, external references, code, you name it. And no, the search interface doesn't cut it. Unfortunately some external components cannot be referenced in usable links.
This has nothing to do with the importance of tickets or lack thereof. This section is pretty much exclusively about my inability to deal with the Jira Webinterface as configured by my lovely colleages to the best of their knowledge.
I grew up on computer terminals with 80x24 monospace layout. Green glyphs on black background. Maroon glyphs later. A separate view for graphics, I could watch the pixels of my formatted LaTeX-document arrive in small groups --- they were carried over the cable by the Turing omnibus, as the joke of those days goes.
Things have become incredibly fast since then. The 80x24 limit fell, monospace font was not a boundary condition any more. Near this point in time in this universe some poor soul had to define the "default font" for things computy. And they settled on Arial: proportional font sans serifs. That programmers cannot distinguish zero an Oh '0O' or Ih, ell, one 'Il1', in Arial, to hell. Something is up for sale always.
Things are still manageable for me, if content and presentation are separate things. I can select monospace font and be done with it. But alas, in email I have to select monospace font every time I start typing a new message. In Confluence and Jira, I haven't even tried. Because my presentation is then forced to everyone else. The separation has been dumped long ago. In Confluence I cannot edit text in raw form any more, another workaround gone.
Long story short: I cannot read Arial well, even if I increase the font size quite a bit.
Context: I can see well, I wear glasses, I do not suffer from any color blindness. More Context: [e]
When interactive elements on web pages came into use, they looked like buttons. They visually snapped, when pressed. That was taken straight from the desktop GUIs of the time, like CDE (common desktop environment). These buttons looked like buttons. I could find them. Plus they were always there. Nowadays a button is flat. I's middle gray on a light gray background. It doesn't visually snap. Most of the time it's not labeled with text but with mostly inexplicable symbols.
Worse: buttons which hide. They become visible only after I hover the mouse pointer over some element, or worse, if I actively select some other element. This often presents an insurmountable barrier to me.
Even much more worse: I have found that the "workflow" button in a Jira ticket does not show all possible states. I can identify this as a button, because it has some "v" icon attached, which makes me suspect a selection list to open. Strangely two of the possible states are missing. It took someone else to point out that the two missing states (Draft, Ready for Implementation) were separate buttons to the left of the workflow button. GUI Designer: 1, me: 0. I am unable to see any structural consistency here.
There's more: Creating a new Ticket. I press the blue "Create" button in a ticket view. A new thing opens. Well, not really, the current ticket is shaded out with a dark grey overlay, and a dialog box opens.
My expectation at this point is, that the newly created ticket opens in the place of the one, where I was, when I pressed "Create". But no. I have to somehow search for this ticket now. All this, plus I don't need them tickets anyway. Sigh.
Is he done yet? No. When I log in to Jira, I am presented with a thing called "dashboard", whatever this is. Someone explained to me, that I can place fancy things here, like the list of my assigned tickets, or the activity trail, or whatever. So I made an attempt to place the "tickets assigned to me" list there. In vanilla configuration this list is completely useless.
I have asked for a thing like a canvas, where I can place links to individual tickets and some lines/arrows and some text. Like I would do on my white board. Not available. I have no good idea, how to organize these tickets in such a way, that my brain can navigate them in a meaningful way.
I have learned the hard way, that my view of what needs to be done to achieve some deliverable is utterly useless, when it comes to transfering this view into tickets. I'm at a complete loss, how to organize them. I will not organize tickets outside of my narrow scope. I have learned that ticket of the sort "make it work" are useless. They are too large. They never get closed. I accept, that I need to help with the creation of tickets to organize some project or product, but I'm unable to see, how to do this in such a way, that it is helpful for others and not driving me mad.
So I will try this:
No, I'm not done yet. I have one more galling insult in this whole mess to report. A ticket is created in state "Draft". Fair enough. It is only visible in my backlog. It is then promoted to "Ready for Implementation", at which point it shows up in the left column of my kanban board. Fine. "In Implementation" moves it to the middle column. However, that should set all other tickets in this column to "blocked", I think. When I'm done I promote the ticket to "Ready for Verifcation".
Sounds good? It isn't. Noone is ever doing verifcation of my stuff. Since the beginning of this year, I have a new colleage, who is able to review my stuff. And that is good. He's smart and asks clever questions. But verification? That would need some well documented requirements, wouldn't it? Where are they? Ok, as a workaround I collect my own, however, those are on implementation level and not as seen from a production/customer/service point of view. So I can skip this step and just select "Done" without any loss of generality. And I know, this is wrong. A developer should be unable to release his deliverable directly into production. But well. Maybe in another universe.
I would actually be interested to hear, whether I'm alone with this (suspect no), and whatever comments you can make. Thanks.
~ew
---