search

unicef / magicbox

A platform that uses real-time data to inform life-saving humanitarian responses to emergency situations
https://www.unicef.org/innovation/Magicbox
BSD 3-Clause "New" or "Revised" License
86 stars 16 forks source link

Create new repo to be a git submodule for other repos #10

Closed jwflory closed 6 years ago

jwflory commented 6 years ago

Summary

Create a new repo in UNICEF to hold common documents (e.g. Code of Conduct, issue / PR / README templates, contributing guidelines, etc.) to be used as a git submodule in other GitHub repos

Background

Every GitHub repo can contain a special .github folder that holds "special" files, like what's shown in the community report card. Some of these files may be the same across multiple UNICEF or MagicBox repos. If a decision is ever made to change a file used across many repositories, that means every repository has to be manually updated…

A simple "hack" is using a git submodule that anyone can clone to the .github directory in their repo. This clones a git repo inside of a git repo. So, if any changes are made to a global file, a project maintainer only has to update the git submodule instead of manually updating the files in each repo.

Details

I haven't tried this out, but in theory, it should work.

If the solution makes sense, we need to create a new repo underneath the UNICEF organization to hold these common files. Possible name ideas could be community or magicbox-community. This also provides us a way to make unique discussions to the MagicBox community as issues.

Alternatively, instead of a new repo, this repository (i.e. UNICEF/magicbox) could serve this purpose. However, the use of this repo, other than the wiki, is not yet clear to me. (Thus, I tagged this issue with needs feedback).

Outcome

Important documents (e.g. code of conduct, misc. templates) shared across multiple UNICEF / MagicBox repos become easy to maintain and it's less work for a small team to remember to update everything if a change is agreed on

jwflory commented 6 years ago

Moving this to backburner. Wasn't as elegant of a solution as I thought it might be – for now, working on getting a basic set of guidelines in place.

jwflory commented 6 years ago

I've given this further thought, and I think it's a more troubling solution than it's worth setting up. Closing this and we'll manage it by a repo-by-repo basis.

derberg commented 3 years ago

@jwflory have a look at https://github.com/derberg/global-workflows-support. We use it for GitHub Actions workflows distribution but there are discussions we should replicate other community health files this way. We use it for several months already in AsyncAPI Initiative and works well, also other organizations adopted it.