Open little-oddball opened 2 years ago
Should we revisit the decision to make the RFC repo Public vs Internal? I wonder if there is more risk than reward with that repo being public.
Should we revisit the decision to make the RFC repo Public vs Internal? I wonder if there is more risk than reward with that repo being public.
Thinking about the potential of RFCs that are more sensitive in nature... definitely makes sense to revisit that option as well.
Per our conversation on the topic:
https://github.com/department-of-veterans-affairs/va.gov-team/issues/43775
We should put together some guidance and make it a part of the VA Guidance ( https://github.com/department-of-veterans-affairs/va.gov-team/blob/master/platform/working-with-vsp/policies-work-norms/sensitive-guidance.md ). Will update. In general the thought is to keep sensitive items (pass keys, etc. out of RFC). Try to make items very black and white and be somewhat prescriptive. Would be good to have more description, etc. vs. allowing folks to interpret.
There was conversation in a Team Leader meeting where Security is putting together a RFC but it contains potentially sensitive information. The concern is we don't want to put these types of items out into the public repos so wanted to raise a quick discussion on thoughts of where.
The initial thought was to have a similar path structure for these under va.gov-team-sensitive that we do in the public space.
Acceptance Critieria