Solidify and document process for spec changes and ratification
Issue #101
new
Originally reported on Google Code with ID 101
In issue 54 and during the 10/19/12 telecon it was discussed that our current process
for updating and ratifying the specifications are vague, scattered and incomplete.
Appendix A contains some process verbiage left-over from 1.2 (which was originally
intended to apply only to library extensions). The wiki at http://code.google.com/p/upc-specification/wiki/UPCSpecProcedures
outlines procedures for updating the committee's working draft. There is no written
procedure for ratification of the final specification.
These process matters need to worked out and formally documented. There is debate as
to whether any process material should appear in the actual specification (eg expanding
the current fragment in Appendix A) or should follow the ISO model and appear elsewhere
in a separate document(s). I personally favor the latter, since the process is completely
irrelevant to readers of the ratified document, and may very well be subject to change
as each new committee is convened to produce a new specification.
Jim has offered to track down process examples from ISO or elsewhere to help guide
us in this respect.
Marking this as milestone 1.3 as we need to at least work out the ratification process
we'll be using for that version.
Reported by danbonachea
on 2012-10-23 23:26:42
Comments (4)
-
Account Deleted -
Account Deleted I assume that we want to follow the rules in Appendix A.3.2 - A.3.4 for extending the specification: ---8<--- A.3.2. The existence of either one (or more) publicly available "reference" implementation written in standard UPC OR at least two independent implementations (possibly specific to a given UPC implementation). A.3.3. The existence of a significant base of experimental user experience which demonstrates positive results with a substantial portion of the proposed API. A.3.4. The concurrence of the UPC consortium that its inclusion would be in the best interest of the language. ---8<--- The open question is how do we conclude concurrence in A.3.4. Typically (e.g. in ISO and other standards bodies), there is voting involved. However, we don't have a notion of formal membership in the standardization group, so voting is a tricky option for UPC. We could construct a by-organization vote from all stakeholders, but this degrades community/individual involvement and is not desired. We had discussed using a quiescence period to determine that there is no disagreement. I think that a one month period to approve the final spec is too brief, since many folks may not be able to find time to review the spec within that window. I think something like 4-6 months would allow for a more thorough review, and potentially broader community involvement/support.
Reported by
james.dinan
on 2013-01-28 19:27:40 -
Account Deleted At the 2/11/13 telecon, we resolved that a 2 month public comment period should be an acceptable timeframe to gather user feedback on the finalized spec draft, and give implementers a head-start on generating 1.3-compliant releases. Our current timeline for ratification: February 28: finalize proposed changes for pending issues (technical and non-technical) March 28: end of internal comment period, release final public draft End of May: Ratification of 1.3, 60 days after release of final public draft (barring any major community objections)
Reported by
danbonachea
on 2013-02-11 20:30:30 - Labels added: Consensus-Medium - Labels removed: Consensus-Low -
Account Deleted Reported by
danbonachea
on 2013-11-16 21:19:46 - Status changed:Done
- Log in to comment
Reported by
danbonachea
on 2013-01-17 00:54:18