considerations for label sets in low-tech repos

One thing to keep in mind is that not all of our org's repos are used to develop software. We also leverage repos for basic project-level collaboration, documentation management, teaching, and whatever else people wanna try to hack GitHub for.

I'm pretty excited about the opportunity to introduce more and more CoA staff to the serious awesomeness that comes with collaborating in the open and using GitHub. Just this week, though, I had colleagues pull me aside to remind me (and it was a bit painful) that we have a lot of current and potential users who are capable but intimidated when it comes to learning to collaborate on GitHub.

Some of my findings working with CoA GitHub newbies (and having little software development experience myself):
- lots of tags can be overwhelming and turn potential CoA staff users off to the issues feature altogether
- project leaders who set the stage for discussion in CoA repos have varied backgrounds and styles when it comes to project management
- project leaders like having control over the collaboration experience for their teams, but they may not have a ton of expertise in customizing that experience (editing tags and milestones, for example.)

Some of my early recommendations for CoA GitHub leaders:
- limit the number of organization-level policies at this stage in the game, until we get a better sense of what the blockers are for our users who don't have a software development background
- make custom tag sets an opt-in feature when initializing a repo