5 ms·

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 a

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.

rohamg 10y ago
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. [1] https://www.zenhub.com https://www.zenhub.com
ajsharma 10y ago
At Goldbely, our solution has been to have a single GitHub repo that's just for issues and use tags to highlight the actual code repos involved. Works pretty well, if a little awkward at first.
- elwell 10y ago
  We do this as well at Purple [0]. It does make issue referencing in commit messages a bit unwieldy; you have to include the full path to the issue (e.g., org-name/repo-name#34). [0] - http://purpleapp.com http://purpleapp.com
scrollaway 10y ago
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.
rogerbinns 10y ago
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.
- toupeira 10y ago
  They recently added a per-user pricing model, so maybe they would be open to suggestions.
  - rogerbinns 10y ago
    It would require fairly extensive changes on how they do things under the hood. Google used suffixes - eg you checked out the wiki as github.com/org/projectX.wiki and could create a git repo like github.com/org/projectX.android
- dr_win 10y ago
  I would put all projects under one repo as orphan branches. With some branch-naming conventions you can easily separate those.
  - postit 10y ago
    Just no.
  - yosyp 10y ago
    Imagine you just hired a new web developer, and added him to this repo. His first local repo clone will include 3 entire projects for iOS, Android, and backend server, that he has no use for, or should even have permissions to access in the first place. This sounds like a security nightmare, that also significantly impacts local update times and makes for a huge repo.
Nimimi 10y ago
Phabricator has the right approach here. 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.
- Klathmon 10y ago
  I've seen a few projects use Phabricator, but I can't seem to understand how to use it. Github's issues, despite it's flaws, is easy enough that non-programmers can use it. Phabricator is complicated enough that it's actually caused me to not report a bug at one point.
mr_november 10y ago
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. [1] https://codetree.com https://codetree.com
moby 10y ago
Thanks for providing the feedback here - I've passed it along to the Engineering team building out Projects.
- inopinatus 10y ago
  I'm curious as to whether you are dogfooding Projects, especially when feature work spans multiple repos. If so a "how Github uses Projects" tutorial may be worth considering.
  - moby 10y ago
    Indeed, many teams are - the original iteration of Projects was released to staff a few months ago (as is common with many of our product releases), so we're continuing to learn how teams are using it most effectively. Yesterday's release to the public will help with that effort too. I personally use it on my team at the moment - it's been pretty useful and we've passed along frequent feedback to the platform team responsible for it.
dfsegoat 10y ago
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.
rickhanlonii 10y ago
For what it's worth, I've had success browsing issues accross repos using the https://github.com/issues https://github.com/issues page. E.g. to view all issues that are in both redux and react-redux: https://github.com/issues?q=repo%3Areactjs%2Fredux+repo%3Areactjs%2Freact-redux+ https://github.com/issues?q=repo%3Areactjs%2Fredux+repo%3Are...

rohamg 10y ago

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. [1] https://www.zenhub.com https://www.zenhub.com

ajsharma 10y ago

At Goldbely, our solution has been to have a single GitHub repo that's just for issues and use tags to highlight the actual code repos involved. Works pretty well, if a little awkward at first.

elwell 10y ago
We do this as well at Purple [0]. It does make issue referencing in commit messages a bit unwieldy; you have to include the full path to the issue (e.g., org-name/repo-name#34). [0] - http://purpleapp.com http://purpleapp.com

scrollaway 10y ago

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.

rogerbinns 10y ago

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.

toupeira 10y ago
They recently added a per-user pricing model, so maybe they would be open to suggestions.
- rogerbinns 10y ago
  It would require fairly extensive changes on how they do things under the hood. Google used suffixes - eg you checked out the wiki as github.com/org/projectX.wiki and could create a git repo like github.com/org/projectX.android
dr_win 10y ago
I would put all projects under one repo as orphan branches. With some branch-naming conventions you can easily separate those.
- postit 10y ago
  Just no.
- yosyp 10y ago
  Imagine you just hired a new web developer, and added him to this repo. His first local repo clone will include 3 entire projects for iOS, Android, and backend server, that he has no use for, or should even have permissions to access in the first place. This sounds like a security nightmare, that also significantly impacts local update times and makes for a huge repo.

Nimimi 10y ago

Phabricator has the right approach here. 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.

Klathmon 10y ago
I've seen a few projects use Phabricator, but I can't seem to understand how to use it. Github's issues, despite it's flaws, is easy enough that non-programmers can use it. Phabricator is complicated enough that it's actually caused me to not report a bug at one point.

mr_november 10y ago

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. [1] https://codetree.com https://codetree.com

moby 10y ago

Thanks for providing the feedback here - I've passed it along to the Engineering team building out Projects.

inopinatus 10y ago
I'm curious as to whether you are dogfooding Projects, especially when feature work spans multiple repos. If so a "how Github uses Projects" tutorial may be worth considering.
- moby 10y ago
  Indeed, many teams are - the original iteration of Projects was released to staff a few months ago (as is common with many of our product releases), so we're continuing to learn how teams are using it most effectively. Yesterday's release to the public will help with that effort too. I personally use it on my team at the moment - it's been pretty useful and we've passed along frequent feedback to the platform team responsible for it.

dfsegoat 10y ago

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.

rickhanlonii 10y ago

For what it's worth, I've had success browsing issues accross repos using the https://github.com/issues https://github.com/issues page. E.g. to view all issues that are in both redux and react-redux: https://github.com/issues?q=repo%3Areactjs%2Fredux+repo%3Areactjs%2Freact-redux+ https://github.com/issues?q=repo%3Areactjs%2Fredux+repo%3Are...