Consider creating ".github" repo for default community health files

[pjsier]

GitHub supports creating default community health files like CODE_OF_CONDUCT.md and CONTRIBUTING.md for organizations by creating a repo named ".github". It wouldn't override any existing project's community files, and projects could opt-out by adding files at any time.

It could make it easier to maintain policies across repos while still making them easy to find through some of GitHub's functionality around flagging codes of conduct and contributing guidelines in the UI for issues and PRs. I didn't see any mention of this in previous issues, but let me know if I missed something!

[michaelkirk]

This is awesome. I didn't know it existed. I'm definitely in favor.

[urschrei]

Yep, this rules.

[pjsier]

Great! I can leave this open for a bit in case anyone has other thoughts. It might also make sense to remove the files from repos where they're currently just duplicated and not intentionally different and update any links pointing to them

[michaelkirk]

Many of the repositories in georust already have this COC, but some might not. I imagine people will be fine with it, but procedurally it would be good to solicit their input before affecting them.

Similarly, I'm not sure what a good generic CONTRIBUTING would contain, but that could be a followup change.

Are you interested in shepherding this @pjsier? =)

https://github.com/organizations/georust/repositories/new

[pjsier]

@michaelkirk sounds good to me! To clarify, is the priority before creating the repo to check with projects that don't currently have a code of conduct file since those repos would be affected? It probably makes sense to eventually check with every project, since some might want to opt-in to using the default.

And is the best way to check with maintainers right now filing issues on each project? I've seen the Core team discussions used a bit, but not sure if that's checked as often

[michaelkirk]

@michaelkirk sounds good to me! To clarify, is the priority before creating the repo to check with projects that don't currently have a code of conduct file since those repos would be affected? It probably makes sense to eventually check with every project, since some might want to opt-in to using the default.

Heh, "the" priority might imply the existence of some nonexistent singular authority. My own perspective is that since georust is a participatory community, I try to approach people from the perspective of: "Here's what I'd like us to do. Do you have concerns?"

Since we're all busy and it's easy to ignore requests for feedback, I often try to expedite the process with a bias for action by phrasing things more like : "Unless I hear otherwise, here's a summary of what I'm planning to do on such-and-such timeframe. But I am very open to feedback. Here's a link to the centralized discussion about why we're doing this [.]."

re: COC

Some "advice" from me would be: audit to see who would be affected. Maybe there's no one and we can move forward immediately since noone will see any changes. If there are some, reach out before hand with the plan and a time window. I usually give it a week. For most people, managing their georust repository isn't a daily responsibility.

To be clear, I expect people will support this change, but I think maintainers should have informed control of their repositories.

And is the best way to check with maintainers right now filing issues on each project? I've seen the Core team discussions used a bit, but not sure if that's checked as often

None of these are a silver bullet, but this is my experience:

• You can tag the georust/core GH group: In my experience a modest group of people will see this.
• You can mention it in the discord: In my experience a slightly larger group of people notice this. Discord itself is nice for rapid back-and-forth, but IMO GH is a better place to record organization decisions.
• You can create issues/pr in each individual repository. In my experience, all the maintainers will respond to these, but it's not a flexible way to have discussions since it's so scattered, so I'd wait until there is a clear action to take before spamming every repository.

With the goal of accelerating adoption and minimizing maintainer effort, once the default CoC is in place, I'd recommend phrasing this as a PR with just enough context so maintainers can understand and click "merge" to adopt the default CoC.

So those are just my thoughts, but I'll also say that since you are intending to do the work, you have some latitude here, and I'm happy to have you make different decisions if you think they are reasonable.

[pjsier]

Thanks for the context and thorough reply! This is helpful, and I think I have a sense of next steps based on what you've mentioned here.

I'll make a separate issue with a proposal including a timeline and a list of projects that would be immediately affected (it looks like there are 10). To keep things clear I'll close this issue this but link it in the new one for additional context. If there aren't any major objections I can open PRs for projects to adopt the default Code of Conduct after that

[pjsier]

Closing this now that #25 is posted, thanks for the comments!