GitHub Projects – Customizable, flexible tool for planning and tracking work
docs.github.com
docs.github.com
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!
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 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.
_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.
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.
Definitely give GitHub projects a go.
Now how do I convince my bosses to do so..?
- will make developers happier (for me, GitHub is far superior than gitlab/bitbucket regarding tooling, e.g. actions, review, etc);
- is simpler to use, so it reduces management overhead;
- is friendly to non-dev teams, again reducing cooperation friction;
It will likely reduce costs overall. It might be by shipping faster (or better, or more robustly, or more homogeneously at least).
My personal take is that management people use Jira and alike because they read it is the "right" tool. Their motives might be weaker than you think.
We have lots of complaints about Jira but any time we consider moving it’s never worth the effort.
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.
- 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.
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.
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?
I was definitely using some project management tool within Github 3 years ago.
[1]: https://docs.github.com/en/issues/organizing-your-work-with-...
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.
Cannot say enough good things about Linear.
Never realized how slow other things were until using linear and was blown away.
Anybody used both Linear and Clubhouse/Shortcut? Curious what the main differences are - Shortcut is a good product.
I noticed that Project Boards (https://docs.github.com/en/issues/organizing-your-work-with-...) visually look a lot like the Board view in Asana when I'm working in a project based on the IT Project Plan template.
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.
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?
And they are native & work inline in text with no need to size or layout images. Or load another font of your icons.
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.
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 :/
If I just create a new project for each milestone instead of using the milestone field, I think GitHub Projects will do what I need.
Project Mgmt should at best be where are we now, and how did we get here. You can then use that to guesstimate how long the next steps might take.
You can get all that out of your commit logs and tests.
Project Mgmt should not be about telling people what to do, but telling them they are doing the wrong thing.
Working Features are all that matters.
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?
You can read the code. But otherwise you cant.
Disclaimer: I'm a founder at Constructor (constructor.dev)
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.)
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.
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.
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!
without using a vendor-specific markup format, too!
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.