Remove hard requirement for GSA agencies to use the GSA org

[konklone]

The draft open source framework says:

All GSA staff interested in using GitHub must utilize the agency account rather than creating accounts for individual offices, programs or projects.

This is, as far as I can tell, a new (draft) requirement. I don't believe this should be made a hard requirement.

In the short-term, the GSA GitHub organization currently has no operational structure that maintains consistent security standards or team management. For example, there is no requirement for users to have two-factor authentication enabled, or for an avatar or full name to be filled out on user profiles to make identity more clear and mistakes less likely. In addition, in order to make these a requirement, a person or team must be delegated responsibility for monitoring and enforcing this, or the requirement will not truly be in effect.

More generally, there are many valid reasons for a program team to use their own organization.

• A program office will benefit from having their own branding (including organization avatar, contact email, URL, etc.), rather than the generic GSA logo and contact information.
• A program team may have multiple repositories that are less confusing to stakeholders and contributors to group together, without being lost in a sea of generic GSA repositories.
• A program team may have higher security needs for particular repositories that merit a narrower range of user accounts with access to those repositories than those authorized to access @GSA repos.
• A program team may wish to administer permissions for outside contributors differently than @GSA at large. For example, 18F's analytics-reporter tool powers analytics.usa.gov and analytics.phila.gov, and we are implementing a traditional open source project workflow where trusted outside implementers may have write permissions.
• A program team may desire more flexibility in how they work, without needing to seek permission from @GSA Owners or Administrators to create and administer teams.

In short, lumping everyone into @GSA is likely to create a slower, less dynamic open source environment for both GSA staff and outside contributors.

Instead of forcing program agencies to use the @GSA organization, defining consistent standards that GSA-administered organizations should follow would enhance both security and program office flexibility, and maximize the efficacy of GSA's open source program.

[NoahKunin]

Concur. It's both expedient logistically, and important from a security model, to have the ability to create entire separate orgs if necessary, which align with GSA functions.

As long as 18F does direct business with non-GSA entities, we will have a business need for a separate org.

[nvembar]

Good points all - I think that makes sense. Want to think through if we do have specific guidance for when we absolutely should use the GSA agency account. Will close when we've updated the language.

[pammiller0]

I like these points too. I will incorporate the guidance for non-gsa projects. I will make these updates now and look/research for guidance for when we should use a GSA agency account.