Start formalizing governance process

[mogul]

In order to enable broad collaboration on OpenControl among parties with overlapping (but potentially misaligned) interests in a common roadmap, we should come up with a lightweight governance process and a cadence for regularly meeting to update and surface concerns related to the roadmap.

[mogul]

Here's a similar precedent involving an 18F product.

[afeld]

@gregelin @joshuamckenty This might help as a jumping off point, and to help determine how much structure we will need:

• What are your biggest concerns?
• What would you like out of a governance structure that you're not getting now?

Feel free to put it bluntly 😉

[gregelin]

@mogul Thanks for starting this thread. @afeld Thanks for asking.

The discussion on governance at https://github.com/openopps/openopps-platform/issues/1287 is very helpful and has great links. @afeld and @joshuamckenty observations in issue discussion resonate for me.

I first started to reply to @afeld above questions in the more abstract, but I think being concrete feels more appropriate.

Guiding Principles and Data Driven Decisions

OpenControl and Compliance-Masonry stuck the landing as a proof of concept of moving Compliance Documentations out of Word and into something structured. It's great.

What are the guiding principles for prioritizing evolution and development going forward? Who is setting the principles and how are they being discussed?

What data are we using to assess if OpenControls and Compliance-Masonry is providing the value we envision? What data is being used as input to what decisions?

OpenControl

OpenControl is a data specification. So what I most want to know is who are the owners of the data spec? Who is using it and Who is backing it? What does backing it mean? What's it trying to achieve? How fast does it evolve? What's the right way to extend/customize it, if at all?

If the idea is that OpenControl becomes a standard that is widely used, then it is important to have a roadmap of what goals / benefits the data spec will support and when approximately that will be supported. Versioning and approach to backward compatibility become very important so others using the spec can plan and invest effort/funds.

OpenControl exists as a data spec for a larger problem, increasing the velocity of compliance. So I also want to understand the vision and practical details of how OpenControl fits into the larger ecosystem. Is OpenControl and official project or just a proof of concept? Since 18F is government, are the 18F folks formally or informally talking NIST RMF or FedRAMP folks? (In other words, how official is OpenControl vs experimental?)

There is absolutely an emerging community interested in OpenControl, and I think that community is OK with anything along the spectrum from experimental to official provided that is clearly identified so expectations can be managed and easily referenced.

The worst case for GovReady is if we are out there evangelizing OpenControl inaccurately as THING A when in fact OpenControl is THING B.

Compliance-Masonry

Compliance-Masonry is an application using the OpenControl data spec. So I most want to know is Compliance-Masonry the "official" application or just a reference build? Is it better to have everyone contributing to Compliance-Masonry or is better if we are encouraging a few different "assemblers" as part of an ecosystem?

As a software application, what is the level of support that can be expected at this time? In the future? What is it's roadmap? Who's using it?

I was caught off guard by the switch from Python to Go, for example. There was a brief discussion. The switch was not a secret. Things were done in the open and all intentions where great. But speaking for myself (and a couple others), we were not paying attention at that moment. When we tuned back in, suddenly everything was Go instead of Python.

I bring up the Python to Go transition not to criticize that decision (it was fine), but to ask this governance-related questions: How important is it to the project that folks like me know about changes like that and weighed in on them? How much effort is reasonable to put forth relative to that stated importance. How do we measure if effort was effective?

If the project only has resources for passive rather than active communication, let's get that fact up on the websites and let people know about the slack channel and this discussion.

[gregelin]

@mogul @afeld I've also promised a client to write up a sober assessment of OpenControl and I hope to get that out today.

[pburkholder]

For reference, Chef uses an RFC process where the benevolent dictator (usually Adam Jacob) has final say on whether an RFC is accepted, but follows the consensus of the community members that participate. The downsides are 1) that Chef is also a product of a profit seeking company where product managers want to move things at a different pace (sometimes faster, sometimes slower) than what the community wants, and 2) that some RFCs are accepted with no resources to implement them and 3) there other competing public inputs such as GitHub issues, and a UserVoice feedback site.

That said it worked well enough that MSFT adopted a similar process for PowerShell. The site is remarkably quiet now that I've checked in on it again, so maybe it's not actually in use.

Refs:

• https://github.com/chef/chef-rfc
• https://github.com/PowerShell/PowerShell-RFC

[gregelin]

I'm a big fan of the RFC process. I think it has worked very well for Python, too, though Python calls them PEPs (Python Enhancement Proposals).

About the PEPs: https://www.python.org/dev/peps/pep-0001/

I also like the fact that IETF's RFC's never change. I think that is a hidden superpower of the RFC approach, the fact that once published the document is authoritative and consistent.

https://www.ietf.org/rfc.html

[mogul]

Do you regard those processes as lightweight enough to warrant their formality given the size of our little community to date? (Alternatively, maybe I underestimate just how many people/organizations are interested in OpenControl...)

[joshuamckenty]

Since we’re tentatively planning an OpenControl event in September, can I suggest a face-to-face discussion of governance?
Speaking of which, we’re planning an OpenControl event in September :) I believe Bret agreed to host it.

On Jul 14, 2016, at 6:18 PM, Bret Mogilefsky notifications@github.com wrote:

Do you regard those processes as lightweight enough to warrant their formality given the size of our little community to date? (Alternatively, maybe I underestimate just how many people/organizations are interested in OpenControl...)

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

[pburkholder]

My comments about the Chef RFC process were not so much to advocate for that process as to note the upsides/downsides to the one community governance process that I was all too familiar with (and sometimes frustrated by).

That said, adding an RFC process wouldn't have to be heavy weight. And writing an RFC prior to undertaking new feature work helps communicate what the feature provides, what problem it solves, and communicates that independently of all the implementation code that might go into the PR for Masonry.

Anyhow, whatever folks decide to do works for me, I have nothing vested in the outcome here. Cheers, Peter

[gregelin]

@mogul I think the governance process can be as light as we'd like. What's really important:

• governance is clearly defined and easy to find
• governance aligns with project charter/goals
• produces quality, reliable artifacts for community

Speaking of artifacts, I am leaning toward RFCs also.

Proposed RFCs:

• OpenControl Schema
• Assembler API (e.g. The API to which Compliance-Masonry adheres)

[gregelin]

So I just grabbed opencontrol.slack.com. I’m wondering if it makes sense to move OpenControl and Compliance Masonry discussions over there since OpenControl is its own organization on GitHub?

[anweiss]

Hey all ... would love to resume these discussions

[gregelin]

I liked the folder structure of https://github.com/PowerShell/PowerShell-RFC. It appears to leverage Git's folder structure nicely to improve the workflow underlying RFC and PEP.

I propose we go with the RFC model, using PowerShell RFC folder structure.

The could be called "RFC" or alternatively "Practices." (Disclosure, I am experimenting with PEP-inspired "Practices" as a way to organize policies for GovReady. "RFC" just did not feel right for organization policies and less technical audience, but same thing under the hood.)

[gregelin]

FWIW, PEPs do not have version numbers. It is an interesting practice that I would suspect forces better synchronization across the community.

In general, Standards track PEPs are no longer modified after they have reached the Final state. Once a PEP has been completed, the Language and Standard Library References become the formal documentation of the expected behavior. - https://www.python.org/dev/peps/pep-0001/#id39

[shawndwells]

Year old discussion. Closing for inactivity. Feel free to reopen as appropriate!