Practice Working Group and Work Product Processes

30 May 2008

Copyright © 2008 XBRL International Inc., All Rights Reserved.

This version (non-normative):

BPB-WG-Processes-Draft-2008-05-30.htm

Editors:

Walter Hamscher, Standard Advantage (walter@hamscher.com)

Contributors - Interim Best Practices Board Members and Staff:

Ignacio Boixo, Banco de España (boixo@bde.es)

Mark Bolgiano, XBRL US, Inc. (mark.bolgiano@xbrl.us)

Lars Dyrner, KPMG (ldyrner@kpmg.dk)

Tony Fragnito, XBRL International, Inc. (tonyf@xbrl.org)

Makoto Koizumi, Fujitsu Ltd. (koizumi.makoto@jp.fujitsu.com)

Diane Mueller, Justsystems (diane.mueller@justsystems.com)

Yossef Newman, Deloitte (ynewman@deloitte.com)

Ken Shipman, Deloitte (kshipman@deloitte.com)

Bill Swirsky, CICA (bill.swirsky@cica.ca)

Hugh Wallis, XBRL International, Inc. (hughwallis@xbrl.org)

Mike Willis, PricewaterhouseCoopers (mike.willis@us.pwc.com)

---

Status

Circulation of this Internal Working Draft is restricted. Other documents may supersede this document. Recipients are invited to submit comments to bpb@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Abstract

This document formally defines the organisation, processes, work products and terminology needed for the effective operation of all practice working groups (PWG) of the Best Practices Board (BPB). It is largely based on the proven organization and processes of the XBRL International Standards Board (XSB).

Contents

1 Introduction

2 Organisational components and their interrelationships

3 Definitions

4 PWG life cycle and internal processes

4.1 PWG eGroups

4.2 PWG Formation

4.3 PWG Chairs and Vice-Chairs

4.4 PWG Transparency

4.5 PWG Procedure

4.6 PWG Meetings

4.7 PWG Charter Clarification

4.8 PWG Rechartering

4.9 PWG Voting

4.10 PWG Subcommittees

4.11 Closing a PWG

4.12 Intellectual Property Rights Procedures

4.13 Work Product Formatting

5 Work product life cycle

5.1 Components of a Work Product

5.2 Maturity Levels

5.3 Document Naming

5.4 General Requirements for Promotion

5.5 Reviews and Review Responsibilities

5.6 Returning a Work Product to a PWG

5.7 Ending Work on a Work Product

5.8 Modifying a (Public) Note

A References

B Intellectual property status (non‑normative)

C Acknowledgements (non‑normative)

D Document history (non‑normative)

E Errata corrections in this document

Figures

Figure 1: BPB Composition and Relationship to the ISC and PWGs

Figure 2: PWG Formation Process

Figure 3. Membership States

Figure 4. Work Product Maturity Levels and Transitions

---

1 Introduction

The goal of this document is to formally define the organization, processes and terminology needed for the effective operation of all practice working groups (PWG) of the Best Practices Board (BPB). The definitions are based on the proven organization and processes of the XBRL International Standards Board (XSB). There are three main views of the subject matter of this document:

1. Organisational components and their interrelationships

This view addresses the different types of groups of individuals that participate in the work product development process and how they relate to each other. It includes the different types of Practice Working Group (Permanent and ad hoc) and how they relate in their activities to each other and to other bodies such as the BPB, XSB, ISC, etc.

2. PWG life cycle and internal processes

This view addresses how PWGs are formed, who participates in them and in what capacity, how their day to day business is to be conducted and how they are wound up when their work is complete.

3. Work Product life cycle

The output of PWGs is generally a “work product”. Each such work product goes through a set of stages. These views address those stages and how work product progresses between them.

2 Organisational components and their interrelationships

With the formation of the BPB the organisational structure represented in Figure 1 was approved. This structure provides the framework in which to understand the rest of this document.

Figure 1: BPB Composition and Relationship to the ISC and PWGs

The BPB derives its authority from the ISC and the by-laws of the corporation make this explicit. To emphasise that fact, the term “ISC” is used in this document to describe various activities and responsibilities that are actually discharged by the BPB. The remaining parts of this report are to be understood in that context. In general, responsibilities that will be discharged by the BPB are identified as such to make the operational aspects clear but in all such cases it is to be remembered that the BPB is simply acting as an agent of the ISC. At times it is necessary to distinguish between activities and responsibilities that are discharged by the BPB or the ISC and this is done by use of the appropriate acronym where required.

While this process imposes certain requirements on PWG Chairs and Vice-Chairs, the BPB is committed to supporting the activities of the PWGs and ensuring their success. This is achieved by expediting the addressing of requests and communications from the PWGs; providing staff resources for liaison and guidance in the implementation of the processes and procedures wherever necessary, and proactive communication between the BPB and PWG leadership.

3 Definitions

This section provides the definitions of terms used elsewhere in the document.

Term	Definition
Administrator	The person or persons representing XII in respect of PWG related administrative matters.
Charter	The document that defines the terms of reference for a PWG. It should contain at least the items included in the proposal to form that PWG. See sections 6.2 and 6.11.
Director	The Practices Director, a member of the XII Staff.
eGroup	An electronic discussion list owned and managed by XII.
Entitled Person	Someone who is either an XBRL Participant or who has been deemed by ISC or the XSB to be entitled to the same privileges as an XBRL Participant in respect of the processes defined herein.
IP Policy	XII Intellectual Property Policy at http://www.xbrl.org/legal/
Leave of Absence	During a Leave of Absence, a Voting Member is exempt from the participation criteria.
Majority Vote	A vote in which the number of “yes” votes cast is greater than the number of “no” votes cast without counting abstentions. For example, in a quorate PWG Meeting in which 16 Voting Members are present, if 6 vote “yes” and 3 vote “no”, the motion passes.
Member of a PWG	An Entitled Person who subscribes to the PWG eGroup list, and is permitted to attend PWG Meetings. They are allowed to post messages to the PWG eGroup list, to speak in PWG Meetings and to make Contributions to the PWG.
Minimum Membership	Five Voting Members of a PWG representing at least three XBRL member organisations.
Observer	An Entitled Person who subscribes to the PWG eGroup list, and is permitted to attend PWG Meetings. They are not allowed to post messages to the PWG eGroup list, or speak in PWG Meetings except by invitation of the chair, or make Contributions to the PWG. See section 6.4.
Primary Representative	An employee of an organisation registered in the records of XII or the relevant XBRL jurisdiction as primary representative.
Proper Majority Vote	A PWG vote in which more than 50% (more than half) of the Voting Members vote “yes”, irrespective of the number of Voting Members present in the meeting and not counting abstentions. For example, suppose that in a PWG there are 16 Voting Members, then at least 9 Voting Members must vote “yes” in order for a motion to pass.
Public (Publicly)	All people, whether XBRL Participants or not.
PWG Meeting	A meeting of the PWG that is properly called and scheduled in advance.
PWG Organiser	An Entitled Person who performs the function of organizing the first meeting of the PWG.
PWG Subcommittee (PWGSC)	A group of Members of a PWG producing work product for consideration or adoption by the parent PWG.
PWG Working Draft	Any version of work product (such as a specification or a taxonomy or best-practice guidance material) of the PWG which has not yet received any level of approval from the PWG.
Quorate PWG Meeting	A PWG Meeting at which a quorum is present. A meeting that is not quorate is “inquorate”.
Quorum	The number of Voting Members of a PWG that must be present in a PWG Meeting so that Resolutions and decisions may be made. The Quorum for PWG Meetings is a majority (more than half) of Voting Members.
Resolution	A decision reached by a PWG as a result of a vote. Resolutions require a Majority Vote to pass, unless the process dictates that a Proper Majority Vote or Super-Majority Vote is necessary.
Substantive Change	A change to Work Product that would be likely to cause a user in the audience of the work product to use XBRL differently.
Super-Majority Vote	A PWG 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 PWG Meeting, without counting abstentions. For example, in a PWG in which there are 18 Voting Members, at least 12 Voting Members must vote “yes” for a motion to pass in a Super-Majority Vote; but if 5 or more vote “no” then the motion fails. All Super-Majority Votes must be conducted by the Administrator.
Voting Member	A Member of a PWG who may vote in the PWG.
XII Member Organisation	A firm that is a member of a Jurisdiction, or a direct member in XII.
XII Participant	A person that is an employee of a firm that is an XBRL member organisation or an individual, academic or other category of member of a Jurisdiction, where the appropriate Jurisdiction has such category.
Request for Comment (RFC)	A work product providing information about practices and techniques to XII members or the public, and that may evolve continually based on experience.
Note (NOTE)	A work product suggesting methods or practices to XII members or the public and that reflects a stable consensus based on experience.

4 PWG life cycle and internal processes

To provide a framework in which PWGs can function effectively the following aspects must be taken into consideration:

· A PWG has a start, a middle and end to its existence. This is true for all PWGs even those designated as “standing” PWGs by the BPB although in those cases the “end” is not specifically anticipated at the start. Most PWGs are wound up once they have finished producing the work product for which they were formed.

· Individuals interact with PWGs either as “members” or in some other capacity. Certain criteria are applied to determine the capacity in which any individual that interacts with a PWG does so.

· PWGs need leaders. These are denoted in Figure 1 as Chair and Vice-Chair.

· To conduct business and make decisions PWGs communicate electronically and in person as well as holding more or less regular meetings. These must follow certain rules.

· To ensure that the work product of PWGs conforms to any legislation or requirements generated as a result of patent claims etc. there must be certain safeguards in place.

· There are two ways in which PWGs can be formed. One is at the instigation of the BPB and the other is at the instigation of a group of members. In both cases the BPB is responsible for approval of the formation of the PWG. The BPB will apply criteria as it sees fit in making this determination but which shall include the consideration and assessment of

· a) the appropriateness of the proposed PWG activities in the context of the XII standards setting strategy and

· b) the availability and commitment of resources to perform the proposed activities.

The following paragraphs describe in detail the stages in the PWG lifecycle. In summary, however, they are as follows:

1. Formation

A charter is prepared by individuals identified by the BPB and approved by the BPB. XII Participants may request the BPB to initiate a charter.

2. Conducting business

Once the PWG is chartered it conducts business using a combination of its eGroup, telephone conference calls and face to face meetings. It may create subcommittees to perform sub tasks as it sees fit. It creates work product according to the Work Product Life Cycle as defined below. It reports regularly to the BPB so that its work can be monitored and guided within the overall strategy of XII as appropriate.

3. Closing

Once the PWG has completed the business for which it is chartered it prepares and publishes a final report and is closed by the BPB.

4. Rechartering

At times it maybe appropriate for a PWG that has completed (or partially completed) the business for which it was originally chartered to be re-chartered to conduct “follow on” business that is substantially of the same scope as that for which it was originally chartered but which is necessary to reflect changed circumstances. Such changed circumstances may include:

· Experience being gained in actual implementation of its original work product

· Identification of an expanded scope that is closely related to the original scope (although the BPB will take considerable care to ensure that this is not simply “scope creep” but is, indeed necessary – at times a new PWG might be formed rather than the old one being rechartered)

· Publication of new XBRL specifications or other work products

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

Figure 2: PWG Formation Process

4.1 PWG eGroups

The BPB may authorize three or more Entitled Persons to begin an eGroup for the purpose of proposing the formation of a PWG. No more than two of the minimum number of three may be employees of the same XBRL Member Organisation. The Administrator must receive the following items:

· The name of the eGroup. This must not be the same as the name of the eGroup that the PWG itself shall use if formed.

· The names, e-mail addresses and membership affiliations of the three or more Entitled Persons proposing to create the eGroup.

· The name of the eGroup leader(s).

· A draft statement of scope for the PWG.

Within 15 days of receiving the submission, the Administrator shall provide these materials to the membership and issue a “Call for Participation” (CFP) inviting members to subscribe to and participate in the eGroup.

Discussion on the eGroup is restricted to evaluating the interest in proposing a new PWG, and defining the proposal for one or more new PWGs. The list of subscribers to the eGroup shall be available to all subscribers subject to any relevant privacy legislation. The eGroup shall automatically close 90 days after the CFP is issued.

4.2 PWG Formation

The BPB may authorise any group of at least Minimum Membership to form a PWG by submitting to the Administrator the following items, written in English and provided in electronic form. The proposal shall not have any additional information other than that described below.

The Charter of the PWG, which includes only the following items:

· The name of the PWG. This name must not have been previously used for any PWG and must not include any trademarks or service marks not owned by XII. It is subject to Administrator approval and 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 refer to the PWG.

· A statement of purpose, including a definition of the problem to be solved.

· The scope of the work of the PWG, which must be relevant to the mission of XII. This must include a definition of what is and what is not the work of the PWG, and how it can be determined when the work of the PWG has been completed.

· The scope may include a specific contribution of existing work as a starting point. Other contributions may be made by Members on or after the first PWG Meeting of the PWG. Such other contributions must be considered by the members of the PWG on an equal basis to improve any original starting point contribution.

· A list of deliverables, with projected completion dates.

· The expected audience or users of the work.

Additional information regarding the start up of the PWG, which must include:

· Identification of similar or applicable work that is being done in other PWGs or by other organisations, why there is a need for additional work in this area and how the proposed PWG will be different, and what level of liaison will be sought with such other organisations. (Required)

· The date, time, and location of the first PWG Meeting, whether it will be held in person or by phone. The first PWG Meeting of a PWG must occur within 30 days of the announcement of its formation in the case of a telephone or other electronic PWG Meeting, and within 45 days after the announcement of its formation in the case of a face-to-face PWG Meeting.

· The projected on-going PWG Meeting schedule for the year following the formation of the PWG, or until the projected date of the final deliverable, whichever comes first.

· The names, e-mail addresses, and membership affiliations of at least Minimum Membership who support this proposal and are committed to the Charter and projected PWG Meeting schedule.

· The name of the PWG organiser who must be an Entitled Person.

The additional information regarding the start up of the PWG may include:

· A list of contributions of existing work that it is anticipated will be made to this PWG.

· A proposed working title and acronym for the work product(s) to be developed by the PWG.

The Administrator will then provide these materials to the XII membership with a CFP and an announcement of a first PWG Meeting.

4.2.1 First Meeting of a PWG

At least 15 days prior to the first meeting of the PWG, Entitled Persons who intend to participate in the first PWG Meeting must register as a Member by sending an e-mail to the PWG organiser, copying the Administrator, and specifying whether they intend to gain voting rights.

If the Entitled Person is an employee or designee of an XII Member Organisation, they must confirm to the Administrator that they have permission of that organisation to participate in the PWG and that the organisation agrees to abide by the IP policy in respect of their participation. Upon receiving such confirmation, the Administrator will provide a copy thereof to the Primary Representative.

Every Entitled Person who has so registered and been confirmed will be a Member of the PWG effective from the date of the first PWG Meeting. Every Entitled Person who has so registered, requested voting rights, been confirmed, and is present at the first PWG Meeting of a PWG will be a Voting Member of the PWG effective from the date of the first PWG Meeting. Persons who register to attend the first PWG Meeting but do not attend must notify the PWG Chair after the first PWG Meeting to become a Member of the PWG, as described below.

The first PWG Meeting of a PWG must take place when, where and how it has been described in the announcement. Any first PWG Meeting whose time or location is changed and any initial telephone or other electronic PWG Meeting that fails to grant access to every Entitled Person previously registering to attend shall be subject to appeal to the BPB.

At least Minimum Membership must become Voting Members at the first PWG Meeting or the PWG shall be considered not to have been successfully started and shall be closed.

At the first PWG Meeting the PWG must suggest the name of a Chair and Vice-Chair to the BPB as the first order of business, from among nominations made by Voting Members at that PWG Meeting. The BPB will consider the request as soon as practical thereafter and either confirm those individuals in their roles or appoint alternative individuals from among the Voting Members of the PWG. Once the Chair is appointed by the BPB, then the role of PWG Organiser ends. The PWG Organiser acts as Chair until that appointment has been made.

4.2.2 PWG Membership and Participation

PWG membership is on an individual basis, not on a per organisation basis. PWG membership may not be transferred from person to person. No individual may attend a PWG Meeting unless they fall into one of the following categories.

4.2.2.1 Voting Member

After the first meeting of a PWG, a Member shall obtain voting rights at the close of the second consecutive PWG Meeting attended by the Member or 60 days after the person becomes a Member, whichever comes first.

A Voting Member must remain active in a PWG to maintain voting rights. A Voting Member who is absent from three consecutive PWG Meetings or six weeks which ever is the longer period of time (as recorded in the minutes) loses his or her voting rights at the end of the second PWG Meeting missed. Being absent “for six weeks” means that a Voting member has not attended any meetings in a period of six calendar weeks PLUS has been absent for the first meeting AFTER the six week anniversary of the most recent meeting they have attended. Thus, by way of example, if meetings are held every two weeks, missing four consecutive meetings is the same as being absent for six weeks. If they are held every three weeks then missing three consecutive meetings is equivalent to being absent for six weeks. In any doubtful or ambiguous circumstance (such as considering the timing of the meetings during a particular day or the effect of daylight savings time etc.) the rule shall be interpreted in favour of the member retaining their voting rights.

A Member who has lost his or her voting rights may regain them by attending two consecutive PWG Meetings (as recorded in the minutes), thus regaining voting rights after the end of the second PWG Meeting attended. A Member of a PWG that does not hold two PWG Meetings within a 60 day period may regain voting rights by making a request to the chair(s) to regain them, effective 60 days after the request.

Voting Members who lose their voting rights remain Members of the PWG. The Chair may send a warning to the Member, but the loss of voting rights is automatic and the sending of a warning is not a requirement.

4.2.2.2 Member

Any time after the first PWG Meeting, an Entitled Person may become a Member of an existing PWG by registering as a Member. A member of the BPB is automatically a member of all PWGs. If the Entitled Person is an employee or designee of an XII member organisation, they must confirm to the Administrator and the PWG Chair that they have permission of that organisation to participate in the PWG and that the organisation agrees to abide by the IPR policy in respect of their participation. Upon receiving such confirmation, the Administrator will provide a copy thereof to the Primary Representative of that organisation. Upon receipt by the Chair of this confirmation the Member may begin participating, but shall not have voting rights. A Member shall become eligible to vote in the PWG when the requirements described above are met.

4.2.2.3 Observer

An Entitled Person may become an Observer of a PWG by registering as such, but this is rarely necessary or desirable since it means that the organisation of the Entitled Person is unwilling to adhere to all aspects of the IPR policy. The Observer is not a Member of the PWG. There are therefore no attendance or participation requirements in order to maintain this status. To become an observer they must send an e-mail to the PWG organiser or Chair (depending on the status of the PWG at the time), copying the Administrator. If the Entitled Person is an employee or designee of an XII member organisation, the Administrator will inform the Primary Representative of that organisation that the person has requested to become an Observer.

Figure 3. Membership States

4.2.2.4 Termination of PWG Membership

Termination of membership in a PWG shall occur under the following conditions:

A Member is considered to have resigned from a PWG upon their sending notification of resignation to the PWG eGroup.

Persons who lose Entitled Person status for reasons including, but not limited to, change of employment have up to 30 calendar days of PWG membership as an Individual Member in which to request a Leave of Absence or re-establish eligibility. A Member loses PWG membership on the 31st day after losing Entitled Person status or at the end of a Leave of Absence requested if Entitled Person status has not been re-established.

The Chair may, after giving due warning, terminate the membership of any individual who behaves in an unprofessional manner. This includes but is not limited to use of abusive or foul language, spamming of the mailing list, harassment of other members etc. Any such individual whose membership is so terminated may appeal against the termination to the BPB.

Termination of membership in a PWG shall automatically end voting rights in the PWG as well as membership in any PWG Subcommittee of that PWG.

4.2.2.5 Leaves of Absence

Every Voting Member of a PWG is allowed at least one Leave of Absence during any one twelve month period. During a Leave of Absence, a Voting Member is exempt from all participation criteria. A first Leave of Absence during any one twelve month period is granted automatically upon application to the Chair of the PWG. The Chair must notify the PWG of any Leave of Absence by reporting it in the minutes of the first PWG Meeting following the granting of that Leave of Absence.

A Voting Member who has already taken a Leave of Absence during any twelve month period may apply for a maximum of one additional Leave of Absence during the same twelve month period, but a second Leave of Absence during any twelve month period can be granted only upon formal Resolution of the PWG.

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

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 was submitted to the Chair of the PWG and shall end on the date specified, or at the beginning of the first PWG Meeting or PWG Subcommittee PWG Meeting attended after the Leave begins, or upon transmittal of the first mail ballot returned after the Leave begins, whichever comes first. Time allocated for a Leave of Absence but not used due to early resumption of participation cannot be carried over into another Leave.

4.3 PWG Chairs and Vice-Chairs

Each PWG must have a Chair and a Vice-Chair. Only Voting Members of the PWG are eligible to be Chair, Vice-Chair or co-Chair. The initial PWG Chair and Vice-Chair are appointed by the BPB. If the PWG does not have a Chair and does not have a Vice-Chair then all PWG activities, with the exception of the selection of a new Chair and/or Vice-Chair, are suspended.

The responsibilities of Chair of a PWG may be discharged by no more than two co-Chairs at the discretion of the BPB (although having co-Chairs is only to be implemented in unusual circumstances as it is not considered a desirable way of organising PWGs – having a Vice-Chair fill the role of Chair in the absence of the Chair is preferred). In the event that the Chair position is so shared each co-Chair is equally responsible for the Chair duties and responsibilities. Throughout this PWG Process, whenever a notification to the PWG Chair is required this must be made to both co-Chairs.

A PWG Chair or Vice-Chair may be removed by the BPB or by a Super-Majority Vote of the PWG. In the event that a PWG has co-Chairs each may be removed individually or both may be removed by a single action.

A vacancy in chairing a PWG shall be deemed to exist when (i) the Chair or one or both co-Chairs has been removed, (ii) the Chair or one or both co-Chairs has resigned the position, or (iii) the Chair or one or both co-Chairs ceases to be a member of the PWG. Vacancies in chairing a PWG shall be filled by the BPB from the membership of the PWG.

The same provisions regarding Leaves of Absence shall apply to the Chair or co-Chair of a PWG as to the other members of a PWG, except the Chair must notify both the Administrator and the PWG 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.

The Vice-Chair carries out all the duties of the Chair in the Chair’s absence. Where a PWG is expected to continue its work for a period of more than 12 months the PWG should consider annually any changes to the Chair or Vice-Chair and advise the BPB of its recommendation. The BPB will then determine what, if any, changes are to be made.

4.4 PWG Transparency

The official copies of all resources of the PWG and its associated PWG Subcommittees (PWGSCs), including web pages, documents, eGroup lists and any other records of discussions, must be located only on facilities designated by PWGs and PWGSCs must not conduct official business or practices discussions, store documents, or host web pages on servers or systems not designated by XII.

In the event of PWG members hosting non-XBRL International websites pertaining to the subject matter being addressed by the PWG they must indicate clearly that the site is not an official XBRL International PWG website and they must also ensure that no work product of the PWG that has not been authorised for publication is displayed on that website. All web pages, documents, ballot results and eGroup archives of all PWGs and PWGSCs must be available to all XII members upon request to the Administrator.

4.4.1 eGroups

Upon formation each PWG 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 PWG.

The minutes of each PWG Meeting and a record of all decisions must be published to that PWG’s general eGroup list on a timely basis, and at least 2 working days before the next PWG Meeting. All official communications and non-verbal discussions of the PWG must take place on the eGroup list. All PWG eGroup lists shall be archived for the duration of the consortium, and all PWG eGroup archives shall be available to all XII members upon request to the Administrator.

The reason for a PWG 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 PWG including the PWG Chair. PWGs are not required to respond to comments. Comments to the PWG made by Members of the PWG must be submitted via the PWG general eGroup list, and comments made by non-WG members, including from the public, must be made via the PWG’s comment facility. Comments shall not be accepted in any other way

4.4.2 Collaborative Workspace

The Administrator shall provide the PWG with an online workspace for collaboration, file storage, calendaring functions etc. The PWG must keep the following information current in the PWG collaborative workspace: the PWG name and Charter; standing rules and other adopted procedures; PWG 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 PWG Chair or co-Chairs and Vice-Chair as well as any other important positions that may have been created by the PWG; list of PWG Subcommittees, their deliverables, and members; draft and completed PWG documents with identification of the most recent versions of the PWG’s work product; and copies of the IPR declarations for that PWG.

4.4.3 Announcements

The Administrator shall create an archived list for announcements from the Administrator regarding PWGs. Any Entitled Person shall be eligible to subscribe to this list. Every important change in PWG status will be posted to the announcement list; such changes including but not limited to the following: PWG formation; PWG Charter revision; announcements of any change in the status of PWG work product as it passes through the Work Product Life Cycle; and closure of a PWG.

4.5 PWG Procedure

The operation of PWGs shall be governed by Robert’s Rules of Order Newly Revised, insofar as such rules are not inconsistent with or in conflict with this PWG Process, the XII IP Policy, the XII Bylaws, other BPB-approved policies, or with provisions of law. The duration of a PWG shall be considered a single session. The official language of all PWGs shall be English with all written material being in UK English. Members of PWGs who wish to communicate with each other on PWG 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 PWG members and other XBRL Participants.

Standing rules may be adopted by Proper Majority Vote of the PWG. The PWG may not adopt standing rules or other Resolutions related to Intellectual Property Policy, quorum requirements, membership, voting, participation, or that otherwise conflict with or supersede any XII policy. Standing rules must be communicated to the BPB, who may override them if they conflict with XII policy. They must also be published in the PWG’s collaboration tool.

4.6 PWG Meetings

PWG 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 PWG’s eGroup. PWG Meetings scheduled or conducted so as to exclude any Member are subject to appeal to the BPB. PWG Meetings may be conducted face-to-face or via telephone conference or other electronic media that allow participation of all Members of the PWG. PWG Meeting minutes must be recorded and published to the PWG’s eGroup and archived in the PWG’s collaboration tool.

If a PWG Meeting is inquorate then 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 PWG. Attendance must be recorded in the PWG Meeting minutes. Inquorate PWG Meetings shall nevertheless count towards attendance for purposes of Members gaining, maintaining, or losing voting rights.

4.7 PWG Charter Clarification

A PWG may clarify its Charter only to remove ambiguity or to narrow the scope of the topic defined by the Charter. The PWG must not broaden or otherwise change its scope of the topic of work without BPB approval. This is not considered “Clarification” but is “Rechartering”. The list of deliverables may be expanded only if the new deliverables are within the scope of the topic.

Approval for clarification requires a Super-Majority Vote of the PWG. The clarification of the Charter may occur no earlier than the first PWG Meeting of the PWG. The PWG Chair shall notify the Administrator that a motion has been made to clarify the Charter, and the Administrator shall set up and conduct the ballot.

The Administrator may prevent the proposed clarification from coming to vote if it is not in conformance with XII policies. The Administrator must within 15 days either open the ballot or reply to the PWG with the reason why the change cannot be voted upon. In the event of the latter circumstance occurring, the mover of the motion to be voted on may appeal the Administrator’s decision to the BPB. The clarified Charter shall not take effect until approved by the BPB and announced by the Administrator. The Administrator must publicise approved changes in the same manner as the initial formation of the PWG is publicised.

4.8 PWG Rechartering

A PWG may be rechartered for purposes of expanding the scope of the PWG. The PWG shall retain the name of the predecessor, and all eGroups and archives, collaboration tools, etc. shall be transferred from the predecessor PWG to the rechartered PWG. However, any Contributions made to the previous PWG must be recontributed.

A proposal to recharter the PWG must be submitted to the Administrator. This proposal shall be in all respects the same as a proposal to form a new PWG with the exception that the PWG name must be the same as the predecessor PWG. The Administrator shall reply to the proposers within 15 days, and if the proposal is complete shall schedule a ballot. Approval for rechartering requires a Super-Majority Vote of the PWG being rechartered and ratification by the BPB. Upon approval of the ballot and ratification by the BPB, the Administrator shall announce the newly rechartered PWG in the same manner as a new PWG. Membership in the rechartered PWG shall be determined in the same manner as for a new PWG. The predecessor PWG shall be closed at the end of the day prior to the date of the first PWG Meeting of the rechartered PWG. The time period for determining Members’ Participation Obligation shall restart at the first PWG Meeting of the new PWG.

4.9 PWG Voting

PWG votes require a Majority Vote to pass, except as noted elsewhere in this Process. All PWG ballots requiring a Super-Majority Vote for approval must be conducted by the Administrator. The PWG Chair must notify the Administrator that a motion has been made that requires a Super-Majority Vote, and the Administrator will set up and conduct the ballot.

4.9.1 Eligibility

A Member of a PWG 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 PWG has a single vote. Organisations do not vote in PWGs. Proxies are not allowed in PWG voting.

4.9.2 Electronic Voting

PWGs may conduct electronic ballots, either by using the PWG’s eGroup list or any other electronic voting functionality provided by XII. The minimum period allowed for electronic voting shall be seven calendar days; the PWG may specify a longer voting period for a particular electronic ballot.

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

4.10 PWG Subcommittees

The PWG may by Resolution create a PWG Subcommittee (PWGSC). The Resolution must be minuted, and must include the name, statement of purpose, list of deliverables, and name of the Chair of the PWGSC. All of these items must fall within the Charter of the PWG and conform to XII policy.

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

4.11 Closing a PWG

A PWG may be closed by Proper Majority Vote of the PWG, by Resolution of the BPB, or by the Administrator.

The Administrator must close a PWG that has completed the deliverables listed in its Charter if the PWG does not add new deliverables.

The Administrator may close a PWG that

· fails to conduct at least one Quorate PWG Meeting during any six month period; or

· whose membership falls below the Minimum Membership; or

· 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.

4.12 Intellectual Property Rights Procedures

The PWG 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 Administrator, who shall post the disclosure in the PWG’s collaboration tool and notify the PWG via the PWG eGroup. The PWG 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 PWG’s eGroup either the contribution, or a notice that the contribution has been submitted to the PWG’s document repository; a URL or other reference is not adequate. Written contributions must be converted to electronic format and submitted to the PWG’s eGroup or collaboration tool. The PWG is not required to acknowledge or use any Contribution.

Additionally a call for claims must be made at the start of every PWG 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 XBRL International Intellectual Property Policy (XIIIPP). 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 PWG Meeting.

Every published agenda for PWG Meetings shall also contain the following text:

“This PWG Meeting is open to XBRL Participants and individuals who have been deemed by ISC or the BPB to be entitled to the same privileges as an XBRL Participant in respect of PWG Meeting attendance only. PWG Meeting attendees are bound by the XBRL International Intellectual Property Policy (XIIIPP). 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 this 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 PWG Chair.”

4.13 Work Product Formatting

All documents and other files produced by the PWG must use the XII file naming scheme, and must include the XII copyright notice. All document files must also use the XII document templates. The name of any work product must not include any trademarks or service marks not owned by XII.

The work product must include a list of people who participated in its development. This list shall be initially compiled by the Chair, and any Member of the PWG may add or remove their names from the list by request. The final list shall be approved by the Chair and Vice-Chair 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 PWG, 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 may appeal to the BPB.

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

All machine-processable addenda such as sample XBRL files that are part of the work product 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.

All files in an archive files in zip format must be under a root folder whose name is the same as the base name of the archive itself. For example, Note42.zip must unzip to folder Note42.

A 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 PWG 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.

5 Work product life cycle

The BPB Work Product development process is the set of steps and requirements followed by BPB PWGs in the production of the work products for which they have been chartered. The processes followed by a PWG to manage Requests for Comment (RFCs) and Practice Notes (NOTEs), called Work Products, include:

· Advancing from early draft RFC to Public RFC; this is called the XII RFC path.

o Ending work on an RFC before it reaches Public RFC

o Revising an XII RFC

· Advancing from early draft NOTE to mature Public NOTE; this is called the XII NOTE path.

o Ending work on a NOTE before it reaches Public NOTE

o Revising an XII NOTE

o Deprecating a Public NOTE no longer endorsed by XII.

It is the nature of an RFC that real world experience continuously uncovers new information, and the RFC provides a medium to communicate this experience and may be revised many times. An RFC is never deprecated.

A NOTE provides an evaluation and suggested approaches given particular circumstances and consequently should have fewer revisions. A NOTE may emerge from evaluation of the information in an RFC.

The XII Work Product development process is designed to

· Ensure high content quality;

· Maximize substantive contributions to the RFC;

· Provide timely information of value to XBRL users;

· Promote consistency among NOTEs;

· Maximize consensus about the content of a NOTE;

· Obtain endorsement for NOTEs within XII and from the broader community.

The following sections describe:

1. Typical components of a Work Product

2. The maturity level of a Work Product at each step (e.g., “Working Draft”).

3. Steps of the Work Product development process (e.g. “Announcement of Last Call”).

4. Requirements for each Step

5.1 Components of a Work Product

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

Every document published as part of the Work Product development process must be a public document. XII will make every effort to make archival documents indefinitely available at their original address in their original form.

The primary language for XII technical work products is UK English. XII encourages the translation of its work products.

5.1.1 Status (mandatory)

Every document published as part of the Work Product development process must clearly indicate its maturity level.

Each Work Product must include a section about the status of the document. The status section should explain: why XII has published the Work Product; what are expectations about next steps; who developed it; where to send comments about it; whether usage experience is being sought; whether there are any significant changes from the previous version; why work on the Work Product has ceased; and any other relevant information or rationale.

5.1.2 Goal (mandatory)

Each work product must clearly state its goals, in particular: who are intended users and what benefits they may expect.

5.1.3 References (mandatory)

Descriptions of implementation techniques should always refer by URL to specific versions of XII recommendations and other work products.

5.1.4 History (mandatory)

The document history is a table that indicates the date, editor, and nature of each revision.

5.1.5 Errata (mandatory)

Once a Work Product has reached NOTE it is likely that errors (errata – singular erratum) will be discovered that need to be corrected. If it is decided that these are of sufficient importance to be publicly corrected then they will be published by the PWG. This may either be managed by the PWG responsible for the Work Product in the first place or, if that PWG has been wound up, by a “Note Maintenance” PWG that has that specific mandate.

5.2 Maturity Levels

The maturity level of a published Work Product indicates where it is in the development process. The maturity level “Working” denotes the initial state of a Work Product in the development process and revisions that are visible only to Members. The maturity levels “Public” and “Deprecated” are the possible end states.

During preparation of work products 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. Unlike the maturity levels of XSB work products, no published document is ever referred to as “working draft” nor “candidate”. The term “internal” is not used at all, since anything that is not “public” is by definition “internal”. While the terminology is different, it does reflect that because the work products are not normative and do not require independent implementation, the entire process and set of work products can be simplified.

The term “public working draft” is not used, particularly for an RFC which in a sense is always a “public draft” subject to change. The term “candidate” refers to work products that have been approved by the PWG but not yet by the BPB. The term “final” only refers to “final edits” in the sense of non-substantive, editorial polishing that may occur after a last call.

Figure 4. Work Product Maturity Levels and Transitions

5.3 Document Naming

The status of a document is indicated by the prefix of the filename, such as “RFC‑PostValidation‑2009‑02‑29” or “CD‑NOTE‑CascadingFormulas‑2010‑02‑29”.

5.3.1 Working Draft (WD-RFC or WD-NOTE)

A WD is a document that is under discussion by the relevant PWG. While it is available to any XBRL Participant who wishes to see it, it is not generally published beyond the mailing lists and files areas belonging to the relevant PWG or to certain individuals or other PWGs, possibly to obtain review and comment on specific parts of the document.

A WD is created, edited and distributed by one (or more) of the editors of the document, to the members of the PWG.

5.3.2 Candidate RFC (C-RFC)

A Candidate RFC is a WD-RFC that a PWG has decided to distribute broadly to XII Participants, but not yet to the public. This is for the purposes of obtaining feedback commentary from the general XII membership or to provide an “early look” at a document that is planned to be distributed to the general public as an RFC.

· Announcement: The Director must announce each C‑RFC to all XII Participants. The release of a Candidate is a signal to XII Participants to begin reviewing the document prior to its release to the Public.

· Entrance criteria: By a Majority Vote the PWG must pass a motion that requests the BPB to approve the publication of the C-RFC.

o In order to make Working Drafts available to a wide audience early in their development, the requirements for publication are limited to an agreement by the PWG to publish the RFC.

o This must be ratified by the BPB prior to publication.

o Consensus and completeness of a document is not a prerequisite for approval to publish; the PWG may request publication of an RFC or NOTE at any time.

· Ongoing work: The PWG will continue to revise the Work Product in accordance with its charter.

o PWGs should encourage early and wide review of work product, within and outside of XII, especially from other Working Groups with dependencies on the technical work product.

o ISC representatives should encourage review within their jurisdictions and member organizations as early as possible, and for a NOTE, well before the Last Call.

· The PWG should be responsive to and facilitate ongoing review by addressing issues in a timely manner and clearly indicating changes between versions (e.g., by providing “diffs” and summaries of substantive changes).

· Possible next steps, at the discretion of the BPB, are one or both of:

o Public RFC

o Revision, in the form of a new WD-RFC

5.3.3 Public RFC (RFC)

An RFC, once published, may be subsequently revised.

· Announcement: The Director must announce each RFC to the public and XII Participants.

· Entrance criteria: By a Majority Vote the BPB must pass a motion for promotion of a C‑RFC to (Public) RFC.

· Ongoing work: The PWG may continue to revise and issue new versions of the RFC in accordance with its charter.

5.3.4 Candidate Draft Note (CD-NOTE)

A CD-NOTE is a WD-NOTE that a PWG has decided to distribute broadly to XBRL Participants, but not to the general public. This may be for the purposes of obtaining feedback commentary from the general XII membership or to provide an “early look” at a document that is planned to be distributed to the general public as a PD-NOTE.

The BPB may deem a Candidate Draft Note satisfactory for distribution to the public.

A Candidate RFC is a WD-RFC that a PWG has decided to distribute broadly to XII Participants, but not yet to the public. This is for the purposes of obtaining feedback commentary from the general XII membership or to provide an “early look” at a document that is planned to be distributed to the general public as an RFC.

· Announcement: The Director must announce each CD-NOTE to all XII Participants. The release of a Candidate Draft Note is a signal to XII Participants to begin reviewing the document prior to its release to the Public.

· Entrance criteria: By a Majority Vote the PWG must pass a motion that requests the BPB to approve the publication of the Candidate Draft.

o In order to make Working Drafts available to a wide audience early in their development, the requirements for publication are limited to an agreement by the PWG to publish the Work Product.

o This must be ratified by the BPB prior to publication.

o Consensus and completeness of a document is not a prerequisite for approval to publish a Draft Note; the PWG may request publication of a Draft NOTE at any time.

· Ongoing work: The PWG will continue to revise the NOTE in accordance with its charter.

o PWGs should encourage early and wide review of work product, within and outside of XII, especially from other Working Groups with dependencies on the technical work product.

o ISC representatives should encourage review within their jurisdictions and member organizations as early as possible, and for a NOTE, well before the Last Call.

· The PWG should be responsive to and facilitate ongoing review by addressing issues in a timely manner and clearly indicating changes between versions (e.g., by providing “diffs” and summaries of substantive changes).

· Possible next steps, at the discretion of the BPB, are one or both of:

o Public Draft NOTE

o Public Last Call Draft NOTE (if requested by PWG)

o Revision, in the form of a new WD-NOTE

5.3.5 Public Draft Note (PD-NOTE)

A PD-NOTE is a NOTE that XII has published for review by the public, but is subject to further change by the PWG.

5.3.6 Public Last Call Draft Note (PLC-NOTE)

A PLC-NOTE is a special case of PD-NOTE whose earlier versions have had previous exposure and has incorporated sufficient feedback that it is ready to finalise; the PLC notation indicates that it is about to become a NOTE and that public comment may not be accepted after a specified date.

· Announcement: The Director must announce the Last Call to other XII bodies and to the public. A Last Call announcement must:

o Specify the deadline for review comments;

o Identify known dependencies and solicit review from all dependent XII bodies;

o Solicit public review including identifying of significant stakeholders and engaging in communication intended to obtain feedback specifically with them.

· Rationale: A Last Call announcement is a signal that:

o The PWG believes that it has reached consensus and incorporated feedback;

o The PWG believes that it has satisfied significant dependencies with other work;

o Other XII bodies should review the document to confirm that these dependencies have been satisfied.

o A PWG should work with other interested and relevant XII bodies prior to a Last Call announcement to reduce the risk of surprise during this stage.

o It is hoped that, after a Last Call announcement, a PWG will receive only indications of support for the NOTE, with no proposals for substantive change. In practice, Last Call announcements could generate comments that sometimes result in substantive changes to a NOTE.

o A PWG should not assume that it has completed its work when it issues a Last Call announcement.

· Entrance criteria: Before announcing a Last Call, the PWG must:

o By Majority Vote, pass a motion that requests the BPB to approve the promotion of the Work Product.

o Fulfil the relevant requirements of the PWG charters, or report which relevant goals have not been fulfilled.

o Indicate which dependencies with other work the PWG believes it has satisfied, and report which dependencies have not been satisfied.

o Obtain approval of the BPB to issue the Last Call

· Duration of the review: The announcement begins a review period that should last at least three weeks but may last longer if the NOTE is complex or has significant external dependencies.

· Ongoing work: During the review period, the PWG solicits and responds to comments from XII participants, XII bodies and the public.

· Possible next steps (mutually exclusive):

o Candidate NOTE

o Return for revisions as WD-NOTE

5.3.7 Candidate Note (C-NOTE)

A C-NOTE is a PLC-NOTE that has received final edits and that the PWG has requested the BPB to publish without further revisions anticipated.

The BPB may deem a C‑NOTE satisfactory for distribution to the public as a NOTE.

5.3.8 Public Note (NOTE)

A NOTE is the normal final state of Notes.

· Announcement: The Director must announce the publication of a NOTE to the public.

· Rationale: XII publishes NOTE when it believes that the ideas in the Work Product are appropriate for widespread deployment and that they support the strategic direction set down by the ISC.

· Entrance criteria: The Director publishes a NOTE upon request of the BPB and upon approval of that request from the ISC.

· Possible next steps:

o End state: A Work Product may remain a NOTE indefinitely

o Otherwise: Revise or Deprecate a NOTE

· The BPB or the ISC may request that the Director submit a NOTE to another standards body for adoption and formal approval by that body.

5.3.9 Deprecation Note (DEP-NOTE)

The BPB may publish a (short) NOTE that is a deprecation of a previously published NOTE. This could be, but is not necessarily triggered by the publication of a new and updated NOTE on the same topic.

5.4 General Requirements for Promotion

The following information is important to justify the decision to promote a Work Product and therefore must be publicly available. In preparation for promotion to Candidate or Public status, a PWG must:

· By a Majority Vote, pass a motion that requests the BPB to approve the promotion of the Work Product.

· Provide public documentation of all changes (both substantive and minor) to the Work Product (e.g., by providing “diffs” in addition to summaries of substantive changes) since the previous step.

o 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 usage experience.

o Other changes (e.g., clarifications, bug fixes, editorial repairs, and minor error corrections) are minor changes.

· Report which, if any, of the PWG’s goals for this document have changed since the previous step.

· Report any changes in dependencies with other XII work products.

· Show evidence of wide review and stakeholder support.

· Report any objections.

· Formally address all issues raised about the work product since the previous step.

5.5 Reviews and Review Responsibilities

The following actions build consensus around work products:

· Early review, to find errors quickly and decrease the chances of diverging practices.

· Frequent publication (a guide is at least one publication once every three months or other such minimum period as determined from time to time by the BPB). However, too frequent publication is undesirable. Common sense should prevail in determining the most appropriate frequency.

· Wide review and stakeholder support, including from other groups inside and outside of XII.

A document receives review starting with its first release as a Candidate. Starting with the First Candidate until the start of a Last Call review, a PWG should formally address any substantive review comment about a Work Product and should do so in a timely manner.

Starting with a Last Call review up to the promotion to Public NOTE, a PWG must formally address any substantive review comment about a Work Product and should do so in a timely manner. When a PWG requests to promote its Work Product to Candidate or beyond, it must provide positive documentation that issues have been formally addressed (e.g., in an issues list that shows how they have been addressed).

The Director must formally address any substantive issue raised by BPB members during review periods.

The PWG must communicate to the Director any substantive issues raised during review periods by anyone other than BPB representatives.

Reviewers should not send substantive reviews late on the NOTE path. Reviewers should not expect that a PWG will readily make substantive changes to a mature NOTE. The more evidence a PWG can show of wide review and stakeholder support, the less weight substantive comments will carry when provided late on the NOTE path. Worthwhile ideas should be recorded even when not incorporated into a mature NOTE.

The PWG must be able to show evidence of having attempted to respond to and satisfy reviewers. Reviewers may register a Formal Objection any time they are dissatisfied with how a PWG has handled an issue.

When a PWG receives a substantive issue after the end of the Last Call review period, the PWG must respond to the reviewer but may decline to formally address the issue. In this case, the PWG may consider the issue as part of tracking errata.

5.6 Returning a Work Product to a PWG

A Work Product is returned to a PWG for further work in either of the following situations:

· The PWG makes substantive changes to the Work Product at any time after a Last Call announcement and prior to Publication as a NOTE except when the changes involve the removal of features at risk identified in a Call for Implementations. In the case of substantive changes, the PWG must republish the Work Product as a Working Draft.

· The BPB requires the PWG to address important issues raised during a review or as the result of implementation experience. In this case the BPB may request that the PWG republish the Work Product as a Working Draft, even if the PWG has not made substantive changes.

After re-publication as a Working Draft, the next forward step available to the PWG is a Last Call announcement. The Last Call announcement may occur at the same time as the publication of the Working Draft.

The BPB may ask the PWG to republish a Work Product as a Candidate NOTE.

5.7 Ending Work on a Work Product

Work on a Work Product may cease at any time. When a PWG completes its work on a product, it publishes it either as a RFC or NOTE.

Work may also cease because the BPB determines that the PWG cannot productively carry the work any further. For example, the PWG might have been closed, the participants might lose interest in the work product, or the ideas might be incorporated in another work product.

· Possible next steps:

o End state: A Work Product may remain a Working Draft Note indefinitely

o Otherwise: A PWG may resume work on the Note as a Working Draft if directed to do so by the BPB.

5.8 Modifying a (Public) Note

XII works to maintain its Notes (e.g., by tracking errata) and to encourage widespread usage. The following sections deal with the management of errors and the process for making changes to a Note.

5.8.1 Errata Management

Tracking errors is a critical part of a PWG’s ongoing care of a Note; for this reason, the scope of a PWG charter should generally allow time for work after publication of a Note. Alternatively such ongoing maintenance may be carried out by a separate PWG whose charter specifically states that as its purpose, as determined by the BPB. In this Process Document, the term “erratum” (plural “errata”) refers to any class of mistake, from simply editorial to a serious error.

Note: Before a document becomes a Recommendation, the process focuses on substantive changes (those related to prior reviews). After a document has been published as Recommendation, the process focuses on those changes to a Work Product that might affect the conformance of content or deployed software.

PWGs must track errata internally in a list of enumerated error reports (such as the “Bugzilla” incident tracking system), possibly accompanied by corrections.

A correction is first “proposed” by the PWG. A correction becomes normative -- of equal status as the text in the published RFC or NOTE -- through one of the processes described below. The PWG publishes updated “errata corrected” versions of the Work Product at intervals as necessary and as approved by the BPB.

A PWG should keep their tracked errata up-to-date, as errors are reported by readers and users. A PWG must report changes in tracked errata to interested parties when corrections are proposed or become normative.

5.8.2 Classes of Changes to an RFC or NOTE

There are 4 classes of change to a public work product.

1. No changes to text content

These changes include fixing broken links or invalid document formatting.

2. Corrections that do not affect usage

Editorial changes or clarifications that do not change the meaning or content, but only assist in interpretation.

3. New or changed content

The first two classes of change do not require review of the proposed changes, but all other changes require a new (revised) Candidate.

A References

CHARTER

XII "XBRL Best Practices Board - Charter"

(See http://www.xbrl.org/BPB/BPB-Charter-2008-03-03-Approved.htm)

XSB Processes

XBRL International Standards Board. “Technical Working Group and Work Product Process” (See http://www.xbrl.org/XSB/XBRL_Technical_Working_Group_Processes-Approved-2007-04-17.htm)

B Intellectual property status (non‑normative)

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to XBRL International or XBRL organizations, except as required to translate it into languages other than English. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

This document and the information contained herein is provided on an "AS IS" basis and XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT not LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL not INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

The attention of users of this document is directed to the possibility that compliance with or adoption of XBRL International specifications may require use of an invention covered by patent rights. XBRL International shall not be responsible for identifying patents for which a license may be required by any XBRL International specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. XBRL International specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. XBRL International takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

C Acknowledgements (non‑normative)

The editors thank the members of XBRL International for supporting the creation of this document, and for providing valuable feedback on internal drafts.

D Document history (non‑normative)

Date	Editor	Details
2008‑05‑21	Hamscher	Created internal working draft based entirely on XSB technical working group process document.
2008-05-21	Hamscher	Edited internal working draft based on consensus reached during regularly scheduled Interim Best Practices Board meeting.
2008-05-23	Hamscher	Edited internal working draft to exclude all but RFC and NOTE work products from the description of work products and processes.
2008-05-28	Hamscher	Relax the requirement that only Quorate meetings count for establishing voting rights. Reformatted.
2008-05-28	Hamscher	Make all BPB members (non voting) members of all PWGs.

E Errata corrections in this document

This appendix contains a list of the errata that have been incorporated into this document. This represents all those errata corrections that have been approved by the XBRL International Interim Best Practices Board up to and including 30 May 2008. Hyperlinks to relevant e-mail threads may only be followed by those who have access to the relevant mailing lists. Access to internal XBRL mailing lists is restricted to members of XII.

No errata have been incorporated into this document.