mhoyeI felt this in my teeth.
Lemme lean into this a little harder: JIRA is what companies buy when they should have invested in manager training five years ago.
Benjamin Smedberg@mhoye very curious about this because I can’t tell if you mean jira in particular or bug tracking systems in general.
@bsmedberg Every project needs issue trackers, but describing Jira as an issue tracker is like describing McDonald's as a restaurant. It's a organizational culture and language least-common-denominator normalization tool whose endpoint happens to resemble an issue tracker.
A well-functioning issue tracker is a core part of making an org visible and legible to itself; adopting a tool that forces every part of an org to speak the same operational language is the lowest-trust path to that goal.
Andromeda Yelton@mhoye @bsmedberg mcdonalds but like…if the franchisee had strict instructions for how you may and may not eat a burger, and had locally altered the rules of physics to enforce that
Lee Ann@thatandromeda @mhoye @bsmedberg also you can’t order a burger without checking all the options on all the items, even the ones this franchise doesn’t sell.
Josh TriplettI think I'd *prefer* the "McDonald's of issue trackers", because at least it'd be a consistent "meh" experience everywhere. Jira is different everywhere, typically encoding every random field someone once wanted so that prospective issue filers have 50 fields to fill out and "computer says no" is the response to anything that doesn't fit the presumed process.
Paul CoenYup. When we re-implemented, I made sure any project I had to deal with had far fewer mandatory fields and very few specific issue types. The previous iteration was insanely specific. The other projects were simplified as well.
@paulrcoen @josh @bsmedberg One of the challenges in issue tracker design is that the specificity in those fields is correctly believed to matter a lot. We know from SE research that the most important _predictor_ that a bug will eventually be fixed is whether or not it lands in front of the right team on first contact. In practice, bugs that get re-triaged 2-3 times are effectively gone, and overspecific fields are an organizational allergic reaction to that.
@paulrcoen @josh @bsmedberg When I say "allergic reaction", I really did mean that; it's an near-involuntary over-rotation on the fear of losing important bugs, without a critical sense of the org-wide cost of that specificity. A more level-headed approach is to realize that any bug that bounces twice is bouncing because it needs a _leadership decision_, not an engineering one. So, on the second bounce they should go into a manager's-triage queue, rather than engineering triage.
@mhoye @josh @bsmedberg Yup. We're relying on a controlled vocabulary of labels across projects for classification and making sure the right team sees it. It's its own overhead, but we've found it a bit easier to manage.
Stefanie Janine Stölting@mhoye @bsmedberg #PostgreSQL doesn't use any bug tracker. There's only a mailing list.
Seems to work pretty well in the last 26 years.
Seems to work pretty well in the last 26 years.
Oliver Maksimović@sjstoelting that's interesting. On the other hand, what works for one org may not work for others. I'm not defending Jira, it's a pile of trash. But, email for issue tracking / project management is (to me) as bad as Jira 😦
Tito Ciuro@oliver @sjstoelting But how do you manage priorities, manage bug state (proposal, in progress, verify, complete, etc), etc? Just replying to an issue helps keep track everything about the issue, but not within its ecosystem. Curious how you do that per release. There’s got to be another doc keeping track of it, no?
@oliver @sjstoelting This reminds me a conversation I had 20 years ago with a certain VP that hated DBs with a passion. A really, deep hatred I might add. He suggested storing data in plists (property lists) and index them separately. I wish I was joking, but sure as heck I’m not. That pushed me to write one of the first SQLite wrappers in Objetive-C in early 2002.
The man is brilliant, trust me, but this serious suggestion threw me for a loop.
True story.
@titociuro @oliver PostgreSQL has an extension for this: hstore
https://www.postgresql.org/docs/current/hstore.html
Developing failures that other people had already solved is stupid.
@sjstoelting @oliver Geez… is there *anything* Postgres doesn’t have?! 🤣 When will it make Cappuccinos? 😉
@titociuro @oliver A bit more fun facts:
The first .net provider hasn't been M$ SQL Server, it's been PostgreSQL.
And there is a foreign data wrapper to read from and write to Sqlite: https://github.com/pgspider/sqlite_fdw
@sjstoelting @oliver One step away from making Cappuccinos 🤣
Andreas Scherbaum@titociuro @oliver It's very well documented. PostgreSQL has a thing called CommitFest https://wiki.postgresql.org/wiki/CommitFest_Checklist?ref=timescale-blog
A list of previous and coming CommitFests can be found here: https://wiki.postgresql.org/wiki/CommitFest_Checklist?ref=timescale-blog
This is for new features. Bug fixes are done on email lists.
@sjstoelting @oliver Amazing. Such detail! My hat off to you, team.
@titociuro @oliver @sjstoelting There is no such thing, as far as I'm aware. People work on something, or they don't.
Companies might prioritize this internally, and have people work on this, using their internal tools. Which may or may not end up in upstream.
@ascherbaum @oliver @sjstoelting Right, but what if there some dependencies? That is, some prior work that needs to be completed before another task can happen? Just trying to understand how something as massive as Postgres can be managed via email/mailing list alone. Fascinating!
@sjstoelting @mhoye @bsmedberg It worked for 26 years, more or less. If it works "pretty well" is questionable.
iwein@sjstoelting @mhoye @bsmedberg Linus Torvalds started git to improve on email only mgt iirc. Linux kernel would be another example then.