The Open Geospatial Consortium (OGC) is an international consortium of organizations and individuals driven to make geospatial (location) information and services FAIR - Findable, Accessible, Interoperable, and Reusable. More information is available on the OGC website.

The OGC was formed to undertake a common objective that is beyond the resources or capabilities of any single organization, that is, to provide a collaborative, consensus forum for the discussion and resolution of interoperability issues in the geospatial domain. The work of the consortium is based on volunteerism.

The OGC is defined as a Voluntary Consensus Standards Organization.

The OGC provides a collaborative, consensus process for developing and approving open, international Standards and supporting content for the geospatial domain, collectively known as OGC Products. To guide the OGC Product development and approval process, a member-approved Policies and Procedures document for the Technical Committee (TC) is required.

This document describes the TC Policies and Procedures (TC PnP). The TC has been granted authority to operate by the OGC Bylaws. The TC is composed of individuals representing organizations that are duly recognized members in good standing of the OGC.

As the needs and purpose of the TC change, changes to these policies and procedures are approved by an electronic vote of the Voting Members of the OGC TC. These policies and procedures may be augmented or clarified by Policy Directives issued and approved by the TC or the Executive Planning Committee (EPC). Such directives are databased and hyperlinked to/from the appropriate portion of this document.

The OGC Principles of Conduct govern personal and public interactions in any TC activity.

At times, the Technical or Planning Committees may identify new policies or changes to existing policies that should be made official on a more rapid basis than approval of a revision to a policy document. Such a new policy is known as a Policy Directive. Policy Directives are accessible from the OGC website Policy Directives database.

Policy Directives are sequentially ordered and more recent Directives may invalidate older Directives. Further, older Directives may now be incorporated into these Policies and Procedures.

OGC’s Intellectual Property Rights (IPR) policy helps minimize the possibility of inadvertent infringement of the IPR of Members and third parties using or implementing any OGC Standards. OGC’s IPR policies reflect the mainstream of current standard-setting best practices.

The Compliance Program operates as part of the Standards development process to provide resources for the testing of implementations against OGC Standards. The Policies and Procedures for the Compliance Program describe the roles and responsibilities, compliance testing procedures, development of test packaging, and policies for developing and releasing the software used for testing.

The preferred repository of OGC document templates is found in the templates GitHub repository. Templates in Microsoft Word format are also available on the OGC Portal. All templates are annotated to assist in document preparation.

OGC maintains a style guide in the templates repository. This guide is not a formal policy document, rather it is intended to assist authors and editors in developing content for OGC documents in a consistent manner. The style guide is periodically updated and expanded.

The TC provides an open forum for professional discussion of issues and items related to the consensus development and/or evaluation and approval of candidate Standards and revisions to existing adopted OGC Standards that provide the ability to build and deploy interoperable geospatial solutions in the larger IT domain.

More specifically, the OGC Bylaws authorize the TC to perform the following functions:

The TC has the following composition:

There is no limit to the number of TC representatives for any OGC Member organization.

The TC Members are organized into a number of roles. Members might have multiple roles. The following roles are formally part of the TC hierarchy.

The TC is the primary group where OGC Standards and many Products are developed, discussed, approved, and maintained. The TC members are responsible for the development and maintenance of all Standards and related technical documents and supporting deliverables. The TC membership includes Voting TC Members, non-voting TC Members, and Invited Guests, per the OGC Bylaws.

The TC contains a number of Subgroups.

TC activities rely upon collaboration with other groups, inside and outside the OGC.

Appeals by any member to a decision made at the subgroup level can be brought to the TC Chair for consideration. Further appeal can then be made before the OAB. Each appeal or issue will be taken on a case-by-case basis, but rulings made by the OAB with approval of the Executive Planning Committee that affect the process will be reflected in these Policies and Procedures. If the member making the appeal is not satisfied by the decision made at the OAB level, the OGC Board of Directors may be presented with the case for final deliberation.

TC members have access to personal information about other members. This information is stored in the OGC Portal and all participants in the OGC agree to having this information available to other OGC members. However, in the course of conducting TC business, a TC member shall not share contact information or a record of that member’s activities in the OGC without the permission of that member.

Public meeting minutes shall not contain attribution of a specific TC member. For instance, the results of a subgroup vote can be circulated to the public, but the names of the member making and seconding the motion shall not be disclosed.

The TC agrees to abide by the privacy regulations in the jurisdiction in which a TC activity occurs.

A subgroup is composed solely of representatives of current OGC members and (potentially) invited guests. The following rules apply to membership in subgroups of the TC.

There are two types of Working Groups in the TC: Domain Working Groups (DWGs) and Standards Working Groups (SWGs).

A subcommittee (SC) is a standing group of individuals composed of members of the TC and invited guests, with a mission to provide recommendations to the TC in some general area. A Subcommittee does not generate a Standard nor does it work on a Standard.

SCs are long-standing entities with general portfolios or missions. OGC staff can chair SCs. Any OGC member can attend a SC meeting and participate.

A SC may be proposed by any TC member and approved via charter.

There are two additional subcommittees with specialized purposes: the OGC Naming Authority and the Document Team.

A Regional Forum is a subgroup dedicated to advancing OGC topics in a particular region of the world. The Forum can cover international, national, or sub-national interests and one particular region may be part of multiple Regional Forums.

A Regional Forum may be proposed by any TC member and approved via charter.

At any time, a group of Members may determine that a new area of technology or domain exploration is required. This interest may lead to the formation of a new OGC subgroup.

All OGC subgroups must have a charter approved by the TC. The charter starts with the mission and scope of the subgroup as initially envisioned, but may be updated as the subgroup work continues.

Subgroups include special roles for administration of the subgroup as well as development of subgroup documents and products.

The first order of business of a new subgroup is to elect one or more chairs. Chairs may also be elected over the course of the subgroup’s active operation. The chairs must be from different member organizations. Chairs are nominated and elected as follows:

The election of the chair does not require TC approval. Once the election is complete, the new TC Chair shall notify the subgroup of the results of the election.

Chairs are elected to serve for a period of two years. At least one month before the expiration of the chair term, the subgroup must call for chairs via the TC email reflector and, optionally, in a subgroup meeting. Existing chairs may run for re-election. The subgroup then holds a vote to elect or confirm re-election of the chair(s) in a quorum-valid meeting or electronically.

Voting in subgroups (excluding SWGs, see SWG voting) is by simple majority of OGC Members present at the subgroup meeting, not just Voting TC Members, with the caveat that no OGC Member organization may cast more than one vote in a subgroup vote.

Subgroups should be able to use all of the expertise at hand in arriving at recommendations. All TC member organizations can be represented and vote at subgroup meetings in order to allow the expression of all members' opinions.

Subgroups work in the TC Operational environment. Portal resources, email reflectors, and collaboration environments will be established for each subgroup as per the TC.

Subgroups may wish to develop their own smaller working entities (subgroups of the subgroup). Typically, these have been of shorter duration to deal with specific issues in DWGs or edit parts of a candidate Standard in SWGs. A subgroup may organize such entities at-will and request work environments for those entities. TC approval is not required for internal organization of a subgroup.

The TC Chair will provide a list to the TC at least once a year of those subgroups that have not met in the previous 18 months. The TC will then vote to determine if these groups should be continued, disbanded, or possibly combined with more active groups.

A SWG may be formed whenever:

The formation and execution of the work of a SWG is closely tied to the OGC Intellectual Property Policies. Members are strongly encouraged to read this Policy prior to forming or joining a SWG.

The policies and procedures defined below are in addition to the requirements to form and operate a subgroup.

Technical Committee meetings shall be conducted under the general guidance of Robert’s Rules of Order. Meetings shall be facilitated by the TC Chair or other appointed representative(s) of the OGC. The TC currently holds three meetings per year. The number of meetings per year can be changed by a vote of the TC and the EPC or by direction of the Board of Directors.

TC meeting dates and locations will be announced as far in advance as possible but no less than three months in advance of the meeting. Announcements will be through formal OGC Communication. All recommendations, summary notes, presentations, and other meeting materials and records shall be posted to the OGC Member Portal.

Members of the OGC, Invited Guests, and non-OGC members are welcome to register for and attend TC meetings. TC Meetings may also include sessions that are open to the general public. Any TC member may send another representative of their organization as a substitute to a TC meeting and may assign Proxy for Voting.

OGC staff or an OGC member may wish to invite one or more individuals from organizations who are not OGC members to attend an OGC TC meeting. Reasons for invitations may be to provide technical input, speak, or meet with OGC members and/or staff on items and issues germane to the work of the OGC.

Invited Guests (representatives of organizations that are not members of the TC) may actively participate in an OGC meeting at the sole discretion of the TC Chair. That is, in the interests of ensuring the efficient operation of any meeting, the TC Chair may limit or eliminate the opportunity of any invited guest to participate in discussion at any meeting.

All Invited Guest invitations and registration must be coordinated with the TC Chair and the OGC staff responsible for meeting logistics.

The Invited Guest may or may not have to pay a meeting registration fee. OGC staff will work with the members to determine the fee structure for Invited Guests for any given TC meeting.

OGC meetings may be open to attendance of non-OGC members. Such attendance is at the discretion of OGC staff, the TC, and/or the EPC. Non-members can only attend DWGs, open sessions, or public sessions. Non-members who wish to attend a SWG must abide by the Policy for Invited Guests. OGC staff will work with the members to determine the fee structure for non-members for any given TC meeting.

At least eight weeks before a TC meeting, a draft master schedule for that TC meeting will be posted to the public OGC web site. The agenda is managed by the TC Chair and OGC staff and will be modified prior to the meeting as appropriate. The TC Chair will maintain a master agenda that is available to members and which is generated from the agendas of each subgroup as they are populated.

The subgroup chairs shall work with the TC Chair to schedule sessions and set agendas. Subgroups cannot have alternative meetings that overlap temporally with the TC Meeting without approval of the TC Chair.

Each subgroup chair shall post an agenda to the meeting web site at least three weeks before the meeting. Subgroup chairs that fail to provide a proposed agenda by three weeks before the meeting may forfeit the right to meet during the course of regularly scheduled TC meeting times. Any subgroup can elect to have an ad-hoc meeting during the off-hours of a meeting (such as a breakfast or after-dinner session), but may not hold votes during those ad-hoc meetings.

Most TC and subgroup meetings include a virtual meeting option via online conference tools. These sessions are generally recorded for later use by OGC staff and OGC members. Guidance for such recording is as follows.

Subgroups may meet with any frequency that they feel is necessary to accomplish their work. These meetings may be virtual (online), teleconference, or in person. Meetings with anticipated votes must be announced at least two weeks in advance or scheduled to occur on a regular basis. All meetings must be reserved in the OGC Portal calendar.

The TC or subgroups of the TC may organize other meetings on topics of interest to OGC’s mission, but which do not fulfill the purpose of regular TC or subgroup meetings. These meetings are organized on behalf of the TC or subgroup, may involve members and guests, and may have registration a fee terms on a basis that is best for the meeting.

All thresholds for quorum, sufficiency, and voting are calculated to meet or exceed the fraction or number indicated. For example, a quorum of 1/3 of members means that exactly 1/3 or more members are required to meet quorum. 33.2% does not meet quorum, 33.3333 does.

For votes that require documentation, such as adoption of particular documents as Standards or documents to be released for public comment, documentation supporting the vote must be available to all members in the Pending Documents list on the Portal three weeks prior to the vote. The three-week rule clause ensures that Voting TC members have adequate time to read, distribute and gather comments on documents before voting on the document at the following TC meeting.

The TC may override the 3-week rule by a 2/3-majority vote of Voting TC members in attendance at a meeting.

Quorum for meetings and electronic votes are specified for the TC and subgroups, below.

Quorum is always assumed for email votes as all eligible voters are subscribed to their respective group reflectors.

"Sufficiency" is the minimum number of votes cast to have a valid vote result. In most cases, sufficiency is equal to quorum, but for electronic votes, quorum is assumed and a sufficient number of voters need to participate.

The criteria for approval of votes is generally Unanimous consent or a majority in favor, however an exception exists for the TC on a Required TC electronic vote.

Any eligible voter in the TC or a subgroup can assign their proxy to another full-time employee of their organization, to another individual from another TC Member voting organization, or to the TC Chair or subgroup chair.

Proxies can be assigned electronically or in written form. A written proxy form is provided for each TC meeting and is posted to the TC meeting folder for which the proxy will be valid.

Proxy shall be communicated to the TC Chair in advance of the TC Closing Plenary. The TC Chair shall send reminders to the voting members prior to the meetings. Assignment of proxy to another full-time employee of the Voting member’s organization may be communicated verbally to the TC Chair in advance of or at the TC Closing Plenary.

Proxies are not transitive: that is, if Member A holds a proxy for Member B and Member B holds a proxy for Member C, Member A can only vote on behalf of Member B and CANNOT further vote on behalf of Member C by “proxy to a proxy.”

All subgroup document votes, except for Best Practices and Standards adoption votes, shall have the following language.

Standards and Best/Community Practice adoption votes shall have the following language.

OGC offers progressively more direct voting methods for actions of the TC or subgroups. Regardless of the method, only one vote is allowed per member organization.

OGC Standards documents are often broken into parts along modular lines. Adoption votes for such multi-part documents must either be sequential and not overlapping in terms of start and stop dates or in parallel with the same start and stop dates for the vote.

If the votes are in parallel and if a part fails, then any part containing a module dependent upon a module in the failed part also fails. If the vote is sequential, any part containing a module dependent upon a module in a previously failed part cannot be voted until the failed part is re-voted and approved or the dependency is removed.

A motion may only be withdrawn by the subgroup that made the original motion or by the TC Chair for procedural reasons. The subgroup shall have a formal documented vote to withdraw a motion. The reasons for withdrawing a motion are not constrained. The subgroup shall communicate to the TC Chair the request to withdraw a motion. The TC Chair shall then communicate the decision to withdraw a motion to the entire membership.

The following procedures shall be followed for those cases in which a revote is required.

The following rules relate to transparency of the voting process.

If the vote did not pass, then the appropriate OGC subgroup needs to address all comments, revise the document and restart the approval process (for a Standard: OAB review, public comment, and a new adoption vote).

If the vote failed by not meeting Sufficiency criteria, a new request to start an electronic vote can be made to the TC and the vote can repeat, but only once. A subsequent lack of sufficiency is treated as the vote not passing.

The numbered document (see Document numbers) as distributed to members is to be considered the official document of the TC. All documents must use the templates found in the templates GitHub repository or equivalent Microsoft Word templates found on the Portal; the latter are discouraged. Document development will result in periodic milestone releases which may be shared on the OGC Portal or in the applicable Collaboration environments. Official release of documents for OGC member or public review must be made available on the Portal. OGC Communication shall be used for announcing the availability of new official documents. Other electronic forms of documents can be made available at the written request of members.

OGC documents are authored and edited in AsciiDoc or Microsoft Word format. Publication of approved documents must be in HTML, but also includes PDF and Word formatted versions. The format for dissemination may change as distribution technology changes. Prior to mid-2014, all approved documents were only available in PDF and sometimes Microsoft Word format.

The TC Chair reserves the right to reject a document that is in a non-industry standard distribution format.

An OGC Standards document is the principal document type that captures the work and the consensus of the OGC membership. Standards documents must use the OGC Standards document template during development (with the exception of Community Standards). Standards may be published in multiple official views, as follows.

OGC uses a multi-track Standards policy with three possible states: OGC Community Standard, OGC Draft Standard, and OGC Standard. These are described in The Two Track Standards process: characteristics.

Standards are further categorized as follows (see Annex A: Terms and Definitions for details): * Abstract Specification * Conceptual Model * Encoding * Implementation

Approval of an OGC Standard is described in Policies for the OGC Consensus Standards Process.

Each Standard distributed by the OGC shall include a cover page with the statement as specified in Policy Directive 4.

Standards documents have version numbers that shall start at 1.0 (see Versioning).

Standards may be accompanied by supporting normative content such as schemas and/or registries. This content is approved as part of the Standard and is managed in concert with the Standard lifecycle.

Informative products may also be developed along with the Standard, such as compliance tests, user guides, sample code, registered code lists, etc. This informative material may be created by a subgroup, members, or OGC staff and is managed by its originating party without formal obligation for maintenance.

Registries are managed by the OGC-NA per the OGC-NA Policies and Procedures. Some registered content is normative content for a Standard, some supporting one or more Standards, and some enables geospatial interoperability for specific domains. Informative registry content is developed, approved, and maintained by the owning subgroup without further need for TC approval.

OGC Members, TC subgroups, or COSI Initiatives may generate Best Practice (BP) and Community Practice (CP) documents for the community covering best practices related to the use of an OGC Standard or other technology relevant to one or more OGC Standards. These documents describe a technique or methodology that, through experience, implementation, and research, has proven to reliably lead to a desired result. In some cases, BPs or CPs may transition to full Standards through the OGC Consensus Standards process.

BP and CP documents have version numbers that shall start at 1.0 (see Versioning). BP and CP documents may also have corrigenda per the process defined in Corrigendum (errata) Changes to OGC Standards and Best and Community Practices.

Best Practice: a document describing the use of one or more OGC Standards, typically to address a domain-specific topic or provide a solution to an interoperability challenge. Best Practices may also describe implemented extensions to or profiles of OGC Standards.

Community Practice: a document describing implemented Standards, specifications, or technologies that originate outside of OGC, but which are relevant to address interoperability requirements in the geospatial and related communities.

Any OGC COSI Initiative will have Engineering Reports (ER) as a deliverable. These ERs are posted to pending documents and presented and discussed in a WG meeting. The WG may recommend to the TC that the ER be publicly released. If approved by the TC, these documents shall be released as “Public Engineering Reports.”

While these ERs shall be distributed by the OGC, and might in fact lead to adopted Standards later, they do not represent the official position of the OGC TC or the OGC.

Motions to approve release of a document as an Engineering Report may originate from a WG with TC approval, from a motion at a TC Plenary, or from a motion by the TC Chair.

Each Public Engineering Report distributed by the OGC shall include a cover page with the statement as specified in Policy Directive 6.

Engineering Reports do not have a version number.

A subgroup can generate Discussion Papers for the community covering a specific technology area germane to the subgroup’s interest area.

While these Discussion Papers shall be distributed by the OGC, and might in fact lead to adopted Standards later, they do not represent an official position of the OGC TC or the OGC itself.

Motions to approve release of a document as a Discussion Paper may originate from a subgroup with TC approval, from a motion at a TC Plenary, or from a motion by the TC Chair.

Each Discussion Paper distributed by the OGC shall include a cover page with the statement as specified in Policy Directive 5.

Discussion Papers do not have a version number.

Technical Papers are OGC member-approved publications released to the public that present a position on one or more technical considerations or other subjects that are germane to the work of the OGC. Technical Papers often include a high-level explanation of a Standards-based architecture or framework of a solution. Technical Papers may explain the results or conclusions of research or workshops.

Technical Papers do not represent an official position of the OGC TC or the OGC itself.

Motions to approve release of a document as a Technical Paper may originate from a subgroup with TC approval, from a motion at a TC Plenary, or from a motion by the TC Chair.

Each Technical Paper distributed by the OGC shall include a cover page with the statement as specified in Policy Directive 5 where the word "Discussion" is replaced with the word "Technical" in the statement.

Technical Papers do not have a version number.

A policy is a principle, rule, or process that guides decisions to achieve rational outcome(s). The work of the OGC is guided by a number of member-approved policies and processes. These policies and processes are documented in various OGC Policies and Procedures documents. These shall be known as “Policy” documents. This TC PnP is a policy document. Policy documents are either maintained by the members or by OGC staff. In all cases, new policy documents or revisions to existing policy documents applicable to the TC or its subgroups shall be reviewed and approved by both the Technical and Planning Committees. Approval of a policy document shall follow the rules as defined for a Required TC electronic vote. If the TC approves the Policy document, then a simple majority of the EPC Voting Members must approve the TC recommendation.

Policy documents have version numbers that shall start at 1.0 (see Versioning).

A Guidance document is developed by a subgroup, the TC, or OGC staff to provide informative guidance on the development of OGC documents and products. This guidance is intended to provide consistency in approach and common properties for OGC deliverables. Guidance documents are not official policy, but the guidance may be required for use by SWGs per one or more Policy Directives.

All member-submitted documents shall be assigned a document number. Members can obtain document numbers using the Portal, Pending Documents page.

Instructions are available for obtaining a Pending Document number and posting the document.

All adoption votes to approve a document as an OGC Standard shall be electronic. Only Voting TC members may vote on an adoption vote. However, any OGC member, regardless of membership level, can 1) be part of a team submitting a candidate document and 2) join a SWG and work on a candidate Standard.

There are two possible tracks for proposing and approving candidate Standards or proposing and approving revisions to an existing adopted Standard: The OGC Community Standard and the OGC Full Standard tracks. These two tracks are described below. Regardless of the submission track, the OGC Consensus Standards Process shall be used. There are key differences in the OGC Consensus Standards process depending on whether the Community or the Full Standards track is being used. The following table summarizes the key aspects and steps in the OGC Consensus Standards process for the two tracks.

Community Standard: This is a document, developed by communities external to the OGC, that OGC members wish to bring into the OGC process. The key consideration for a Community Standard submission is that there is very strong evidence of implementation. At the same time, the community owning the Standard may not want to allow normative changes (except for errors) to the document, may not wish to follow the OGC Modular Specification Policy, nor do they wish to develop CITE tests. Annex C: Community Standard adoption checklist summarizes the steps in the Community Standard submission, review, and approval process.

The Full Standards track consists of two possible target levels of a Standard.

Draft Standard: This is a document developed by the OGC membership for which there is no evidence of implementation or CITE tests. However, the members wish to approve the document as an official OGC document in order to have developers and organizations implement the Draft Standard and provide feedback. A Draft Standard is uplifted to a Standard once evidence for implementation is provided. Annex B: OGC Consensus Standards adoption checklist summarizes the steps in the Draft Standard submission, review, and approval process.

Standard: This is a mature OGC Standard for which there is evidence of implementation This is the final stage in the Full Standards track.

The OGC Consensus Standards Process (Policies for the OGC Consensus Standards Process) is the only way for a candidate Standard to move through the review and approval process. This is the approach for proposing a new candidate Standard, submitting an externally developed community specification into the OGC process, extensions to an existing Standard, profiles of an existing Standard, or an application schema for consideration by the membership. For the Full Standards track, a SWG manages the OGC Consensus Standards process.

The following sections details the requirements, policies, and procedures for adoption of a candidate Standard using the OGC Consensus Standards process. Each section specifies whether that step or requirement in the process is for All submissions, Community Standard only, or Full Standard track only.

The OGC Abstract Specification development, revision, and approval process is the same as for any OGC Standard except for documents that originated in Authoritative Standards Development Organizations or are joint Standards activities between OGC and an Authoritative SDO.

OGC membership may choose to submit an approved OGC Standard to another SDO for adoption of the Standard by that SDO. A number of OGC Standards have been submitted to ISO / TC 211 and are now also approved as ISO Standards. Such a submission will follow the steps below.

At any time, any OGC member or non-member can submit a CRP. A CRP allows for the formal documentation of a proposed change to an existing, adopted OGC Standard or Abstract Specification Topic. The change could be an identified error (see Corrigendum (errata) Changes to OGC Standards and Best and Community Practices), an inconsistency, a requested enhancement, or a major proposed enhancement.

CRPs are used as the basis for new SWG work items. The SWG must consider proposed changes and enhancements.

In addition to the formation of a SWG, there is a requirement for an editor or editors who will maintain the content of the candidate Standard based on member input and the decisions of the SWG. One or more members can fill the editor position. The editor has the responsibility for managing the text and related resources of the Standard document. The editor is not necessarily the author nor the owner of the document. By way of guidance, the editor is responsible for:

Many OGC Standards have an associated compliance test suite of software that enables qualification or certification of software that accurately implements the Standard. These tests are managed under the Compliance Program Policies and Procedures.

Each Compliance Test is approved via the Voting forum and process.

OGC Standards (and Best and Community Practices) are versioned according to Policy Directive 18, which follows the Semantic Versioning Specification (SemVer). The guidelines for version/revision numbers for documents are as follows.

Building blocks may undergo their own lifecycle of development. A change to a building block results in a revision (and thus new version) of its owning Standard. Each building block is individually versioned, but cannot be versioned higher than the owning Standard.

All OGC Standards will undergo periodic review to ensure that the Standards are meeting community needs. Periodic review will occur at a maximum interval of every four years. However, the TC or a subgroup can request an earlier review based on observations of poor adoption, lack of market relevance, or significant errors in the Standard. The TC Chair will put requests for earlier review to a TC vote (all members) via the Voting forum and process.

The process for periodic review is as follows.

A SWG manages the revision of a Standard based on either a) comments received as part of the OGC Consensus Standards process or b) the contents of one or more official OGC Change Request Proposal(s) (CRPs), which can include Issues logged in the SWG collaboration environment such as GitHub or GitLab or Change Requests logged in the OGC central Standards Tracker.

All voting in a SWG for revisions to an existing Standard will follow the rules as defined for SWG voting.

Revision of a Community Standard is treated similar to a new Community Standard submission and all processes for approval of a Community Standard from approval of a Work Item to vote for final approval are required. The only difference in the process is the TC vote to recommend the Work Item for revision to a Community Standard for EPC approval can occur at a Plenary or via a two-week e-mail vote, i.e., the vote is not a 45 day electronic vote. The revision process is effectively identical to the addition of a Task to a SWG Charter for a Full OGC Standard.

Errors may be discovered in a published and approved OGC Standard, Best Practice, or Community Practice. Under the corrigendum process, an error (or errors) in a published document discovered after adoption and publication is shown with its correction(s) in a document that is clearly identified as a corrigendum.

This process to create and approve a corrigendum is as follows.

In all cases of adopted Standards in a revision process, the members will work to insure the highest level of achievable backwards compatibility to the previous release. In those cases in which backwards compatibility cannot be achieved, the Standard will have a major revision and the SWG will provide Release Notes that document all enhancements, changes, and compatibility issues resulting from the revision of the Standard. Both the TC and the EPC reserve the right to review the issues related to backwards compatibility for a given revision of a Standard. If the backwards compatibility issues are deemed too onerous, the TC and/or the EPC may elect to reject the proposed revision.

Other OGC documents and products also have a managed lifecycle. The process for each type is generally as described for Standards, with the following specific policies.

The Technical Committee may temporarily override specific procedures set forth in this document by a motion to override the normal TC Policies and Procedures. Approval of such an override motion shall require a two-thirds majority vote of non-abstaining Voting TC Members, present at a quorate TC meeting or by electronic TC vote.

The TC may choose to generate a Policy Directive to create a specific rule for use in the TC business. The Policy Directive is approved per the rules for Voting forum and process in a meeting. TC-generated Policy Directives are not approved via email or electronic votes in the TC. The EPC may also recommend a Policy Directive for TC and such a directive can be approved by email vote of the TC.

The following is a list of questions that the submission team needs to answer in the affirmative prior to submitting community specification into the OGC.