digitalmars.D - GSoC leaderboard
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 2019
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 2019
On Tuesday, 19 March 2019 at 12:12:55 UTC, lagfra wrote:On Tuesday, 19 March 2019 at 09:59:48 UTC, Seb wrote: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.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 2019
lagfra <me fragal.eu> 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 2019
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 2019