1.0 timeline

[jpmckinney]

I'm not sure that getting to 1.0 by Nov 18 leaves enough time for feedback and real-world implementations. There should be at least two full implementations of the spec by real users (not project staff) before it can be considered 1.0; an untested spec is not 1.0-ready. In general, I would propose the following process:

1. You've made available a first public working draft, on which you are seeking broad feedback, which you will integrate into the draft.
2. At some point, the feedback will no longer lead to substantive changes. At this point, announce a "last call" for feedback. This period should last three weeks to give sufficient time to reviewers. If there is any new substantive feedback, the last-call period should be extended.
3. Now that the spec is stable and appropriate for implementation, issue a call for implementations. The goal is to get two independent, interoperable implementations for each feature in the spec. Some features can be marked "at risk" if there's a risk those features won't be implemented.
4. Once implementations have been collected, any "at risk" features without implementations can be cut. No other substantive changes should be made. If any are made, you need to go back to step 1. If the implementers' experience was poor, you may also want to return to step 1.
5. If everything is good to go ahead, there should usually be a 3-4 week window for final review; at this point, the changes should be mostly cosmetic. At the end of this period, the spec is 1.0.

This process roughly follows the W3C process (which is more rigorous). The goal is to have a 1.0 that is stable. 1.0 is of no use if there's a 1.1 with substantive changes soon after release.

[jpmckinney]

Just read:

Approximately every 3 months a new versioned release will take place that incorporates learnings from field missions, public engagement, and demand-side requirements.

Every 3 months is surprising. How are implementers expected to keep up with a moving target? It can take implementers up to a year to fully adopt a standard... A standard should ideally not change. If you're expecting to make changes every 3 months, you should still be in draft.

Update: Perhaps this release schedule is just for pre-1.0 releases...

[jpmckinney]

@practicalparticipation @michaeloroberts @birdsarah Would be interested to hear your thoughts on this issue in particular.

[birdsarah]

@jpmckinney - i'm not working on the governance side of things, @practicalparticipation and @michaeloroberts might have more on this.

[birdsarah]

"Once implementations have been collected, any "at risk" features without implementations can be cut. No other substantive changes should be made. If any are made, you need to go back to step 1. If the implementers' experience was poor, you may also want to return to step 1." -

Copying my comment from #70 "This is a very supply-centric position. We have looked closely at supply-side, but are also looking at demand-side stakeholders. The standard is also part of advocay, and what open contracting data could and should be, not just what it is."

[jpmckinney]

I'll just refer to my reply in #70 so that we don't have the same conversation in two places.

[practicalparticipation]

To address the specific question Should the 1.0 (or 1.1) standard include fields for which no implementation exists", based on the elaboration in #70 I would propose:

• By 1.1 any field should be either implemented on the supply side, or required by a named purpose.
• Following the technical scoping, purposes, which describe a goal for use of the standard and a set of data requirements, should be marked as 'proposed' or 'implemented' and should be regularly reviewed to ensure they remain relevant and achievable.
• We look to label fields/elements as stable to indicate we do not anticipate any change in them (based on widespread implementation of those fields), or target to indicate that no supply-side data has yet been identified, but that those seeking to publish this kind of data in future can reasonable assume that it should be standardized in this way.
• We look to track implementation of given fields, and to provide publishers and users with an easy way of looking up the extent of implementation for given fields (this is not likely to happen in the current iteration of work, but should be an area of work for whatever future structure exists to steward the OCDS).

(A note on naming: Political considerations mean we have to call the launch version 1.0, and that many implementations will only occur after this is launched. But I would hope we can clearly communicate to users that we anticipate a 1.1 by the end of 2015 which would contain only minimal changes, focused on confirming stable fields, and, on the basis of evaluating implementation, making any minor revisions required to increase compliance and usefulness of the data)

[jpmckinney]

Regarding implementations, this sounds reasonable.

Regarding feedback, I'm still not sure Nov 18 gives enough time for steps 1-2 in issue description.

[birdsarah]

"Regarding feedback, I'm still not sure Nov 18 gives enough time for steps 1-2 in issue description." - I think we all agree with this, but we've compressed standard writing into a very short space of time.

How do you feel about the fact that really step 2 is taking place between, as @practicalparticipation lays it out, between our Nov 18 launch and the release of a 1.1 in late 2015?

[jpmckinney]

It's doable - but if the feedback suggests major revisions for 1.1, they will be harder to implement if the 1.0 implementations expected there to be only minor/minimal revisions. This puts more pressure on the draft spec and early feedback to figure out all the major issues. It may be a good idea to add a caveat that there could be major changes between 1.0 and 1.1.

[birdsarah]

"It may be a good idea to add a caveat that there could be major changes between 1.0 and 1.1." +1 - that sounds right to me.

[practicalparticipation]

Agreed. I had been kind of thinking that we might have a sense of how much big change is likely as we get towards November, but you're right that it might be better to be clear that there could be big changes, even if we're not anticipating any.

[birdsarah]

Should we think about referring to the "next" version, the one with major revisions and based on implementations, as a 2.0?

[LindseyAM]

@sdavenpo422 what do you think of james' idea?

[jpmckinney]

add a caveat that there could be major changes between 1.0 and 1.1

Not sure who does that?

[practicalparticipation]

Documentation at http://ocds.open-contracting.org/standard/r/master/en/standard/history_and_development/#development-process

Governance document still forthcoming.