[Discuss] Organization of Controls

[jcscottiii]

Originally, we had the components organized by components. Such as CloudCheckr, ELKStack, Jumpbox. With the recent sprint to finish the documentation, we organized by XXPolicy, for example ACPolicy. I wanted to start a discussion as to:

• To be consistent, should we name component per component, by policy, or another way?
• Do we need to change the schemas to better reflect the naming convention?

[gregelin]

@jcscottiii - this seems a significant change. Is this a suggestion that policies become the primary organizing hierarchy instead of components?

It seems that components are the primary items that are re-used and assembled into a system. If a system uses NGINX as a component and NGINX implements particular controls then the documenting those controls with NGINX seems to make sense.

It is definitely challenging to track whether a control is completed when the implementation is shared across multiple components.

If the thinking is policies makes better sense as the organizing hierarchy, can you provide more detail as to why?

Also, if the schema starts to change, the question of governance and coordinating such transitions among all parties interested in OpenControl arises.

[afeld]

Is this a suggestion that policies become the primary organizing hierarchy instead of components?

I believe he is suggesting that we go back to organizing by component within this repository.

if the schema starts to change, the question of governance and coordinating such transitions among all parties interested in OpenControl arises.

For the v2->v3 schema jump, we made sure that Masonry could handle different schema versions on a per-file basis. Therefore, we could update them piecemeal, rather than all at once. This might be harder to do if there's a more dramatic schema change, but works for now!

[jcscottiii]

Is this a suggestion that policies become the primary organizing hierarchy instead of components?

I believe he is suggesting that we go back to organizing by component within this repository.

@gregelin sorry for the confusion! as @afeld said i'm just wanted there to be some consistency in this repository. and then we can plan the work here to do so.

[gregelin]

Standardization sounds great!

Sent from my iPhone

On Jul 1, 2016, at 8:02 AM, James C Scott III [email protected] wrote:

Is this a suggestion that policies become the primary organizing hierarchy instead of components?

I believe he is suggesting that we go back to organizing by component within this repository.

@gregelin sorry for the confusion! as @afeld said i'm just wanted there to be some consistency in this repository. and then we can plan the work here to do so.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[geramirez]

Just my two cent. Originally, the *Policy components were created to represent the actual compliance policies not the documentation under the each control family.

Maybe all the *Policy components should be organized under a 18F_Governance_Documents component. This would make it clear that 18F's policies are a unique component in 18F's SSPs and that other organizations should develop their own.

[afeld]

Maybe all the *Policy components should be organized under a 18F_Governance_Documents component.

Agreed! See #148.