Typically you're going to have a pile of scripts for CI, development setup, deployment, so may as well have those in bin/ systematically. To avoid having confi

Typically you're going to have a pile of scripts for CI, development setup, deployment, so may as well have those in bin/ systematically. To avoid having configuration files clogging up the bottom-level, put those in etc/, and so on. Maybe also share/ for common library code (which could be symlinked into per-plugin locations if you wanted them to be self-contained (git handles symlinks gracefully except on Windows I understand). A doc/ directory maybe? It's likely that the amount of this whole-repo administration code will increase with time, so worthwhile having it with some structure from the start -- the /bin, /etc ... conventions are from Unix of course, but perhaps your team has other roots, in which case whatever works for you. I would advise having these as non-hidden directories with short lower-case names without spaces, makes it easier to script; and README.md files so the documentation is nice & visible on GitHub etc. And yes, the "real" per-project directories in a subdirectory, pkg/, client/, product/, something likes that. Re issues, I've previously used tags to reasonable effect. Not as convenient as per-repo issues, but that's one of the downsides to monorepos. I think the benefits outweigh those.