Add a slightly more comprehensive way of monitoring JSON files

[vladh]

What if a member's JSON file starts 404ing? Should they stop showing up on the website? Should they stay there, but with a warning label? Should we receive an alert, so that we can contact the member?

What if a member doesn't add an annual report for a long time? Should we receive an alert, so that we can ask them for one?

[voxpelli]

One flow I have started using is to use scheduled GitHub Actions to automatically raise PR:s with such changes.

Examples:

1. https://github.com/SocketDev/socket-sdk-js/pull/228 (see workflow)
2. https://github.com/neostandard/neostandard/pull/172 (see workflow)
3. https://github.com/voxpelli/tsconfig/pull/59 (see workflow and especially this reusable one, which is the latest iteration of these three)

I could try to lend a hand in this if you are interested

[vladh]

Thanks @voxpelli! A workflow would be nice, but I think it needs to send an email or similar — if the JSON file is down on a member's website, we don't have the ability to fix that, so all we can do is let them know.

[chadwhitacre]

(Simplifying labels fwiw)

[vladh]

Here's a suggestion. We could have a scheduled GitHub action that runs a script that checks the JSON files. The script would check two things. First of all, is the JSON file inaccessible? Secondly, is the date of the last annual report 11 months in the past or more? We could also add other checks. If one of the checks fails, the action would send an email to all Open Source Pledge maintainers. The maintainers can then decide on the appropriate course of action, which will most likely be forwarding the email to the appropriate contact for that company.

Additionally, on individual member pages, when showing annual reports, if the last annual report is from more than a year ago, we should show a message on the website, explaining that we're waiting for this member's annual report. This will ensure we avoid the appearance of the website being unmaintained or of us being too lax.

[chadwhitacre]

I'm generally in favor of solving this one way or another.

If one of the checks fails, the action would send an email to all Open Source Pledge maintainers.

Won't a PR like @voxpelli suggests naturally result in an email (or other notification) to Pledge maintainers?

[vladh]

Won't a PR like @voxpelli suggests naturally result in an email (or other notification) to Pledge maintainers?

For sure, I'm just not quite seeing what suggested changes to our repo the PR would contain.

[chadwhitacre]

I guess removing the company from members.csv could make sense? Bot proposes removing, we then follow up to see if that is the right decision?

[vladh]

Hmm, I don't think so, because:

1. We could use a system that alerts us before action is required, so that we can give some notice. For example, if a member has 1 month left to submit the next annual report, this is not cause for removal, but a notification should still be sent.
2. It would be nice to preserve goodwill by addressing lapsed memberships with inquiry/conversation, not an automated removal “one strike and you're (automatically proposed to be) out” policy.

[chadwhitacre]

My thinking was that using GH notification flow is low-hanging fruit, and it's easy enough to close (rather than merge) the PR if/when the member re-ups.

[chadwhitacre]

Having the PR also gives us a natural place to keep track of pending renewals and provide updates as we reach out.

[vladh]

Got it, then let's have it open an issue instead of a PR — best of both worlds! If any action is taken we can mention the issue as related.

[chadwhitacre]

Perfect. :) 🎉