12.3 Resolution of Proposed Changes

12.3.1 Responding to Submissions

The COUNTER Executive Committee (EC) will review submissions as recommended by the Technical Advisory Group (TAG) and provide a response via the Project Director after their next regularly scheduled EC meeting. The EC will respond to every submission with one of the following, providing clarity when needed:

  • Proposed change accepted without modification

  • Proposed change accepted with modification

  • Proposed change accepted for further study

  • Proposed change rejected

If further study is needed, the EC may convene a separate working group to study the proposal and make recommendations related to the suggested comments.

12.3.2 Approval of Changes

Changes that are approved will enter the usual Explicit Versioning process. Fix and Feature changes do not require community consultation and will be added to the TAG worklist for upcoming releases.

Changes that are substantive in nature (e.g. those that would require changes in how reports are generated or consumed) will be incorporated into the worklist for future Breaking releases and form part of the community consultation process.

After the community consultation period, changes to the COUNTER Code of Practice MUST be voted upon by the COUNTER Executive Committee and approved by committee majority. EC Members can respond to a ballot by voting Yes, No or Abstain. For clarity, the number of affirmative votes MUST be greater than 50% of the total number of EC members minus abstentions (a non-vote is considered a “No” vote.)

12.3.3 Communication of Changes

COUNTER will inform the COUNTER membership about upcoming changes to the COUNTER Code of Practice through email and on the COUNTER website and through posting on listservs that discuss usage topics.

12.3.4 Version and Change Control

Each update to the COUNTER Code of practice will generate a new version number (i.e. the initial release of “R5” was designated as version 5.0.

Under Explicit Versioning, a four-digit numbering system in the structure Release.Breaking.Feature.Fix, “Breaking” releases including changes that are not backwards compatible take the first point place (e.g. R5.1.0.0), “Feature” releases with new features or extensions that are backwards compatible take the second point place (e.g. R5.1.1.0), and “Fix” releases with bug fixes, typographic corrections and similar small amendments take the third point place (R5.1.0.1). Note that in practice, trailing zeroes will be omitted from release numbering.

Explicit Versioning thus allows for us to change the Release number where changes are so comprehensive that Release 5 would no longer apply.

All changes included in each release will be included in the Change History section of the Code of Practice. The prior release will be archived as a PDF document and access to that release provided via the COUNTER website.