Technical
Site
Home / Technical Work / Governance / Operations & Policy Manual
Site Map

Related Links

Versions

Download

TSC Operations and Policy Manual

Approved by the FHISO Board and published on 28 August 2014; updated by approval of the FHISO Board on 21 November 2015.

Authors/Contributors:

This manual accompanies the Technical Standing Committee (TSC) Charter, as specified in the Bylaws of the Family History Information Standards Organisation, Inc. This manual is principally concerned with the procedures and practises of the various Project Teams and Exploratory Groups of the Family History Information Standards Organisation.

1. The Standard Development Process

A new or updated standard shall go through the following steps in sequence. The process may be abandoned at any step, and may result in deliverables other than the core deliverables identified in this section.

1.1. Idea Generation

An idea for a new standard or new area needing standardisation may be generated from any source. The FHISO Call for Papers and the mailing list tsc-public@fhiso.org are provided by the TSC as ways to facilitate idea generation; however, neither need to be used for an idea to appear.

In most cases, the deliverable produced at the end of the idea generation phase is an Exploratory Group Proposal. This proposal is used by the TSC to create an Exploratory Group, as outlined in section 3.1.

The TSC has the ability turn an idea directly into a Project Proposal if they deem that there is not enough unresolved exploratory work for the formation of an Exploratory Group to be justified.

1.2. Exploratory Work

Some exploration of an idea is required before a project team can be formed. Exploration defines the scope of the possible standard and verifies that there are sufficient interest and resources to justify full standards development by a project team. Effort should be made to identify possible obstacles to open standard development (such as intellectual property concerns) during the exploratory phase.

Most often, exploratory work is performed by an Exploratory Group. However, the TSC may state that the exploratory work has been performed by some individual or individuals who were not part of an exploratory group, perhaps as a byproduct of idea generation phase.

The exploratory stage will normally include a review of prior art in the field. This may include the behaviour of applications in common use, the content of previous standards and data models (in particular GEDCOM), and previous research done by third parties. Where applicable, the exploratory stage shall identify any requirements for backwards and forwards compatibility, and produce a recommendation on the scope of future FHISO work in the field.

The deliverable produced at the end of the exploratory work is a Project Proposal. This proposal is used by the TSC to create a Project Team, as outlined in section 4.1.

1.3. Project Development

A proposed standard is developed by a Project Team. No standard may be proposed without going through a project team devoted to that standard.

The deliverable produced at the end of the project development is a proposed standard suitable for vote by the general FHISO membership. It is expected, though not required, that the standard be accompanied by an executive summary accessible to members of FHISO whose primary interest lies in areas of FHISO’s work that is unrelated to the standard being proposed.

1.4. TSC and Board Approval

Before a proposed standard is voted on by the general FHISO membership, it must be declared ready for vote by the TSC. In particular, the TSC shall vote on each of the items below:

  1. The proposed standard is clear and unambiguous.

  2. The process used to generate the standard followed the principles outlined in section 6 of this document.

  3. Reasonable steps have been taken to ensure the proposed standard is free from legal issues such as patents and other intellectual property concerns.

  4. The proposed standard does not unfairly advantage or disadvantage any particular group or company.

  5. The proposed standard contains any necessary summaries, examples, or other supporting material.

  6. The proposed standard does not materially exceed its scope as defined in the project’s directives.

  7. The proposed standard achieves all of its objectives as defined in the project’s directives.

  8. Reasonable steps have been taken to discover and correct problems in the proposed standard, and any remaining known issues are sufficiently minor that they can be fixed in subsequent errata.

A separate vote shall be taken by the TSC on each item above. If and only if the TSC approves all of the items above, they shall then vote on one more item:

  1. The proposed standard is recommended to the Board and general membership for their consideration.

If all of the above items are approved by the TSC, the proposed standard is then referred to the FHISO board for their consideration. The board shall have two weeks (14 days) in which to review the proposed standard and raise any objections. If no objections are raised then the proposed standard shall be deemed a recommended standard and proceed to the next phase of standard approval.

1.5. General Vote

Each recommended standard shall be made available to the general public. The TSC should work with the Membership Standing Committee to announce its recommended status to the FHISO membership and the general public.

A recommended standard does not become a standard until approved by a vote of the general FHISO membership. These votes are administered by the Executive Committee in accordance with the Bylaws and the Vote Administration Policy. The vote should be scheduled no less than 60 days after its recommended status was announced to the FHISO membership and no more than 365 days after it became a recommended standard.

If the recommended standard passes by a simple majority of the votes cast, it shall become a full standard and proceed to the next phase of standard approval. If it does not pass by a simple majority it shall be identified as a “rejected standard proposal” and published along with the results of the vote.

1.6. Publication

If a standard is approved, is is published on the fhiso.org website and made available without fee or royalty by FHISO. Every published standard created by FHISO will be available from FHISO as long as FHISO shall last.

1.7. Appendices, Errata, and Clarified Drafts

A standard, once published, is immutable. No edits of any kind may be performed.

The TSC may approve and publish three kinds of updates to a published standard without requiring a vote of the full FHISO membership:

  1. Appendices may be added that expand on portions of the standard. An appendix that is added after a standard is approved may not change the meaning of the standard in any way, but may simplify the process of understanding the standard or of creating an artifact that complies with the standard.

  2. Errata may be issued that describe changes to the standard. These changes should be limited to correcting spelling or grammar, adding cross-references or citations, or minor re-wording to add clarity. Errata may not change the meaning of the standard; for example, if an ambiguity is identified within the standard an erratum may identify and make more explicit that ambiguity but it may not remove it.

    Errata should not impact section, list, or paragraph numbering.

  3. A “clarified draft” version of a standard may be issued that applies the errata. Such a version shall clearly identify itself as a draft that has not received full FHISO approval as a standard; it shall also contain prominent links to the original standard and to the set of errata that it has applied.

1.8. Follow Up Work

FHISO may establish additional activities that take place after a standard has been published. These might include efforts to promote and certify standards compliance or to solicit and collect suggestions for changes to be made in future versions of the standard. Specifics of post-publication activities are beyond the scope of this document.

Standards may be revised from time to time. For the purpose of this document, a revised version of a standard is a separate standard, and will be developed following the process outlined in this section.

2. Policies for all Technical Groups

Exploratory Groups (EG) and Project Teams (PT) are collectively referred to as Technical Groups (TG). General policies for all TGs are given in section 4 of the TSC Charter. In particular,

The TSC may appoint a Coordinator for each TG who shall chair TG meetings. The working language in all TG meetings and documents will be English.

Appeal should rarely be needed by a TG. If frequent appeals are made within a particular TG, the TSC should strive to identify and rectify the source of the issue, possibly dissolving or restructuring the TG.

FHISO members may request to become members of a TG by contacting the TSC, or the TSC may after consultation with the TG Coordinator invite a FHISO member to become a member of a TG.

New members of a TG and members that are returning after a period of inactivity are considered Transitional Members and their votes are not considered in determining majority or consensus. Details regarding Transitional Member status may be found in section 4 of the the TSC Charter.

If a member of a TG has a vested interest in a particular outcome or a potential conflict of interest with the TG’s work, the member is required to make that known to the TG Coordinator (or to the TSC if the member in question is the TG Coordinator). The TG Coordinator may inform other TG members as deemed appropriate by the TG Coordinator. A member with a declared interest is not barred from participating in consensus building or from voting on any matter under consideration.

In the absence of an appointed Coordinator, the TSC shall collectively assume the Coordinator’s role.

3. Policies for Exploratory Groups

Exploratory Groups (EG) are a type of Technical Group and are governed by all policies that apply to other Technical Groups, as outlined in section 2 of this document.

3.1. Exploratory Group Formation

Any FHISO member (the Proposer) can, after consultation with the TSC coordinator, propose the establishment of an EG by submitting a proposal to the TSC. The TSC can also propose an EG directly.

EG proposals should detail the parameters in which the proposed EG is to operate. Detailed technical proposals should be put in CFPS papers accompanying the EG proposal, rather than the in the EG proposal itself.

EG proposals shall be reviewed by the TSC or a subcommittee assigned by the TSC. If the proposal has significant problems it should be returned to the proposer with comments regarding how they might be addressed.

Reviewed proposals shall be published and announced publicly by the TSC. The announcement shall include a way for members to notify their intent to participate in the EG to the Proposer.

If significant problems or improvements are identified after announcing an EG proposal, the TSC may suspend the proposal and return it to the proposer with comments.

An EG proposal may be approved by the TSC and the EG formed once all of the following conditions are met:

  1. At least three members have committed to participate in the EG.

  2. At least 11 days have elapsed since the EG proposal was published and announced.

  3. At least one person (generally the Proposer) has expressed willingness to serve as the EG Coordinator.

If the proposal fails to get the required support, the Proposer may withdraw the proposal. Six months after a proposal is filed, or any time thereafter, the TSC may classify any proposal that lacks sufficient support as rejected; however, there is no requirement to do this.

The current procedure for performing each of these steps is outlined on http://fhiso.org/tsc, or on a page linked from that web portal, and may be updated from time to time as the TSC deems appropriate.

3.2. Exploratory Group Operation

When the TSC approves a new EG it also provides the EG with a set of Directives based on the proposal. EGs may propose changes to their Directives to the TSC.

The EG has a Coordinator appointed by the TSC. The Coordinator may appoint a recorder, editor, and/or other offices within the EG as needed. The Coordinator is responsible for providing regular updates on the work of the EG to the TSC, which shall normally be made public.

Participation in an EG is open to all and the TSC will not normally deny requests by FHISO member to join an EG. Because exploratory groups are not producing documents or recommendations intended for approval as FHISO standards, participation in EGs is less restricted than it is for project teams or among FHISO officers. An individual who is an Associate per by-law 5.2 may participate in an EG as an associate member. EG associate members do not have their votes counted in determining consensus and may not serve in a leadership role within the EG, but they may be given as large a role in furthering the EG’s work as any other group member.

The work of an EG should ordinarily be carried out in public, and it should seek to engage with the wider community. The TSC will provide each EG with a public mailing list to facilitate this.

3.3. Exploratory Group Deliverables

The result of the work in an EG is one or more of the following deliverables:

The TSC may return any deliverables to the EG for further work with comments on the particular issues that need addressing.

Where an EG has been unable to produce the expected deliverables, it should at least produce a Technical Group Note summarising why it was unable to do so. Technical Group Notes shall be approved by the TSC and then published and announced to members. Technical Group Notes are not Standards and do not bind the future actions of the TSC.

Once EG has produced all its deliverables, its Coordinator should request that the TSC dissolve the EG. When notice is given that an EG is to be dissolved, whether at the request of its Coordinator or otherwise, its Coordinator shall produce a final report summarising the work of the EG, including a review of how EG policies and procedures could be improved. The report is approved by the TSC, after which the EG is dissolved.

4. General policies for Project Teams

Project Teams (PT) are a type of Technical Group and are governed by all policies that apply to other Technical Groups, as outlined in section 2 of this document.

4.1. Project Team Formation

A PT is established after approval of a Project Proposal developed by an EG, or a proposal developed by the TSC without a preceding EG.

The proposal shall normally include a recommendation on the broad substance of the standard to be produced. It will also normally include recommendations on major decisions, particularly those likely to impact the work of other PTs.

The proposal shall be reviewed by the TSC. If the proposal has problems preventing its approval it should be returned to the EG with comments regarding how those problems might be addressed. The TSC may merge several project proposals into a single proposal or split a proposal into several separate ones.

Members may comment on the proposal and may notify their intent to participate in the PT to the TSC or an appointed member of the EG, unless the TSC has decided to limit participation and to appoint all members of the PT.

A simple majority vote of the TSC voting members is required to approve the creation of projects working on standards. If the TSC rejects a project proposal, it has to provide the reason for this, in writing, to be published together with the voting result.

4.2. Project Team Operation

The directives for the PT are developed and approved by the TSC when the proposal to establish a PT is approved. The initial set of directives are based on the proposal. The directives are published and announced publicly. The PT may later propose changes to the directives; if the TSC approves the changes the changed directives are also published. The TSC may also change the directives based on proposals from EGs or others.

PT Recorders are appointed by the PT Coordinator; if there are no project recorders, the PT Coordinator is responsible for filling the role. Other members of FHISO may also register to work on the Project.

The coordinator of each PT is given a seat on the TSC by virtue of that coordinator role. This is true even if other members of the PT already have seats on the TSC. If the coordinator already has a seat on the TSC in some other capacity, then being given a seat by virtue of being a PT coordinator has no effect.

Some PTs may have directives that do not involve the creation or refinement of standards. These teams are governed more loosely that standards-effort PTs. For example, the TSC may chose to limit participation in a non-standards-effort PT by appointing the project members. The quorum and the percentage of “Yes” votes required for approval may also be defined on a per-team basis for non-standards PTs.

4.3. Project Team Deliverables

Project Teams maintain meeting minutes and produce reports in the form of status/milestone reports, proposed changes to the Project Directives or deliverables.

The work of the Project Team results in (part of) a Proposed Standard or other deliverable as described in the Project Directive. If the PT determines that producing this primary deliverable is not advisable or not feasible, they instead produce a document describing why the primary deliverable can/should not be produced at this time. Project Teams may also produce Technical Group Notes and proposals for new EGs or PTs.

Project Teams shall from time to time publish Working Drafts of the standard they are producing, and shall keep track of issues reported regarding the drafts, whether reported by team members or by members of the general public.

The TSC may dissolve or suspend PTs. After a Proposed Standard is produced, a PT may continue to work on new versions of the standard or other work described in the project directives. If a PT is dissolved without proposing a Proposed Standard, the PT coordinator is responsible for producing a final report of PT activities.

5. Policies of all Deliverables

All documents published by the TSC or its supervised groups, including but not limited to

will be archived and made available to the public even if they are later superseded by another document. Each such published document should also abide by the following criteria:

  1. The main content of each document must either be self contained or rely only on other FHISO published documents. The meaning of the document should not depend on any of its Citations, URIs, or other references to documents, websites, or similar information sources.

    As an exception to this rule, the TSC, the Executive Committee, or the Board of FHISO may approve particular documents produced by other standards organisations as acceptable to reference by citation even if the content of said documents are integral to the meaning of FHISO-produced documents.

  2. The documents should not contain any inappropriate information. Inappropriate information includes:

    • Sensitive personal information about any living person.

    • Slanderous, libellous, insulting, or inflammatory language.

    • Content that violates copyright, patent, or other intellectual property law.

    Documents containing inappropriate information should be prevented from being published until the inappropriate material is removed.

    If a document is discovered to contain inappropriate material after it is published, that material should be removed from the document and all versions containing the inappropriate material removed from all FHISO-controlled archives.

If documents submitted for publication are discovered to violate any of these criteria before they are published, they should be returned to the submitter for revision.

6. Characteristics of Standards and the Standardisation process

All technical work conducted by the Family History Information Standards Organisation or any of its constituent Technical Groups should conform to the principles of open standards development.

Open Standards Development is characterised by by the Open Stand community on http://open-stand.org/. They identify five salient characteristics of open standards, reproduced below as sections 6.1 through 6.5. FHISO and the TSC are additionally committed to the principles listed in section 6.6.

6.1. Cooperation

Respectful cooperation between standards organisations, whereby each respects the autonomy, integrity, processes, and intellectual property rules of the others.

6.2. Adherence to Principles

Adherence to the five fundamental principles of standards development:

Due process.
Decisions are made with equity and fairness among participants. No one party dominates or guides standards development. Standards processes are transparent and opportunities exist to appeal decisions. Processes for periodic standards review and updating are well defined.
Broad consensus.
Processes allow for all views to be considered and addressed, such that agreement can be found across a range of interests.
Transparency.
Standards organisations provide advance public notice of proposed standards development activities, the scope of work to be undertaken, and conditions for participation. Easily accessible records of decisions and the materials used in reaching those decisions are provided. Public comment periods are provided before final standards approval and adoption.
Balance.
Standards activities are not exclusively dominated by any particular person, company or interest group.
Openness.
Standards processes are open to all interested and informed parties.

6.3. Collective Empowerment

Commitment by affirming standards organisations and their participants to collective empowerment by striving for standards that:

6.4. Availability

Standards specifications are made accessible to all for implementation and deployment. Affirming standards organisations have defined procedures to develop specifications that can be implemented under fair terms. Given market diversity, fair terms may vary from royalty-free to fair, reasonable, and non-discriminatory terms (FRAND).

6.5. Voluntary Adoption

Standards are voluntarily adopted and success is determined by the market.

6.6. Additional Characteristics of FHISO’s Technical Work

Due process
Comments from members shall be considered and responded to. Objections shall be documented and the process shall seek to resolve them with the objector within reasonable time.
Requirements Driven Process
Technical solutions specified by standards shall be based on defined, and documented, requirements stated or confirmed by users, program vendors, service providers or other stakeholders.
International and non-discriminatory
The process and standards shall seek to engage participants from the whole international community, and shall seek to minimise the negative consequences of a single working language (English), thus allowing members who do not have English as their first language to participate on an equal basis. The same considerations apply to the negative consequences of different time zones.
Auditable Process

All organisational entities in FHISO involved in standardisation shall retain records to demonstrate

  1. compliance with the procedures,
  2. efforts to resolve potential conflicts, and
  3. coordination with other standards activities.

Such records shall be available for audit. To the extent possible and practical, the rationale for major decisions shall be documented so that succeeding groups do not have to reanalyse or re-justify decisions that were already made on a sound basis.

Stable Standards
Standards and standards versions should have a reasonably large expected lifetime, and new versions should not be published too frequently in order to reduce interoperability issues and implementation costs.
Complete Standards
The standards shall contain, or reference other publicly available standards that contain, all information in sufficient detail such that any two independent implementations of the standards can inter-operate without the need for additional agreements not explicitly identified by the standard.
Independent Standards
Standards shall not depend on any patented technology or other intellectual property held by other organisations. Preferably the technologies used should be in the public domain, but irrevocable and transferable royalty-free licenses may also be considered if no public domain solution is available.
Certifiable Standards
FHISO may develop requirements to, and procedures for, conformance testing services certifying software product or information services. Details of conformance testing, including who provides the testing services, may be defined and changed by the Board or the TSC based on need and the availability of resources.

A. Acronyms and definitions used in this document

Call for Papers Submission:
A paper submitted to FHISO’s Call for Papers
CFPS:
see Call for Papers Submission
Consensus:
Lack of “substantial opposition.” A vote demonstrates sufficient consensus if less than 25% of votes cast are opposing (abstentions are not counted in the percentage). Censuses building should try to bring opposition to a minimum and not stop when 75% support is obtained. See also “Simple Majority”
EG:
see Exploratory Group
EG Associate Member
A member of an EG that is not a full member of FHISO. See the by-law 5.2 and section 3.2 of this document for more.
Exploratory Group:
A group of at least three people who explore the potential for adding or modifying a project team. See section 3 for more.
Functional Requirement:
A description of some functionality that each implementation of a standard must supply. Functional requirements are one type of User Requirement.
Project Team:
A group of people primarily responsible for a Technical Project. See section 4 for more.
PT:
see Project Team
Simple Majority:
A vote demonstrates simple majority if less than 50% of votes cast are opposing (abstentions are not counted in the percentage). For example, 5 votes of “yes”, 4 votes of “no” and 3 abstentions is a simple majority (5 > 4), but 6 “yes” and 6 “no” is not a simple majority. See also “Consensus.”
Specification:
Something (usually a Functional Requirement) expressed in a formal, technical, mathematical, or otherwise unambiguous way. When not specifying a Functional Requirement, “specification” is often preceded by qualifying noun: for example, “precondition specification,” “process specification,” etc.
Standard:
A specification accepted by vote of the FHISO membership. Sometimes also used to describe a “candidate standard,” a specification that a project team hopes will become a FHISO standard.
Technical Group:
A general term encompassing Exploratory Groups and Project Teams. The TSC can also be called a Technical Group.
Technical Project:
Any project supervised by the Technical Standing Committee. This includes efforts to define or refine a particular candidate standard or set of interrelated standards, but may also include other projects of TSC interest, such as educational initiatives, conference participation, internal infrastructure, certification projects, etc.
Technical Standing Committee:
A group of people primarily responsible for the oversight of Project Teams and Exploratory Groups, as well as for directing the focus of Technical Projects. See section 1.8, as well as the rest of this charter, for more.
TG:
see Technical Group
Transitional Member:
A member of a particular group who either recently joined that group or who failed to participate in the group for a period of at least a month during which two or more ballots were taken, and who has neither participated in two ballots nor participated in one month of group meetings since that joining or absence.
TSC:
see Technical Standing Committee
Voting Member:
A FHISO member eligible to vote on a particular issue. For proposed standards, this is any member of FHISO. For votes in a Technical Group or committee, this is any member of that group that is not a Transitional Member.
Copyright © 2012–2024, Family History Information Standards Organisation, Inc.
Hosting generously donated by Mythic Beasts, Ltd.