This person signed the wrong one accidentally, they in no way support Richard Stallman nor his despicable behaviour and I can attest to the quality of their character. They tried to remove their signature from the list, but the repo is archived.

Naturally they're blocked from making a PR themselves, hence the request coming from me. I hope that's ok.

Still seeing 502s here. I've looked at the resource limit documentation but don't really understand how this query could be hitting them. In any case splitting up the query seems to resolve the issue.

Apparently sometimes github users go away and thusly can't be blocked. I ran target/release/crabby -vvv -t [redacted] block-users < jerks.csv

...where jerks.csv was generated via list-pr-contributors -r rms-support-letter/rms-support-letter.github.io . It crashed

23:41:13 [WARN] eligiobz was already blocked
23:41:13 [WARN] eliphatfs was already blocked
Error: GitHub { source: GitHubError { documentation_url: "https://docs.github.com/rest/reference/users#block-a-user", errors: None, message: "Not Found" }, backtrace: Backtrace(   0: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll

I can work around by editing jerks.csv , no problem. But it'd be nice if this crash were just a warning, yep.

This PR tweaks the readme so that the examples can be copied from directly. It adds a suggestion to set the token as an environment variable with the name already used in the example and points at the CSV included in the repo.

This PR adds a very basic vscode devcontainer configuration which removes the need for a local Rust install if using the recommended vscode container-based workflow.

The code is unmodified from vscode's suggestion for Rust development, so the container isn't minimal, but does allow for further extension.

Hi! I'm not sure if I should have opened an issue to ask if you wanted this before implementing it, but I figured you can always reject the PR.

One thing I wanted when I ran the command was to also get the user's Twitter handle, which is sometimes available. That way I can use other tools to block or mute them on Twitter as well. One caveat is that Github does not verify whether or not you own the Twitter account you declare as your own, so it could be wrong or targeting someone else.

Also, this my first ever attempt at Rust code so I'm not sure if there's something I maybe should have done differently!

@lahosken noted in #17 that block-users previously crashed when given accounts that no longer existed as input. This was fixed in #6 and #7, but while the command no longer crashed on those inputs, it did still give an inaccurate log message ("was already blocked"). This PR includes several improvements to the log messages, including passing through unknown responses, since I'm not sure we've covered the full range of what the API does here.

You can now enable the appropriate read:org or write:org scope when creating your personal access token and then add --org $MY_ORG to the list-blocks or block-users commands.

This morning I got an email from someone who said they had signed the Richard Stallman support letter but then read this article and decided to remove their signature.

Their GitHub account will still appear in the reports that this tool generates for that repository at the moment, since it simply lists all contributors who have opened PRs against the repo. It seems reasonable to me that somebody should be able to let users of this tool know that they've changed their mind, though, so I've added a (fairly simple) exclusion system in this PR.

By default the tool reads the data/exclusions.csv file, which should be a CSV file where each line includes a repo path (e.g. travisbrown/octocrabby) and a GitHub account that should not be associated with that repo. Specifically, anyone who no longer wishes to be associated with the Stallman letter can add an exclusion to this file, and their account will not show up either in the data/rms-support-letter-contributors.csv file, or in the results for anyone who is using this tool with the default settings.

Any user of this tool can point it to their own exclusions file with --exclusions-file, or can disable the default exclusions with --ignore-exclusions. There are currently two hard-coded excluded users for all repos: ghost and dependabot.

I'll only merge PRs adding rms-support-letter exclusions that link to a rms-support-letter PR removing a signature. Any PRs that demand that I remove "personal information" or whatever will just be closed immediately. I encourage anyone who's tempted to open a PR like that to send me a cease-and-desist email instead, and please use your best fake legalese.

Fixes #8 and #2.

If someone decides that they no longer wish to be associated with the open letter supporting Stallman, it should be possible for them to make that decision known to users of this tool (note that simply removing their signature isn't sufficient, since this tool reports all contributors to a repository).

The implementation is likely to be a data/exclusions.csv file where each line indicates a GitHub username and a repository. This exclusions file would be respected by default when running the list-pr-contributors command, although it will be possible for users of the tool to provide their own exclusions file, or simply to ignore the default exclusions.

The message can include other information about the blocked user ("Blocked user has already been blocked, Blocked user has been flagged as spam"), so we can't just check equality. We could probably also just check that errors is empty. I wish Octocrab would provide the status code in the case of error so we could check for 304 (I don't think it does), but since this is just for a log message it's not a big deal.

There are some pretty fucked-up conversations happening over on the rms-support-letter issue tracker (e.g. some pretty extreme bigotry here, "We know the name of harassing person, it is… as per … . We may want to send abuses against it.", etc.).

It'd be fairly straightforward to add a command that would check for new issue threads or comments on a repo and request snapshots for all updated pages in the Wayback Machine, as a way of tracking and documenting this abuse. My cancel-culture project already has a number of tools for doing this kind of thing for Twitter accounts, and it wouldn't be hard to repurpose some of that code.

The basic approach would be the following:

1. Make a request against the Wayback CDX index to get a list of all archived pages.
2. Get the time of most recent snapshot for each.
3. Make requests against the GitHub API to identify new or updated issues, PRs, and comments.
4. Hit the Wayback save page endpoint for all pages that have been updated since the last snapshot.
5. Report all new Wayback URLs.

At some point we might also want to add Wayback search and bulk downloading tools.