Announcing new tools, forums, and features

https://github.com/blog/2256-a-whole-new-github-universe-announcing-new-tools-forums-and-features

by joshmanders • 10 years ago

1142 269 10 years ago

github.com

source992• 10 years ago

Link goes right to 404 - Thats one heck of a new feature.

homeyer3• 10 years ago

Heh, 404s if you aren't logged in to GitHub

source992• 10 years ago

Nope. I was logged in. Guessing it was something else.

I like how I got downvoted for providing information...

huac• 10 years ago

Definitely cool, but weren't you always able to comment inline on a PR?

Arnavion2• 10 years ago

The GIF shows "Start Review" button and "Finish your review" buttons (and a "Pending" flag), which makes me think this is more geared to the complaints that every comment sent an individual email instead of being batched when the reviewer was ready to send them out.

Edit: Indeed, from the github blog post - "You can also leave a review summary and delete, edit, or bundle comments before you submit them."

Arnavion2• 10 years ago

1st party link: https://github.com/blog/2256-a-whole-new-github-universe-ann...

joshmanders4• 10 years ago

Can we get this updated to this? defunkt didn't post this blog post before TechCrunch talked about it. I'd much rather had linked to it.

sctb• 10 years ago

OK, we've updated the link from https://techcrunch.com/2016/09/14/github-gets-built-in-proje....

stevejohnson• 10 years ago

Missed opportunity to call the platform forum the "GitHub PlatForum."

nchelluri4• 10 years ago

I'm not sure "missed opportunity" is the right name for that :)

Hovertruck• 10 years ago

Batch review has been my #1 most desired feature for Github for many years now. This is great!

rsanheim3• 10 years ago

Thanks! It has been on our list for a long time as well, excited to get it shipped.

bsimpson• 10 years ago

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).

bhuga• 10 years ago

This is an important part of the new integrations early access program: https://developer.github.com/changes/2016-09-14-Integrations...

web007• 10 years ago

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/

welder• 10 years ago

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.

idbehold• 10 years ago

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.

scrollaway2• 10 years ago

Impressive. I have to think that this is all competition fostered by Gitlab - all those features were present in Gitlab. Competition at work :)

imsodrunklol• 10 years ago

I have been a huge pusher for GitLab, and my basic reasoning was that GitHub isn't open sourced like GitLab. GitHub was going awfully slow and no communication to its customers in new features. Looks like GitLab lit a fire underneath them. I wonder which one is "better". Nevertheless, at least there is competition now. SCM is the biggest component in any coding practices, I'm that it is finally getting attention.

midwestcode• 10 years ago

Hopefully the community forum will help GitHub to keep in touch with the community!

deathanatos2• 10 years ago

I sent this to support, but the "Files changed" tab in Pull Requests now has an announcement "We've made some change to reviewing code"

The "Learn more" button on that banner is a broken link…

(It's a good thing this HN post later directed me to the blog post, as now I've learned from that.)

moby17• 10 years ago

Sorry about that! Is the link working now?

deathanatos2• 10 years ago

Looks like it is! (The URL that was broken now has content; the banner has since vanished for me.)

BinaryIdiot• 10 years ago

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? :)

moby17• 10 years ago

We're glad you like it! This is the first of many Code Review enhancements we'll be providing, so stay tuned.

These features will be coming to GitHub Enterprise soon - we always aim to get new features onto the Enterprise platform on the next major release (which occurs every 3 months on average).

Nimimi4• 10 years ago

Phabricator and Gerrit had this for ages!

majewsky2• 10 years ago

The review stuff actually reminded me of http://review.ninja, which has existed for at least 1.5 years at this point.

dblooman• 10 years ago

Wonder how services like Waffle will react to this

homeyer3• 10 years ago

http://blog.waffle.io/say-hello-to-wafflebot/

bowmessage• 10 years ago

Is this the death of Trello?

toddsiegel3• 10 years ago

Lots of non-devs use Trello.

Trello also has lot of features this does not, but I can see GH users using Trello jumping to this, like me.

jglovier3• 10 years ago

Very unlikely. We hope that Projects will be the best place for people to coordinate work on a GitHub repository, but that doesn't really limit Trello's value much. They'll continue to offer lots of value as a great way to coordinate work for many contexts outside GitHub repositories.

eyelidlessness• 10 years ago

I'd switch instantly if:

1. There was a faster and more contextual way to edit issues on a project.

2. There was a way to set up an opinionated workflow where e.g. opening a PR against an issue moves the issue to "Review"; closing said PR moves issue to "Done" and closes it; closing an issue directly moves it to "Done" and vice versa. Without this, there's way too much interaction required for even GitHub's own preferred workflow.

3. Automatic bidirectional linking between issue/PR on the project board. (Honestly haven't had a chance to see if it does this, but will on the next PR I open.)

4. Automatically pre-fill a backlog with existing issues.

5. A project could span multiple repositories (e.g. for tracking user stories which might be addressed in an API or frontend repo, or both). We also track non-dev work on our Trello board, and a project per repo doesn't support this.

6. Filtering.

Edit... Also nice to have: ability to reference a checklist item in a link from PR to issue, check it on merge, and so on.

mr_november2• 10 years ago

Hi - Codetree [1] does a lot of what you're asking for (specifically 3, 5, 6) and I love the other stuff you mention, we've been thinking hard on a couple of them. Would love to quickly chat about your workflow just to learn, not to sell, if you can spare the 15 mins. If you're interested shoot me an email at arif@codetree.com.

[1] https://codetree.com

sgarrity• 10 years ago

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• 10 years 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

ajsharma• 10 years 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• 10 years 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

scrollaway2• 10 years 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.

rogerbinns2• 10 years 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• 10 years ago

They recently added a per-user pricing model, so maybe they would be open to suggestions.

dr_win• 10 years ago

I would put all projects under one repo as orphan branches. With some branch-naming conventions you can easily separate those.

Nimimi4• 10 years 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• 10 years 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_november2• 10 years 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

moby17• 10 years ago

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

inopinatus• 10 years 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.

dfsegoat• 10 years 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• 10 years ago

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:

https://github.com/issues?q=repo%3Areactjs%2Fredux+repo%3Are...

captn3m03• 10 years ago

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

thegarside• 10 years ago

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.

jglovier3• 10 years ago

projects. replaces trello, waffle.io, zenhub and many other similar services.

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.

captn3m03• 10 years ago

I'm looking at https://www.zenhub.com/product, and while it does have some extra features (filters on priority, labels), but for most people the base set provided by github is gonna be sufficient.

Sure, it won't completely replace them, but GitHub building this as a platform counts as competition.

homeyer3• 10 years ago

At Waffle.io, we're all about making project management better for engineers. We believe it's awesome that GitHub is investing in this too, and we'll continue to make GitHub delicious :). More here: http://blog.waffle.io/say-hello-to-wafflebot/

ma1382• 10 years ago

At ZenHub, we have already starting working on some integrations with this functionality which you can read more about here - https://www.zenhub.com/blog/dispatches-from-github-universe/

Our focus is going to remain on how to integrate a full-featured project management suite within the GitHub eco-system. The GitHub projects release will make a great foundation, and ZenHub will be there to provide the more advanced features like issue hierarchy (epics), time estimation and reporting. Lots of exciting releases coming soon for ZenHub users :)

bigkahunaburger• 10 years ago

Except all those services have already built a foundation ...

This will inevitably force out GH's integration partners once users start to complain how feature-deficient projects are in their current state.

jenniferDewalt• 10 years ago

Founder of Zube here. GitHub Projects seems like a nice solution for very small teams, side projects and open source projects. However, serious teams need more powerful features like a well thought out workflow, support for multiple repos and burndown charts.

Shameless plug: Zube has all these things and more - https://zube.io :)

mstade3• 10 years ago

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/

jedberg• 10 years ago

Contact everyone, tell them they have a week, then tick the box. If they didn't do it within the week it's either not important to them or they'll add it right quick after you tick the box.

captn3m03• 10 years ago

Currently, we tell every new employee on joining the org to enable it, and review it a week later to ensure that they followed through.

It is the exact same with Google Apps as well (where you add the user to the 2faexceptions group and review+remove them a week later).

I was ready to flip the switch, till I realized that a third-party bot account in our organization doesn't have 2fa. Dropped them a mail, hoping to flip it by tomorrow (100% non-bot users have it enabled, so no one is getting auto-kicked).

elliotec7• 10 years ago

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.

markdog123• 10 years ago

I don't really quite understand all the love of GitLab

- Open Source

- Free private repos

- Free self-host (edit to add "Free")

- Everything in one spot (repos, ci, review, coding environment, etc...)

AsyncAwait• 10 years ago

I don't really quite understand all the love of GitLab except rooting for the underdog.

and self-hosting :-)

kuschku• 10 years ago

It is the central location for the vast majority of code I use and see.

And that’s exactly why you shouldn’t use it.

Since the open letter to Github with the complaints of feature requests,

This, and the answer from GitLab to that letter, is what made GitHub move in the first place.

You need competition for a healthy market.

lucideer• 10 years ago

As well as the sibling comments here, one could also argue Gitlab deserves at least partial credit for motivating this pick up in pace.

detaro3• 10 years ago

Then be a fan of of GitLab for putting the fear of competition back into GitHub ;)

(It's of course not certain they are the reason they are moving again, but GitHub looked a lot like the market leader that feels like it doesn't have to bother much anymore. And they weren't entirely wrong.)

ascendantlogic• 10 years ago

built in CI integration is a huge draw. There are also a nontrivial amount of companies that refuse to let source code "out of the building" so they need to self host, either for real reasons or perceived.

frontendless• 10 years ago

Very fast? Maybe in the US, but rest of the world still has oceans in between of them. Adding 200msec+ of latency to every request makes it feel very sluggish.

Maybe they should start looking into global rollout like Google, Facebook and basically every serious company having world-wide audience.

hoorayimhelping• 10 years ago

I think particularly here on HN, I've seen a good deal of concern over github's social agenda and the perception that they've hired a lot of non-engineering folks to push that agenda.

tootie3• 10 years ago

This all seems like baby stuff compared to Atlassian though. JIRA, Confluence, Bitbucket, HipChat. That's hard to beat.

rwbcxrz• 10 years ago

baby stuff

JIRA doesn't support markdown. That seems like baby stuff to me.

draw_down2• 10 years ago

If Atlassian's competition is baby stuff, give me a pacifier and a bottle.

obi1kenobi• 10 years ago

re: enforced 2FA, it does not appear to play well with bot accounts -- it's either all on or all off, and bots don't count as using 2FA.

draw_down2• 10 years ago

I thought the stuff about Github's pace was funny too. People have short memories, I guess.

vcarl• 10 years ago

The improvements to code reviews are really exciting. Having comments submit all at once instead of one at a time is a great UX change, I've definitely gotten sidetracked mid-review because somebody started responding to my initial comments when I'm neck deep. Comment threading is super useful for discussion-heavy comments like code review, and an in-UI approve/request changes is great.

moby17• 10 years ago

That's awesome to hear - we're glad you like those changes! As you dive into it further, let us know how it works for you.

hannob• 10 years ago

And still no HTTPS for github pages with custom domains...

dorianm• 10 years ago

You can use Cloudflare for that. (That's what I do on https://doma.io)

avitzurel• 10 years ago

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.

mwarkentin2• 10 years ago

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.

toddsiegel3• 10 years ago

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

jglovier3• 10 years ago

Great idea. Thanks!

toddsiegel3• 10 years ago

While I have your attention. A few thoughts on code reviews. It's be nice if 1) approvals somehow show up on the pull requests index page, 2) create a notification within GH, 3) send an email. Right now you have to go to the PR page itself to see approvals.

Edit: I saw an approval email notification on one PR, but not another.

Thanks!

mstade3• 10 years ago

Similar thing I'd like to see is repo templates. It seems for every repo I create in an organization, I spend time ticking the same boxes over and over. Protected branches for instance is a typical setting I have to duplicate for every repo.

glenjamin• 10 years ago

You might be able to do this using the new graphql api :)

misiti37802• 10 years ago

d) create issue templates also, i have to currently cut and paste the same markdown into every issue

e) create user-level permissions - i work on a team where everyone would use this, but currently not everyone can have access to the code base so we have to say in trello until you can allow me the ability to turn off code access to "non-engineers"

majewsky2• 10 years ago

Issue templates have been a thing for some months now. https://help.github.com/articles/creating-an-issue-template-...

mintplant• 10 years ago

Was really hoping "forums" would mean users could add dedicated discussion boards to repositories.

agumonkey• 10 years ago

I predict, one day github will host a school.

drewolson• 10 years ago

Reviews are very exciting, but seem to be unable to fit the following use case:

I want to setup a repo such that a subset of collaborators (or organization members) can merge reviewed PRs to protected branches. I want the rest of the users to be able to create new branches and submit PRs from them, but _not_ to be able to push to protected branches. They should _only_ be able to land code in protected branches via reviewed PRs (via the merge button).

Is there a way to achieve this now that I'm missing? Gitlab's more granular user roles + permissions allow this.

deeplyoptional• 10 years ago

https://github.com/blog/2137-protected-branches-improvements

dkn• 10 years ago

Gotta love a little competition.

oneloop• 10 years ago

I know, right. GitHub hasn't moved in years, until they felt Atlassian and GitLab starting to close in.

douche• 10 years ago

Maybe I can finally get my boss to switch off of Unfuddle. Although moving 10 years of history out of a couple dozen SVN repos into git would likely be lots of fun...

dasmoth• 10 years ago

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.

PieterH• 10 years ago

This isn't a random shift in direction for github... in the end it will make the platform so complex and irrelevant for open source teams that they will go elsewhere. I wrote an analysis of this shift some time back: http://hintjens.com/blog:111

st3v3r2• 10 years ago

Why? These features don't change the individual experience at all. You're not forced to use them.

cdnsteve• 10 years ago

Finally, Github getting some Love! Can't wait to switch to Projects and wave Goodbye Jira. I'm a happy dev today.

joshmanders4• 10 years ago

Indeed, when GitLab announced Kanban I tried to migrate, but it just wasn't as great as GitHub, this is the nail in my foot that keeps me at GitHub.

sytse7• 10 years ago

What can we improve in GitLab that would have convinced you to stay?

Nimimi4• 10 years ago

Take a look at Phabricator's project management and work board, too!

moby17• 10 years ago

We're happy that you're happy. :) Keep the feedback coming; we're listening!

exception_e2• 10 years ago

I'm liking the recent design changes, however, I don't like the new implementation of contrib. activity... information overload!

donatj• 10 years ago

Code reviews currently do not seem to come through on the webhooks at all.

Our in-house automation suites depend on it, so this is a big do not use for us.

I really wish their APIs weren't second class citizens. It takes weeks or months for new features to show up in the API - if at all. I wish there was 1-1 parity with the API.

rsanheim3• 10 years ago

We definitely have plans to get full support into the API around pull request reviews.

Given how much iteration we do after an initial ship like this, especially one with as much feedback as code review, we prefer shipping the API after things have solidified and settled down after the wide release.

berns• 10 years ago

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.

korva• 10 years ago

This product video for GitHub Projects features a logo that's exactly like Trello's. Cold. https://youtu.be/NoBI4_9EuUw

dkuntz22• 10 years ago

That's the symbol they're using for Projects everywhere. If you look at a repo, it's there.

sergiotapia• 10 years ago

Can we import a Trello project with all it's lists/cards seamlessly into a github repos `project`?

gerry_shaw• 10 years ago

Not even close. Trello has way more features for cards. Project notes are really just a blob of text (Markdown?) and that's it. No title, description, checklists, attachments, or comments. One can imagine them coming though and with the Projects API on the roadmap you would then be able to do an import.

Mizza• 10 years ago

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. :(.

Example: https://github.com/Miserlou

10 font sizes is too many for any one page.

SSLy• 10 years ago

I on the other hand have troubles reading it all - the contrast is way too small.

dkuntz22• 10 years ago

I haven't checked, but it looks like there's only three.

voaie• 10 years ago

Just report it: https://github.com/contact

SEJeff2• 10 years ago

Now I wonder how long before some of these features such as mandatory reviews will make it into Github Enterprise?

moby17• 10 years ago

The updated Code Review features will be coming to GitHub Enterprise soon - we always aim to get new features onto the Enterprise platform on the next major release (which occurs every 3 months on average).

SEJeff2• 10 years ago

Thanks, our team was literally lamenting about lacking specific reviewers when migrating from phabricator to github enterprise last week. Looking forward to it!

romanovcode• 10 years ago

GitHub is playing catch-up with GitLab. Interesting.

prh83• 10 years ago

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.

moby17• 10 years ago

Great feedback point here - I've passed it along to our Engineering team.

prh83• 10 years ago

Thank you! Can I make one more request? I'd love to be able to see merge conflicts from the diff page (also like BB does).

Knowing the conflict is just db/schema version instead of something more problematic-- that is especially handy when used in conjunction with various target branches.

i.e. I know <another-feature> branch is about to be merged before right before <my-branch> gets merged. Then, I can know what I'm going to have to fix quickly without having to go back to terminal, fetch <another-feature>, merge <my-branch>, just to find the conflicts. Yes, I have to do that with master after it's merged anyways, but I find it great to see quickly and at a glance beforehand.

klodolph• 10 years ago

A minor nit: the commit graph full of green squares should not be encouraged. I don't think that kind of behavior is healthy.

gohwell2• 10 years ago

How about diffs on pull request? The biggest gripe I have with github is the inability to compare my feature branch with the branch I'm merging too. The diff you see is comparing the feature branch with the "base" branch which would be stale when working on a dev team.

moby17• 10 years ago

I want to make sure I capture your feedback correctly, so let me know if this doesn't help: we recently released the ability to change your base branch on a PR. https://github.com/blog/2224-change-the-base-branch-of-a-pul...

Let me know if that helps!

gohwell2• 10 years ago

Here's an example. It's meant to illustrate 2 developers working on a feature branch based on master and one pulls their code in before the other.

https://github.com/jparmstrong/gittest/pull/3/files

- Two feature branches were created based on master at the same time.

- Branch1: committed a change to readme and it's pulled into master via PR.

- Branch2: committed a change to readme, raised a pull request (PR#3), and the diff doesn't show the line that was added with the branch1 pull request.

In this example, the PR is telling me there's a conflict and I need to merge master with the PR branch (this is good). What it doesn't tell me is where the conflict is.

Solution, merge the base branch into the interim PR branch. The result will show you the conflict and properly represents what would happen if this PR is accepted. (Bitbucket does this)

Thanks for following up.

gist of merge master example output: https://gist.github.com/jparmstrong/07cab1a566c5c1495d7c8e07...

tav• 10 years ago

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!

[1] https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-...

moby17• 10 years ago

Reading, and passing that feedback along to our Engineering team. Thanks!

samblr• 10 years ago

Can't seem to find free private repos and unlimited collaborators ?

But good to see GitHub responding - would be keen to hear from bitbucket which I personally use for private repos.

gitdude• 10 years ago

Here is a list of features we shipped in the last 12 months: https://blog.bitbucket.org/2016/09/07/bitbucket-cloud-5-mill...

sorkin2• 10 years ago

Hmm.. So was there a workflow where I could say "I'd like for this not to be pushed until I've approved it", even if the patch is assigned to be reviewed by someone else? Of course, I could just comment with that on the issue, but it would be nicer if the issue would pop up somehow after the other reviewer has reviewed it, and it would be obvious to everyone that it's waiting for my approval.

makecheck• 10 years ago

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.

[1] https://github.com/search?p=1&q=project&type=Repositories&ut...

the_duke2• 10 years ago

I agree, Projects is a poor choice, in my opinion.

Some alternatives that randomly come to mind: "Boards", "Plan", "Plans", "Tasks".

old-gregg• 10 years ago

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 ;)

Myrmornis• 10 years ago

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.

brandur• 10 years ago

I think they could iterate on this to a place where projects are repository-specific, but still useful for high-level organization and planning.

For example, if they allowed repo projects to reference issues in other repos, that would you get you 99% of the way there. You could start a single meta-repository that referenced as many repo-specific issues as you cared to consider.

sytse7• 10 years ago

I agree that putting projects under repositories looks counterintuitive. In BitBucket you have multiple repositories under one project https://confluence.atlassian.com/bitbucket/projects-79249795...

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

bhldr• 10 years ago

Enough with the ads here.

tyre• 10 years ago

Meta-comment: As a founder and engineer, I used to give a lot of shit to Social Media as a growth channel.

GitLab staff are "on point" by commenting on anything relevant to their industry (code creation/management) where their target customers are (HN).

To other founders, this is what good marketing looks like.

notatoad• 10 years ago

In BitBucket you have multiple repositories under one project

however, unless i'm missing something, a "project" in bitbucket is basically just a folder to group your repositories in. there's no real features associated with it. A github project is project management tools based on a repository.

If GitHub had called their feature something else, (for example, call it "the board") and nobody would be expecting it to be anything other than per-repo.

w_t_payne• 10 years ago

It would be nice if there were a taxonomy of different organisational approaches so that we could have a common terminology to discuss the pros and cons of each.

E.g. I come at things from the intersection of (embedded) product line engineering and continuous integration, which leads me towards a different place than somebody coming at things from (e.g.) consulting or web services ... but it is difficult to have a meaningful discussion about the pros & cons of each approach without the language / terminology that we need.

terda12• 10 years ago

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.

supercoder• 10 years ago

They definitely cost you money if you're paying for the product. Otherwise if they weren't developing new things they could lower the price

hellcow• 10 years ago

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.

luikore2• 10 years ago

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?

kareemm• 10 years ago

One project with multiple repos just adds unnecessary work of integration and management. Or, your definition of project is something big, vague and blurry.

I think this depends on your job function. At Codetree we have a bunch of customers who need to see a project that spans multiple GitHub repos. The person who needs this view is the person responsible for delivery - usually a project manager, a product manager, or a dev manager.

A common example is a project that spans an API repo, a front end repo, and a mobile repo. If you're responsible for delivery, you want to be able to answer questions like "How much work is left to deliver the FooBar feature", or "Show me all the tickets assigned to Joe". To answer these, you must see issues from multiple repos rolled up into a single view.

kalleboo2• 10 years ago

Client/Server is one case where I think having multiple repos under one project makes a lot of sense.

Another one is where we have forks of libraries with minor patches to suit our needs.

empath75• 10 years ago

https://github.com/spinnaker

Spinnaker is comprised of a bunch of quasi-independent microservices, designed to work together. I don't think it would necessarily make sense to have them all in the same repo, when they could be swapped out or even used separately in another project.

PeterisP• 10 years ago

Reusable and reused components span multiple projects and even companies. A quite reasonable scenario is when a project includes a component library that's loosely coupled, open-sourced and used by others (so it pretty much has to be in a separate), but it's not just an included dependency but being actively worked on in a project - e.g. a single small new feature would require commits to both the library and the repository that's using it.

echelon• 10 years ago

Unless you're a large company. Then you have a monorepo.

twitterdawg• 10 years ago

Have feedback on this post? Let @github know on Twitter.

fosk• 10 years ago

If anybody from GitHub is here, I have a feedback on the new Reviews feature.

When the Review approval is missing or required, please make it clear in the "Pull Requests" list-view by updating the color of the little dot and it's popup description.

Right now the colored dot and its description are only including "Checks" but not "Reviews". It would be nice to have a clear indicator of which Pull Requests are missing a review just by looking at the list.

jcoffland• 10 years ago

Oh how I want the ability to group repos into projects on GitHub. Thought this was it. It's not.

dham• 10 years ago

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.

Animats• 10 years ago

I just hope Github doesn't pivot in a direction that makes them no longer a safe place to archive open source code. We've had two failures already - Google Code (shut down) and Sourceforge (started putting adware on the executables of others.)

Github, please don't blow it.

rileytg• 10 years ago

anyone else consider this too little too late?

shurcooL• 10 years ago

I've just used the new review mode to do a bigger (still medium) sized review [0], and it was quite nice.

It's strange that I can edit any of the inline comments, but not the actual review body itself. What if I made a typo there?

[0] https://github.com/google/go-github/pull/427#pullrequestrevi...

reustle2• 10 years ago

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? :)

Corrado• 10 years ago

I think their recent change to per user pricing plays into this nicely. These features look really cool, but I can see it being costly to an organization when you have to give managers, project managers, etc. access to Github just so they can manage issues.

musicmatze• 10 years ago

What I really wonder right now: When reviewing my own PR on my own repo, I cannot select that the things I proposed must be resolved before the PR can be merged - why is that? Am I not allowed to keep myself from merging things I considered changeworthy or what?

Announcing new tools, forums, and features

Related Stories