🤖 Add authors and contributors to Practice Exercises

[ErikSchierboom]

If you got tagged in this PR, it is because you are being credited for work you've done in the past on Exercism here, and we want to ensure you don't miss out on the recognition you deserve 🙂

---

With v3, we've introduced the idea of exercise authors and contributors. This information is stored in the exercises' .meta/config.json files (see the docs).

Concept Exercises, which are all new, already contain authors and contributors. Practice Exercises though are missing this information. In this PR, we attempt to populate the authors and contributors of Practice Exercises based on their commit history.

Maintainer TODO list

These are the things you, the maintainers, should do:

• Check the authors and contributors, adding/removing users where the data is missing or incorrect
• Double-check any renamed Practice Exercises
• Check for Practice Exercises with missing authors, which are most likely due to the author not being on GitHub anymore
• Add additional authors if you know that a Practice Exercise has actually been created by more than one author

For clarity, authors should be the people who originally created the exercise on this track. Contributors should be people who have substantially contributed to that exercise. PRs for typos or multiple-exercise PRs do not automatically mean someone should be considered a contributor to that exercise. Those non-exercise-specific contributions will get recognition through Exercism's reputation system in v3.

If you find something needs updating, just push a new commit to this PR.

Automatic Merging

We will automatically merge this PR before we launch v3, but will give the maximum time we can to maintainers to review it first.

---

The rest of this issue explains how this PR has been generated. You do not need to read it.

Algorithm

We start out by looking at the current Practice Exercises. For each Practice Exercise, we'll look at the commit history of its files to see which commits touched that Practice Exercise. How renames are handled is discussed in the "Renames" section later in this document.

Any commit that we can associate with a Practice Exercise is used to determine authorship/contributorship. Here is how we assign authorship/contributorship:

Authors

1. Find the Git commit author of the oldest commit linked to that Practice Exercise.
2. Find the GitHub username for the Git commit author of that commit
3. Add the GitHub username of the Git commit author to the authors key in the .meta/config.json file

Contributors

1. Find the Git commit authors and any co-authors of all but the oldest commit linked to that Practice Exercise. If there is only one commit, there won't be any contributors.
2. Exclude the Git commit author and any co-authors of the oldest commit from the list of Git commit authors (an author is not also a contributor)
3. Find the GitHub usernames for the Git commit authors and any co-authors of those commits
4. Add the GitHub usernames of the Git commit authors and any co-authors to the contributor key in the .meta/config.json file

We're using the GitHub GraphQL API to find the username of a commit author and any co-authors. In some cases though, a username cannot be found for a commit (e.g. due to the user account no longer existing), in which case we'll skip the commit.

Renames

There are a small number of Practice Exercises that might have been renamed at some point. You can ask Git to "follow" a file over its renames using git log --follow <file>, which will also return commits made before renames. Unfortunately, Git does not store renames, it just stores the contents of the renamed files and tries to guess if a file was renamed by looking at its contents. This can (and will) lead to false positives, where Git will think a file has been renamed whereas it hasn't. As we don't want to have incorrect authors/contributors for exercises, we're ignoring renames. The only exception to this are known exercise renames:

• bracket-push was renamed to matching-brackets
• retree was renamed to satellite
• resistor-colors was renamed to resistor-color-duo
• kindergarden-garden was renamed to kindergarten-garden

If you know of a rename of a Practice Exercise, please check to see if its authors and contributors are correctly set.

Exclusions

There are some commits that we skip over, which thus don't influence the authors/contributors list:

• Commits authored by dependabot[bot], dependabot-preview[bot] or github-actions[bot]
• Bulk update PRs made by ErikSchierboom or kytrinx to update the track

Tracking

exercism/v3-launch#24

---

cc @alexschrod, @andrewclarkson, @AndrewKvalheim, @andy5995, @ashleygwilliams, @attilahorvath, @austinlyons, @AvasDream, @Baelyk, @bantic, @benreyn, @bitfield, @bobahop, @Br1ght0ne, @britto, @cbzehner, @ccouzens, @CGMossa, @chancancode, @chivalry, @cjmochrie, @ClashTheBunny, @cmcaine, @cmccandless, @Cohen-Carlisle, @coriolinus, @counterleft, @cscorley, @cwhakes, @cypher, @danieljl, @darnuria, @DarthStrom, @Dimkar3000, @DmitrySamoylov, @durka, @dvoytik, @Dysp, @eddyp, @EduardoBautista, @efx, @ekse, @elbaro, @elektronaut0815, @Emerentius, @ErikSchierboom, @etrepum, @f3rn0s, @felix91gr, @ffflorian, @fudanchii, @gefjon, @gibfahn, @glennpratt, @go717franciswang, @GoneUp, @gregcline, @gris, @gsauthof, @hekrause, @Henning-K, @hilary, @houhoulis, @hunger, @hydhknn, @IanWhitney, @idealhack, @iHiD, @ijanos, @imbolc, @insideoutclub, @Insti, @ironhaven, @isgj, @jalovatt, @janczer, @jgilray, @JIghtuse, @jku, @Jonah-Horowitz, @jonasbb, @jonasbn, @jonmcalder, @joshgoebel, @juleskers, @k33nice, @kedeggel, @kotp, @krodyrobi, @ktomsic, @kunaltyagi, @kytrinyx, @LeBlue, @leoyvens, @lewisclement, @LogoiLab, @lpil, @lutostag, @matbesancon, @Menkir, @michalfita, @miken500, @mkantor, @mtodor, @murlakatamenka, @N-Parsons, @nathanielknight, @navossoc, @nertpinx, @nfiles, @NieDzejkob, @nikamirrr, @nikhilshagri, @ocstl, @omer-g, @PaulDance, @pedantic79, @petertseng, @piepero, @pminten, @quartsize, @r4f4, @razielgn, @regnerjr, @RiderSargent, @robkeim, @rofrol, @rpottsoh, @rrredface, @sacherjj, @samcday, @scarvalhojr, @shaaraddalvi, @shenek, @shingtaklam1324, @shybyte, @sjwarner-bp, @Smarticles101, @snoyberg, @spazm, @sputnick1124, @sshine, @ssomers, @Stargator, @stefanv, @stevejb71, @stkent, @stringparser, @taravancil, @tejasbubane, @Teo-ShaoWei, @TheBestJohn, @TheDarkula, @thvdburgt, @tjade273, @tmccombs, @TomPradat, @treble37, @tushartyagi, @uzilan, @vadimkerr, @vinmaster, @vvv, @workingjubilee, @xakon, @yawpitch, @ZapAnton as you are referenced in this PR

[sduquette-devolutions]

Edit: oops I'm logged in my work account, my username is @ekse.

Thanks for the credit. Could I be added to the contributors of the circular-buffer exercise? I wrote the first implementation in Rust (#52), I think that was lost in the commit history with the migration to v2.

[cmccandless]

I have never contributed to any exercise on this track

[ErikSchierboom]

I should be removed from the list of contributors.

[cwhakes]

I have only ever contributed to the robot-name and poker tracks.

[ghost]

We'll let this sit for a while to give contributors time to chime in.
In the meantime I will work on some jq magic to address Erik's request to be removed and any other's that crop up.

jq magic WIP

find ./exercises/practice -iname config.json | xargs jq '.contributors = (.contributors | map(select(. != "ErikSchierboom")))' "$0"

[ErikSchierboom]

@efx Ooh, I'm gonna "borrow" that jq magic :)

[petertseng]

I have never contributed to any exercise on this track

Allow me to address this comment, with my choice of this particular comment (rather than anyone else's comment) being only that it is the first example available at hand, not because I'm trying to pick on anyone.

You can blame me for this.

While it is true that is:pr author:cmccandles has zero results, it is nevertheless true that the following pull requests have these following commits, with corresponding originating problem-specifications pull requests:

• Regenerate READMEs from problem-specifications commits #384, originating from dominoes: improve description readability problem-specifications#972
• bob: limit scope of incoming messages #597, originating from bob: limit scope of incoming messages problem-specifications#1267
• isbn-verifier 2.7.0 #745, originating from isbn-verifier: add a test case that would be accepted by an implementation where an invalid character is simply dropped problem-specifications#1245
• bowling 1.2.0 #746, originating from bowling: add tests for rolling after bonus rolls problem-specifications#1189

Whenever I make pull requests that follow changes (READMEs, tests) from problem-specifications and apply them to other tracks, I felt it would be unfair to strip away credit from the originators of the problem-specifications idea.

When discussing how it applies to this pull request, I would say my stance is somewhat similar. If an individual has contributed a README change or test to problem-specifications that is thereafter used in the Rust track, I feel that that contribution is just as valid as a contribution that originated solely in the Rust track.

However, if a contributor who was added for that reason still wishes to be removed (for any reason), no judgment at all, happy to respect their wishes.

As a practical matter, I understand that the guidance in this pull requests says only to retain those who "substantially contributed to that exercise". It may put maintainers in a difficult position, however, if maintainers need to comb through all their exercises (in some tracks, dozens and dozens of them) and judge which contributions are substantial enough. We're only human, after all, and I know as a human that not only am I fallible, the time I have is limited. We all know this, from the fact that I have not taken any substantial maintainer-related actions in many months. There may not be much that can be done, unless there is a way to write a rule that a computer would understand.

[ErikSchierboom]

As a practical matter, I understand that the guidance in this pull requests says only to retain those who "substantially contributed to that exercise". It may put maintainers in a difficult position, however, if maintainers need to comb through all their exercises (in some tracks, dozens and dozens of them) and judge which contributions are substantial enough. We're only human, after all, and I know as a human that not only am I fallible, the time I have is limited. We all know this, from the fact that I have not taken any substantial maintainer-related actions in many months. There may not be much that can be done, unless there is a way to write a rule that a computer would understand.

I 100% agree that we are putting maintainers in a difficult position. We are thus also not reviewing what maintainers do decide upon, so that might reduce the weight of the decision a bit I hope. Phrasing it differently: we're fine with whatever you as maintainers decide to do.

[coriolinus]

My personal instinct is to be generous with attribution: if git says that someone has contributed to an exercise, I'm not interested in doing research to attempt to prove that their contribution was insubstantial. Over-attribution doesn't hurt us in any way. (In all honesty, this policy is motivated by personal reluctance to do all that research, but I'm still not really seeing any downsides to it.)

…

On Fri, Mar 26, 2021 at 8:53 AM Erik Schierboom ***@***.***> wrote: As a practical matter, I understand that the guidance in this pull requests says only to retain those who "substantially contributed to that exercise". It may put maintainers in a difficult position, however, if maintainers need to comb through all their exercises (in some tracks, dozens and dozens of them) and judge which contributions are substantial enough. We're only human, after all, and I know as a human that not only am I fallible, the time I have is limited. We all know this, from the fact that I have not taken any substantial maintainer-related actions in many months. There may not be much that can be done, unless there is a way to write a rule that a computer would understand. I 100% agree that we *are* putting maintainers in a difficult position. We are thus also not reviewing what maintainers do decide upon, so that might reduce the weight of the decision a bit I hope. Phrasing it differently: we're fine with whatever you as maintainers decide to do. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1216 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3V4TQIRSKTUSTF7AZZYC3TFQ4NZANCNFSM4ZXKZDZQ> .

[coriolinus]

@ErikSchierboom Have you given any thought to a reusable github action which validates that this list is maintained? I think it could be work as a file that various tracks could literally just paste into their workflows folder. It would work in two parts:

• When a PR creates a new subfolder of practice or concept, the PR author must appear in appropriate author metadata.
• When a PR touches any file in an existing exercise, the PR author must appear in appropriate contributor metadata unless they are already among the authors.

I'd expect that most tracks would mark this workflow as optional, but it will be very helpful for indicating to new contributors how to get attributed.

[ErikSchierboom]

@ErikSchierboom Have you given any thought to a reusable github action which validates that this list is maintained?

Not yet.

When a PR creates a new subfolder of practice or concept, the PR author must appear in appropriate author metadata.

I like this a lot.

When a PR touches any file in an existing exercise, the PR author must appear in appropriate contributor metadata unless they are already among the authors.

Well, this is not entirely true according to our definition or when someone is a contributor. If it is only a typo fix or a simple cross-exercise update (i.e. not a sizeable contribution) that does not make someone a contributor according to our definition. That said, we could have the workflow detect changes and suggest looking into if the author should be a contributor.

[coriolinus]

If it is only a typo fix or a simple cross-exercise update (i.e. not a sizeable contribution) that does not make someone a contributor according to our definition.

Yeah, agree. We're just constrained by the GHA API, in which the only output statuses are Pass or Fail. I'd ideally like to see a yellow dot if that part of the check failed, but I don't see a simple way to produce it.

Still, if the action results in a failure, producing the red x, but then the details output says something like:

User foo has edited:

practice/bar
practice/bat
concept/baz

but does not appear in the "contributors" metadata of those exercises.

If this is intentional, this failure can be ignored

I think that would be sufficient to inform new users that they should consider adding themselves to the contributors without messing up the CI too badly.

[ghost]

Following my reasoning offered here, I'll approve so we can get this into main.

Follow up PR's most appreciated!

[ErikSchierboom]

Thanks all!