GitHub Issues-only project management

Oh, sure, I don’t mean “why does this app exist”; I mean “why isn’t its underlying data model merged/synchronized with that of the other OS note-taking app.” Why can’t I see my computer’s Sticky Notes on my iPhone in Notes under “Sticky Notes - [Computer name]”? Why can’t I add a sticky note to my computer by putting it in such a folder?

Yep, I do the same. I also combine with github wiki for larger projects and documentation (often these will reference a bunch of issues).

Arguably any tool will eventually be hacked around to fit needs, unless you are the owner --in which case you just hack on the tool.

If anyone from Gitlab is reading: our OSS community would love to use Gitlab for everything, but we don't seem to be able to:

- disable the "packages and registry" menu item for the project (despite disabling it in the permissions) - odd help texts, such as "enable LFS to upload a design" displayed to non-admins - can't hide the service desk menu item, despite permissions.

I understand it's not an easy compromise to balance discovery and user-friendlyness, but then we have people in our community who repeat "gitlab is only for devs" because of this.

Example: https://lab.civicrm.org/support

Not super convinced.

First off, I am not sure why people like Kanban boards so much. It seems like the most inefficient way to display issues possible -- you can't see the details, the title gets cut off into lines of 4 letters each, and you still have horizontal and vertical scroll bars. The idea of Kanban was that if you didn't have space for a card, you wouldn't take on the task. To some extent, this can work for software; you can say "there are a maximum of 3 changes per release", and so if there are 3 cards in the "to be released" column you know you have to do one before anything else can proceed. But nobody has that rule. Meanwhile, does it apply to all the columns? Like, you can't report a bug in the software if the backlog column is full? It makes no sense to me, and I think it's a huge anti-pattern.

I much prefer Linear's cycle view ("sprint view" for those of you that think sportsball metaphors play well with software engineers), where you can group issues and they show up as the category and then a list of issues that take up the entire horizontal width of the window -- so you can see what's in progress, what's to do, what's done, what's released, at a glance. Or during cycle planning, you can group by assignee and see that someone who is on vacation for one week and oncall for the other has 8 XL tasks assigned to them, and not commit to that impossible plan.

I'm not a fan of Github Issues. I find everything I want to do to be very high overhead. If I want to open three issues, I have to navigate to the issues page, click "create new issue", type a title, type a description, click "tags", type the name of the first tag, click it, delete the stuff I already typed, type the name of the next tag, click it, etc. Then you submit, and you see the issue that you just submitted. To file the next issue, you hit back twice, click "new issue", and repeat. It is incredibly tedious, and people flat-out don't file issues for stuff they're working on. (Projects and Milestones are similarly high overhead. They're infinitely configurable, so useless out of the box, and therefore require a bunch of setup you have to do for every project. If you treat Projects as their version of Epics, then you probably need a Terraform script of something just to get the right columns on the board, which as I mentioned I don't even like.) Github's workaround for all of this is some automation to make PRs close issues, and that's about it.

Github is also awful with notifications. If someone comments on an issue assigned to me, nothing happens. If someone @mentions me in a Github issue, it notifies my phone. If someone requests a code review from me, it notifies me on Slack. I don't know how anyone can tolerate a system that is this bad. It's like Microsoft made the product before they even bought it.

My experience with all of this is that people don't file issues for things they're working on, don't close issues that span multiple PRs, don't reply to issues that require their attention (or even know what's assigned to them), and leave tasks 90% done because crucial followup gets forgotten after Github automatically closes an issue. This makes the system actively harmful -- at best, it's a dumping ground for ideas that will never be. If someone was going to do something, they'd just do it. If it goes into Github issues, it is only worth it for "I thought of an idea that will take a month to implement, here it is". Very bad.

This doesn't even scratch the surface of what an issue tracking system can or should do, but is hopefully enough to convince you that it's totally useless. I don't know what issue tracking zen is, except that when I worked at Google their internal tool didn't have any of these problems.

Linear (https://linear.app/) looks really nice. It's like someone took my exact ideas for how an organization should manage projects and made it into a computer program. It's speedy. It tracks exactly the right pieces of information. It lets you take a look at the company's progress towards its goals, across teams, with one click. You can operate it entirely with the keyboard. It has an inbox for everything that requires your specific attention. It understands the concept of issue triage. Really great tool. Miles ahead of Github issues (and the things that integrate with Github issues, like Zenhub).