18F / handbook

The home of policies and guidelines that make up TTS.
https://handbook.tts.gsa.gov/
Other
118 stars 124 forks source link

Document procedure or tips for handling spam contributions on GitHub repositories #3403

Open kingcomma opened 1 year ago

kingcomma commented 1 year ago

As a maintainer of an open source GitHub repository, I want guidance on how I should respond to spam or disconcerting contributions (comments, issues, pull requests, etc) from unknown users. Who, if anyone, should be notified of concerning activity? What moderation tools are recommended? Should the user be reported to GitHub? Etc.

Background

Multiple 18F teams have experienced these types of contributions. Without a documented procedure, these teams are left to make their own decisions about how to respond on an ad-hoc basis. This new content would ideally systematize future responses.

Pages

Suggest adding this to the existing GitHub page, potentially in the "tips" section: https://handbook.tts.gsa.gov/tools/github/#tips

kingcomma commented 1 year ago

Note: this type of issue is relevant for any open source repository host (GitHub, GitLab, Gitea, etc), but the handbook currently only has a page devoted to GitHub.

echappen commented 1 year ago

Raising my hand to look further into this.

When moderating open source activity, I like having a code of conduct to reference, so that it doesn’t appear that I’m making decisions unilaterally.

TTS has a COC, and we should report offenders who are part of TTS through TTS’s reporting structure. But of course, open source projects can have offenders outside of TTS.

To account for all scenarios, do we have a version of the TTS COC that is suitable for open source work? If not, I propose that we create one. Among other things, this COC would clarify:

As for who, if anyone, should be notified of concerning activity—I’m not sure, but am willing to look into it. To me, a purpose of reporting activity to the rest of TTS is to identify patterns of behavior across the org and to preemptively warn others of ongoing activity.

kingcomma commented 1 year ago

Pulling some examples of contributing guidelines and codes of conduct from other 18F open source projects:

echappen commented 1 year ago

Thanks! It looks like some of these pull from the Contributor Covenant which I was going to suggest pulling from.

Do we think it's necessary to have One COC to Rule Them All, or leave it up to teams to create their own?

annepetersen commented 1 year ago

digital.gov or USWDS may have some relevant resources