This is the example of how hard it can be for companies, especially successful companies, to alter their course even slightly.
Github success was about making code repositories pretty and social. But this is no longer enough to keep evolving as a company of their size. Yet the internal product DNA still revolves around repos, so as a result, issues, wikis and now Projects (!) live under a single repository.
This is backward.
A project is a way to group resources to achieve a predefined goal. Those resources include multiple people, multiple issues and multiple repositories. Sticking a project under a repository makes no sense.
In fact, a code repository in most organizations is a fairly small and an insignificant asset, just another way to organize code, i.e. function -> module -> directory -> repository, etc. It's quite awkward to think of what your company is doing in terms of repositories, so anything Github adds to repos feels out of place by default.
Another example of repository-centric thinking is the homepage of https://github.com itself when a user is logged in. It's the most important page of all, yet nothing on it has any relevance to me: just a list of people I like starring random repos. Same thing for the organization home page, just a list of repos, again.
The Project idea is great. It had the potential to solve all of these issues by giving me a tool to organize digital assets in a way that's important to me. But sticking it under a repository killed it.
[EDIT] It's easy to be me and be posting a comment like this, telling successful people what to do. But it's enormously hard to have a large team of PMs, developers and designers, all of whom are smart and ambitious individuals, to actually do something that falls outside of the settled way of doing things. Kudos to Github founders and employees for getting it this far and congratulations on dealing with big company problems ;)
I disagree, I have zero problems with these new features, which cost no extra money to me. These are all extra features, that I can choose to use or not use, that github rolled out for its users. I personally treat repositories as a single self contained code project, and I find that a lot of other people do too. The home page makes me feel less lonely. It's all good for me. Yeah a repo-centric trello board won't serve a whole corporation, but is it really that important? Github isn't trying to kill trello.com, it's just rolling out a nice little feature that the average hacker appreciates. I can see how a bigger team would lump multiple repos under one project but for that why not just use trello.com, after all it's a specialized tool created for such a task.
You've summarized my thoughts perfectly. Projects often span multiple repos.
I hope Github rethinks their design and places Projects under user and organization profiles, rather than repos. It's a very useful feature that's sadly trapped in a single repo.
One project with multiple repos just adds unnecessary work of integration and management. Or, your definition of project is something big, vague and blurry.
Some people are eager to divide their project into multiple repos in spite of git being a distributed version control system. Having many teams doesn't mean you should have many repos. Why not just let your team work on one small directory inside the repo?
Although there will still be lots of projects (e.g. `an open source project with one repo`, `some company with a huge monolithic repo`) that will be able to use per-repo Projects profitably.
But yes, someone, please make something that kills JIRA as soon as possible.
This is a rough summary of what all I read in the blog post:
1. projects. replaces trello, waffle.io, zenhub and many other similar services.
2. code reviews allow approval/request changes as sunny's screenshot shows
3. reviews can be made mandatory.
4. github platform integrations is getting a roadmap
5. a graphql api to query their database
6. enforce 2fa in organizations (much love for this one)
7. summarized timeline for your contibutions
Just a few days back, at the GitLab release, I'd noticed a lot of complains about gitlab releasing useful and impactful features and github being slow on releases. Moreover, now with a public roadmap (even if it is just for platforms), it is a great start.
I'm really liking this change in pace.
mods: Can we make this the canonical discussion for this topic? Otherwise, a lot of branching will happen
I agree with you that the pick up in pace of Github's lacking features has been phenomenal, and I don't really quite understand all the love of GitLab except rooting for the underdog. Github is the clear industry leader, has been since essentially it's creation. It is very fast and feature-filled. It is the central location for the vast majority of code I use and see. Since the open letter to Github with the complaints of feature requests, they've really stepped up their game and made competitors really non-starters from my point of view.
It looks like enforcing 2fa in an org (finally!) means anyone who doesn't have 2fa will be booted out (included whoever may be paying for it at the time) with an email explaining why. I'm afraid to tick the box because of this. :o/
Doesn't look like Projects comes close to replacing ZenHub / Waffle.. Not for proper teams anyway – real project management needs to be much more robust so I'm keeping ZenHub for now.
Some nice improvements here. It appears, though, that Projects suffer from the same problem we've had with Issues: they are limited to one repo.
I know there are some tools to manage Issues across repos, but for the most part, the tools seem to assume you work on only one repo, or that milestones only affect a single repo.
I would love to see projects/milestones become more capable when dealing with cross-repo issues.
This has been why we don't use github's issues, wikis, and why we won't use their projects. For example if the overall product has a web site repo, server repo, iOS repo and an Android repo then they need to be used as a coherent whole. An issue might be reported against iOS but the cause is in the server, so the ticket would need to be moved. Rinse and repeat for all the other interactions of piece, and that collaborators often don't know (and shouldn't need to) precisely what issues, wikis etc correspond to which repo.
The now defunct Google Code had a very good solution for this. You could create additional "sub" repositories alongside the "main" one. Github already does that for the wiki, but doesn't generalise it to allowing additional ones. I'm somewhat convinced this is because github has the whole "charge by the repository" model, which is at odds for being useful for projects that require multiple git level repos.
Take a look at ZenHub [1] - it lets you stay inside GitHub, but adds much more full-featured project management capabilities including multi-repo boards and advanced reporting features like estimates, issue hierarchy (epics), personal to-dos, burndown and velocity charts, etc.
Issues and projects are global and not bound to a single repository. In my experience, this is the only approach that works in a company. JIRA does the same thing.
It's the closest to a fully open source Atlassian suite that you get. Phabricator has code review, repository hosting, project management and even a CI tool.
This. There are fewer and fewer places for single repository applications in this day and age: We break out a repo for everything to our DDL / Stored procedures and of course our API vs. Front-end code.
It sort of boggles the mind, really - and makes me feel like they did not really take the community's desires seriously.
Yup! Using Projects will force us to maintain multiple projects for one single "real" project, as our code is split across multiple repositories. (Web app, desktop client, infrastructure, company issues, etc)
I suspect it's still a lot better than the alternative but not having org-wide Projects is a little sad.
For what it's worth, I've had success browsing issues accross repos using the https://github.com/issues page. E.g. to view all issues that are in both redux and react-redux:
Codetree [1] addresses the multi-repo issues problem you mention, we roll up as many repos as you want under one 'project' which you can view in either table or kanban board style.
We also add a host of project management functionality on top of GitHub issues like advanced filtering/sorting, dependency tracking, and the ability to setup your own dev/release workflow.
I'll be curious to see if they've made API granularity more sane.
We haven't been able to use any third party tools because our security people don't feel great about giving third parties write access to everything (including our source) for tools that don't need it. In the past, GitHub hasn't differentiated write access to issues (which many tools need) and write access to the source itself (which basically nothing should need).
Plus a million - I'm not sure how this still isn't a feature.
Considering all of the PCI-DSS / HIPAA / SOX / etc. audit points around change control (even ignoring corporate versions of the same) it's practically impossible to add external services to GH and have them be useful while still meeting compliance. Change control is required, but that also implies control of change control. As-is any service could delete all of your content, whether intentionally or inadvertently, or even worse could corrupt or otherwise alter your history.
It may be detectable and recoverable because git, but it would be infinitely easier to have code and PR be r--rw-.
EDIT: This is now a thing, according to @bhuga below. Also, GH is now publishing a roadmap for what's coming down the pipe, so we're not in the dark as to when these critically-important-why-isnt-it-out-yet features are being worked on. https://developer.github.com/early-access/platform-roadmap/
I can't even get permission to read from private repos without also requesting write access to the user's entire codebase on GitHub. I don't want that power.
WakaTime has been bitten by this lack of granularity too... it hurts integration usage when we ask for code access when we only need commit log messages.
I’m not sure if the name “project” is a good choice here.
For one, GitHub still has some pages that refer to the idea of creating projects on GitHub, except those aren’t referring to these new kinds of “projects” (they actually are referring to new repositories or new accounts or something).
And, there are literally over a million repositories that have the name Project or Project somewhere in their name[1] so you can now create projects within things that are already called Projects (except the “projects” act more like issues, or tasks, or something).
Naming is important, there’s a reason why engineers devote so much time to it.
There's some nice stuff here -- probably some of it that I'll use -- but most of this is targeted at organisations (and in particular, managers and administrators) rather than individual developers.
Understandable -- it's clearly companies that are paying the bills these days -- but a little disappointing given the extent to which GitHub got big by attracting lone hackers and little open source projects.
If somebody else manages to claim the small-scale end if the market it could eventually spell trouble for GitHub.
The review stuff is semi similar to what I requested GitLab do and I'm surprised it's taken so long for anyone to really do it. It's a great workflow. I'm still not convinced about keeping all of your project's management in the version control system (I mean I prefer issues in there but the rest seems...wrong to me for whatever biased reason I have).
Overall looks good! When does Enterprise get these features? :)
My team and I played around with Projects for a little bit and these are things that were blockers / annoyances for us from moving away from trello. I'm posting because I know some GH people are reading these comments.
- Mobile support: Trello mobile app is great, projects web doesn't even resize for mobile.
- Slack support: Card Created notifications
- Easier “card” preview: Projects requires you to go to a new page to view a card
- Projects (1): This little "1" will always be 1. At least with PRs and Issues it means something (pending tasks, etc).
- Limited to one repo
I also found it funny that they call it "notes" as in "add note" "delete note" etc, but there is a menu item on each card that says "Copy Card URL". Maybe they renamed from "cards" to "notes" mid development? :)
I'd really like it if the Pull Requests page would denote which PRs I've already approved. That is one thing I really liked from Bitbucket, it makes it easy to skip over what I've already approved. It would become slightly more complex though, because then you'd probably want to see something for PRs you've approved but had subsequent changes on.
If anyone from Github reads this, a) this looks great, b) add project templates please, so we don't have to recreate the same columns every time. Thanks. <3
I'm actually really interested in the tech stack they used to make these new features. Specifically Projects. No latest and greatest framework or anything of that caliber. Just plain PJAX which is what everything else they have done uses. That's pretty cool to me. Looks like a pretty strong engineering culture of using stuff that works, instead of the shiniest object at the moment in time.
The inconsistent and non-sensical font and white space on the new profile pages is giving me an indescribable form of anxiety. If anybody out from the GH design team is out there, please put it back to how it was. :(.
Another Discourse forum. I was sceptical that the Discourse style of forum would become popular. Too complex and heavy, specially for mobile. I must admit that it's looking very good and is very usable.
If anyone from GitHub reads this, it would be great if you could use Task Lists [1] within Notes, e.g.
Note Title.
- [ ] Some subtask.
- [x] Another subtask.
You could then group subtasks within a single note and tick them off as you go without having to edit the note every time. Cheers and thank you for the fantastic new features!
Batched review and pending state have both been a long time coming.
Most of the times when I do a review it's not a single comment and right now the workflow is to let the team know on Slack that I am reviewing this.
From the Gif it's not 100% clear what the pending state does but I would want something like blocking the PR until every team member that started reviewing will "release" the PR. I also see the negative side of this of course but I think the positive outweighs the negatives.
You can block merges until there's an "approved" code review in the Protected Branches setting. I don't think it has anything like "everyone who reviewed must approve" though.
[+] [-] old-gregg|9 years ago|reply
Github success was about making code repositories pretty and social. But this is no longer enough to keep evolving as a company of their size. Yet the internal product DNA still revolves around repos, so as a result, issues, wikis and now Projects (!) live under a single repository.
This is backward.
A project is a way to group resources to achieve a predefined goal. Those resources include multiple people, multiple issues and multiple repositories. Sticking a project under a repository makes no sense.
In fact, a code repository in most organizations is a fairly small and an insignificant asset, just another way to organize code, i.e. function -> module -> directory -> repository, etc. It's quite awkward to think of what your company is doing in terms of repositories, so anything Github adds to repos feels out of place by default.
Another example of repository-centric thinking is the homepage of https://github.com itself when a user is logged in. It's the most important page of all, yet nothing on it has any relevance to me: just a list of people I like starring random repos. Same thing for the organization home page, just a list of repos, again.
The Project idea is great. It had the potential to solve all of these issues by giving me a tool to organize digital assets in a way that's important to me. But sticking it under a repository killed it.
[EDIT] It's easy to be me and be posting a comment like this, telling successful people what to do. But it's enormously hard to have a large team of PMs, developers and designers, all of whom are smart and ambitious individuals, to actually do something that falls outside of the settled way of doing things. Kudos to Github founders and employees for getting it this far and congratulations on dealing with big company problems ;)
[+] [-] sytse|9 years ago|reply
We at GitLab are trying to keep it simple by having only one repository, one wiki, one issue tracker, one CD pipeline, and one set of milestones per project. Projects always below to a group. We aggregate on the group level, for example issues https://gitlab.com/groups/gitlab-org/issues, merge requests https://gitlab.com/groups/gitlab-org/merge_requests and milestones https://docs.gitlab.com/ce/workflow/milestones.html#groups-a...
There are several things we're still considering to solve this problem better, comments are very welcome:
1. Multi project pipelines https://gitlab.com/gitlab-org/gitlab-ce/issues/17069
2. Group level issue boards https://gitlab.com/gitlab-org/gitlab-ee/issues/928
3. Nested groups https://gitlab.com/gitlab-org/gitlab-ce/issues/2772
[+] [-] terda12|9 years ago|reply
[+] [-] hellcow|9 years ago|reply
I hope Github rethinks their design and places Projects under user and organization profiles, rather than repos. It's a very useful feature that's sadly trapped in a single repo.
[+] [-] luikore|9 years ago|reply
Some people are eager to divide their project into multiple repos in spite of git being a distributed version control system. Having many teams doesn't mean you should have many repos. Why not just let your team work on one small directory inside the repo?
[+] [-] Myrmornis|9 years ago|reply
But yes, someone, please make something that kills JIRA as soon as possible.
[+] [-] twitterdawg|9 years ago|reply
[+] [-] echelon|9 years ago|reply
[+] [-] captn3m0|9 years ago|reply
1. projects. replaces trello, waffle.io, zenhub and many other similar services.
2. code reviews allow approval/request changes as sunny's screenshot shows
3. reviews can be made mandatory.
4. github platform integrations is getting a roadmap
5. a graphql api to query their database
6. enforce 2fa in organizations (much love for this one)
7. summarized timeline for your contibutions
Just a few days back, at the GitLab release, I'd noticed a lot of complains about gitlab releasing useful and impactful features and github being slow on releases. Moreover, now with a public roadmap (even if it is just for platforms), it is a great start.
I'm really liking this change in pace.
mods: Can we make this the canonical discussion for this topic? Otherwise, a lot of branching will happen
[+] [-] elliotec|9 years ago|reply
[+] [-] jglovier|9 years ago|reply
This is really not about replacing those services, it's more about building a better foundation for integrators like Waffle and ZenHub to build on.
[+] [-] mstade|9 years ago|reply
[+] [-] thegarside|9 years ago|reply
[+] [-] tootie|9 years ago|reply
[+] [-] draw_down|9 years ago|reply
[+] [-] obi1kenobi|9 years ago|reply
[+] [-] sgarrity|9 years ago|reply
I know there are some tools to manage Issues across repos, but for the most part, the tools seem to assume you work on only one repo, or that milestones only affect a single repo.
I would love to see projects/milestones become more capable when dealing with cross-repo issues.
[+] [-] rogerbinns|9 years ago|reply
The now defunct Google Code had a very good solution for this. You could create additional "sub" repositories alongside the "main" one. Github already does that for the wiki, but doesn't generalise it to allowing additional ones. I'm somewhat convinced this is because github has the whole "charge by the repository" model, which is at odds for being useful for projects that require multiple git level repos.
[+] [-] rohamg|9 years ago|reply
[1] https://www.zenhub.com
[+] [-] Nimimi|9 years ago|reply
Issues and projects are global and not bound to a single repository. In my experience, this is the only approach that works in a company. JIRA does the same thing.
It's the closest to a fully open source Atlassian suite that you get. Phabricator has code review, repository hosting, project management and even a CI tool.
[+] [-] ajsharma|9 years ago|reply
Works pretty well, if a little awkward at first.
[+] [-] moby|9 years ago|reply
[+] [-] dfsegoat|9 years ago|reply
It sort of boggles the mind, really - and makes me feel like they did not really take the community's desires seriously.
[+] [-] scrollaway|9 years ago|reply
I suspect it's still a lot better than the alternative but not having org-wide Projects is a little sad.
[+] [-] rickhanlonii|9 years ago|reply
https://github.com/issues?q=repo%3Areactjs%2Fredux+repo%3Are...
[+] [-] mr_november|9 years ago|reply
We also add a host of project management functionality on top of GitHub issues like advanced filtering/sorting, dependency tracking, and the ability to setup your own dev/release workflow.
[1] https://codetree.com
[+] [-] bsimpson|9 years ago|reply
We haven't been able to use any third party tools because our security people don't feel great about giving third parties write access to everything (including our source) for tools that don't need it. In the past, GitHub hasn't differentiated write access to issues (which many tools need) and write access to the source itself (which basically nothing should need).
[+] [-] web007|9 years ago|reply
Considering all of the PCI-DSS / HIPAA / SOX / etc. audit points around change control (even ignoring corporate versions of the same) it's practically impossible to add external services to GH and have them be useful while still meeting compliance. Change control is required, but that also implies control of change control. As-is any service could delete all of your content, whether intentionally or inadvertently, or even worse could corrupt or otherwise alter your history.
It may be detectable and recoverable because git, but it would be infinitely easier to have code and PR be r--rw-.
EDIT: This is now a thing, according to @bhuga below. Also, GH is now publishing a roadmap for what's coming down the pipe, so we're not in the dark as to when these critically-important-why-isnt-it-out-yet features are being worked on. https://developer.github.com/early-access/platform-roadmap/
[+] [-] bhuga|9 years ago|reply
[+] [-] idbehold|9 years ago|reply
[+] [-] welder|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] makecheck|9 years ago|reply
For one, GitHub still has some pages that refer to the idea of creating projects on GitHub, except those aren’t referring to these new kinds of “projects” (they actually are referring to new repositories or new accounts or something).
And, there are literally over a million repositories that have the name Project or Project somewhere in their name[1] so you can now create projects within things that are already called Projects (except the “projects” act more like issues, or tasks, or something).
Naming is important, there’s a reason why engineers devote so much time to it.
[1] https://github.com/search?p=1&q=project&type=Repositories&ut...
[+] [-] the_duke|9 years ago|reply
Some alternatives that randomly come to mind: "Boards", "Plan", "Plans", "Tasks".
[+] [-] scrollaway|9 years ago|reply
[+] [-] dasmoth|9 years ago|reply
Understandable -- it's clearly companies that are paying the bills these days -- but a little disappointing given the extent to which GitHub got big by attracting lone hackers and little open source projects.
If somebody else manages to claim the small-scale end if the market it could eventually spell trouble for GitHub.
[+] [-] BinaryIdiot|9 years ago|reply
Overall looks good! When does Enterprise get these features? :)
[+] [-] reustle|9 years ago|reply
- Mobile support: Trello mobile app is great, projects web doesn't even resize for mobile.
- Slack support: Card Created notifications
- Easier “card” preview: Projects requires you to go to a new page to view a card
- Projects (1): This little "1" will always be 1. At least with PRs and Issues it means something (pending tasks, etc).
- Limited to one repo
I also found it funny that they call it "notes" as in "add note" "delete note" etc, but there is a menu item on each card that says "Copy Card URL". Maybe they renamed from "cards" to "notes" mid development? :)
[+] [-] prh8|9 years ago|reply
[+] [-] mintplant|9 years ago|reply
[+] [-] toddsiegel|9 years ago|reply
[+] [-] dham|9 years ago|reply
[+] [-] Mizza|9 years ago|reply
Example: https://github.com/Miserlou
10 font sizes is too many for any one page.
[+] [-] Hovertruck|9 years ago|reply
[+] [-] cdnsteve|9 years ago|reply
[+] [-] klodolph|9 years ago|reply
[+] [-] berns|9 years ago|reply
[+] [-] tav|9 years ago|reply
[1] https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-...
[+] [-] avitzurel|9 years ago|reply
Most of the times when I do a review it's not a single comment and right now the workflow is to let the team know on Slack that I am reviewing this.
From the Gif it's not 100% clear what the pending state does but I would want something like blocking the PR until every team member that started reviewing will "release" the PR. I also see the negative side of this of course but I think the positive outweighs the negatives.
[+] [-] mwarkentin|9 years ago|reply