Added by gunther.stuhec, last edited by gunther.stuhec on Apr 03, 2007

Labels

 

Table of Contents

1. Introduction

This is a subset of the complete ODP document including additional information about the activities that are required for each ODP step at the TMG website. It considers only the chapter "Open Development Process (ODP) Overview" and the chapter "ODP for Technical Specication". Especially the chapter "ODP for Technical Specification" provides the handling instructions at the TMG website.

1.1 UN/CEFACT's Mission

UN/CEFACT's mission is to support activities dedicated to improving the ability of business, trade, and administrative organizations, from developed, developing, and transitional economies to effectively exchange products and services. Its principal focus is on facilitating national and international transactions through the simplification and harmonisation of processes, procedures, and information flows; and in so doing contribute to the growth of global commerce.
One way in which CEFACT fulfils this mission is by publishing standards, specifications, recommendations, and user guides (collectively referred to as publications in this document).

1.2 Publication Types

UN/CEFACT produces the following four publication types:

  • UN/CEFACT Technical Standard (TS): Specifications established by consensus within the Forum and approved by the Plenary to establish how one or more Business Standards and/or Recommendations shall be developed.
  • UN/CEFACT Business Standard (BS): Specifications established by consensus within the Forum and approved by the Plenary that provide rules, guidelines, and/or principals related to activities in the context of trade facilitation or electronic business.
  • UNECE Recommendation (RE): Trade facilitation or electronic business standards that provide formal guidance to governments, the private sector, and the business community.
  • UN/CEFACT User Guide (UG): Informative (in contrast to normative) documents and/or audio/video productions that provide guidance to publication implementers.
  • Other: Other publication types exist and more will likely emerge. This document does not address these publication types. Examples of such publications include:
    • TMG's Glossary Project
    • TMG's eBusiness Architecture Project

1.3 UN/CEFACT Publication Production Process

UN/CEFACT produces publications by executing a process called The Open Development Process, which is generally referred to by its acronym, ODP. This document specifies the ODP.

1.4 Open Development Process Requirements

Project teams executing their project according to the ODP must:

  • Welcome participation by anyone designated as an expert by a Head of Delegation to UN/CEFACT.
  • Encourage global input.
  • Work quickly.
  • Avoid incorporating specific hardware or operating system requirements or any other proprietary software tool into their processes and publications.
  • Understand, agree to be subject to, and abide by the UN/CEFACT Intellectual Property Rights (IPR) policy.

1.5 UN/CEFACT Activity Initiation

1.5.1 A Stakeholder Expresses a Need: CEFACT Activity Request (CAR)

A stakeholder is a person or organization that would like UN/CEFACT to do something for them. Stakeholders may initially express their need in any written form and consider it officially submitted once it has been delivered to any FMG member or to TBG16. The need, once written and delivered, is called a CEFACT Activity Request (CAR).

1.5.2 UN/CEFACT Addresses a Stakeholder's Need

When an FMG member receives a CAR, they will immediately forward it to TBG16 where initial processing occurs. TBG16 reviews the CAR, categorizes it as a Simple CAR or a Project CAR, and assigns the CAR to the appropriate permanent group.

Simple CARs are generally requests for small revisions to existing publications (i.e., maintenance). They include, but are not limited to:

  • Errata
  • Requests for rules and/or guidelines that do not significantly impact multiple groups and/or business processes
  • Requests to add a single Business Information Entity into the Core Component Library
  • Requests to include existing UN/EDIFACT Segments/Data Elements that do not significantly impact business processes
  • Requests to add values to a code listProject CARs include, but are not limited to:
  • Requests that would result in new publication production (not revisions)
  • Requests that would result in revised publication production where the revisions would likely have major impact on implementers
  • Requests that require considerable resources, leadership, coordination among CEFACT groups, or expert engagement

The assigned Permanent Group specifies Simple CAR processing. The Open Development Process (i.e., this document) specifies Project CAR processing.

2. Open Development Process (ODP) Overview

2.1 Introduction

Each publication type may have unique development-process requirements and as a result each has its own ODP specified in a later section. This section's intent is to provide those unfamiliar with the ODP a general understanding of it without needing to understand the details of each publication-type-specific ODP. It also serves as a starting point for each publication-type-specific ODP, which must generally align with the process steps set forth in this section.

Each of the following ODP steps is described in a following subsection:

  • ODP1: Project Proposal and Team Formation
  • ODP2: Requirements Gathering
  • ODP3: Internal Draft Development
  • ODP4: Internal Review
  • ODP5: Public Review
  • ODP6: Implementation Verification
  • ODP7: Publication
  • ODP8: Maintenance

2.2 Key Terms: Artefact and Publication

Two terms, artefact and publication, are used extensively throughout the remainder of this document. An artefact is any bit of information collected or created during an ODP process. Artefacts include, but are not limited to:

  • project CAR
  • project proposal
  • call for participation
  • initial submissions
  • requirements document
  • team emails
  • draft documents
  • UML models
  • diagrams
  • comment log
  • final work product (what is eventually published)

A publication is a CEFACT project's final work product as specified by the project proposal and published by CEFACT. All publications are artefacts, but not all artefacts are part of a publication (e.g., team emails). Some artefacts may be made available on the CEFACT website but would not be considered part of a publication (e.g., comment log).

2.3 ODP1: Project Proposal and Team Formation

2.3.1 Activities

New publication development or changes to existing publications officially begins with a project proposa submission by a Permanent Group (PG) chairperson to the Forum Management Group (FMG). The FMG will consider the proposal and either approve it or reject it. The FMG will assign approved project proposals to the appropriate PG for execution. Some projects are regarded as cross-domain, i.e. successful project execution depends upon the expertise of contributors to two or more Permanent Groups. In such cases, the FMG will designate one PG the host group. The host group is then accountable for the project. Multiple Working Groups within a PG may also need to cooperate on a project. The same procedures apply except that it is handled by the PG's Steering Committee.
Projects in dispute that are rejected by the FMG will be reported to the UN/CEFACT Plenary for potential further consideration.
The team-formation process includes an activity called call for participation, which is an announcement to interested parties regarding the intent to execute a project and an invitation to contribute. Regardless of the method by which the project team is formed, it is acceptable that the team could be composed entirely of a small number of editors.
If major changes occur during the project to either the purpose of the project or potential outcomes or deliverables a revised version of the project proposals must submitted to FMG for approval and actions as required.

2.3.2 Artefacts

Typical artefacts produced by ODP1 include:

  • Project proposal
  • Call for participation
  • Initial contributions

2.4 ODP2: Requirements Gathering

2.4.1 Activities

The project team engages stakeholders and domain experts to document requirements. The comment log may serve as the requirements document for projects that change existing publications.

2.4.2 Artefacts

Typical artefacts produced by ODP2 include:

  • Requirements Documents
  • Comment Log

2.5 ODP3: Internal Draft Development

2.5.1 Activities

The project team writes an internal draft while continuing to engage project stakeholders and domain experts as required. This draft must be substantially content-complete, but need not be polished.

2.5.2 Artefacts

Typical artefacts produced by ODP3 include:

  • Internal Draft
  • Comment Log

2.6 ODP4: Internal Draft Review

2.6.1 Activities

The parent PG circulates the internal draft within the group, to other PGs as appropriate, and among project stakeholders and contributing domain experts, inviting comments. The project team logs and processes comments, and circulates updated internal drafts. The comment/update/circulation cycle continues until the PG approves a project team recommendation to conclude ODP4. While the criteria, evaluation, and ultimate decision to conclude ODP4 is left to the PG, the PG must ensure that the project team has met all comment processing requirements (see later section).

2.6.2 Artefacts

Typical artefacts produced by ODP4 include:

  • External Draft
  • Updated Comment Log

2.7 ODP5: Public Review

2.7.1 Activities

The UNECE Secretariat publishes the external draft via the UNECE website. The FMG notifies Heads of Delegation and subscribers to email distribution lists that the external draft is available for review and provides them with review-process details. The project team logs and processes comments and posts updated external drafts and comment logs to the PG website or the UNECE website (through the Secretariat). The comment/update/posting cycle continues until the PG approves a project team recommendation to conclude ODP5. While the criteria, evaluation, and ultimate decision to conclude ODP5 is left to the PG, the PG must ensure that the project team has met all comment processing requirements (see later section).

2.7.2 Artefacts

Typical artefacts produced by ODP5 include:

  • Implementation Draft
  • Updated Comment Log

2.8 ODP6: Implementation Verification

2.8.1 Activities

The UNECE Secretariat publishes the implementation draft via the UNECE website. The FMG notifies Heads of Delegation and subscribers to email distribution lists that the implementation draft is available for implementation and provides them with details regarding the process for submitting comments. The project team logs and processes comments and posts updated implementation drafts and comment logs to the PG website or UNECE website (through the Secretariat). The comment/update/posting cycle continues until at least two independent implementations have been confirmed and the PG approves a project team recommendation to conclude ODP6. While the criteria, evaluation, and ultimate decision to conclude ODP6 is left to the PG, the PG must ensure that the project team has met all comment processing requirements (see later section).
If comments are received that require substantial revisions of the artefact the project goes back to the required previous step in ODP. Normally this means ODP3.
Implementation verification may not be possible or suitable for some artefacts. An exemption, fully or partly, can be decided by the FMG. The UN/CEFACT Plenary must be informed prior to approving an artefact.

2.8.2 Artefacts

Typical artefacts produced by ODP6 include:

  • ICG Submission???
  • Updated Comment Log

2.9 ODP7: Publication

2.9.1 Activities

The UNECE Secretariat publishes relevant project artefacts to the UNECE website. The FMG notifies Heads of Delegation and subscribers to email distribution lists that the release is available for implementation. What is ICG's role? Do any quality assurance activities occur in this step?

2.10 ODP8: Maintenance

During ODP8, organizations implement the release. Implementers may offer comments. The PG that oversaw the release's development will log all comments. If artefact stakeholders determine that a revision project is worth executing, they may initiate such a project at ODP1.


3. ODP for Technical Specifications

3.1 ODP1: Project Proposal and Team Formation

3.1.1 Activities

New publication development or changes to existing publications officially begins with a project proposal submission by a Permanent Group (PG) chairperson to the Forum Management Group (FMG). The FMG will consider the proposal and either approve it or reject it. The FMG will assign approved project proposals to the appropriate PG for execution. Some projects are regarded as cross-domain, i.e. successful project execution depends upon the expertise of contributors to two or more Permanent Groups. In such cases, the FMG will designate one PG the host group. The host group is then accountable for the project. Multiple Working Groups within a PG may also need to cooperate on a project. The same procedures apply except that it is handled by the PG's Steering Committee.
Projects in dispute that are rejected by the FMG will be reported to the UN/CEFACT Plenary for potential further consideration.
The team-formation process includes an activity called call for participation, which is an announcement to interested parties regarding the intent to execute a project and an invitation to contribute. Regardless of the method by which the project team is formed, it is acceptable that the team could be composed entirely of a small number of editors.
If major changes occur during the project to either the purpose of the project or potential outcomes or deliverables a revised version of the project proposals must submitted to FMG for approval and actions as required.

3.1.2 Artefacts

Typical artefacts produced by ODP1 include:

  • Project proposal
  • Call for participation
  • Initial contributions

3.1.3 Activities at Confluence

  1. Define new project (see Guideline Chapter "4. Create a New Project and a New Group"
  2. Define new project proposal by the following steps:
    1. Go to project overview page of newly created project
    2. Click on link "Project Proposal" at column "ODP Name"
    3. Click in the area "Unable to render {include} Couldn't find a page to include called:..." on link "#PROJ# - ODP1 - Project Proposal Document"
    4. A new page with the selected name will be shown.
    5. Click on link "Select page template"
    6. Select template "Project Proposal" from the global templates list
    7. Push button "Next" at global templates list. You will come back to the new project proposal web page.
    8. Push button "Save" at the new project proposal web page.
    9. Edit the project proposal by using the provided template
    10. Push button "Save"
    11. Add link "#PROJ# - ODP1 - Project Proposal Document" to project details page at relevant documents of ODP Step 1.
  3. Define and send "call of participation" announcement
    1. Go to ODP Step Details page of ODP Step 1 (Project Proposal) of the newly created project aand to the tab "Information"
    2. Click on the link "#PROJ# - ODP1 - Call For Participation". A new page with the same name will be raised up-
    3. Select the template "CallForParticipation" by clicking on the link "Select a page template" and selecting and the list that will be shown up.
    4. Push the "Next" button, and afterwards push the "Save" button at the new page.
    5. Complete the "Call for Participation" template with the appropriate information.
    6. Push "Save" button.
    7. Add news by push link "Add news" at the left navigation pane. A new "News" page will be raised up.
    8. Edit title "#PROJ# - ODP1 - Announcement of Call For Participation"
    9. Go to "Wiki Markup" representation.

3.2 ODP2: Requirements Gathering

3.2.1 Activities

The project team engages stakeholders and domain experts to document requirements. The comment log may serve as the requirements document for projects that change existing publications.

3.2.2 Artefacts

Typical artefacts produced by ODP2 include:

  • Requirements Documents
  • Comment Log

3.3 ODP3: Internal Draft Development

3.3.1 Activities

The project team writes an internal draft while continuing to engage project stakeholders and domain experts as required. This draft must be substantially content-complete, but need not be polished.

3.3.2 Artefacts

Typical artefacts produced by ODP3 include:

  • Internal Draft
  • Comment Log

3.4 ODP4: Internal Draft Review

3.4.1 Activities

The parent PG circulates the internal draft within the group, to other PGs as appropriate, and among project stakeholders and contributing domain experts, inviting comments. The project team logs and processes comments, and circulates updated internal drafts. The comment/update/circulation cycle continues until the PG approves a project team recommendation to conclude ODP4. While the criteria, evaluation, and ultimate decision to conclude ODP4 is left to the PG, the PG must ensure that the project team has met all comment processing requirements (see later section).

3.4.2 Artefacts

Typical artefacts produced by ODP4 include:

  • External Draft
  • Updated Comment Log

3.5 ODP5: Public Review

3.5.1 Activities

The UNECE Secretariat publishes the external draft via the UNECE website. The FMG notifies Heads of Delegation and subscribers to email distribution lists that the external draft is available for review and provides them with review-process details. The project team logs and processes comments and posts updated external drafts and comment logs to the PG website or the UNECE website (through the Secretariat). The comment/update/posting cycle continues until the PG approves a project team recommendation to conclude ODP5. While the criteria, evaluation, and ultimate decision to conclude ODP5 is left to the PG, the PG must ensure that the project team has met all comment processing requirements (see later section).

3.5.2 Artefacts

Typical artefacts produced by ODP5 include:

  • Implementation Draft
  • Updated Comment Log

3.6 ODP6: Implementation Verification

3.6.1 Activities

The UNECE Secretariat publishes the implementation draft via the UNECE website. The FMG notifies Heads of Delegation and subscribers to email distribution lists that the implementation draft is available for implementation and provides them with details regarding the process for submitting comments. The project team logs and processes comments and posts updated implementation drafts and comment logs to the PG website or UNECE website (through the Secretariat). The comment/update/posting cycle continues until at least two independent implementations have been confirmed and the PG approves a project team recommendation to conclude ODP6. While the criteria, evaluation, and ultimate decision to conclude ODP6 is left to the PG, the PG must ensure that the project team has met all comment processing requirements (see later section).
If comments are received that require substantial revisions of the artefact the project goes back to the required previous step in ODP. Normally this means ODP3.
Implementation verification may not be possible or suitable for some artefacts. An exemption, fully or partly, can be decided by the FMG. The UN/CEFACT Plenary must be informed prior to approving an artefact.

3.6.2 Artefacts

Typical artefacts produced by ODP6 include:

  • ICG Submission???
  • Updated Comment Log

3.7 ODP7: Publication

3.7.1 Activities

The UNECE Secretariat publishes relevant project artefacts to the UNECE website. The FMG notifies Heads of Delegation and subscribers to email distribution lists that the release is available for implementation. What is ICG's role? Do any quality assurance activities occur in this step?

3.8 ODP8: Maintenance

During ODP8, organizations implement the release. Implementers may offer comments. The PG that oversaw the release's development will log all comments. If artefact stakeholders determine that a revision project is worth executing, they may initiate such a project at ODP1.

Appendix A: Comment Processing Requirements

Anyone may submit a comment on any CEFACT artefact at any time. The PG responsible for the artefact shall ensure that each comment is logged. The comment log shall include the following fields:

  • Comment Submission Date (in ISO 8601 format YYYY-MM-DD)
  • Comment-Period Identifier: identifier associated with a comment-period begin date, comment-period end date, and ODP step
  • Submitter's Name
  • Submitter's Email Address (all lower case)
  • Submitter's Delegation (if applicable; ISO country code)
  • Exact Comment: submission text, exactly as submitted, including any clarifying comments provided by the submitter
  • Edited Comment: Exact Comment edited to more clearly express the submitter's intent (default is Exact Comment)
  • Artefact: artefact name and version to which the comments applies
  • Reference: intra-artefact reference information to which the comment applies (e.g., line number or range, figure number, general comment on entire artefact or section)
  • Comment Processing State: See the section below for details.
  • Notes: an explanation of the comment processing state (required for comments in Comment Processing State M, R, D, N, and W)
  • Other fields specified by the PG
  • Other fields specified by the working group
    Figure 2 is a UML state diagram expressing Comment Prossessing State. The Comment Processing State field shall contain one of the following values:
  • Z: The comment was received at a time other than during a comment period. The comment is queued for processing.
  • Q: The comment was received during or before a comment period, or was a W-state comment assigned to a Q state, and has not been processed. The comment is queued for processing.
  • I: The comment is implemented as requested.
  • M: The comment is implemented with modification.
  • R: The comment is rejected.
  • D: The comment is deferred.
  • W: Waiting for clarifying information from the submitter.
  • N: The comment is not applicable (e.g., changes to draft artefact make the comment irrelevant) Additional comment processing requirements:
  • When a comment is initially received it is immediately transitioned to a Q state or Z state, depending on whether the comment was received during a comment period (see guards in Figure 2).
  • When a comment period starts, all Z- and D-state comments transition to Q state (see triggers in Figure 2).
  • Some comments may require clarification and in such cases the project group will email the submitter requesting such clarification. The submitter's original comment and clarifying comments shall be a Q-state comment if a comment period is in progress. If a comment period is not in progress, the working group will decide (based on their own publicly available written criteria) whether the comment is assigned a Q state or Z state.
  • All Q-state comments must be processed before ODP4, ODP5, or ODP6 may be declared complete.

Figure 1


Appendix B: Publication-Type ODP Summary

This table summarizes variations in the ODP-steps by publication type. An ODP step is complete when all required activities have been completed and all required artefacts have been produced.

ODP1

Step Name BS TS RE UG
Project Proposal and Team Formation
Activity BS TS RE UG
Permanent Group creates project proposal
FMG approves project proposal
Permanent Group issues call for participation
Permanent Group selects a project team leader and editors
Permanent Group launches team
Artefact BS TS RE UG
Approved project proposal
Project team contact list

ODP2

Step Name BS TS RE UG
Requirements Gathering
Activity BS TS RE UG
Document requirements
Create comment log
Artefact BS TS RE UG
Requirements Document
Requirements Specification Mapping (RSM)
Comment log

ODP3

Step Name BS TS RE UG
Internal Draft Development
Activity BS TS RE UG
Artefact BS TS RE UG

ODP4

Step Name BS TS RE UG
Internal Review
Activity BS TS RE UG
Artefact BS TS RE UG

ODP5

Step Name BS TS RE UG
Public Review
Activity BS TS RE UG
Artefact BS TS RE UG

ODP6

Step Name BS TS RE UG
Implementation Verification
Activity BS TS RE UG
Artefact BS TS RE UG

ODP7

Step Name BS TS RE UG
Publication
Activity BS TS RE UG
Artefact BS TS RE UG

ODP8

Step Name BS TS RE UG
Maintenance
Activity BS TS RE UG
Artefact BS TS RE UG

Appendix D: Glossary

  • artefact: Artefact refers to all material produced in the course of executing an ODP project. Some artefacts become publication component and others exist solely to support the ODP project. Examples include UML models, comments logs, project proposals, and emails posted on public listservs.
  • Applied Technologies Group: need definition
  • ATG: See Applied Technologies Group.BS: See UN/CEFACT Business Standard.
  • CAR:
  • CEFACT Activity Request
  • expert: Expert is an official United Nations designation for people whose anticipated contributions meet certain criteria. The expert criteria and how a person is designated expert is not addressed in this document.
  • FMG: See Forum Management Group.
  • Forum: need definition
  • Forum Management Group: The Forum Management Group coordinates activities among the PGs in support of UN/CEFACT's mission.
  • ODP: ODP stands for Open Development Process (specified by this document).
  • ICG: See Information Content Group.
  • Information Content Group: need definition
  • Legal Group: need definitionLG: See Legal Group.
  • Permanent Group: Permanent Group generically refers to TMG, ATG, TBG, ICG, and LG.PG: See Permanent Group.
  • Plenary: need definition
  • Project CAR:
  • Publication: Publication refers to technical standards, business standards, UNECE Recommendations, and user guides that are developed in accordance with the ODP and are published in the UNECE website.RE: See UNECE Recommendation.
  • Simple CAR:
  • TBG: See Trade and Business Groups.
  • Techniques and Methodologies Group: need definition
  • TBG16:
  • TMG: See Techniques and Methodologies Group.
  • Trade and Business Groups: need definition
  • TS: See UN/CEFACT Technical Standard.UG: See UN/CEFACT User Guide.
  • UN/CEFACT: UN/CEFACT stands for United Nation Centre for Trade Facilitation and Electronic Business.
  • UN/CEFACT Business Standard: Specifications established by consensus within the Forum and approved by the Plenary that provide rules, guidelines, and/or principals related to activities in the context of trade facilitation or electronic business.
  • UN/CEFACT Technical Standard: Specifications established by consensus within the Forum and approved by the Plenary to establish how one or more Business Standards and/or Recommendations shall be developed.UN/CEFACT User Guide: Informative (in contrast to normative) documents and/or audio/video productions that provide guidance to publication implementers.
  • UNECE: UNECE stands for United Nations Economic Commission for Europe.
  • UNECE Recommendation: Trade facilitation or electronic business standards that provide formal guidance to governments, the private sector, and the business community.