To provide an answer to the question "How many Java projects does each committer work on?"

[fernandocastor]

We need to implement and test the features required to use Groundhog to answer the question in the title of the issue. We then have to use it to actually answer the question.

[rodrigoalvesvieira]

About this question, how are we going to address this issue?

Will we get each particular committer (User) A of a project B and see how many projects with Java as prevailing language does A have?

Please help me identify the approach we will take to answer this question.

[fernandocastor]

Yes, as long as the set of all the Java projects that we get from all the committers is the same as or a subset of the projects that have Java as a language (the "subset" must be specified in case a project can have a main language but no committers). To me, there seems to be only two options, really: (i) the one you proposed; or (ii) to get every Java project and traverse their lists of committers recording whenever each one appears in one such list. Are there any shortcuts I'm not aware of?

[rodrigoalvesvieira]

So professor,

I remember we talked about this very issue last friday. I guess we had decided something that - for lack of attention - I forgot to write down here.

Had we come to the agreement of taking a project A, with a set B of its contributors (with only those who are also GitHub users) and determining the number of Java projects that each committer within B has worked on? Is that correct or have I misunderstood something?

We need to have at least one approach defined so this Issue can be started and then finished. Occasional updates may come later, of course, but we have got to get this Issue going 😏

[fernandocastor]

What would be easier to implement, we the infrastructure that we currently have? To start from the projects or from the developers?

[rodrigoalvesvieira]

Certainly, from the developers. After that that'll just be a matter of
expanding the search to gather user metrics from projects. A bottom-up
approach.

-- rodrigo

2013/8/2 Fernando Castor [email protected]

What would be easier to implement, we the infrastructure that we currently
have? To start from the projects or from the developers?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/52#issuecomment-22016918
.

[fernandocastor]

Go for it, then.

[rodrigoalvesvieira]

Currently, I know no way to get all the projects that a given user is working on. I can only get these projects if the user owns them.

[fernandocastor]

Can't we discover that based on the commits and pull requests that the user performed?

[rodrigoalvesvieira]

Theoretically, yes.

But to get the commits and pull requests we must use the GitHub Events API,
which offers a higher cost in terms of requests necessary to get relevant
data.

To explain better, is obtainable via the GitHub Events API, but this API
endpoint displays all kinds of events, such a Comment or Issue or Milestone
creation. For that reason, way too many requests might be needed in order
for us to be able to fetch sufficient data about Commits.

-- rodrigo

On Wed, Oct 16, 2013 at 4:41 PM, Fernando Castor
[email protected]:

Can't we discover that based on the commits and pull requests that the
user performed?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/52#issuecomment-26450685
.

[fernandocastor]

Hmmm... no straightforward way of associating commits with a project? What if we looked directly at the Git (not Github) commits? The problem in this case might be that the (Github) user might not be directly identifiable. Am I wrong?