@Beanow you bring up some very good points. Conceptually, I think we’re finding that “amount of activity on a PR” is a very bad proxy for “value of the PR”, since lots of activity is more likely to correspond to conversational debugging, controversy, or perhaps bikeshedding–none of which are robust indicators of value.
A better approach may be to have the value of the PR be independent of the activity, but the cred from the PR flows out based on the activity. So a PR that merges without any fuss gives most of the cred to the author; a PR that involves a long conversation prior to merge splits the cred between the participants. Of course this would introduce its own issues (e.g. people incentivized to bikeshed so they can take cred from a PR) but for now I think it would be a better heuristic.
We can implement this by making change to weights; most directly, by changing the “has child” weight to 0. That means, PRs (or issues) will no longer get cred from their comments. If the “has parent” weight is above zero, then PRs (or issues) still give cred to the comments, they just don’t get any back.
If we do so, then the docker PR falls off the top of the cred chart:
I do think the docker PR should get plenty of cred, but the reason is because it was very important for some end users and made it easier to use SourceCred, not because it involved a lot of activity on GitHub. 
I think the best approach will be to come up with a simple system for categorizing PRs by kind (“feature-work”, “bugfix”, “refactor”, “documentation”, “build”, “misc”) and perhaps by difficulty (“trivial”, “easy”, “medium”, “hard”). Then we can categorize the PRs manually, and assign weights to each of these types.
Here’s how the cred looks with the edge weight change applied:
@vsoch still rates quite highly; in part this is because while I changed the edge weights, we still have a pretty high node weight on GitHub comments. Arguably the weight should be close to zero, since we don’t value GitHub comments in and of itself, we mostly just value the changes to code that they participate in. Here’s the scores with the GitHub comment weight set to zero.
Just looking at the relative ordering, I think this might be an improvement over the scores in the first post. Not to downplay @vsoch’s contributions, but both @mzargham and @s_ben have been considerably more involved in the project, so it makes sense to me that they would be ranked higher.