611 lines
28 KiB
Plaintext
611 lines
28 KiB
Plaintext
head 1.17;
|
|
access;
|
|
symbols;
|
|
locks; strict;
|
|
comment @# @;
|
|
expand @o@;
|
|
|
|
|
|
1.17
|
|
date 2006.08.16.02.22.55; author StanleyBlum; state Exp;
|
|
branches;
|
|
next 1.16;
|
|
|
|
1.16
|
|
date 2006.08.14.21.11.45; author StanleyBlum; state Exp;
|
|
branches;
|
|
next 1.15;
|
|
|
|
1.15
|
|
date 2006.08.14.19.28.20; author StanleyBlum; state Exp;
|
|
branches;
|
|
next 1.14;
|
|
|
|
1.14
|
|
date 2006.06.04.13.56.46; author LeeBelbin; state Exp;
|
|
branches;
|
|
next 1.13;
|
|
|
|
1.13
|
|
date 2006.06.04.10.42.00; author StanleyBlum; state Exp;
|
|
branches;
|
|
next 1.12;
|
|
|
|
1.12
|
|
date 2006.06.04.10.40.33; author LeeBelbin; state Exp;
|
|
branches;
|
|
next 1.11;
|
|
|
|
1.11
|
|
date 2006.06.04.10.07.13; author StanleyBlum; state Exp;
|
|
branches;
|
|
next 1.10;
|
|
|
|
1.10
|
|
date 2006.06.04.07.49.45; author StanleyBlum; state Exp;
|
|
branches;
|
|
next 1.9;
|
|
|
|
1.9
|
|
date 2006.06.03.16.18.29; author RicardoPereira; state Exp;
|
|
branches;
|
|
next 1.8;
|
|
|
|
1.8
|
|
date 2006.06.03.16.08.21; author StanleyBlum; state Exp;
|
|
branches;
|
|
next 1.7;
|
|
|
|
1.7
|
|
date 2006.06.03.10.44.10; author StanleyBlum; state Exp;
|
|
branches;
|
|
next 1.6;
|
|
|
|
1.6
|
|
date 2006.05.09.06.37.48; author StanleyBlum; state Exp;
|
|
branches;
|
|
next 1.5;
|
|
|
|
1.5
|
|
date 2006.05.09.00.50.30; author LeeBelbin; state Exp;
|
|
branches;
|
|
next 1.4;
|
|
|
|
1.4
|
|
date 2006.05.09.00.21.38; author StanleyBlum; state Exp;
|
|
branches;
|
|
next 1.3;
|
|
|
|
1.3
|
|
date 2006.05.08.07.20.48; author StanleyBlum; state Exp;
|
|
branches;
|
|
next 1.2;
|
|
|
|
1.2
|
|
date 2006.05.08.06.09.03; author StanleyBlum; state Exp;
|
|
branches;
|
|
next 1.1;
|
|
|
|
1.1
|
|
date 2006.05.06.21.20.05; author StanleyBlum; state Exp;
|
|
branches;
|
|
next ;
|
|
|
|
|
|
desc
|
|
@none
|
|
@
|
|
|
|
|
|
1.17
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@%META:TOPICINFO{author="StanleyBlum" date="1155694975" format="1.1" version="1.17"}%
|
|
%META:TOPICPARENT{name="WebHome"}%
|
|
---+ The TDWG Standards Development Process
|
|
|
|
This document establishes the organizational and procedural framework for developing and ratifying TDWG standards.
|
|
|
|
---++ Interest and Task Groups
|
|
|
|
Interest Groups and Task Groups are the organizational entities responsible for investigating and creating specifications that enable biodiversity information interchange. Interest Groups provide a base for informal discussions of problems, goals, strategies, methods and the application of available technologies. Task Groups are created within Interest Groups to develop specific products within a specific time frame. Interest Groups are also responsible for maintaining the products of its past Task Groups.
|
|
|
|
---+++ Interest Groups
|
|
|
|
---++++ Purpose and Responsibilities
|
|
|
|
An Interest Group advances and promotes information sharing capabilities (interoperability) within an area of biodiversity science. An Interest Group has a responsibility to:
|
|
|
|
* Evaluate the needs of TDWG members against available methods and technologies;
|
|
* Devolop consensus around new approaches to information sharing;
|
|
* Create Task Groups to create specific products within specific time frames;
|
|
* Maintain and update products that continue to be useful.
|
|
|
|
---++++ Establishing an Interest Group
|
|
|
|
A TDWG member can petition for the establishment of an Interest Group by submitting an Interest Group charter to the Executive Committee. The charter specifies the mandate and operation of the Interest Group. Interest group charters undergo public review and comment. If the Executive Committee judges a proposal to be problematic, it may return the proposal to the submitter with justification but without public review. The Executive Committee should return a decision and explanation to the proposer within 30 days of acknolwedged receipt.
|
|
|
|
| Should the EC appoint someone to manage public review and summarize the results? -- Stan |
|
|
| I think this is simple enough with the 'automation' for the Secretary to manage it --Lee |
|
|
|
|
The approval of an Interest Group charter is announced to the TDWG members. This action formalises the establishment of the Interest group, and authorizes the establishment of the group's collaboration facilities.
|
|
|
|
| This sets the due date for future annual reports. -Stan |
|
|
|
|
A TDWG member can become an interest group member by joining the group's communication system and meeting any other requirements prescribed in the group's charter.
|
|
|
|
---++++ Maintaining an Interest Group
|
|
|
|
The interest group convener must submit an annual status report against the _Outputs and Outcomes_ of its charter to the Executive Committee for review. The Executive Committee must notify the Interest group Convenor of approval or rejection of the annual report within 30 days of receipt. A report can be rejected for two reasons:
|
|
|
|
* the report is not up to the standard required or
|
|
* the Interest Group is not fulfilling the requirements under its charter.
|
|
|
|
| In the first sentence under maintaining an interest group, I think it's problematic to refer to a specific part of a charter when the template for a charter is not strictly normative -- at least not yet. I am working on alternative wording. |
|
|
|
|
In the former case, the report should be edited and re-submitted. In the later case, the Executive Committee may reorganize or disband the Interest Group.
|
|
|
|
An Interest Group charter can be revised at any time and submitted to the Secretary as a draft. A draft revision may reflect minor corrections or clarification, or may reflect a change in operation or purpose. The Secretary may approve minor changes, but must distribute any substantive revision to the Executive Committee for review and approval before it replaces a prior charter.
|
|
|
|
---++++ Composition
|
|
|
|
The only formal position required in an Interest Group is the Convener, who is responsible the managing the group's operations. The Convener may appoint group members to other roles as required.
|
|
|
|
---+++ Task Groups
|
|
|
|
---++++ Purpose and Responsibilities
|
|
|
|
A Task Group is created within an Interest Group to develop a specified product within a specified timeframe.
|
|
|
|
---++++ Creating a Task Group
|
|
|
|
The charter for any new Task Group must be submitted to the Executive Committee by the Convener of the parent Interest Group. The Task Group Charter must include a schedule of milestones and products. The Executive Committee should seek external review as appropriate and render a decision to the Interest and Task Group Convenors within 30 days of receipt.
|
|
|
|
The approval of a Task Group charter is announced to the TDWG members. This action formalises the establishment of the Task Group, and authorizes the establishment of the group's collaboration facilities.
|
|
|
|
---++++ Maintaining a Task Group
|
|
|
|
The Task Group Convener must submit an annual status report against its charter to the Executive Committee for review. The Executive Committee must notify the Task Group and associated Interest Group Convenors of approval or rejection of the annual report within 30 days of receipt. A report can be rejected for two reasons:
|
|
|
|
* the report is not up to the standard required or
|
|
* the Task Group is not fulfilling the requirements under its charter.
|
|
|
|
In the former case, the report should be edited and re-submitted. In the later case, the Executive Committee may reorganize or disband the Task Group.
|
|
|
|
| Should Task Group reports be submitted by the TG convener, the IG convener, or both? I'm inclinded to say the IG convener. -- Stan |
|
|
| No, it is the Executive Committee that has authority over the Task (and Interest) Groups. The EC must however report to the Task AND Insterest Group Convenors on any review issues. |
|
|
|
|
A Task Group charter can be revised at any time and submitted to the Secretary as a draft. A draft revision may reflect minor corrections or clarification, or may reflect a change in operation or purpose. The Secretary may approve minor changes, but must distribute any substantive revision to the Executive Committee for review and approval before it replaces a prior charter.
|
|
|
|
---++++ Composition
|
|
|
|
The only formal position required of a Task Group is a Convener. The Convener may appoint other positions as required. Members of the Task Group are defined by joining the group's communications system and meeting any other requirements specified in the charter. By definition, a member of a Task Group is also a member of the Interest Group that created it.
|
|
|
|
---++ Ratification of Standards
|
|
|
|
1. When a Task Group believes that a working draft is ready for wider review, the Task Group Convener submits the working draft with appropriate documentation as a package to the Executive Committee via the Secretary.
|
|
1. The Secretary notifies the Executive Committee of the submission and requests a decision on progressing the draft. This decision must be made within 30 days of receipt of the draft.
|
|
a. If the response is positive, the Executive Committee appoints a Review Manager to seek appropriate independent and expert reveiws.
|
|
a. If the response is negative, the Secretary reports the decision with justification to the Task Group Convenor .
|
|
1. The Review Manager submits the reviews along with a summary and recommendation as a package to the Executive Committee.
|
|
1. The Executive Committee may-
|
|
a. advance the draft as a Proposed Standard with call for public comment, or
|
|
a. decline (with justification) to advance the draft, or
|
|
a. request a new revision to address specific problems.
|
|
1. Public Review -- The Executive Committee directs the Proposed Standard to be placed in the TDWG repository, publishes a request for comment (RFC) that describes facilities for, and duration of public comment. A minimum of 30 days must be allowed for comment. At the end of the comment period, the Task Group may modify the specification or its documentation as necessary. Any subsequent submission should address the comments received in the public review.
|
|
1. Accept as a Standard -- A draft is accepted as a Standard and its status in the repository is updated accordingly. A specification must have been through at least one round of public review before the Executive Committee may accept it as a Standard.
|
|
|
|
|
|
|
|
---++ Maintenance of Standards
|
|
|
|
Once a standard has been approved, experience with its application is likely to show that a standard needs to be revised. If the changes are minor, they can be incorporated into a revision by the Interest Group, without establishing Task Group. The revision must be submitted to the Secretary, who must then decide (with expert consultation if necessary) whether the changes are minor or warrant further review. In that case, the Secretary will submit the revised standard to the Executive Committee, who must decide whether the changes require a full public review. Any approved revision must be announced to the TDWG membership and published in the repository.
|
|
|
|
|
|
-- Main.StanleyBlum - 06 May 2006
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Process_Overview_v4.png: <br />
|
|
<img src="%ATTACHURLPATH%/Process_Overview_v4.png" alt="Process_Overview_v4.png" width='380' height='525' />
|
|
|
|
|
|
%META:FILEATTACHMENT{name="Process_Overview_v4.png" attr="h" autoattached="1" comment="" date="1155694785" path="Process_Overview_v4.png" size="19070" user="Main.StanleyBlum" version="1"}%
|
|
@
|
|
|
|
|
|
1.16
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="StanleyBlum" date="1155589905" format="1.1" version="1.16"}%
|
|
a95 2
|
|
* Process_Overview_v3.png: <br />
|
|
<img src="%ATTACHURLPATH%/Process_Overview_v3.png" alt="Process_Overview_v3.png" />
|
|
d110 5
|
|
a114 1
|
|
%META:FILEATTACHMENT{name="Process_Overview_v3.png" attr="" autoattached="1" comment="" date="1149413093" path="Process_Overview_v3.png" size="20780" user="Main.StanleyBlum" version="4"}%
|
|
@
|
|
|
|
|
|
1.15
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="StanleyBlum" date="1155583700" format="1.1" version="1.15"}%
|
|
d3 1
|
|
a3 1
|
|
---+ Interest and Task Groups
|
|
d5 1
|
|
a5 1
|
|
Interest Groups and Task Groups are the entities responsible for investigating and creating methods that enable biodiversity information interchange. Interest Groups provide a base for informal discussions of methods and strategies. Task Groups are created within Interest Groups to develop specific products within a specific time frame.
|
|
d7 1
|
|
a7 1
|
|
---++ Interest Groups
|
|
d9 5
|
|
a13 1
|
|
---+++ Purpose and Responsibilities
|
|
d19 1
|
|
a19 1
|
|
* Create Task Groups to create specific products within specific timeframes;
|
|
d22 1
|
|
a22 1
|
|
---+++ Establishing an Interest Group
|
|
d35 1
|
|
a35 1
|
|
---+++ Maintaining an Interest Group
|
|
d48 1
|
|
a48 1
|
|
---+++ Composition
|
|
d52 1
|
|
a52 1
|
|
---++Task Groups
|
|
d54 1
|
|
a54 1
|
|
---+++ Purpose and Responsibilities
|
|
d58 1
|
|
a58 1
|
|
---+++ Creating a Task Group
|
|
d64 1
|
|
a64 1
|
|
---+++ Maintaining a Task Group
|
|
d78 1
|
|
a78 1
|
|
---+++ Composition
|
|
@
|
|
|
|
|
|
1.14
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="LeeBelbin" date="1149429406" format="1.1" version="1.14"}%
|
|
d5 1
|
|
a5 1
|
|
Interest Groups and Task Groups are the entities responsible for investigating technologies to improve bio-data sharing and communication. Interest Groups provide a base for informal discussions of methods and strategies. Task Groups are created within Interest Groups to develop specific products within a specific timeframe.
|
|
d38 2
|
|
@
|
|
|
|
|
|
1.13
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="StanleyBlum" date="1149417720" format="1.1" version="1.13"}%
|
|
d3 1
|
|
a3 1
|
|
---+ Standards Development Process
|
|
d5 70
|
|
a74 1
|
|
_The material below is under active editing to reflect decisions emerging from a recent meeting (Berendsohn, Rissone, Blum, Belbin, Hobern, Hyam, Perreira -- 2006/06/1-2)_
|
|
d78 1
|
|
a78 1
|
|
1. When a Task Group believes that a working draft is ready for wider review, the Task Group Convener submits the working draft and appropriate documentation as a package to the Executive Committee via the Secretary.
|
|
d80 2
|
|
a81 2
|
|
a. If the response is positive, the Executive Committee appoints a Review Manager and charges him/her to seek independent and expert reveiws as appropriate.
|
|
a. If the response is negative, the Secretary reports the decision with reasons to the Task Group Convenor
|
|
d83 4
|
|
a86 1
|
|
1. The Executive Committee may advance the draft as a Proposed Standard with call for public comment, or decline to advance the draft with explanation or may request that a new revision address specific problems.
|
|
d88 4
|
|
a91 1
|
|
1. Accept as a Standard -- The draft is accepted as a Standard and its status in the repository is updated accordingly. A specification must have been through at least one round of public review before the Executive Committee may accept it as a Standard.
|
|
a92 1
|
|
-------
|
|
a98 1
|
|
|
|
d103 1
|
|
a103 2
|
|
* Process_Overview_v3.png: <br />
|
|
<img src="%ATTACHURLPATH%/Process_Overview_v3.png" alt="Process_Overview_v3.png" />
|
|
@
|
|
|
|
|
|
1.12
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="LeeBelbin" date="1149417633" format="1.1" version="1.12"}%
|
|
d11 2
|
|
a12 2
|
|
1. If the response is positive, the Executive Committee appoints a Review Manager and charges him/her to seek independent and expert reveiws as appropriate.
|
|
1. If the response is negative, the Secretary reports the decision with reasons to the Task Group Convenor
|
|
@
|
|
|
|
|
|
1.11
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="StanleyBlum" date="1149415633" format="1.1" version="1.11"}%
|
|
d10 4
|
|
a13 2
|
|
1. The Executive Committee then appoints a review manager and charges him/her to seek independent and expert reveiws as appropriate.
|
|
1. The review manager then submits the reviews along with a summary and recommendation as a package to the Executive Committee.
|
|
@
|
|
|
|
|
|
1.10
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="StanleyBlum" date="1149407385" format="1.1" version="1.10"}%
|
|
d7 2
|
|
d10 5
|
|
a14 4
|
|
1. The Executive Committee then appoints a review manager and charges him/her to seek independent and expert reveiws as appropriate, and to summarize the reviews into a recommendation.
|
|
1. The review manager then submits these as a package back to the Executive Committee, which may then either return the draft to the task group for modification or advance the draft as a proposed standard with call for public comment.
|
|
1. Public Review -- The Executive Committee directs the Draft to be placed in the TDWG repository, publishes a request for comment (RFC) that describes facilities for, and duration of public comment. A minimum of 30 days must be allowed for comment. At the end of the comment period, the Task Group may modify the specification or its documentation as necessary. Any subsequent submission should address the comments received in the public review.
|
|
1. Accept as TDWG Standard -- The draft is accepted as a TDWG standard and its status in the TDWG repository is updated accordingly (4c). A specification must have been through at least one round of public review before the Executive Committee may accept it as a TDWG Standard.
|
|
d16 1
|
|
d18 1
|
|
d20 1
|
|
a20 1
|
|
-------
|
|
a21 6
|
|
* Exec Comm Reviewing responsibilities:
|
|
* Interest and Task Group (TG) Charters for formation of new subgroups;
|
|
* Modifications of Charters;
|
|
* Interest and Task Group reports against Chaters every year after the formation of the subgroup;
|
|
* summaries of expert reviews
|
|
* Existing standards (annually)
|
|
a26 3
|
|
* Process_Overview_v2.png: <br />
|
|
<img src="%ATTACHURLPATH%/Process_Overview_v2.png" alt="Process_Overview_v2.png" width='472' height='630' />
|
|
|
|
d29 1
|
|
a29 1
|
|
<img src="%ATTACHURLPATH%/Process_Overview_v3.png" alt="Process_Overview_v3.png" width='558' height='694' />
|
|
d32 1
|
|
a32 5
|
|
%META:FILEATTACHMENT{name="Process_Overview_v2.png" attr="" autoattached="1" comment="" date="1149351486" path="Process_Overview_v2.png" size="0" user="Main.RicardoPereira" version="3"}%
|
|
%META:FILEATTACHMENT{name="Process_Overview_v3.png" attachment="Process_Overview_v3.png" attr="" comment="" date="1149407385" path="Process_Overview_v3.png" size="36985" stream="Process_Overview_v3.png" user="Main.StanleyBlum" version="2"}%
|
|
%META:FILEATTACHMENT{name="Process_Overview_v31.png" attr="" autoattached="1" comment="" date="1149350861" path="Process_Overview_v31.png" size="0" user="Main.StanleyBlum" version="1"}%
|
|
%META:FILEATTACHMENT{name="Copy_of_Process_Overview_v3.png" attr="" autoattached="1" comment="" date="1149350813" path="Copy_of_Process_Overview_v3.png" size="0" user="Main.StanleyBlum" version="1"}%
|
|
%META:FILEATTACHMENT{name="Process_Overview_v3.jpg" attr="" autoattached="1" comment="" date="1149350901" path="Process_Overview_v3.jpg" size="0" user="Main.StanleyBlum" version="1"}%
|
|
@
|
|
|
|
|
|
1.9
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="RicardoPereira" date="1149351509" format="1.1" version="1.9"}%
|
|
d32 4
|
|
d37 1
|
|
a37 1
|
|
%META:FILEATTACHMENT{name="Process_Overview_v3.png" attr="" autoattached="1" comment="" date="1149350729" path="Process_Overview_v3.png" size="0" user="Main.StanleyBlum" version="1"}%
|
|
@
|
|
|
|
|
|
1.8
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="StanleyBlum" date="1149350901" format="1.1" version="1.8"}%
|
|
d3 1
|
|
d5 28
|
|
a32 1
|
|
%META:FILEATTACHMENT{name="Process_Overview_v2.png" attr="" autoattached="1" comment="" date="1147155202" path="Process_Overview_v2.png" size="43950" user="Main.StanleyBlum" version="2"}%
|
|
d36 1
|
|
a36 1
|
|
%META:FILEATTACHMENT{name="Process_Overview_v3.jpg" attachment="Process_Overview_v3.jpg" attr="" comment="" date="1149350901" file="/var/www/html/twiki/pub/Process/StandardsDevelopmentProcess/Process_Overview_v3.jpg" path="Process_Overview_v3.jpg" size="61354" stream="Process_Overview_v3.jpg" user="Main.StanleyBlum" version="1"}%
|
|
@
|
|
|
|
|
|
1.7
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="StanleyBlum" date="1149331450" format="1.1" version="1.7"}%
|
|
a2 1
|
|
---+ Standards Development Process
|
|
d4 5
|
|
a8 28
|
|
_The material below is under active editing to reflect decisions emerging from a recent meeting (Berendsohn, Rissone, Blum, Belbin, Hobern, Hyam, Perreira -- 2006/06/1-2)_
|
|
|
|
1. When a Task Group believes that a working draft is ready for wider review, the Task Group Convener submits the working draft and appropriate documentation as a package to the Executive Committee via the Secretary.
|
|
1. The Executive Committee then appoints a review manager and charges him/her to seek independent and expert reveiws as appropriate, and to summarize the reviews into a recommendation.
|
|
1. The review manager then submits these as a package back to the Executive Committee, which may then either return the draft to the task group for modification or advance the draft as a proposed standard with call for public comment.
|
|
1. Public Review -- The Executive Committee directs the Draft to be placed in the TDWG repository, publishes a request for comment (RFC) that describes facilities for, and duration of public comment. A minimum of 30 days must be allowed for comment. At the end of the comment period, the Task Group may modify the specification or its documentation as necessary. Any subsequent submission should address the comments received in the public review.
|
|
1. Accept as TDWG Standard -- The draft is accepted as a TDWG standard and its status in the TDWG repository is updated accordingly (4c). A specification must have been through at least one round of public review before the Executive Committee may accept it as a TDWG Standard.
|
|
|
|
|
|
|
|
-------
|
|
|
|
* Exec Comm Reviewing responsibilities:
|
|
* Interest and Task Group (TG) Charters for formation of new subgroups;
|
|
* Modifications of Charters;
|
|
* Interest and Task Group reports against Chaters every year after the formation of the subgroup;
|
|
* summaries of expert reviews
|
|
* Existing standards (annually)
|
|
|
|
|
|
-- Main.StanleyBlum - 06 May 2006
|
|
|
|
|
|
* Process_Overview_v2.png: <br />
|
|
<img src="%ATTACHURLPATH%/Process_Overview_v2.png" alt="Process_Overview_v2.png" width='472' height='630' />
|
|
|
|
|
|
%META:FILEATTACHMENT{name="Process_Overview_v2.png" attachment="Process_Overview_v2.png" attr="" comment="" date="1147155202" path="Process_Overview_v2.png" size="43950" stream="Process_Overview_v2.png" user="Main.StanleyBlum" version="2"}%
|
|
@
|
|
|
|
|
|
1.6
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="StanleyBlum" date="1147156668" format="1.1" version="1.6"}%
|
|
d5 1
|
|
d7 16
|
|
a22 7
|
|
1. When a Task Group believes that a working draft is ready for wider review, the Task Group Convener submits the working draft and appropriate documentation as a package to TAG to review and advise the Executive (1).
|
|
1. The TAG may recommend to the Executive to approve the working draft (2a) or recommend that it be returned to the Task Group Convener for further editing (2b). If the TAG recommends the approval of the working draft, The TAG chair forwards the package to the TDWG Editor. _(This would guarantee that the package is unaltered, but may be too rigid.)_
|
|
1. The TDWG Editor can approve the structure and format and forward the Draft to the Executive Committee (3a) (_this EC review is only final if this draft has already gone through public review_), or return the draft to the Task Group Convenor for further editing.
|
|
1. The Executive Committee reviews the Draft, and provides a response to the Task Group Convenor within 30 days of receiving the draft. The Executive Committee has three choices:
|
|
a. Public Review -- The Executive Committee directs the Draft to be placed in the TDWG repository (4a1), publishes a request for comment (RFC) that describes facilities for, and duration of public comment (4a2). A minimum of 30 days must be allowed for comment. At the end of the comment period, the Task Group may modify the specification or its documentation as necessary. Any subsequent submission should address the comments received in the public review.
|
|
a. Return to Task Group -- Return the draft to the Convenor of the Task Group with specific reasons for rejection (4b).
|
|
a. Accept as TDWG Standard -- The draft is accepted as a TDWG standard and its status in the TDWG repository is updated accordingly (4c). A specification must have been through at least one round of public review before the Executive Committee may accept it as a TDWG Standard.
|
|
@
|
|
|
|
|
|
1.5
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="LeeBelbin" date="1147135830" format="1.1" version="1.5"}%
|
|
d6 3
|
|
a8 3
|
|
1. When a Task Group believes that a working draft is ready for wider review, the Task Group Convener submits the working draft and appropriate documentation as a package to TAG to review and advise the Executive.
|
|
1. The TAG may recommend to the Executive to approve the working draft or recommend that it be returned to the Task Group Convener for further editing. If the TAG recommends the approval of the working draft, The TAG chair forwards the package to the TDWG Editor. _(This guarantees that the package is unaltered.)_
|
|
1. The TDWG Editor can return the draft to the Task Group Convenor for further editing, or approve the structure and format and forward the Draft to the Executive Committee for final approval.
|
|
d10 3
|
|
a12 3
|
|
a. Public Review -- The Executive Committee directs the Draft to be placed in the TDWG repository, publishes a request for comment (RFC) and describes facilities for, and duration of public comment. A minimum of 30 days must be allowed for comment. At the end of the comment period, the Task Group may modify the specification or its documentation as necessary. The Task Group should incorporate the results of the public review in any subsequent submission.
|
|
a. Accept as TDWG Standard -- The draft is accepted as a TDWG standard and its status in the TDWG repository is updated accordingly. A specification must have been through at least one round of public review before the Executive Committee may accept it as a TDWG Standard.
|
|
a. Return to Task Group -- Return the draft to the Convenor of the Task Group with specific reasons for rejection.
|
|
a16 2
|
|
* Process_Overview.png: <br />
|
|
<img src="%ATTACHURLPATH%/Process_Overview.png" alt="Process_Overview.png" width='410' height='520' />
|
|
d18 5
|
|
a22 1
|
|
%META:FILEATTACHMENT{name="Process_Overview.png" attachment="Process_Overview.png" attr="" comment="" date="1147132933" path="Process_Overview.png" size="16880" stream="Process_Overview.png" user="Main.StanleyBlum" version="1"}%
|
|
@
|
|
|
|
|
|
1.4
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="StanleyBlum" date="1147134098" format="1.1" version="1.4"}%
|
|
d6 5
|
|
a10 5
|
|
1. When a Task Group believes a working draft has achieved sufficient maturity that it is ready for wider review the Task Group Convener submits the working draft and appropriate documentation as a package to the TAG for review.
|
|
1. The TAG may approve the working draft or return it to the Task Group Convener for modification. If the TAG approves the working draft, The TAG chair forwards the package to the TDWG Editor. _(This guarantees that the package is unaltered.)_
|
|
1. The TDWG Editor approves the structure and format and on approval, submits the Draft to the Executive Committee for approval.
|
|
1. The Executive Committee reviews the Draft and should attempt to reach a decision within 30 days of receiving the draft. The Executive Committee has three choices:
|
|
a. Public Review -- The Executive Committee directs the Draft to be placed in the TDWG repository, publishes a request for comment (RFC) and describes facilities for and duration of public comment. A minimum of 30 days must be allowed for comment. At the end of the comment period, the Task Group may modify the specification or its documentation as necessary. The Task Group should incorporate the results of the public review in the next submission.
|
|
d12 1
|
|
a12 3
|
|
a. Return to Task Group -- Return the draft the Executive Committee must provide reasons to the Task Group.
|
|
|
|
|
|
a19 1
|
|
|
|
@
|
|
|
|
|
|
1.3
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="StanleyBlum" date="1147072848" format="1.1" version="1.3"}%
|
|
d5 1
|
|
d18 6
|
|
@
|
|
|
|
|
|
1.2
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="StanleyBlum" date="1147068543" format="1.1" version="1.2"}%
|
|
d5 2
|
|
a6 2
|
|
1. When a Task Group Convener believes a working draft has achieved sufficient maturity that it is ready for wider review s/he must submit the working draft and appropriate documentation as a package to the TAG for review.
|
|
1. The TAG may approve or return the working draft to the Task Group Convener for modification. If the TAG approves the working draft, The TAG chair forwards the package to the TDWG Editor. _(This guarantees that the package is unaltered.)_
|
|
d8 4
|
|
a11 4
|
|
1. The Executive Committee reviews the Draft. The Executive Committee should respond to the Task Group within 30 days of receipt of the Draft. The Executive Committee has three choices with mandatory consultation with the TAG:
|
|
a. The Executive Committee directs the Draft to be placed in the TDWG repository, publishes a RFC and describes facilities for and duration of public comment with minimum of 30 days. Responses to RFC must be documented. It is up to the responders to the RFC to engage with the Task Group Convener to ensure that their views are adequately addressed. Applications and responses will be public by default, but the applicant may direct the EC to keep private the response to a denied charter application.
|
|
a. The Draft becomes a TDWG standard
|
|
a. Upon decline, the Executive Committee must provide reasons to the Task Group
|
|
@
|
|
|
|
|
|
1.1
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="StanleyBlum" date="1146950405" format="1.1" version="1.1"}%
|
|
d5 8
|
|
a12 1
|
|
Stub
|
|
@
|