www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GSoC leaderboard

reply Seb <seb wilzba.ch> writes:
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/
Mar 19
parent reply lagfra <me fragal.eu> writes:
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.
Mar 19
parent reply Seb <seb wilzba.ch> writes:
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.
Mar 19
next sibling parent lagfra <me fragal.eu> writes:
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.
Mar 22
prev sibling parent lagfra <me fragal.eu> writes:
 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.
Mar 22