
GitHub Report Card - adamlieb
http://githubreportcard.com/
======
Ntagg
I'm a Technical Product Manager at GitHub. I just took a look at this (pretty
cool, maybe we should have deeper user metrics...). I saw a couple of comments
about the 'write access' so I just figured I'd chime in and point out that
it's a required scope to get all of the private contrib info out of the API. I
definitely encourage people to be mindful of what access they grant, but for
what it's worth I did it :)

~~~
throwanem
> it's a required scope to get all of the private contrib info out of the API

Is there a technical reason why that's so, or is it just an artifact of the
way GitHub's OAuth scheme is set up? I can't think offhand of a reason why it
should be the former, but my experience with GitHub private repos is somewhat
seldom, so it's quite probable it is necessary for a reason of which I'm
unaware.

~~~
tomschlick
The new Integrations api they announced at their conference should allow way
more granular control. Still in beta though AFAIK.

[https://developer.github.com/early-
access/integrations/](https://developer.github.com/early-access/integrations/)

~~~
gjtorikian
You are totally correct.

------
aaronpk
If you want to grant it read-only to public repos, try this link:

[https://github.com/login/oauth/authorize?response_type=code&...](https://github.com/login/oauth/authorize?response_type=code&redirect_uri=https%3A%2F%2Fgithubreportcard.reflect.io%2Fauth%2Fgithub%2Fcallback&scope=user%3Aemail&client_id=da6db9cf6cad668b0b89)

~~~
lyinsteve
This should be much higher. Thanks!

------
watson
I have over 200 open source repos, and 2-3 private once on GitHub. They are
private for a reason and it's irresponsible of GitHub to "force" me to make
this choice in order to participate in the echo-system of 3rd party apps that
connect to GitHub. In todays developer world, you need a lot of these 3rd
party tools in order to be a productive programmer (granted not this one, but
hey).

It's even more irresponsible of this dev WHO WORKS AT GITHUB to take this fact
to lightly. Read AND write access to both my public AND private repos is an
insane amount of trust to put in another person. I'm sure this person is a
stand up individual. But does he/she write secure code? How easy is it to gain
access to his database of access tokens?

In this world of Yahoo/Sony/You-name-it hacks that we live in, I'm honestly
surprised there haven't been a hack yet where someone got a hold on a whole
bunch of access tokens to private repos. You could do A LOT of damage with
this. I'll never sign up for a service such as this and the author should be
ashamed to even suggest it.

Instead he/she should focus their time on fixing this issue at GitHub instead
of making apps like this.

~~~
j_s
_echo-system_ I like it! Kind of a mash-up with echo chamber, which seems
equally applicable.

In case English is not your favorite language, the word I believe you're
looking for is _ecosystem_.

~~~
watson
Ups, thanks :)

------
minimaxir
GitHub data is public (for public repositories) and archived, so you don't
even need to use auth.

Example superquick BigQuery for tabulating all 2016 Push Events to GitHub by a
given user for each day-of-week (1 = Sunday):

    
    
       SELECT DAYOFWEEK(created_at) as day_of_week, COUNT(*) as num_pushes
       FROM TABLE_DATE_RANGE([githubarchive:day.], TIMESTAMP('2016-01-01'), TIMESTAMP('2016-12-31'))
       WHERE type = "PushEvent" AND actor.login = "minimaxir"
       GROUP BY day_of_week
       ORDER BY day_of_week
    

Tabulating commits is possible too but requires JSON shenanigans. (Although
the BigQuery data does not have commit dates which may not necessarily be the
same as Push dates, so that may be a problem)

------
maplebed
Once you have your report card, don't forget to revoke access.
[https://github.com/settings/applications](https://github.com/settings/applications)

~~~
josh_carterPDX
Good point. I can see a lot of people are worried this is getting write
access. Thanks for providing a link and a reminder.

~~~
aisofteng
This immediately suggests the ability to provide permissions only for a
specific transaction at a time.

In fact, I believe that that is essentially how Vault manages security.

------
yefim
Please include a checkbox to exclude private repos. I have a lot of private
work that I just can't let anyone see. Thank you!

~~~
biggestlou
Important note: these reports are accessible only by you, the user. They are
not publicly available.

~~~
nothrabannosir
> these reports are accessible _only by you_

And by you, githubreportcard, and by all of your devs, etc, etc. I'm no
lawyer, but I have a feeling this is what some of those NDAs were talking
about.

~~~
Spivak
Sure, but GitHub and all their devs have access to your private repos too. If
that doesn't violate the NDA I'm not sure why GHRC would violate it either
unless they've been grated special exception.

~~~
eridius
The company put the code on GitHub, and the company has the rights to do so.
The developer who signed the NDA doesn't have the rights to do that. And if
the code was actually stored elsewhere and the developer decided to create
their own private repo and upload the code there, that would be a violation of
the NDA.

------
aarohmankad
Open Source Report Card (OSRC) used to be a similar application that I used
quite a bit with my friends. Unfortunately it seems to have broken with
changes to the Github API.

OSRC: [https://github.com/dfm/osrc](https://github.com/dfm/osrc)

------
po1nter
The page is not scrollable so if you're on a small screen and want to see the
rest of the image then here it is:
[https://githubreportcard.reflect.io/images/screenshot.jpg](https://githubreportcard.reflect.io/images/screenshot.jpg)

------
morinted
There's no preamble describing why this report is a thing, nor what will be
included. I'm waiting on mine to be generated, but the landing page leaves
much to be desired.

~~~
morinted
It gave me:

\- Total commits

\- Unique repos

\- Unique languages

\- Total commits by day of week (my favorite graph as it shows a clear trend
in my coding style)

\- Average commits per day

\- % of commits made on weekdays vs weekends

\- Collaborators by changes (other GH users who collaborated on my repos)

\- My additions (+ LOC)

\- My deletions (- LOC)

\- My open source changes

\- Preferred language by repo count (owned)

\- Stars on my stuff

\- Forks of my stuff

\- # of people subscribed to me

Some easy tweet templates at the top.

------
franciscop
It would be awesome if I could see the whole image in the landing page without
having to resize the page. Maybe you could allow the visitors to, you know,
scroll a bit?

Also, I'm under some NDAs so I cannot allow access to the private
repositories. It'd be great if it took only the public ones or public data.

------
killercup
> We're experiencing unusually high traffic so we'll email you when it's
> complete.

That's a nice touch!

~~~
pedrorijo91
same here. are you still having the same problem?

------
rajangdavis
Not sure if anyone else is getting this, but I can't seem to scroll down past
the fold for the site on Chrome on my Windows 7 machine.

Tried using Internet Explorer 11 and nothing showed up at all...

~~~
joatmon-snoo
Yeah, it's just poor UX on their part. The "report card" that you see is
actually a screenshot cropped from the bottom.

------
masukomi
It wants the ability to WRITE to my public AND private repos & create issues.
no. just no.

~~~
biggestlou
Unfortunately, there is no such thing as read-only access to GitHub repos.
Read/write access is the only scope that GitHub currently grants:
[https://developer.github.com/v3/oauth/#scopes](https://developer.github.com/v3/oauth/#scopes).
If you've given a third-party app access to your repos in the past (CircleCI,
Auth0, TravisCI, Heroku, etc.), that access has been read/write.

~~~
atarian
Shouldn't have used OAuth then.

~~~
sergiotapia
You must not be familiar with OAuth authentication for Github. There is no way
to access your repos to analyze except by allowing write-permissions. Github
doesn't allow read-only unfortunately.

~~~
tomschlick
[https://developer.github.com/early-
access/integrations/](https://developer.github.com/early-access/integrations/)

~~~
sergiotapia
>Early Access

~~~
tomschlick
Just means its in beta. You can signup and use it instantly.

------
wildpeaks
Looks like it's getting a bit overloaded at the moment, got the following
error (and indeed, it's missing a good chunk of data):

    
    
      We ran into a small snag
      Some of your change information might be missing.
      GitHub didn't generate repository statistics fast enough so we gave up after a few tries.

------
devoply
I am weary of having managers that might be somewhat incompetent being given a
tool like this to help manage developers.

------
apetresc
I think you're misattributing merge commits or pushes of repository histories
where I'm not the author or something. You claim I've contributed over 2M
lines of code in 2016, which... I don't think is right.

------
mugsie
Unfortunately, it only shows commits done via github directly - not commits
that come in from other sources (I.E. if you have a gerrit instance, that
mirrors to github)

------
gabrielcsapo
The main page sticks when trying to scroll all the way to the bottom. Running
Safari Version 10.0.2 (11602.3.12.0.1) on OS X 10.11.6 (15G1212)

~~~
citruspi
If you're referring to it getting stuck at the "Top Collaborators by Changes"
graph, I think that's actually the bottom.

I had the same experience in Safari, but after looking at the page source, I
think that's actually the complete page. It also looks the same in Firefox
Developer Edition.

Here's the report card image used[0] - it actually does end in the middle of
that graph.

The only thing below that is a footer with the "Crafted by reflect" mark but
it's hidden if the browser is wider than 768px (in which case it shows up on
the top right).

[0]:
[https://githubreportcard.reflect.io/images/screenshot.jpg](https://githubreportcard.reflect.io/images/screenshot.jpg)

------
WhitneyLand
What is the difference between Reflect and and something like Power BI? They
both have embedding, apis, designers, etc.

------
tibu
Is there some way I could use this for our private Github? Would be
interesting to see those numbers.

------
jokavaje
This application does, for some reason, require _write_ access to all of mine
and my organisation's repos.

Just no.

~~~
biggestlou
We understand your reticence (Reflect employee here). Two things to note:

1\. GitHub does not grant read-only access to repos. Any time you authorize a
third-party app to access your repos, you are granting write access. We will
never write to your repos, and our report card isn't doing anything out of the
ordinary (i.e. it's not doing anything that TravisCI, Auth0, and a lot of
other GitHub third-party apps don't do). 2\. Your report card is accessible
only by you and is not publicly viewable.

~~~
jlgaddis
I've read your other replies here and you're apparently still missing the
point several people are trying to make:

The "report card" being public isn't the big concern. The problem is that they
don't know _you_ and they certainly don't _trust_ you. Perhaps they trust some
other devs/orgs ("TravisCI, Auth0, and a lot of other GitHub third-party
apps") but that has nothing whatsoever to do with _you_ (and "but you trust
them, so why not us?" is a laughable argument).

The "report card" requires write access to user's repositories -- and your
statement that "we will never write to your repos" isn't worth the bits it was
written on. While some folks are obviously okay with that, many aren't and
likely never will be (regardless of how many times you repeat it) for any
number of reasons (personal privacy, NDAs, etc.).

~~~
Pyxl101
Just to expand on the parent's point further: it's not just about what the
service does, it's about what could happen in a worst-case scenario if the
service is compromised by an attacker.

Companies get hacked. Well-known companies get breached and their data stolen.
When these companies store access credentials from users, those access
credentials can be stolen too. For example, see the recent DataDog breach [1].
Security credentials that customers gave to DataDog, for the purpose of
allowing DataDog to monitor their infrastructure, were compromied by an
attacker:

> the attacker gained unauthorized access to three of our AWS EC2 instances
> and a subset of our AWS S3 buckets. Those AWS resources included user
> credentials for the Datadog service, service metadata, and _credentials
> shared with Datadog for third-party integrations_.

The attacker then used those credentials to penetrate systems owned by those
customers! Customers were hacked not because the customer did anything wrong,
but because they trusted DataDog, and DataDog did something wrong.

Security-conscious customers will consider the implications of trusting any
service they rely upon, and will consider "What could go wrong?". Very few
companies get security right enough to avoid being breached.

A company with read/write access to many users' GitHub repositories, including
private repositories, will _certainly_ be a major target for attackers. It's
not so much that attackers care about source code _per se_. Rather, attackers
know that all kinds of other information such as access credentials,
username/passwords, etc. get checked into source control by accident or
sometimes even intentionally. The credentials might be hidden in the sense
that they don't show up in a branch currently, but are present in some
historical version of some branch - perhaps a dotfile someone checked in by
mistake, and deleted, but didn't erase the history of. It happens. An attacker
will scan this source history and find those credentials.

Every company that accepts credentials from customers to integrate with other
parties should understand the pivotal role they play in the security of their
customers. What the service _intends_ to do is only part of the story. What
the service _could do_ if compromised by an attacker is an important piece of
the story, and limiting this blast radius by embracing least privilege is an
important part of earning the trust of security-conscious customers.

It is a shame that GitHub does not make least privilege possible in this
scenario, by failing to offer a form of access less powerful than read/write
access. To solve this problem well, GitHub would ideally offer a read-only
API, and perhaps a read-only metadata API that can view commit histories but
not the content of commits. Then, a service integration built on this API can
reassure its customers that, even if the service is hacked, an attacker has no
ability to push commits to customer repos, nor view customer source code.

[1] [https://www.datadoghq.com/blog/2016-07-08-security-
notice/](https://www.datadoghq.com/blog/2016-07-08-security-notice/)

------
lqdc13
Might as well just publish
[https://i.sli.mg/d3m2MD.jpg](https://i.sli.mg/d3m2MD.jpg)

More constructively, people should publish the projects they worked on, not
how often they press save.

