XBRL International Standards Board

Working Groups and

Work Product Development Process

XBRL International Standards Board © 2012, XBRL International Inc.

Abstract

The XSB Process Document describes the organizational structure of the XSB and the processes related to the responsibilities and functions they exercise to enable XBRL International to accomplish its mission. This document does not describe the internal workings of the Team or XBRL International  public communication mechanisms.

Status of this Document

This is the 2012-03-19 version of the XSB Process Document. This document has been produced by the XBRL Standards Board and reviewed by the XBRL International Board of Directors.

Versioning: 2007-04-17

Versioning: 2012-03-19

Table of Contents

1. Introduction. 6

2. Background. 6

3. Sources of Input 6

4. Document Structure. 6

5. Organisational Components and their Interrelationships. 7

6. Definitions. 7

7. Working Group Life-Cycle and Internal Processes. 9

7.1 Formation: 9

7.2 Conduct of Business: 9

7.3 Closure: 9

7.4 e-Groups. 10

7.5 Group Formation. 11

7.6 First Meeting of a Group & Appointment of Chairs. 12

7.7 Group Membership and Participation. 13

7.8 Termination of Group Membership or Observer Rights. 14

7.9 Leaves of Absence. 15

7.10 Group Chairs and Vice-Chairs. 15

7.11 Group Recordkeeping. 16

7.12 Group Procedure. 17

7.13 Official Language and Translations. 17

7.14 Group Meetings & Minutes. 18

7.15 Group Charter Revision. 18

7.16 Group Resolutions &Voting. 18

7.17 Group Subcommittees. 19

7.18 Closing a Group. 19

7.19 Intellectual Property Rights Procedures. 20

7.20 Specification Quality. 21

7.21 Application to Existing Groups. 21

8. XII Technical Work Product Development Process. 22

8.1 Work Products. 23

8.2        Maturity Levels. 23

8.2.3    Maturity Level for other publications about a Work Product 25

8.2.4    Maturity Level When Ending Work on a Technical Work Product 25

8.2.5    Maturity Level When Editing a Recommendation. 25

8.2.6    Maturity Levels When Rescinding a Recommendation. 25

8.3        Requirements for Promotion of Work Products on the Recommendation Path. 26

8.4        Reviews and Review Responsibilities. 27

8.5        Promoting a Work Product to Recommendation. 28

8.5.1    Requirements for Public Working Draft (PWD) 28

8.5.2  Requirements for Candidate Recommendation (CR) 28

8.5.3    Call for Implementations. 29

8.5.4    Requirements for Proposed Recommendation (PR) 29

8.5.5    Publication of a XII Recommendation (REC) 29

8.5.6    Returning a Work Product to a Group for additional work. 30

8.6        Ending development of a Work Product 30

8.7        Modifying an XII Recommendation (REC) 30

8.7.1    Errata Management 30

8.7.2    Classes of Changes to a Recommendation. 30

8.7.3    Call for Review of a Proposed Edited Recommendation (PER) 31

8.8        Rescinding an XII Recommendation (REC) 32

8.8.1    Proposal to Rescind a Recommendation (REC) 32

8.8.2    Publication of a Rescinded Recommendation (REC) 32

1. Introduction

The XBRL International Standards Board (XSB) Working Groups and Work Product Process Document provide the operating rules for Working Groups and the product development guidelines for the Work Products of   XBRL International Inc. (XII) undertaken by the XSB. This document should be read with an understanding of XBRL International Inc current Bylaws, the XBRL Standards Board (XSB) Charter and the XII Intellectual Property Policy available through the XII web site at www.xbrl.org in the governing documents section.

2. Background

With the formation of the XBRL International Standards Board (XSB), both the structure of Working Groups and the processes to be followed in the production of  Work Product were reformed. The concept of ad hoc Working Groups and Task Forces (TF), referred collectively as Group(s) in this document, organised around a specific Charter has become the norm within XII. This document defines a set of processes and structures to enable XII to manage Groups which create quality products based upon market needs that have ample opportunity for XII Member and market input. As XBRL shall remain a royalty-free standard these rules and guidelines are an important aspect of governance of XII Work Products.  

3. Sources of Input

The following organisations bear certain resemblances to XII, OASIS (Organisation for the Advancement of Structured Information Standards) and the W3C (World Wide Web Consortium), in that they are both dedicated to the creation of royalty-free standards related to computer data and meta-data representation. Both are consortia that have a membership structure similar to XII. There are certain overlaps between the work of XII and these bodies Much of the XII process described here is either derived from or consistent with related industry practice.

4. Document Structure

There are three primary components to this Document. They are as follows: 

1. Organisational Groups

           This  section addresses the different types of Permanent and Ad Hoc Groups that participate in the XSB technical development  process. It includes, for example,  Taskforces and Review Teams. Collectively these are referred to as “Group” or “Groups” throughout this document. This document addresses permitted activities and reporting responsibilities. 

2. Group life cycle and internal processes

This section addresses how Groups are formed, who is eligible to participate and in what capacity, how Group business is conducted and how a Group is dismissed.

3. Work Product Life Cycle

The expected output of a Group is generally termed a “Work Product”. Each work product goes through a series of stages prior to formal acceptance. This section addresses these stages, and the requirements necessary to progress a work product through each stage.

5. Organisational Components and their Interrelationships

The XSB derives its authority from the XBRL International, Inc. Board of Directors (BoD) and the XII Bylaws.  To distinguish between activities and responsibilities that are discharged by the XSB or directly by the XII BoD the appropriate acronym will be noted. 

Additional components to the Group framework are “Review Teams” (RT) and Task Forces (TF). These are generally small groups of individuals with particular, focussed skills that review certain technical material as part of an approval process designed for that particular type of material. These Groups are formed to deliver short term (6-12 months) well defined deliverables. These Groups, and their members, are appointed and serve at the discretion of the XSB. 

While these guidelines impose certain requirements on Group operations and leadership, the XSB is committed to supporting the activities of the Groups to ensure their success. This is achieved by expediting requests and communications from Groups, providing technical staff resources for liaison and guidance, supporting the implementation of the processes and procedures wherever necessary, and providing liaison between the Groups, the XSB and the XII BoD.

6. Definitions

This section provides definitions of terms that are used elsewhere in the document and should be referred to in order to understand the precise meaning where the terms defined herein are encountered.

1. “Charter” is the document that defines the scope, deliverables, timeline etc. for a Group.

2. “eGroup” is an electronic discussion list owned and managed by XBRL International  to facilitate exchanges which lead to a Charter being prepared and submitted to the XSB for approval.

3. “Eligible Participant” means someone who is either an XII Eligible Participant or who has been deemed by BoD or the XSB to be entitled to the same privileges as an Eligible Participant with respect to the processes defined herein. Refer to the XII Membership Policies and Procedures, which supersedes this document on XII Membership related topics.

4. "Erratum" (plural “errata”) refers to any class of revisions, from simply editorial to a serious error that may affect the conformance with the Recommendation by software or content (e.g., XBRL instance or taxonomy validity).

5. “IP Policy” is the XBRL International Intellectual Property Policy – see http://www.xbrl.org/legal/

6. “Leave of Absence” has the meaning defined in section 6.6.

7. “Majority Vote” is a vote, at a meeting with a quorum, in which the number of “yes” votes cast is greater than the number of “no” votes cast. Abstentions have the same effect of not voting.

8. “Member” is an Eligible Participant who subscribes to an eGroup, is permitted to attend Group meetings and has agreed to the XII IPR policy (see http://www.xbrl.org/Legal2/XBRL-IP-Policy-2007-02-20.pdf ). They are allowed to post messages to the eGroup, to speak in Group meetings and to make Contributions to a Group. See section 6.4.

9. “Minimum Membership” means five Voting Members of a Group representing at least three XII member organisations.

10. “Observer” is an Eligible Participant who subscribes to an eGroup, and is permitted to attend meetings. They are not allowed to post messages to the eGroup, or speak in Group meetings except by invitation of the Chair. They are not expected to make contributions to the Group.

11. “Proper Majority Vote” is a Group vote in which more than 50% of the Voting Members vote “yes”, irrespective of the number of Voting Members present in the meeting and not counting abstentions.

12. “Public” and “publicly” mean available to all persons, whether XII Eligible Participant or not.

13. “Quorate Meeting” is a Group meeting at which a quorum is present. A meeting that is not quorate is “inquorate”.

14. “Quorum” is the minimum number of Voting Members of a Group that must be present so that resolutions may be voted. The quorum for XII Group meetings is a majority (more than half) of the Voting Members.

15. “Resolution” means a decision reached by a Group as a result of a vote.

16. “Substantive Change” is a change to work product that would require a conformant application or implementation to be modified or rewritten in order to remain conformant.

17. “Super-Majority Vote” is a Group vote in which at least 2/3 (two thirds) of the Voting Members vote “yes” and no more than 1/4 (one quarter) of the Voting Members vote “no”. These numbers are based on the total number of Voting Members, irrespective of the number of Voting Members present in the Group Meeting, without counting abstentions.

18. “Voting Member” is a Member of a Group who processes voting rights in a Group.

19. “Group Meeting” is a meeting of the Group that is properly called and scheduled in advance.

20. “Group Organiser” is an Eligible Participant who performs the function of organizing the first meeting of a Group.

21. “Group Subcommittee” (GSC) is a subset of Members of a Group producing work product for consideration or adoption by the parent Group.

22. “Group Working Draft” (GWD) is a version of work product which has received approval for public dissemination.

23. “Group(s)” contains at least the Minimum Membership, is formed and operated according to this XII Group Process.

24. “Group Administrator” is the person or persons responsible for group-related administrative matters.

25. “XII Member Organisation” is a firm that is a member of a Jurisdiction, or a direct member of XII as defined by the XII Membership Policies and Procedures, which supersedes this document on XII Membership related topics.

26. “XII Technical Lead” is the XII staff member or backup assigned to a particular Group or the XSB. When in doubt as to the assigned staff member correspondence should be sent to admin@xbrl.org.

27. “XII Recommendation Path” is the process of advancing a technical Work Product from early draft to mature deliverable (“Recommendation”)

7. Working Group Life-Cycle and Internal Processes

This Section describes the stages in the Group Lifecycle. In summary, they are as follows:

7.1 Formation:

If a Group is formed at the request of XII Members then an e-Group  is created to ascertain interest from the XII Membership at-large.

If a Group is formed by the XSB a Charter is prepared by individuals identified by the XSB and then approved by the XSB. A Charter, once approved, may be revised based upon a recommendation by either the XSB or the Group.

Upon approval of a revised Charter, each voting member shall be re-affirmed. This will have the effect of re-affirming members agreement to the IP Agreement each makes with XII as a condition of participation.  

7.2 Conduct of Business:

Once a Group is chartered it conducts business using a combination of eGroup, telephone conference calls and face to face meetings. It may create subcommittees to perform specific tasks as it sees fit. Work product it creates must be in accordance with the Work Product Life Cycle as defined in Section 7 below. Groups must regularly report to the XSB so that their work can be monitored and guided within the overall strategy of XII and the work plan of the XSB. Members shall serve at the discretion of the XSB. Members shall not receive remuneration for participation.

7.3 Closure:

Upon completion of the business for which it is chartered a Group shall prepare a final report with a recommendation that the XSB should close the Group.

The following diagram outlines the Working Group formation process which is described in more detail in subsequent sections.

 Working Group Formation Process

7.4 e-Groups

At the request of at least three Eligible Participants an e-Group will be established for the purpose of organizing the formation of a Group. No more than two, out of the minimum number of three, Eligible Participants may be employees of the same XBRL Member Organisation. To establish an e-Group a written request must be submitted to an XII. administrator with the following items:

· A name for the e-Group. Note: This name may not be the Group name proposed in the Charter.

· The names, e-mail addresses and membership affiliations of the three or more Eligible Participants requesting the e-Group.

• The name of the e-Group leader(s).
• A draft statement of scope and deliverables for the Group.

Within 15 days of receiving the request the XII Technical Lead will announce to the membership a “Call for Participation” inviting members to subscribe to and participate in the e-Group. Such request will be posted to the XII web site and distributed by other means deemed appropriate.                             

e-Group discussions are restricted to evaluating interest in forming a new Group and defining the proposed Charter. The list of subscribers to the e-Group shall be available to all other e-Group subscribers. The eGroup shall automatically close 90 days after the “Call for Participation” is issued.

7.5 Group Formation

A collection of individuals, meeting the Minimum Membership requirement, may request the XSB to form a Group. Requests must be submitted to the XII Technical Lead written in English and provided in electronic form. The proposal may have information in addition to that described below, however such additional information should be isolated in an appendix or supplement to the required items.

1. A Proposed Charter for the Group

A Proposed Charter shall include the following;

a) The Name of the Group. This name must not have been previously used for any XII Group and must not include any trademarks or service marks not owned by XBRL International Inc. The proposed name may not include any misleading or inappropriate names. It must specify any acronyms or abbreviations of the name that is intended to be used to reference the Group.

b) A Statement of Purpose, including a definition of the problem to be solved. The purpose of the Group should be relevant to the mission or directly relate to the strategic or operational plans of the XSB or XII. 

c) The Scope of the work proposed. These statements must include a definition of what is and what is not within scope for the Group. The scope may include a specific contribution of existing work as a starting point.

d) List of deliverables with projected completion dates.

e) The expected audience or users of the work. 

1. Additional information regarding the formation of a Group

Such additional information shall include:

a) A listing of the desired skills within the Group. (Required)

b) Identification of similar or related work that is being done in other XII Groups or by other organisations. (Required)

c) The need for additional work in this area and how the proposed Group will complement other works in the area including the level of liaison sought with such other organisations.

d) List contributions of existing work that will be made to this Group and any acknowledgement or IP conditions related to such contributions.  (Required – if contributed work is received or anticipated)

e) A proposed working title and acronym for the specification(s) or other work product to be developed by the Group. (Optional)

f) The date, time, and location of the first Group Meeting. (Required) The first Group Meeting must occur within 30 days, or within 45 days if a face-to-face meeting is planned, of the announcement of a Group. 

g) The projected Group meeting schedule for the year, or until the projected date of the final deliverable, whichever comes first. (Optional)

h) Names, e-mail addresses, and membership affiliations of at least the Minimum Membership requirement who support this proposal and are committed to the Charter and proposed Group meeting schedule. (Required)

i) The name of the Group organiser. (Required) This individual must be an Eligible Participant.

As soon as practical following the submission of the required materials the XSB will consider the request.

The XSB may approve the Group formation, request modifications or clarifications or reject the request.

If approved, the XII Technical Lead will publish a Call for Participation including the skills sought and details of the first Group Meeting.

If the XSB requests modifications or clarification the XII Technical Lead will notify the submitters, providing necessary details of the requested information and suggested timeline for resubmission.

If the XSB rejects the request the XII Technical Lead will notify the submitters of the XSB decision and rationale. The submitters may request a meeting with the XSB or appeal the decision directly to the BoD.  An appeal to the Board shall be written and provide all submission materials originally provided to the XSB, the decision and rationale provided by the XSB and whether a meeting with the XSB was requested and held. An appeal to the BoD may be delivered to the XII Technical Lead or the XII CEO.

The BoD may process the appeal as it sees fit based on the individual circumstances. Such disposition may include confirmation of the XSB decision or any other course of action it deems appropriate.

7.6 First Meeting of a Group & Appointment of Chairs

Eligible Participants who wish to participate in the first Group Meeting must register by sending an e-mail to the Group organiser, copying the XII Technical Lead, within 5 days of the scheduled meeting. Each participant must specify the role being requested as Observer, Member or Voting Member.

Each Eligible Participant must confirm to the XII Technical Lead that they individually agree, and that their employing organisation agrees, to abide by the XII IP policy with respect to their participation and contributions. Upon receiving such confirmation in writing the XII Technical Lead will approve the request to participate.

Every Eligible Participant who has requested and been approved, as either a member or a voting member, will be a Member of the Group effective with the date of the first Group Meeting. Each Member who has requested voting rights and is present at the first Group Meeting will be a Voting Member of the Group. Voting Members who fail to attend the first Group Meeting will automatically be converted to member participants without a vote. To be considered for voting rights after the first Group Meeting the member must notify the Group Chair, or Group organizer, and request a Resolution be presented to the Group to accept them as a voting member for future meetings. Additions to the Voting Members after the first Meeting of the Group require a Resolution from the Group and XSB approval.

The first Group Meeting of a Group must take place when, where and how it has been described in the announcement. If a change is required the XII Technical Lead must make a reasonable attempt to reschedule as soon as possible at a time agreeable to a majority to meet the Minimum Membership. At least the Minimum Membership must become Voting Members at the first Group Meeting or the Group shall not be considered successfully started. In this situation either the meeting can be rescheduled within 30 days or the Group shall be immediately dismissed on the 31^st day.

The Group Organiser acts as Chair until a recommendation for Chair has been made by the Group and approved by the XSB. During the first Group Meeting the Group must recommend the names of a Chair and Vice-Chair(s) (Optional) to the XSB. Candidates for these positions must be Voting Members of the Group. The XSB will consider the request as soon as practical and either confirm the recommendation of the Group or appoint alternate individuals from among the Voting Members of the Group. Once a Chair is approved by the XSB the responsibilities of the Group organiser ends.

7.7 Group Membership and Participation

Group Membership is on an individual basis, not on a per organisation basis. Group membership may not be transferred from person to person.

No individual may attend a Group meeting unless they fall into one of the following categories;

Observer

An Eligible Participant may become an Observer of a Group by requesting such role. To do this they must request in writing to the Group organiser (if prior to the first Group Meeting or approval of the Chair) or Chair (once established), copying the XII Technical Lead. There is no attendance or participation requirement in order to maintain Observer status, however, an Observer must remain an Eligible Participant.

Member

An Eligible Participant may become a Member of a Group by requesting such role. To do this they must request in writing to the Group organiser (if prior to the first Group Meeting or approval of the Chair) or Chair (once established), copying the XII Group Administrator. There is no attendance or participation requirement in order to maintain Member status, however, a Member must remain an Eligible Participant.

Voting Member

An Eligible Participant may become a Voting Member of a Group by requesting such role. To do this they must either meet the requirements above for a newly formed Group or request in writing to the Group organiser (if prior to the first Group Meeting or approval of the Chair) or Chair (once established), copying the XII Group Administrator. There is an attendance and participation requirement in order to maintain Voting Member status and Voting Members must remain Eligible Participants.

A Voting Member must remain active in a Group to maintain voting rights. A Voting Member who is absent from three consecutive Group Meetings or six consecutive weeks, whichever is the longer period of time, loses his or her voting rights immediately and without requirement of notice.  Voting Members who lose their voting rights remain Members of the Group. 

A Member who has lost his or her voting rights, for whatever reason, may regain them by attending two consecutive Group Meetings and then having a recommendation by the Group to the XSB to reinstate them as a Voting Member. Upon an affirmative vote of the majority of the XSB the individual will regain voting privilege for the next Group Meeting. 

7.8 Termination of Group Membership or Observer Rights

Except as provided in 6.6 below, termination of Group Member rights will occur under the following conditions:

· A Member is considered to have resigned from a Group upon notification of resignation or withdrawal to the Group list, Group Chair or XII Group Administrator.

• An individual is no longer an Eligible Participant, for whatever reason.
• A Chair, after providing written notice, may immediately terminate the membership of any individual who behaves in a manner deemed unprofessional. An individual whose membership is so terminated may appeal the termination to the XSB.

Termination of Group membership for any reason shall automatically end participation rights, in any capacity, in the Group and any Group Subcommittee.

7.9 Leaves of Absence

A Voting Member of a Group is permitted one Leave of Absence during any consecutive twelve month period. During a Leave of Absence a Voting Member is exempt from the participation criteria specified in section 6.4. The first Leave of Absence during any twelve month period is granted automatically upon application to the Chair of the Group. The Chair must notify the Group of any Leave of Absence by reporting it in the minutes of the Group Meeting immediately following the granting of such Leave of Absence.

A Voting Member who has taken a Leave of Absence during the previous twelve months may apply for a maximum of one additional Leave of Absence during the same twelve month period. A second Leave of Absence may be granted only upon majority approval of the Group.  

A Voting Member who is granted a Leave of Absence shall not have voting rights in the Group or any of its Group Subcommittees for the duration of the Leave of Absence. Voting rights shall resume immediately upon the person returning from a Leave of Absence.

 The length of a Leave of Absence shall be specified in advance by the Voting Member requesting it and shall not exceed 60 days. A Leave of Absence shall begin no earlier than seven days after the date upon which the request is submitted to the Chair of the Group and shall end on the date specified.

7.10 Group Chairs and Vice-Chairs

Each Group must have a Chair and is recommended to have a Vice-Chair(s). Only Voting Members of the Group are eligible to be Chair or Vice-Chair(s). The initial Group Chair and any Vice-Chair(s) are appointed by the XSB upon recommendation of the Group as defined in section 6.3.  

If a Group does not have a Chair and does not have a Vice-Chair(s), for whatever reason, then all Group activities, with the exception of forming a recommendation of a new Chair and/or Vice-Chair(s), are suspended.

The responsibilities of Chair of a Group may be discharged by no more than two Vice-Chairs(s) at the discretion of the XSB. In the event that the Chair position is shared between 2 Vice-Chairs the role of each shall be documented as to duties and responsibilities. Any notification required shall be made to both Vice-Chairs.

A Group Chair or Vice-Chair(s) may be removed by the XSB or by a Super-Majority Vote of the Group. In the event that a Group has vice-Chairs each may be removed individually or both may be removed by a single action.

 A vacancy shall be deemed to exist when (a) the Chair or one or both Vice-Chairs has been removed, (b) the Chair or one or both Vice-Chairs has resigned the position, or (c) the Chair or one or both Vice-Chairs ceases to be a Group Member for whatever reason. Vacancies of the Chair or Vice-Chair(s) shall be filled by recommendation of the Group from the Group Members or the XSB or any XII Eligible Participant.

The same provisions regarding Leaves of Absence shall apply to the Chair or Vice-Chair(s) of a Group as to the other Group Members. The Chair must notify both the XII Technical Lead and the Group at least 30 days prior to any non-emergency leave of absence. In the event of the Chair being on Leave of Absence the duties of the Chair are to be carried out by the Vice-Chair(s) or other Group Member as determined by the Chair.

The Vice-Chair(s) may carry out all duties of the Chair in the Chair’s absence. Where a Group is expected to continue its work for a period of more than 12 months the Group should consider periodic changes to the Chair or Vice-Chair(s) and advise the XSB of its recommendation. The XSB will determine what, if any, changes it will approve to the Chair positions.

7.11 Group Recordkeeping

Official copies of all resources of the Group and any associated Group Subcommittees (GSC), including web pages, documents, e-Group lists and any other records of discussions, must be located on facilities designated by XBRL International Inc.. Groups and GroupSCs may not conduct official business or technical discussions, store documents, or host web pages on servers or systems not designated by XBRL International Inc.

eGroups

Upon formation each Group will be provided with a general discussion eGroup list and a means to collect public comments. Subscription to the general eGroup list shall be required for Members, Voting Members, and Observers of the Group.

The minutes of each Group meeting and a record of all decisions must be published to the relevant eGroup(s) on a timely basis, and at least 2 working days before the next meeting. All official communications and non-verbal discussions of the Group must take place on the eGroup list. All eGroups shall be archived for the duration of the consortium, and all eGroup archives shall be available to all XII members upon request to the XII Technical Lead.

The reason for a WG having a public comment facility is to facilitate receiving comments from the public and is not for public discussion. Comments shall be publicly archived, and shall be forwarded to one or more Members of the WG including the WG Chair. WGs are not required to respond to comments. Comments to the WG made by Members of the WG must be submitted via the WG general eGroup list, and comments made by non-WG members, including from the public, must be made via the WG’s comment facility. Comments shall not be accepted in any other way

Collaborative Workspace

The XII Technical Lead shall provide the Group with an online workspace for collaboration, file storage, calendaring functions etc.

The Group must keep the following information current in the Group collaborative workspace:

· the Group name and Charter;

· standing rules and other adopted procedures;

· Group Meeting schedule;

· anticipated deliverables and delivery dates;

· list of Members and Observers,

· identifying those with voting privileges;

· the name and e-mail address of the Group Chair and Vice-Chair(s) as well as any other important positions that may have been created by the Group;

· list of Group Subcommittees, their deliverables, and members;

· draft and completed Group documents with identification of the most recent versions of the Group’s work product;

· and copies of the IPR declarations for that Group.

Announcements

The XII Technical Lead shall create an archived list for announcements from the XII Technical Lead regarding Groups. Any Eligible Participant may subscribe to this list. Every important change in Group status will be posted to the announcement list; such changes including but not limited to the following: Group formation; Group Charter revision; announcements of any change in the status of Group work product as it passes through the Work Product Life Cycle, changes to the Voting Membership of the Group and dismissal of a Group.

7.12 Group Procedure

The operation of Groups shall be governed by Robert’s Rules of Order Newly Revised, insofar as such rules are not inconsistent with or in conflict with this Group Process, the XII IP Policy, the XII Bylaws, other XSB-approved policies, or with provisions of law.

Standing rules may be adopted by Proper Majority Vote of the Group and must be communicated to the XSB. The Group may not adopt standing rules or other resolutions related to the XII IP Policy, quorum requirements, membership, voting, eligibility to participate, or that otherwise conflict with or supersede any XII policy. The XSB may override them if they conflict with XBRL International Inc. policy. Approved standing rules must be published in the Groups collaboration tool.

7.13 Official Language and Translations

The official language of all Groups shall be English with all written material being in United Kingdom English. Members of Groups who wish to communicate with each other on Group business in other languages may do so between themselves provided that they provide an English language translation of their communication for the benefit of other Group members and other XBRL Participants. 

7.14 Group Meetings & Minutes

Group meetings must be scheduled in advance and properly called by publishing an announcement of the date, time and place (or phone number) of the meeting to the Groups eGroup. Group Meetings scheduled or conducted so as to exclude any Member are subject to appeal to the XSB. Group Meetings may be conducted face-to-face or via telephone conference or other electronic media that allow participation of all Members of the Group.

If a meeting is inquorate, discussions may take place but no business leading to a vote may be conducted; those present may act as a “Committee of the Whole” as defined in Robert’s Rules of Order Newly Revised, and make a report to the entire Group. Attendance must be recorded in the Group Meeting minutes. Inquorate Group Meetings shall count towards attendance for purposes of Members gaining, maintaining, or losing voting rights.

Meeting minutes must be recorded and published to the relevant eGroup and archived in the Group’s collaboration tool.

7.15 Group Charter Revision

A Group may revise its Charter only to remove ambiguity or to adjust the scope defined by the Charter. The Group may not change its scope of work without XSB approval. The list of deliverables may be expanded only if the new deliverables are within the scope of the Group.  

Approval for revision shall require a Super-Majority Vote of the Group. A revision of the Charter may occur only after the first Group Meeting of the Group. The Group Chair shall notify the XII Technical Lead that a motion has been made to revise the Charter, and the XII Technical Lead shall set up and conduct the ballot.

The Chair shall ensure that the proposed revision is in conformance with existing XII Policies. The Chair will direct the XII Technical Lead to, within 15 days, either open the ballot or reply to the Group with the reason why the revision cannot be voted upon. A decision by the Chair may be appealed to the XSB. The revised Charter shall not take effect until approved by the XSB and announced by the XII Technical Lead. The XII Technical Lead shall publicise approved changes in the same manner as the initial formation of the Group was publicised.

7.16 Group Resolutions &Voting

Resolutions require a Majority Vote to pass, unless this document dictates that a Proper Majority Vote or Super-Majority Vote is necessary.

All Group ballots requiring a Super-Majority Vote for approval must be conducted by the XII Technical Lead. The Group Chair must notify the XII Technical Lead that a motion has been made that requires a Super-Majority Vote, and the XII Technical Lead will set up and conduct the ballot.

Eligibility

A Member of a Group must have voting rights to make or second a motion, and must have voting rights at the time a ballot is opened in order to vote on that ballot. Every Voting Member of a Group has a single vote. Organisations may not vote as a block. Proxies are not allowed in Group voting.

Electronic Voting

Groups may conduct electronic ballots, either by using their eGroup list or any other electronic voting functionality provided by XBRL International Inc. The minimum period allowed for electronic voting shall be seven calendar days; the Group may specify a longer voting period for a particular electronic ballot.

A motion to open an electronic ballot must be made in a Group meeting unless the Group has adopted a standing rule to allow this motion to be made on the relevant eGroup. If such a rule has been adopted, motions made on the eGroup must also be seconded and discussed on that list.

7.17 Group Subcommittees

A Group may by Resolution create a Group Subcommittee (GroupSC). The Resolution must be recorded in the Minutes, and must include

· the Name

· Statement of Purpose,

· List of deliverables,

· Name of the Chair of the GroupSC.

All of these items must fall within the Charter of the Group and conform to XII policy.

The deliverables of the GroupSC are made only to the Group. Members of the GroupSC must first be Members of the Group. Observers of a Group may be Observers of a GroupSC, but may not become GroupSC members without first becoming a Member of the Group. A GroupSC member may resign from the GroupSC and remain a Member of the Group.

7.18 Closing a Group

A Group may be closed by either a;

· Proper Majority Vote of the Group or

· by decision of the XSB.  

The XSB must close a Group once it has has completed the deliverables listed in its Charter.  

The XII Technical Lead may recommend to the XSB to close a Group that fails to conduct at least one Quorate Group Meeting during any six month period; whose membership falls below the Minimum Membership; which has not completed its deliverables within the schedule listed in its Charter; or which has failed to show progress towards achieving its purpose as defined by its Charter.

7.19 Intellectual Property Rights Procedures

The Group shall operate in accordance with the XII Intellectual Property (IP) Policy.

Notices of Disclosed Claims, as defined in and required by the XII Intellectual Property (IP) Policy, shall be made by sending an email message to the XII Technical Lead, who shall post the disclosure in the Groups collaboration tool and notify the Group via the Group eGroup. The Group shall make no formal decision with regard to the applicability or validity of an IP disclosure.

Contributions, as defined in the XII Intellectual Property (IP) Policy, shall be made by sending to the Group’s eGroup either the contribution, or a notice that the contribution has been submitted to the Group’s document repository; a URL or other reference is not adequate. Written contributions must be converted to electronic format and submitted to the relevant eGroup or collaboration tool. The Group is not required to acknowledge or use any Contribution.

Additionally a call for claims MUST be made at the start of every Group meeting by the chair putting the following question to the meeting:

“This is a call for any claims under any patent applications or issued patents that would be likely to be infringed by an implementation of the specification or other work product which is the subject of this meeting, as per XII Intellectual Property (IP) Policy. Are there any such claims?”

Adequate time shall be provided for any such claims to be heard and the Chair may decide to repeat the question if they feel it is appropriate or necessary. The calling of this question, and its wording, must appear in the published agenda for every Group meeting.

Every published agenda for Group meetings shall also contain the following text:

“This Group Meeting is open to XII Eligible Participants and individuals who have been deemed by BOD or the XSB to be entitled to the same privileges as an XII Eligible Participant in respect of Group participation. Group Meeting attendees are bound by the XII Intellectual Property (IP) Policy. If you do not agree to the policy, or do not understand its implications, you MUST NOT attend the meeting. In particular, you should be aware of the content of Section 11 as follows:

 “Each Member represents, warrants, and covenants that it will not submit any Contribution that may subject any Contribution or Recommendation, in whole or in part, to licensing obligations with additional restrictions or requirements inconsistent with those set forth in the XII Intellectual Property (IP) Policy, or that would require any portion of such Contribution to be: (i) disclosed or distributed in source code form; (ii) licensed for the purpose of making derivative works; or (iii) redistributable at no charge. If a Member or Participant has knowledge that a Contribution has been made that may subject any Contribution or Recommendation, in whole or in part, to one or more of the licensing obligations listed in this section 11 above, such Member or Participant will give prompt notice of the same to the Working Group Chair.”

7.20 Specification Quality

All documents and other files produced by the Group, including specifications at any level of approval, must use the XBRL International Inc. file naming scheme, and must include the XBRL International Inc. copyright notice. All document files must also use the XBRL International Inc. document templates. The name of any specification may not include any trademarks or service marks not owned by XBRL International Inc.

 The specification must include a list of people who participated in the development of the specification. This list shall be initially compiled by the Chair and any Member of the Group may add or remove their names from the list by request. The final list shall be approved by the Chair and Vice-Chair(s) taking into account the contribution made by each individual. Criteria such as “providing deliverables or drafts of deliverables in a timely fashion”, “being familiar with the relevant documents of the Working Group, including minutes of past meetings”, “following discussions on relevant mailing list(s)” are to be applied in making this evaluation. If a person’s name is omitted following this evaluation and they object to its omission they have the right of appeal to the XSB.

Editable formats of all versions of Group documents must be stored in the Group’s collaborative workspace. The XSB may set specific standards for the format of such documents from time to time.

 All schema and XML instances, whether by inclusion or by reference, including fragments of such, must be well formed. All expressions must be valid. All machine-processable schemas, XML instances etc. that are part of the specification must be available separately in their own plain text file with their own file name. There shall be only one normative version of any such artefact and non-normative copies provided for “ease of processing” or other purposes shall be identified as non-normative appropriately. 

A specification, taxonomy or document (work product) may be composed of any number of files of different types, though any such multi-part work product must have a single name and version number. Irrespective of the number and status of the constituent parts, the work product as a whole must be approved by a single Group ballot. Any change made requires a new version or revision number or indication of the errata correction status. Exceptions are for changes made to the title page and in the running footer noting the approval status and date, which are to be made after the approval of the work product.

7.21 Application to Existing Groups

This Group Process applies to previously established Groups upon its adoption. Transitional arrangements will be managed by the XSB and issues or inconsistencies dealt with on a case by case basis.

8. XII Technical Work Product Development Process

The XII Technical Work Product Development Process is the set of steps and requirements followed by XII Working Groups in the production of the Work Product for which they have been Chartered.

The process is designed to maximize consensus about the content of a technical work product, to ensure high technical and editorial quality, to promote consistency among specifications, and to obtain endorsement from within XII and from the broader community.

The processes include:

• Advancing a Work Product along the XII Recommendation Path;
• Ending work on a technical work product before it reaches Recommendation, or when not intended to become a Recommendation;
• Modifying an XII Recommendation;
• Rescinding a Recommendation no longer endorsed by XII.

Every document, other than internal drafts, published as part of the Work Product Development Process shall be available to the public.

Every document published as part of the Work Product Development Process shall indicate its maturity level.

Every Work Product published as part of the Work Product Development Process is edited by one or more editors appointed by a Working Group Chair. It is the responsibility of these editors to ensure that the decisions of the group are correctly reflected in subsequent drafts of the work product. All XII editors must be members of the Group responsible for the document(s) they are editing.

Every document published as part of the Work Product Development shall include a section about the status of the document. The status section should explain why XII has published the Work Product, who contributed to the development, where to send comments, whether implementation experience is being sought, any significant changes from the previous version, expectations about next steps, or why work on the Work Product has ceased, and any other relevant information or rationale.

During the preparation of documents for approval, but prior to their approval, the word Draft, for example “Draft Candidate Recommendation” (DCR) should be included.

XII will make efforts to keep archival documents indefinitely available at their original address in their original form.

XII encourages verbatim translations of its Work Products.

8.1 Work Products

In order to ensure that Work Products meets the needs of the market a requirements document for all proposed development must be prepared in writing and approved by the Group and XSB. Requirements must include the following information – the problem(s) identified, the business needs and the functional needs of the proposed Work Product.

Typical components of a Work Product produced by a Group include:

• Requirements (mandatory)
• Covers business and functional requirements, including Use Case definitions. This document is used as a cross reference to ensure that the technical work product is consistent and satisfies the needs of stakeholders.
• Specification (or Taxonomy etc.) (mandatory)
• The normative document that software developers and XBRL users refer to in order to obtain a definition of the standard.
• Conformance suite (optional)
• A set of test cases (with accompanying descriptive material) that users can exercise to determine their conformance to the specification with a view to ensuring interoperability.
• Reference Implementation (optional)
• Software that implements the technical work product which software vendors may use to evaluate their implementation.
• Basic reference on use of the work product (optional)
• Working Group Note(s) (optional)
• Clarifying or other material produced by the Group to assist users of the Technical Work Product.
• Errata Corrections (mandatory if identified errors are of sufficient importance to be publicly corrected)
• Final Working Group Note (mandatory)
• A final statement from the Group when it is dismissed

The Requirements document and the Specification typically will be taken together as being the main Work Product of the Group, reaching REC level simultaneously in that they jointly form the XII Recommendation. 

Conformance Suite, Reference Implementation and Working Group Notes may be at a different maturity level than Requirements and Specification at any time.

8.2 Maturity Levels

The Maturity Level of a Work Product indicates its stage of approval in the XII Recommendation Path.

8.2.1 Maturity Level for Work in Progress

Working Drafts (WD)

A Working Draft (WD) is a document that is under development. There are different levels of Working Draft depending on the breadth of the community to which it is distributed. These levels are:

Group Draft (GDraft)

A GDraft is a Working Draft that is under discussion by the relevant Group. A GDraft is  generally published only to the Group mailing lists and files areas belonging to the Group. A GDraft may be distributed to any XII Eligible Participant either by request or by the Group to seek feedback for the benefit of the Group.

Internal Working Draft (IWD)

An Internal Working Draft (IWD) is a Working Document that a Work Group has decided to distribute to XII Eligible Participants. IWD are not for distribution to the general public. In the case of later maturity levels it is identified as an “IWD of the appropriate level”, such as an “IWD of a CR” (“Internal Working Draft of a Candidate Recommendation”) for example.

Public Working Draft (PWD)

A Public Working Draft (PWD) is a Working Draft that a Group has decided to distribute the general public for the purposes of obtaining feedback and which has been approved for such publication by the XSB.

During the preparation of IWDs and PWDs there is inevitably a time when the document that is to be distributed has been prepared but distribution has not yet been approved by the responsible authority (e.g. by vote of the relevant Group or the XSB). Any document in this state is identified as such by prefixing its description with the word “Draft”.

8.2.2 Maturity Levels of the Recommendation Path

 In addition to Working Drafts the other maturity levels of the Recommendation Path are:

Candidate Recommendation (CR)

A Candidate Recommendation (CR) is a Work Product that has received extensive public review and satisfies the Group’s technical requirements. XII publishes a Candidate Recommendation to encourage project implementations for “field testing”.  The XSB must approve a Group resolution to advance a Work Product to Candidate Recommendation.

Proposed Recommendation (PR)

A Proposed Recommendation (PR) is a Work Product that demonstrates technical soundness through documented public review and market implementations. The XSB and the XII Board of Directors must approve a move to Proposed Recommendation prior to publication.

Recommendation (REC)

A Recommendation (REC) is a Work Product that meets the requirements of Proposed Recommendation (PR) and demonstrates market maturity through comprehensive implementation in multiple production systems.  The XSB and the XII Board of Directors must approve a move to Recommendation.   XII recommends general deployment of Work Products that are granted REC status.

8.2.3 Maturity Level for other publications about a Work Product

Working Group Note (WGN)

A Working Group Note (WGN) is published by a Group to provide additional information about its Work Product that is not necessarily appropriate to include in the Recommendation itself. A Group may publish a Group Note with or without publication as a Working Draft. A Group Note must be approved by the XSB prior to publication.

8.2.4 Maturity Level When Ending Work on a Technical Work Product

Final Group Note (FGN)

A Final Group Note is published by a Group to indicate that its work has ended. When a Group publishes a Final Group Note it may do so with or without publication as a Working Draft. A Final Group Note must be approved by the XSB prior to publication.

8.2.5    Maturity Level When Editing a Recommendation

Proposed Edited Recommendation (PER)

A Proposed Edited Recommendation (PER) is a Recommendation published for review of changes, some of which may affect conformance. When there is consensus about the changes, the document is published as a Recommendation. A Proposed Edited Recommendation must be approved by the XSB prior to publication.

8.2.6 Maturity Levels When Rescinding a Recommendation

Rescinded Recommendation

A Rescinded Recommendation is a Recommendation that XII no longer endorses.

8.3 Requirements for Promotion of Work Products on the Recommendation Path

The following diagram outlines the progress of a document through the various maturity levels on the Recommendation Path. The details are described more fully in subsequent sections.

In preparation for promotion to subsequent maturity levels up to and including publication as a Recommendation, a Group must: 

• By a Proper Majority Vote, pass a Resolution that requests the XSB to approve the promotion of the Technical Work Product.
• Provide public documentation of all changes (both substantive and minor) to the Technical Work Product since the previous step. A substantive change (whether deletion, inclusion, or other modification) is one where it could reasonably be expected that making the change would invalidate an individual’s review or implementation experience. Other changes (e.g., clarifications, bug fixes, editorial repairs, and minor error corrections) are minor changes.
• Report which, if any, of the Groups requirements for this document have changed since the previous step.
• Report any changes in dependencies with other Groups.
• Show evidence of wide review and stakeholder support.
• Formally address all issues raised about the document since the previous step.
• Report any Formal Objections.

The following information is important to justify the decision to promote a Work Product and therefore must be publicly available:

• Documentation of all changes to the Technical Work Product (e.g., by providing “diffs” in addition to summaries of substantive changes);
• A statement that all requirements have been fulfilled or a listing of unfulfilled requirements and the rationale for promoting the Technical Work Product, even though some requirements have not been met.
• Evidence of wide review and that dependencies with other Groups have been resolved;
• All responses that formally address issues raised by reviewers;
• All Formal Objections.

8.4 Reviews and Review Responsibilities

To build consensus for XII Work Products, the following actions are recommended:

1. Regular publication of requirements, product and notes
2. Reference implementation and notes to assist with field testing
3. Broad review and stakeholder input, including from groups inside and outside of XII

Groups should formally address and document all substantive review comments about a Technical Work Product in a timely manner.

The XII Technical Lead must formally address any substantive issue raised by XSB members during any product review period. The Group must communicate to the XII Technical Lead any substantive issues raised during any public review period. 

8.5 Promoting a Work Product to Recommendation

Key stages on the path to Recommendation

Groups embark on this process with the intent of publishing one or more Recommendations. However, the XSB may end work on a technical work product at any time, or may request a Group conduct further work, possibly repeating one or more steps.

8.5.1 Requirements for Public Working Draft (PWD)

A Group must obtain approval from the XSB to publish the first Public Working Draft and all subsequent PWD releases.

The XII Technical Lead must announce the first Public Working Draft (and all published revisions) to XBRL Members, participants and to the public.

8.5.2  Requirements for Candidate Recommendation (CR)

A Group must obtain approval from the XSB to promote a Work Product to Candidate Recommendation. The Group must demonstrate that feedback received during the PWD process has been documented and considered by the Group. Feedback received that was rejected by the Group, for whatever reason, should be documented and the rationale for not acting on this feedback should be noted.

The XSB shall notify the XII BoD and other XII Groups of a revision to a Candidate Recommendation (CR).

8.5.3 Call for Implementations

A Call for Implementations shall issue once a Work Product reaches the level of Candidate Recommendation (CR).

The XII Technical Lead shall announce a Call for Implementations to the XII Membership and Public.

A Call for Implementations may identify specific features of the Work Product as being “features at risk”. A reviewer may register a written Formal Objection to any feature identified as at risk, stating the specific use case or rationale for the Group to consider in making its final determination for such features.

The Call for Implementation shall indicate the minimum time the Group will accept comment.

The Work Product may change based upon feedback from market implementation experience. 

8.5.4 Requirements for Proposed Recommendation (PR)

At this step, the Group seeks endorsement of the stable work product. The outcome of this review is taken as an indication of the Groups support for the work product.

A Proposed Recommendation, once approved, is announced to the XII Members and Public with a request for review. The announcement must include a review period of at least 45 days.

During this review period the Group is encouraged to request endorsement and support from XBRL Participants, projects and vendors which endorse the Work Product.

The XSB shall notify the XII BoD and other XII Groups of a revision to a Proposed Recommendation (PR).

8.5.5 Publication of a XII Recommendation (REC)

XII issues a Recommendation when it believes that the Work Product has progressed in maturity and has received sufficient opportunity for XII Member and public review. Recommendation Work Products are appropriate for widespread deployment and substantially provide the features detailed in the requirements document.

Prior to approval of Work Product as Recommendation (REC), it shall have satisfied the following minimum criteria.

· Publication of Public Working Draft(s).

· Movement through work progress statuses meeting the requirements of each step.

· Call for Implementations.

· Call for Review as a Proposed Recommendation.

The XSB shall notify other XII Members and the public of revisions to a Recommendation (REC).

8.5.6 Returning a Work Product to a Group for additional work

A Work Product may be returned to a Group for further development in the following situations:

1. The Group makes substantive changes to the Work Product at any time prior to Publication as a Recommendation, except when the changes involve removal of features at risk as identified in the Call for Implementations. In the case of substantive changes the Group must republish the Work Product as a Working Draft.
2. The XSB requires the Group to address important issues raised during a review or as the result of implementation experience. In this case the XSB may request that the Group republish the Work Product as a Working Draft, even if the Group has not made substantive changes.

The Group may recommend to the XSB a more direct route to reach PR and Recommendation status based upon the type and level of changes made to the work product. The XSB may request additional exposure steps or further streamlining of the maturity stages, however all required approvals (XSB and/or XII BoD) and minimum timelines for review must be honoured.

8.6 Ending development of a Work Product

Work Product development may cease prior to reaching Recommendation or Final Group Note status at the recommendation of the Group to the XSB or vice versa. If the XSB decides to discontinue work on a Work Product for any reason prior to its completion, the incomplete Work Product should be published as a Working Group Note.

8.7 Modifying an XII Recommendation (REC)

XII works to maintain its Recommendations (e.g., by tracking errata, providing test applications, and helping to create test suites) and encourages widespread implementation. The following sections deal with providing clarifications and correcting errors and the process for making normative changes to a Recommendation.

8.7.1 Errata Management

Tracking errors and requests for clarification are a critical part of the ongoing care of a Recommendation. The Charter of a Group should allow time for work after publication of a Recommendation to receive additional feedback from the market, or a plan for such activities upon the attainment of Recommendation status.

Groups must track errata internally in a list of enumerated error reports, including action taken on each item, including no action proposed.  

8.7.2 Classes of Changes to a Recommendation

There are 4 classes of change to a Work Product at Recommendation.

1. No changes to text content

These changes include fixing broken links or invalid mark-up.

2. Corrections that do not affect conformance

Editorial changes or clarifications that do not change the technical content of the specification.

3. Corrections that MAY affect conformance, but add no new features

These changes may affect conformance to the Recommendation. A change that affects conformance is one that:

a) turns conforming data, processors, or other conforming agents into non-conforming agents, or

b) turns non-conforming agents into conforming ones, or

c) solves an ambiguity or under-specified part of the specification in such a way that an agent whose conformance was once unclear becomes clearly conforming or non-conforming.

4. New features

The first two classes of change do not require technical review of the proposed changes, although a Group may issue a Call for Review. The modified Recommendation is published upon approval by the XSB. The publication must include a both a normative version of the Work Product that includes the accumulated effect of all the changes resulting from errata corrections, and a marked up version indicating the details of the changes resulting from errata corrections compared against the original Recommended version of the Work Product.

For the third class of change, the following is required:

a) Review by XBRL Members and the Public to ensure the technical soundness of proposed corrections.

b) Timely publication of the edited Recommendation, with corrections incorporated.

For this third class of change, the Group must request that the XII Technical Lead issue a Call for Review of an Edited Recommendation.

For the fourth class of change (new features), a Group must follow the full process of Promoting a Work Product to Recommendation.

8.7.3 Call for Review of a Proposed Edited Recommendation (PER)

Upon recommendation of a Group and approval by the XSB the XII Technical Lead must announce a Call for Review for any Proposed Edited Recommendation to the XII Members and Public. In the request to advance to this status, the Group must report any substantive issues about the Work Product that are not resolved. The announcement must indicate that this is a proposal to edit a Recommendation and must also include:

a) A specific deadline to submit review comments – no less than 4 weeks is permitted

b) Submission options;

c) Known dependencies;

The Technical Lead must verify the Group has fulfilled the same criteria as a Call for Review of a Proposed Recommendation. 

During this review period the Group responds to comments from all parties, documents the review comments and action for each, including no action.

8.8 Rescinding an XII Recommendation (REC)

XII may rescind, by recommendation of a Group to the XSB or by the XSB itself, an entire Recommendation for any reason.  A recommendation to rescind a recommendation must be approved by the XII BoD.

To deprecate part of a Recommendation, the process for modifying a Recommendation is followed. 

Once a Recommendation has been rescinded, future Work Products may not include normative references to that Work Product.

8.8.1 Proposal to Rescind a Recommendation (REC)

Once approved, the XII Technical Lead must announce the Proposal to Rescind a Recommendation to XII Members and the Public. The announcement must clearly indicate that this is a Proposal to Rescind a Recommendation and include:

a) A specific deadline to submit review comments – no less than 4 weeks is permitted

b) Submission options;

c) Known dependencies;

d) During this review period the Group responds to comments from all parties, documents the review comments and action for each, including no action.

During the review period, the Group solicits and responds to comments from XBRL Members, other XII Groups, and the Public.

8.8.2 Publication of a Rescinded Recommendation (REC)

The XII Technical Lead, after all required review and approvals, must announce the Publication of a Rescinded Recommendation to the XII Members and Public.

---