I've been working on using github projects beta for the past couple months. I'm super excited for it, but right now it's hard to use because because it lacks basic features.
Things projects have that beta projects don't:
* No easy way to automatically add issues from a repo to your project. You have to add them one by one, or use the graphql API, which lacks batch operations.
* No issue preview on the board.
Basic feature missing from sheet view:
* You can't sort issues along the dimensions available in a repo's issue tab (e.g. newest, oldest, recently updated).
I thought I must have been missing something, until I realized that github's public roadmap repo itself uses a bot to add issues [0]. There's an issue there listing out the parity items [1], which will be super handy!
> * No easy way to automatically add issues from a repo to your project. You have to add them one by one, or use the graphql API, which lacks batch operations.
Yup. I spent an hour evaluating it last weekend, and this is where I stopped. It's difficult to make good use out of so many of the features when there's no way to bulk-add issues to the project tracker.
I got really excited for this when they previewed it a while back but the thing we got just feels like a hobbled spreadsheet with a lot of usability issues.
Our team is really struggling with Projects for these and many other reasons. The most annoying thing is they hijack CMD+F to use their command-line-like filter, which prevents me from quickly finding words that I want to see on the page. There's also no way to just simply make a ticket from the board itself, and the main value prop of using a Github product -- keeping Engineers in the Github environment without having to have multiple tabs opened -- is completely wiped out by Projects opening a new tab for anything you click on. Not impressed so far.
I have used many different project management tools - JIRA, GitHub Projects, Trello before it belonged to Atlassian, Trello after it belonged to Atlassian, Linear, Buganizer at Google, etc. etc. etc. I have used these tools as a member of small teams (~ 5 people), a member of large teams (~ 30 people), a manager of small teams (~ 4 people), and a manager of large teams (~ 20 people).
I have come to the conclusion that the tool doesn't matter. The team does. The best thing to do is to keep the size of your teams small enough that people can map their work and the work adjacent to them in their heads. That is generally amazing for productivity. Expanding the scope that people have to be aware of to make progress... that's poison for productivity.
After I realized this, I have never spent an additional moment bitching about my project management tool. These days, I just use a Google Doc but JIRA is a prefectly good tool TBH.
I like GitHub projects because my team only builds open source software and we see it as a way of communicating our road map and priorities to our users and our customers. However, we have found it less ergonomic than JIRA or Google Docs. We have settled on just using GitHub issues and weekly updates in our Discord.
I have tried Linear and it didn't leave me impressed. Not a black mark against them, though, as this is a space where you have to be orders of magnitude better than your entrenched competition because of the inertia inherent to teams already having content on the older platforms. I can just say with confidence that they aren't an order of magnitude better than Google Docs.
I think there's two reasons to have a tool to track tasks:
1. To help ICs keep on top of what they need to do in a given week. I think your post is a great summary of that reason. The tool doesn't matter as much here - whatever has the least overall impact on developers is likely the best tool here. JIRA can be 'OK' at this, but it can very easily get slow or bureaucratic, largely due to -
2. To help communicate to stakeholders outside of Engineering. This can be a bunch of things - whether a project is on track, is the team performing more or less efficiently over time, are we managing the backlog appropriately. Sometimes this is a requirement imposed from elsewhere ("when will project X be done"), but sometimes it can be something that the engineering team wants to communicate to everyone else ("our bug backlog is becoming unsustainable and we'll hit a crisis point soon"). This tends to put pressure on reason 1 - whatever will give you more useful data for this is going to make actually using the tool more cumbersome. Over-emphasizing this tends to result in the JIRA nightmares everyone hates, but ignoring it leads to conflicts between engineering and other teams when they're viewed as unaccountable and haughty.
For me, the sweet spot is Shortcut (used to be Clubhouse) - it's a very smooth UX that gets out of your way, but still offers some pretty decent reporting and analysis, and doesn't let you get too crazy with overconfiguring things so it always feels pretty snappy and gets out of your way.
Yet it seems like another issue tracker is being developed and advertised every year. Is there something missing in these tools that spurs people to keep making more?
Another issue tracker is being developed and advertised every year, because all the existing ones obviously suck.
_Clearly_ this is a software problem that needs technical fix. But it isn't. As the parent notes: "the tool doesn't matter. The team does"
Many times I have wanted to burn JIRA to the ground, but the fact of the matter is that if that happened, the org would simply re-create dysfunctional processes in another tool and then blame that tool.
Like Todo lists, or Todo iPhone apps, there's easy to make (potentially) + have a giant market aka everyone + approach a largely intractable problem (like weightloss, just perpetually non solveable problem spaces for most attemptees(
We’ve been using the beta for about six months now and have really enjoyed having everything in one place. I don’t miss Jira. The GH team listens to feedback and is consistently adding new features. I would give it a try if you’re on the fence.
It does seem confusing. This is referring to changes which are now in beta. These do seem to be big changes, meant to be a different way of working with your entire repo.
AFAIK, projects has always been a sort of bolted on project management app. These newest changes in beta seem to be a quicker way to manage a high load of activity on a repo.
The text in my GH present the product as "Built like a spreadsheet, project tables give you a live canvas to filter, sort, and group issues and pull requests."
The spreadsheet idea is the key I think. Imagine that a spreadsheet like interface would be easier to managing a high volume of activity, rather than a click to form view.
I second that. It has a limited feature set, which makes you focus on what matters. It is not like Jira that buries you in tons of options and information.
Yeah, unfortunately this is the truth (and also the definition of vendor lock-in, right? :)
IMHO GitHub Actions is the flip switch here. Eventually it will become so useful and powerful that its advantages will overshadow any migration's cost related to tools like Jira.
So I just started in a Senior Product role at one of those two alternatives that you prefer Github to. Any chance you'd be willing to share some specifics that you prefer from GitHub?
Sure! Here is a list of the most important ones (not in any particular order):
- The pull request and code review UI are more user friendly. Everything I need is within reach and clearly visible (build status, test runs, change suggestions, discussions, etc). Gitlab has most of it, but Bitbucket is far behind on this.
- I spend a lot of my "open-source" time on GitHub, so the whole workflow/UI feels super natural to me.
- Issues can track tasks, Discussions can track talking. This is great to keep things organized.
- Great (and simple) release page (recently they added automatic changelog generation from merged PR, which makes it even better).
- GitHub Actions. This is a game changer. It is a well crafted, well documented way of implementing new things in the project workflow. Being able to use a "random" action someone put up that does what I need is priceless. It's like using open-source libs to enhance my code pipeline (allows reusability, discovery, etc). This is also great for CI/CD.
- GitHub projects beta has built-in support for sprints, as well as custom fields (integrated with issues, which is awesome). Everything seems to orbit around the code (imagine coding some custom GitHub action, whose code lives in the same repo as my project, which reacts to the content of a particular issue).
- Issues (and discussions) use markdown and can embed images, videos, spreadsheet, etc, very easily.
This is amazing insight - thank you so much for taking the time, I really mean it.
Let's see if I can stretch the friendship ;)
Would you say that it's fair to say that there's a common theme running under a few of this items which is that Github see's the Repo as the "core entity", and has everything else hanging off that (Project management, conversations, pipelines, etc).
Whereas something - lets say the Atlassian suite for example, more see's "projects" as that "core entity", and then has things like your code, pipelines, conversations, etc hanging off it?
Also a question on Github projects (and this may just be my ignorance), but are the projects in Github tightly coupled to certain repo's? I never liked Gitlabs project tooling because the "Project" was too tightly coupled to a repo, making it kinda jank when you were working on a project that touched multiple repo's.
If you're gitlab, then ignore his criticisms, github is trash. If you're working on bitbucket, then you have my condolences.
Oh except one thing - when I'm reviewing commits, I want to see tags if there are any. I would also like to quickly be able to tag a release while seeing the last version number.
It would make it less annoying to gather all the changes since my last tag for release notes.
You raise a really interesting point re: Tags. I know Bitbucket does have some commit tag grouping functionality. Have you seen a system for that process in Github or Gitlab that you prefer?
We looked at Linear and decided on Kitemaker[0] as their core thesis is enabling collaboration with eng and product (and other stakeholders). The team does daily deployments and like Linear they focus on speed and hotkeys.
I’ve been using Linear as well for the past several months, and I’ve been really impressed with the speed and quality of software updates. It works great in the standalone app and in a browser. And for my needs, the free plan is plenty.
Yea we've been using Linear for almost a year, it's an excellent product. Basically think Superhuman for JIRA. Very clean, not overcomplicated, great keyboard support.
JIRA has a quite good keyboard support once you find the "." (dot) menu: press the . key, for example after selecting tasks or when looking at one, it opens a menu with autocompletion. This feature alone makes JIRA way more bearable for me, you can become really quick once you learn the correct keyword to complete for!
I just saw GitHub Projects for the first time as a result of this link. It looks like it has several of the key features of Asana, which is the project management tool that my very small web publishing consulting firm uses.
In terms of whether companies that are inclined to use web-based project management tools would drop what they are using and adopt GitHub Projects, I think the most likely candidates to do that would be companies where a great deal of the creative work already flows through GitHub and a huge percentage of the staff is in GitHub for some reason every day.
I don't think we would adopt this for work with clients. To the extent that our clients have GitHub as part of their toolset, the only people using it are software developers and engineers on the system administration - devops continuum. Our use of Asana is for things like project communications and high level time management, i.e. when will we hit a milestone.
Tangential but it seems like many web apps shown on HN feature a plethora of emojis. I feel like it's overused, lazy development, and therefore hurts the identity of the app when it shares the same suite of "icons" as so many other sites. At one point they were cute, but I see them absolutely everywhere now and they frankly look juvenile sometimes
I'm not sure how many people will step over the line you've drawn. Offensive as it is to certain sensibilities, there's a reason so many people and products keep using "the same suite of icons".
And really, it's usually all just user-generated content. Has GitHub even done any "lazy development" here, or are they just entering emoji in regular text fields?
This post is about GitHub but I'd like to shout out GitLab projects. It's good for my small team, we moved off Trello to that. Issues list and a simple board for visualization
The tool should be shaped around the team's best way of working.
The problem is that everyone thinks project/backlog organization is the silver bullet to getting things done. It's not. What they don't realize is that too much process or too little process can make or break team's autonomy.
I like GitHub projects. It is simple, Airtable/Notion inspired, and makes it very easy to see a backlog like a spreadsheet. The views are especially helpful for different projects, statuses, and dependencies. The best part about it? It's native to teams who work exclusively in GitHub.
I work on a suite of GitHub OSS repos, and this tool alone looks extremely promising. Even using the beta for a few months now has helped me put everything in one place with many views instead of having to use alternatives like ZenHub. I do everything in the open and need solutions that can be transparent with the very communities I build for.
This is looking good despite the bugs like editing titles in projects beta changes the issue's title on keystroke. It makes it quite easy to quickly create new issues and manage them from a single screen on the web. Big fan so far.
I manage a project that spans several repos, so I've been looking for a good solution for this. I really just want something that lets me prioritize Github issues from different repos.
I tried Github Projects a few months ago, and I don't recall the issue, but I couldn't find any obvious way of adding issues to a project from the issue itself rather than from the project view.
I've been using CodeTree, which does the job, but it feels stupid paying $50/mo for a SaaS whose whole job is to just show me a list of Github issues. Especially because I haven't seen any product development at all in the year that I've been paying for it.
I tried Linear, and I didn't get what all the fuss was about. It's pretty, but I found it unintuitive, and it seems like it wants to be the authoritative store for bugs and tasks, when I wanted to keep them in Github and just have different views of them.
It looks like this latest iteration of Github Projects offers enough for me to migrate away from CodeTree and save myself the $50/month.
> but I couldn't find any obvious way of adding issues to a project from the issue itself rather than from the project view.
You can add issues to the old Projects from the issue view the same way as the new Projects (beta), it just takes 2/3 clicks for both: On the right sidebar in your issue you have "Projects", then a dropdown of your projects, and then you can (optionally) select the column where to place them (without that selection, the land in some kind of inbox inside the board).
I am using CodeTree for the list view of issues in milestones. The new Projects (beta) unfortunately also only offers that via the in between step of manually adding issues to a project and then "tagging" them with the milestone again as an attribute I think :/
It is very frustrating that you can't set a default repo for issues to be created in for a project. Every single time you convert a draft to an issue you have to select a repo from a drop down of all possible repos you have available. A simple solution is just to remember the last issue repo you created and put that at the top of the list.
Working Features can be measured through automated tests.
A Working Feature is complete if the set of tests that "verify" it are passing.
The tests are tagged as verifying that feature, and likely include integration, performance and UI tests as well as unit.
Honestly it does not matter if the tests are written before or after the code. (Its really hard to write tests for a UI element that does not exist yet.)
How can I tell if people are working on the feature I want them to?
Seems they've just wrapped Issues with a container having metadata. Useful yes but not until they preview Issue content in the cards themselves - useless when you have to open Issue externally to view it.
I talk to dev team leaders (EMs and PMs) multiple times a week about project management and it's quite rare that we find anyone using GitHub apart from very small teams (2-3 devs). Our research suggests product managers especially tend to prefer things like Notion/Trello and really don't like the complexity of GitHub.
Disclaimer: I'm a founder at Constructor (constructor.dev)
Jira also has momentum. I've advised at least a dozen places on, or moving to Jira (I was in for a different project but watched it). The reasons I heard were: new CTO had it at the old place, waits it here; and everyone uses it. Many of those startups also didn't have a Jira expert and soon got tangled in workflow automation that mostly got in the way for small, growth phase companies.
Accounting for the use of Jira is easy: known quantity and name recognition. A better question is "With so many unhappy customers, how do we still account for the continued use of Jira as an org matures?" It's the same answer but with the additional caveat that learning a new tool that's so fundamental is disruptive. I consult and advise multiple orgs and have done so for years. I don't often encounter heavy supporters of atlassian products, despite the number of users. Jira is one of those things that flies in the face of most UX logic in that it doesn't appear to lose market share, no matter how much slower, unreliable, inflexible and generally unliked it is. It seems that once a founder has grabbed the first thing off the shelf, you're stuck.
Full disclosure: I have no competitive interests in this space, I just hate garbage tools. (Apologies to my actual friends who work at atlassian. Your software is terrible.)
So full disclosure, I recently (literally this week) started a role at Atlassian, but not on Jira. Standard disclosure - this is 100% my personal opinion and not that of Atlassian in any way.
I think the thing that sets Jira apart is process management. It's the feature that no other competing tool really has to anywhere near the same level of power. If you're at a big org, especially one that has regulatory obligations, the level of control Jira gives you over workflows is pretty unmatched and it allows you to enforce certain practises and processes into the ways your teams work that mean that when you get audited, you can point to your Jira workflow and be like "See, we have system enforced process controls".
I also think that the Jira UX is... weirdly nice (personal opinion), in a brutal utilitarian way. If you compare it to some of the startups that are trying to disrupt Jira (I'm looking at you, Clickup), the UI is SIGNIFICANTLY less noisy.
Big ClickUp user and I feel you comment about it. It has become a massive UX mess. They really need to clean it up per "use case" or have toggles for users to disable UX features.
Too much is too much, and it's getting close to being too much on ClickUp.
But one of the killer features (IMO) is the fact that you can customise the flow of issues to match a flowchart. "TODO - IN PROGRESS - DONE" only goes so far when the org gets bigger.
This way it's a lot harder to move issues to the wrong state and the workflow is clear for everyone.
Jira offers them much more in the way of process management, reporting, and integrations with the likes of ZenDesk for its complexity. They seem to think of GitHub as just for the coders and aren't comfortable there.
Thats a disappointing trend. I personally like github for project management explicitly because it offers more features and options (and they are continuing to improve it)
The old (non-beta) projects were quite useful as a simple kanban board integrated with Github. We used it in Firefox Graphics team with limited success. We use it actively in WebGPU group, and it works well for scoping the work for meetings.
I’m sure we’ve only scratched the surface of what can be done, especially with the new Projects. Excited to see how it’s going to work!
No it doesn't. Github Issues/Projects replicates about 10% of Jira.
Maybe basic issue tracking is fine for your use case. But if you have multiple teams or need to do planning across longer time horizons e.g. SAFE then this is where Jira comes into its own.
We're using the projects beta in our team of five. https://github.com/orgs/flucoma/projects/1 I really like the way that you can have multiple view on the same set of issues and PRS.
Things projects have that beta projects don't:
* No easy way to automatically add issues from a repo to your project. You have to add them one by one, or use the graphql API, which lacks batch operations.
* No issue preview on the board.
Basic feature missing from sheet view:
* You can't sort issues along the dimensions available in a repo's issue tab (e.g. newest, oldest, recently updated).
I thought I must have been missing something, until I realized that github's public roadmap repo itself uses a bot to add issues [0]. There's an issue there listing out the parity items [1], which will be super handy!
[0]: https://github.com/orgs/github/projects/4247/views/1
[1]: https://github.com/github/roadmap/issues/287