We are trying out GitHub projects and I'm wondering if anybody has experience with this feature. What constitutes a project? What's your line in the sand? What is easier with this feature and what is harder?
Feel free to chime in on the general thoughts about project management if you have not used GitHub projects too if it's still sort of relevant. All input is welcome.
Oldest comments (9)
I think you'll get a different answer for what constitutes a project. What I've seen is projects can be across your organization or in a single repository. This makes working on large, cross-product changes easier.
Your team just has to buy in to the idea of using this tool and only this tool. I like the idea of it in that I can completely live in GitHub for my work. What makes it harder is that in my organization we have people who aren't developers that need access to our private repositories so they can be aware of the current work status. For us, we have to give up a license seat for it (which are limited) and give these members of our team write access to our repositories so they can comment on issues. We haven't come up with a way to address this yet, other than making promises to communicate status in a written way. This isn't hard, but it's a drag on the team some.
We're currently trying this out across a team of PO's, designers & devs for an open source application: github.com/inthepocket/white-label...
Since this one of our first semi-large OSS apps, we're trying to use Github Projects as a substitute for Jira:
Todo 👉🏻In Progress 👉🏻 In Review 👉🏻 Done. These auto update for the todo & done columns.I like how where the above is going, but overall it's still very minimal and creating 'tickets' out of the projects board directly is still a bit cumbersome since they need to be converted to issues first and then open the actual issue to do all the labeling & assigning.
Personally, I mostly use it as a road map or once (before I used Things.app) I used it as my personal todo tool to use Kanban for non-dev related tasks. But that was during the early phase when it came out, and it wasn't as mature back then as it is now.
Agreed with the story above. I use GitHub projects the same way as I use all similar tools (Trello for everything, Jira for office job tasks) in Scrum style.
It's for example, my last project with additional column
For reviewfor waiting for a review from a client.Check out zenhub. Pretty useful and similar to Github Projects (on the surface). Keep in mind I never used github projects. Zenhub have a chrome plugin (don't know other browsers) or a web app.
We were using zenhub for a while, but it is SO slow! We lost patience for it, which is why we're giving GH Projects a go!
I had to create a couple github projects recently. Before even entering github what I do is to have a meeting with the team involved in the project, and we have a brainstorm about our organizing system. Once we agree, we create different teams, each one of them using different labels, milestones and goals. CI (continuous integration) maybe added for a better performance, I also tend to give a fast seminar about Kanban (in which is based the github projects boards).
We use a single project board as the entire backlog for the team. It's a bit harder to see the whole thing and prioritize than, say, Jira, but the direct link between working issue and backlog is nice.
We've got four columns:
To Do, Doing, Blocked, and Done. Done means merged and shipped.
Labels are for estimations (1-2,3,5,8) and for category of thing (Front-end, Back-end, Pipeline, operational, etc) so we can get a sense of how much of each we've got lined up each sprint. I have milestones set up for major parts of the work but they don't really do me much good because you can't filter your project board by Milestones (yet? - Feature request!).
The automation pieces are not really working that well. Still manually closing issues for the most part.
Easier things: connecting development directly to your project board. Collaboration in issues that is immediately reflected in where you're tracking the work. Collaborating in issues is still better than other platforms and the ability to use Markdown, link to other issues, PRs, etc still makes this a great tool for the team to track in place.
Harder things: a filtered view of a larger more complex backlog that is useful for longer-run planning such as release planning and project planning. For those broader looks you really need to move stories into another format for discussion to keep things clean, or try to filter your Issues view to look at how things lay out (at which point you lose the prioritization piece of the project).
Being able to sort Issues by project priority order would resolve a lot of these issues pretty quickly and make it a more fully-featured, connected tool. I guess I could prioritize by emoji count... Being able to see projects by Milestone or label, and in priority order in a more "consumable" format is really the biggest thing missing.
I've really only used GitHub Projects to maintain requests for open source projects I've worked on. It provides you a KanBan board to manage the issues you are working.
I worked in releases so each new release was considered a project. Issues would be opened against certain releases. So we knew what work had to be done in that release.
I would recommend this handy little integration for people using the projects board: github.com/dessant/issue-states
You can auto close and re-open issues in specific columns. I've set mine up so that it closes the issue when I drag it to done, and re-opens if I pull it back to todo or in progress.