GitHub org-wide community health file fallbacks

Packaging
1

Hi,

GitHub has (for a while now) a way of having organization-global files for CoC, contributing, support and issue/PR templates.

So files you normally put into separate repos can also exist in a special repo in the organization called .github. If you put a certain file there it will be picked up by all repos not having it. For example, if you put CODE_OF_CONDUCT in this repo, all repos not having CoC will link to this one. You can override it by putting this file into repos.

Ref: https://help.github.com/en/articles/creating-a-default-community-health-file-for-your-organization

This post is inspired by the info that PyPA requires all its repos to adopt its CoC. Since I mentioned this feature to @pradyunsg, he asked me to share this here.

For PyPA to use this, it’d be needed to create https://github.com/pypa/.github repo and go from there.

1 Like
2

@dustin @EWDurbin Let’s do this?

3

I think it makes sense for our CoC. Not sure what else it would make sense for. There were recent discussions about PyPA’s preferred license, maybe we could suggest one as well if we came to an agreement?

1 Like
4

The licence is more complicated as it should be packaged too :thinking:

5

Generic versions of issue/PR templates would also be useful.

6

That say what, though? Every code project is rather unique in our org, so I’m not sure what a generic template would even say.

1 Like
7

From my understanding, if the CoC was only in the top level .github repo, the CoC would not really be present in each repository (in a git sense) meaning that user git cloning a particular repository (pip for example) would not get the CoC file ?
I’m not sure it would be a good idea.

I’m also wondering how it would work on forks…

8

generic things like “provide STR” for bugs maybe, expected/actual result; proposed solution for feature requests.

It shouldn’t be specific about projects but be a fallback for new projects which don’t yet have any of such templates.

9

True, and yet there’s solutions to this.

  1. put a link to the CoC in README/docs;
  2. maybe periodically merge this via git subtree into projects if really needed.

Depending on requirements it shouldn’t be a problem + I want to emphasize once again: it’s a fallback so it’s useful for new repos but can be overridden.