identify examples of community process

[monkeypants]

Before re-inventing the wheel (wrt: #3), let's identify examples of "community process" that may be suitable for this open standard.

[monkeypants]

The "Collective Code Construction Contract" (C4, http://rfc.zeromq.org/spec:42/C4/) has proven effective for the zeromq community (and others).

Observations about C4:

• it is applied to complex software products rather than an open interoperability standard. However, section 2.6 (Evolution of Public Contracts) seems specifically relevant to community-developed interfaces and protocols.
• it seems pragmatically opinionated about workflow (sections 2.3-2.5), which supports it's collective decision making process. Would those workflows fit well with what we need to do?
• The project administration (section 2.7) seems very organic and inclusive. Is that an appropriate decision making framework for project? If it's appropriate in the short term, would it need to transition to a more formal and controlled process at any stage? if so, how would that process work?

C4 is also pragmatically opinionated about copyleft software licensing, which may or may not be appropriate for a community specification of interfaces and protocols.

The project SHALL use a share-alike license such as the MPLv2, or
a GPLv3 variant thereof (GPL, LGPL, AGPL).

Perhaps it would be possible to adapt that to a share-alike content licensing, such as Creative Commons. Note that the Commonwealth Government stakeholders have policy obligations to release content under Creative Commons licences, so compatibility with that may be essential.

[hintjens]

I'll chime in with a few comments:

• For RFC development we've used a different process (COSS) for some years, with success. See http://rfc.unprotocols.org/spec:2/COSS/. During editing, a C4-like approach to patches appears to be helpful. However there is rarely a community around RFCs, rather we aim for consensus between competing implementations.
• The share-alike requirement is mainly to streamline merging; no administration is needed. That is, a fork of a share-alike work is share-alike, and a public patch on that fork can (nearly) always be safely merged. There are exceptions such as, patch includes proprietary code illegally.
• cc-sa would work as a license. For software projects we have found MPLv2 to be the simplest that gives us what we need.

[monkeypants]

Thanks Pieter, 2/COSS looks perfect.

For us, I think it would require:

• @onthebreeze willing to become specification Author?
• a suitable domain administrator (Department of Industry?)
• a suitable IP policy (Commonwealth ?)

If those things are not possible we should keep looking. Otherwise, I propose we close this ticket.

[onthebreeze]

The process looks fine to me. I'm happy to be the specification author.
The domain administrator should probably be the digital business council secretariat.

[monkeypants]

Great.