tl;dr: The Rocket community is using this leaderboard [1, 2] for GSoC contributions from their students.

I am not sure yet whether it's a good idea as not all pull requests are equal, but I like the idea of gamifying the contribution experience.

Should we setup sth. like this?

[1] https://gsoc.rocket.chat
[2] https://github.com/shubhsherl/GSoC-Contribution-Leaderboard/

On Tuesday, 19 March 2019 at 09:59:48 UTC, Seb wrote:
> tl;dr: The Rocket community is using this leaderboard [1, 2] for GSoC contributions from their students.
>
> I am not sure yet whether it's a good idea as not all pull requests are equal, but I like the idea of gamifying the contribution experience.

In my opinion is not just a matter of PRs but of projects. A practical example related to SAoC:

1. vibe-http and HTTP/2: I opened around 15 PRs of variable length. My project required writing a consistent amount of code, so quite often I had to discuss and then replicate / split / rebase my changes. For this reason, most of my work was done through Github.

2. Concurrent GC: FraMecca's work consisted in writing less than 300 lines of code, but required a lot of debugging and many exchanges with his mentor, mainly using emails. All of his work is going to end with one (or possibly two) PRs to DRuntime.

If one had to compare our work following the approach of the Rocket community, there would be a huge gap between us two, even though we worked a similar amount of time and both provided hopefully valid results.

On Tuesday, 19 March 2019 at 12:12:55 UTC, lagfra wrote:
> On Tuesday, 19 March 2019 at 09:59:48 UTC, Seb wrote:
>> tl;dr: The Rocket community is using this leaderboard [1, 2] for GSoC contributions from their students.
>>
>> I am not sure yet whether it's a good idea as not all pull requests are equal, but I like the idea of gamifying the contribution experience.
>
> In my opinion is not just a matter of PRs but of projects. A practical example related to SAoC:
>
> 1. vibe-http and HTTP/2: I opened around 15 PRs of variable length. My project required writing a consistent amount of code, so quite often I had to discuss and then replicate / split / rebase my changes. For this reason, most of my work was done through Github.
>
> 2. Concurrent GC: FraMecca's work consisted in writing less than 300 lines of code, but required a lot of debugging and many exchanges with his mentor, mainly using emails. All of his work is going to end with one (or possibly two) PRs to DRuntime.
>
> If one had to compare our work following the approach of the Rocket community, there would be a huge gap between us two, even though we worked a similar amount of time and both provided hopefully valid results.

Yep, I absolutely understand this and it could definitely lead to "dummy PRs", but I think the idea of this leaderboard was just to track contributions of students before the actual GSoC. Or in other words: motivate new students to get involved before GSoC.

If we make it a requirement for them to be on to be on the leaderboard (i.e. one open PR) this could lead to the effect that they see all the other students who are trying to apply and try even harder to fix bugs. At least that's what I think this gamification approach is trying to go for.

> If we make it a requirement for them to be on to be on the leaderboard (i.e. one open PR) this could lead to the effect that they see all the other students who are trying to apply and try even harder to fix bugs. At least that's what I think this gamification approach is trying to go for.

A similar, but less competitive approach would be to ask applicants to solve one
easy bug (or perform one of the "easy tasks" listed in https://wiki.dlang.org/Get_involved).
In this case a simple list of bugs solved or contributions performed would be
sufficient, and everybody would start from the same point (e.g. one bug closed
each). The Libreoffice Foundation is one of the organizations which uses this
approach (calling them "easy hacks").

Of course gamification could benefit the number of bugs fixed, but IMHO it could introduce lower quality code and result in a lot of noise which would need to be managed by some mentor / mantainer.

On Tuesday, 19 March 2019 at 12:47:18 UTC, Seb wrote:
> If we make it a requirement for them to be on to be on the leaderboard (i.e. one open PR) this could lead to the effect that they see all the other students who are trying to apply and try even harder to fix bugs. At least that's what I think this gamification approach is trying to go for.

A similar, but less competitive approach would be to ask applicants to solve one
easy bug (or perform one of the "easy tasks" listed in https://wiki.dlang.org/Get_involved).
In this case a simple list of bugs solved or contributions performed would be
sufficient, and everybody would start from the same point (e.g. one bug closed
each). The Libreoffice Foundation is one of the organizations which uses this
approach (calling them "easy hacks").

Of course gamification could benefit the number of bugs fixed, but IMHO it could
introduce lower quality code and result in a lot of noise which would need to be
managed by some mentor / mantainer.