Re: [RFC] List of contributors per module
On 6/14/2016 6:10 PM, Seb wrote: On Wednesday, 25 May 2016 at 06:51:45 UTC, Walter Bright wrote: On 5/24/2016 12:22 PM, Seb wrote: I recently made a PR to dlang.org which is aimed to show a list of all contributors to a Phobos module based on the git history. The idea is to give all the awesome people who have helped and contributed their earned credit! One idea is to add a "Contributors" button, and when clicked, it executes some javascript that then loads and displays the avatars for the contributors. As there as been diverse feedback and no conclusion, I would like try to revive this discussion - preferably on Github [1]. To argue against some of the posts here, a short summary of the Github discussion: 1) There's _no_ performance impact - everything is down lazily after the page was loaded (see Github for an detailed description) 2) The clutter isn't visible too most users anyhow as the contributer's list is shown at the bottom of the page 3) It currently would require a lot of hard-to-main ddoc hacks to due this at compile-time (see Github) There's still the added net traffic (bad for mobile users). If you have better ideas how we could incorporate such statistics, let me know :) Sure: One idea is to add a "Contributors" button, and when clicked, it executes some javascript that then loads and displays the avatars for the contributors.
Re: [RFC] List of contributors per module
On Wednesday, 25 May 2016 at 06:51:45 UTC, Walter Bright wrote: On 5/24/2016 12:22 PM, Seb wrote: I recently made a PR to dlang.org which is aimed to show a list of all contributors to a Phobos module based on the git history. The idea is to give all the awesome people who have helped and contributed their earned credit! One idea is to add a "Contributors" button, and when clicked, it executes some javascript that then loads and displays the avatars for the contributors. As there as been diverse feedback and no conclusion, I would like try to revive this discussion - preferably on Github [1]. To argue against some of the posts here, a short summary of the Github discussion: 1) There's _no_ performance impact - everything is down lazily after the page was loaded (see Github for an detailed description) 2) The clutter isn't visible too most users anyhow as the contributer's list is shown at the bottom of the page 3) It currently would require a lot of hard-to-main ddoc hacks to due this at compile-time (see Github) If you have better ideas how we could incorporate such statistics, let me know :) [1] https://github.com/dlang/dlang.org/pull/1307
Re: [RFC] List of contributors per module
On 5/24/2016 12:22 PM, Seb wrote: I recently made a PR to dlang.org which is aimed to show a list of all contributors to a Phobos module based on the git history. The idea is to give all the awesome people who have helped and contributed their earned credit! One idea is to add a "Contributors" button, and when clicked, it executes some javascript that then loads and displays the avatars for the contributors.
Re: [RFC] List of contributors per module
On 2016-05-24 21:22, Seb wrote: Hei, I recently made a PR to dlang.org which is aimed to show a list of all contributors to a Phobos module based on the git history. The idea is to give all the awesome people who have helped and contributed their earned credit! https://github.com/dlang/dlang.org/pull/1307 A couple of questions from this PR are still open though: 1) How can we best integrate this with the author section? - Should we move this into the header? - Maybe a module could also have a current maintainer(s) (that is in charge of approving changes) 2) Should we show the avatars? They are loaded lazily, so they don't block the page load. If neccessary out of privacy concerns, contribs.dlang.io could act as a proxy. 3) I would prefer to generate this information on deploy-time, but rolling a small (vibe.d) service was a lot easier than integrating this properly in the current Makefile. Maybe once we migrate to ddox this would be easier? Please don't add this to the docs. It's enough information there already. -- /Jacob Carlborg
Re: [RFC] List of contributors per module
I enjoy a good ego stroking, but there are enough issues with the docs being cluttered and harder to digest than necessary already. I'm not a big fan of adding more clutter. On 5/24/16 12:22 PM, Seb via Digitalmars-d wrote: Hei, I recently made a PR to dlang.org which is aimed to show a list of all contributors to a Phobos module based on the git history. The idea is to give all the awesome people who have helped and contributed their earned credit! https://github.com/dlang/dlang.org/pull/1307 A couple of questions from this PR are still open though: 1) How can we best integrate this with the author section? - Should we move this into the header? - Maybe a module could also have a current maintainer(s) (that is in charge of approving changes) 2) Should we show the avatars? They are loaded lazily, so they don't block the page load. If neccessary out of privacy concerns, contribs.dlang.io could act as a proxy. 3) I would prefer to generate this information on deploy-time, but rolling a small (vibe.d) service was a lot easier than integrating this properly in the current Makefile. Maybe once we migrate to ddox this would be easier?
Re: [RFC] List of contributors per module
On 05/24/2016 09:22 PM, Seb wrote: 3) I would prefer to generate this information on deploy-time, but rolling a small (vibe.d) service was a lot easier than integrating this properly in the current Makefile. Maybe once we migrate to ddox this would be easier? I agree that this should be done when documentation is being built. The information doesn't change, so loading it dynamically only makes things slower. Generally, I think we should be reducing the amount of JavasScript where possible, not do even more with JS that could be done when generating HTML. A relatively simple, non-disruptive way towards more static generation would be writing small programs that generate .ddoc files, like the changelog builder you've got in the making [1]. So maybe we can have a little tool that generates a git-contributors.ddoc which contains a bunch of contributor lists as Ddoc macros, one per module. Then, for example, in std/stdio.d we put `$(GIT_CONTRIBUTORS_STD_STDIO)` somewhere. That means touching every single module, but there's precedent with the PHOBOSSRC macro. Or, since the .html files actually seem to be built individually, the tool could generate a bunch of git-contributors-*.ddoc files, each of which defines just a single GIT_CONTRIBUTORS macro. Then it could be included in a skeleton file, or at least there less potential for mistakes when it's put in all source files. [1] https://github.com/dlang/tools/pull/186
Re: [RFC] List of contributors per module
On Tuesday, 24 May 2016 at 19:22:31 UTC, Seb wrote: I recently made a PR to dlang.org which is aimed to show a list of all contributors to a Phobos module based on the git history. The idea is to give all the awesome people who have helped and contributed their earned credit! Is this really a good idea? The file with the most authors is std/traits.d with 73 authors. Really list them all? There might be duplicates, if people use different names or email addresses. There should be a deduplication. Btw if you want some more stats, I have script which gives me this for the phobos repo: Top Committers (of 338 authors): Andrei Alexandrescu 1608 commits during 8 years until 2016-04-15 k-hara646 commits during 4 years until 2016-04-28 Walter Bright 643 commits during 8 years until 2016-04-25 H. S. Teoh625 commits during 4 years until 2016-05-10 Dmitry Olshansky 517 commits during 4 years until 2016-05-20 jmdavis 501 commits during 3 years until 2014-10-26 monarch dodra 421 commits during 2 years until 2015-03-12 Martin Nowak 369 commits during 4 years until 2016-05-14 Brad Roberts 340 commits during 8 years until 2016-04-16 Vladimir Panteleev323 commits during 4 years until 2016-05-18 Andrej Mitrovic 296 commits during 4 years until 2015-10-18 Jonathan M Davis 261 commits during 5 years until 2016-05-04 Ilya Yaroshenko 208 commits during 23 months until 2016-05-15 David Nadlinger 207 commits during 5 years until 2016-05-22 David Simcha 207 commits during 2 years until 2012-10-18 Hara Kenji193 commits during 4 years until 2016-03-24 monarchdodra 181 commits during 2 years until 2014-10-10 Denis Shelomovskij179 commits during 3 years until 2015-03-06 Don Clugston 172 commits during 5 years until 2013-12-10 Tomoya Tanjo 166 commits during 2 years until 2016-03-22 Daniel Murphy 162 commits during 4 years until 2016-05-18 Steven Schveighoffer 149 commits during 5 years until 2016-05-17 Alex Rønne Petersen 147 commits during 3 years until 2014-08-04 Robert burner Schadek 134 commits during 2 years until 2016-05-02 Lars T. Kyllingstad 117 commits during 5 years until 2016-02-25 dsimcha 109 commits during 22 months until 2012-12-08 Jack Stouffer 94 commits during 9 months until 2016-05-18 Sean Kelly 93 commits during 6 years until 2014-10-27 Михаил Страшун 90 commits during 6 months until 2015-01-26 Shin Fujishiro 79 commits during 6 months until 2010-11-18 Nick Treleaven 79 commits during 4 years until 2016-05-04 Jonas Drewsen 75 commits during 2 years until 2014-01-13 JakobOvrum 70 commits during 3 years until 2016-04-04 Peter Alexander69 commits during 3 years until 2015-07-22 together these authors have 80+% of the commits (9530/11853) Files with most commits: 411 commits: std/traits.d during 8 years until 2016-05-07 414 commits: std/string.d during 8 years until 2016-05-11 442 commits: std/range.d during 5 years until 2014-11-07 475 commits: std/conv.d during 8 years until 2016-05-14 653 commits: std/algorithm.d during 7 years until 2015-01-17 Files with most authors: 64 authors: std/stdio.d 66 authors: std/file.d 68 authors: std/conv.d 71 authors: std/algorithm.d 73 authors: std/traits.d By file extension: .d: 511 files .h: 66 files together these make up 80+% of the files (577/697)
Re: [RFC] List of contributors per module
On Tuesday, 24 May 2016 at 19:22:31 UTC, Seb wrote: Hei, I recently made a PR to dlang.org which is aimed to show a list of all contributors to a Phobos module based on the git history. The idea is to give all the awesome people who have helped and contributed their earned credit! https://github.com/dlang/dlang.org/pull/1307 A couple of questions from this PR are still open though: 1) How can we best integrate this with the author section? - Should we move this into the header? - Maybe a module could also have a current maintainer(s) (that is in charge of approving changes) 2) Should we show the avatars? They are loaded lazily, so they don't block the page load. If neccessary out of privacy concerns, contribs.dlang.io could act as a proxy. 3) I would prefer to generate this information on deploy-time, but rolling a small (vibe.d) service was a lot easier than integrating this properly in the current Makefile. Maybe once we migrate to ddox this would be easier? I forgot if you want to see this in live, you can browse the output of DAutotest, e.g.: http://dtest.thecybershadow.net/artifact/website-2ebaa0abe10645832000264a7cb6499949dee786-2b1fd6809124063d6afd0801431f016f/web/phobos/std_uri.html
[RFC] List of contributors per module
Hei, I recently made a PR to dlang.org which is aimed to show a list of all contributors to a Phobos module based on the git history. The idea is to give all the awesome people who have helped and contributed their earned credit! https://github.com/dlang/dlang.org/pull/1307 A couple of questions from this PR are still open though: 1) How can we best integrate this with the author section? - Should we move this into the header? - Maybe a module could also have a current maintainer(s) (that is in charge of approving changes) 2) Should we show the avatars? They are loaded lazily, so they don't block the page load. If neccessary out of privacy concerns, contribs.dlang.io could act as a proxy. 3) I would prefer to generate this information on deploy-time, but rolling a small (vibe.d) service was a lot easier than integrating this properly in the current Makefile. Maybe once we migrate to ddox this would be easier?
