GitHub community health files - #127
Conversation
|
This makes me think we might want a section for resources covering multiple requirements, and from there just link to those it covers. That way we only need to add it once but still get it connected to the requirements. However, this will be easy to miss for a reader diving into a specific requirement. |
|
For my employer, I'm working on a to-do list with guidance and templates when setting up a new repo based on the Foundation for Public Code's Product Assets and Community Assets checklists. It's currently localized to the Netherlands, but I can share a generic version when I'm finished? |
|
Update from community call: merge as is (even with repetition) so that all potentially helpful content is colocated, and because this PR alone won't make the Implementation Guide too hard to read (because it' s currently pretty sparse). In the future, when we have more content or a clearer plan for building a 'getting started' guide, then we can edit/slice it differently. |
This implements #123.
I'd like feedback on my approach. I've gone for completeness and added the Github instructions for adding a community health file to every criterion where the content fulfilling that criterion lives naturally in that file (example: a CONTRIBUTING could contain content on both coding style and how to group changes in commits).
But it results in potentially reduced readability, since the same or similar content is reproduced in multiple places. A different approach would be to link once to the file instructions in only the most relevant place, and trust the reader to work it out from there.
Thoughts?