Contributors page proposal.

[s1db]

Having a list of contributors to an organisation not only gives all its contributors a token of appreciation but also emphasises on the human aspect of open source. But it isn't easy for Sugar Labs to implement this as many contributors are scattered inside repositories and the GitHub API doesn't give a complete list of contributors to an organisation(it just gives the members). We'd need to write a script to go through all our repositories and update that list periodically or we could just have the data from our top 5-10 repos. (i.e www-sugarlabs, sugar, sugar-docs, etc.)

During my last GCI I helped build this: https://zulipchat.com/team/ (Although it has changed a lot since the last time I looked at it. :p)

It'd be a pretty cool addition to add to our website. :D

[samswag]

Nice concept and Idea @cosmicAsymmetry, would you want to do the honors?

[s1db]

@samswag I'd love to! But we need to create a proper structure of the things that we're going to implement and how we'll be going by it.

Like I mentioned above we can do three things(Problems that we could/will encounter/benifits are);

1. Write a script that fetches all the contributors;
   1. Due to the sheer number we'd need to implement pagination.
   2. Find a way to automate the periodic updates to the list.
2. Have the data from our top 5-10 repos;
   1. It doesn't completely represent our organisation. Which well, is a bit sad tbh. :/
   2. It's relatively simpler to implement.
3. Have a list of top contributors and a dropdown for specific projects(basically 1 and 2 :p );
   1. It's relatively hardest to implement.
   2. IMO the best from all 3 as it'll capture us perfectly.

[quozl]

Interesting.

Release manager (currently me) lists contributors for each release of Sugar desktop. I've done that with git log of commits between the previous release tag and the new release tag, for each of the sucrose components being released, and for each of the activities in the core fructose set. I've also removed several trivial contributions such as spelling.

This does not capture;

• translators,
• reviewers,
• testers,
• issue reporters, or
• issue solution negotiators.

We don't have a good reason to only include commit authors. We don't consistently use the Reported-by, Tested-by or Reviewed-by commit message markers.

Look at Linux kernel git history visualisation for some options. Developers in Sugar Labs are clustering around specific repositories, so perhaps express that clustering as well. Especially note the Music Blocks and Sugarizer contributions which are not part of our GitHub organisation. So don't write anything that only looks within our organisation.

[s1db]

I completely agree and that's kind of my point. If we want to represent the contributions in an organisation we need to show everyone. But for that we'd need a consolidated list of contributors for specific fields and (this is preferred but it's fine if it isn't there) the number of contributions. For translators we have: https://translate.sugarlabs.org/about/contributors/ If there are any resources for reviewers, testers, issue reporters, and/or issue solution negotiators please do let me know.

We should collect up all the possible resources before we start work on this.

[quozl]

Sure, here's some ideas;

• reviewers; non-GitHub users who add a Reviewed-by marker to a commit message, GitHub users who post comments to pull requests but are not in the list of authors of the commits on the pull request; except cases where reviewers post commits and post comments,
• testers; non-GitHub users who add a Tested-by marker to a commit message, GitHub users who say they have tested a pull request, or who have created an issue that they don't need a solution for,
• issue reporters; non-GitHub users who add a Reported-by marker to a commit message, GitHub users who create an issue that they need a solution for, but who aren't core developers using issue tracking for task tracking,
• issue solution negotiators; GitHub users who comment on issues but don't end up being authors of any commits that solve the issues, and are not the issue reporter.

Next to consider are;

• wiki.sugarlabs.org page editors,
• IRC speakers,
• activities.sugarlabs.org reviewers,
• mailing list posters.

I'd also like a way for a contributor to be excluded from this system by their choice. I'll nominate myself.

[s1db]

Haha okay. :) Basically I need to write a Python script to get all this data and store it in a JSON which then gets called by the the SL website. Exceptions should be easy to code onto this.

Should I think about ways to automate this script later and start work on the layout? Or should we iron that out now?

[Hrishi1999]

There is a GitHub API which gives result in JSON, like author name, and else. You can later sort it out. We used this for pre-GCI preparations.

On Jan 8, 2018 4:14 PM, "Sidhant Bhavnani" notifications@github.com wrote:

Haha okay. :) Basically I need to write a Python script to get all this data and store it in a JSON which then gets called by the the SL website. Exceptions should be easy to code onto this.

Should I think about ways to automate this script later and start work on the layout? Or should we iron that out now?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sugarlabs/www-sugarlabs/issues/191#issuecomment-355933589, or mute the thread https://github.com/notifications/unsubscribe-auth/APdTUusVp09EAHURrLe2vbd-fF8A--apks5tIfGngaJpZM4RVvNZ .

[quozl]

I'm not the target audience of the resulting information and layout, so my opinion shouldn't matter. Having explained the difficulties I see with the idea, I've nothing further to add. Have fun! :grin:

[s1db]

I have an upcoming school exam. I'll start working on this on Thursday! :smile: