OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: 00cf22.pdf



Karsten,

Klaus gave me two html files that should be used: 1) eBTWB Project
Proposal, and 2) User Guide to UN/CEFACT's Open Development Process for
Technical Specifications.  These do not look like CEFACT/2000/22, but are
specific to the ad hoc group being formed.  Go with these. Proposals should
be sent to the bBTWG ad hoc group chair as soon as a chair is announced.

Regards,

Paul
(See attached file: eBTWG-Project Proposal.html)(See attached file:
userguide.htm)


                                                                                                  
                    Karsten Riemer                                                                
                    <Karsten.Rieme        To:     ebxml-bp@lists.ebxml.org                        
                    r@Sun.COM>            cc:     (bcc: Paul R. Levine/Telcordia)                 
                                          Subject:     00cf22.pdf                                 
                    07/19/01 06:10                                                                
                    PM                                                                            
                    Please respond                                                                
                    to Karsten                                                                    
                    Riemer                                                                        
                                                                                                  
                                                                                                  





The process for UN/CEFACT project proposal is at:
www.unece.org/cefact/docum/download/00cf22.pdf
It starts with a 'proposal', then a small editing team writes a first
working
draft of the actual specification. It does not contain anything about
format
of the proposal. Paul, will you find out if there is a required format,
if not, I will just write it as an e-mail. Who should I send it to.
Also please confirm, that this the above URL is in fact pointing to the
right
process. It only mentioned WG, not ADHOC groups.

-karsten


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org

Title: Project Proposal - e-Business Transition Ad-hoc Working Group (eBTWG)

eBTWG Project Proposal

Project Name

1. Objectives

1.1 Purpose

The purpose of the project is to ...

1.2 Scope

The project relates to the eBTWG key delieverable .... identified in its mandate (or workplan).

2. Deliverables

The deliverables by the project are:

  • Name of output document(s)

3. Functional Expertise of Membership

The project team is a group of experts with broad knowledge in the area of ....... Each UN/CEFACT head of delegation may designate one or more experts to the project team. In doing so, they may delegate this task to one or more organizations, which may be national, regional or international. Experts are expected to contribute to the work based solely on their expertise.

4. Geographical Focus

The focus is global (or sectorial/functional area).

5. Initial Contributions

The following contributions are submitted as part of this proposal. It is understood that these are only for consideration by the project team and that other participants may submit their own contributions in order to ensure the gathering of as much information as possible from those with expertise and a material interest in the project but at the same time allow diverse voices to comment on the details of the projects and ensures that no single organization can dominate the process.:

  • list of contributions


Statement of resource requirements

Participants in the project shall provide resources for their own participation. The existence and functioning of the project shall not require any additional resources from the UN/ECE secretariat.

Title: User Guide to UN/CEFACT's Open Development Process

User Guide to UN/CEFACT's Open Development Process for Technical Specifications

Author: Klaus-Dieter Naujok, CSG member and Editor of UN/CEFACT's Open Development Process

Introduction

In March 2000 the UN/CEFACT approved document TRADE/CEFACT/2000/22 (UN/CEFACT's Open Development Process for Technical Specifications) to serve its Working Groups in an effort to encourage electronic working using an open and inclusive process that produces high-quality specifications in "Internet-time."

TRADE/CEFACT/2000/22 outlines in detail the process to be followed, however, many readers have suggested that a simple user guide outlining the steps in more detail would aid in usage of the new process. This document is intended to be that user guide.

The Process - Step by Step

Step 1 - The Proposal

A request for a new project proposal should be filed directly with the appropriate UN/CEFACT Working Group. The Working Group's first step is to form a project team and assign a project team leader.. This is achieved by publicly calling for participation in the project and announcing the first meeting date. The WG shall appoint a project team leader before the meeting. During the first meeting of the project team, the participants present shall appoint a small editing team (not more than 5, ideally 3 is a good number). The editing team shall select its Project Editor. The editing teams function is to work on the specification taking into account directions form the project team as well as comments submitted during the review process.

Step 2 - The Requirements List

After the creation of the editing team, the project members begins their work by compiling a requirement list.This shall take in to account any contributions that where submitted to the WG in response to the call for participation and contributions. Discussions should involve the project requesters, participating contributors as well as industry experts, software developers, end-users, and implementors. The goal is to gather as much information as possible from those with expertise and a material interest in the project but at the same time allow diverse voices to comment on the details of the specification and ensures that no single organization can dominate the process. The team shall agree to the requirements list before moving to the next step.

Step 3 - 1st Working Draft

The editing team, taking in to account all contributions, the requirements list and directions that where passed on by the project team, shall write the first working draft. It is not expected that this draft is a nearly final, polished version, but a document that is suitable for review and comments. In order to move to the next step the project team must have reached consensus.

Step 4 - Internal Review of the 1st Working Draft

The first working draft is distributed to members of the responsible Working Group, as well as technical implementors and interested industry experts that serve as virtual members to the project for their review and comment. This initial review serves to identify potential problems, point out areas for improvement, and to build consensus. The editors collect the comments, revise the working draft, and re-circulate it until the reviewers are satisfied with the content. The goal is to get the first working draft into a form suitable for public review as quickly as possible. After reaching agreement within the project team to move to the next step, the working group is requested to approve that request.

Step 5 - Public Review

After reaching agreement on the 1st working draft, the project team or working group publishes the second working draft at their web site. This will allow the public world-wide to review and comment on the specification. The public review period lasts for at least a month (or longer if there are many comments). The editing group collects the comments, criticisms, and suggestions from the public, to further refine and improve the specification. As changes are made, the updated document and disposition log will be republished at the web site. This will allow everyone to not only see the changes, but also the rational behind them and reasons for suggestions that were not accepted. It will be up to the project team to determine when consensus is reached in order to request that the working group approves their request to move to the next step.

Step 6 - Implementation Verification

After approval by the working group the final specification and its disposition log will be posted to the UN/CEFACT web site to allow verification through implementation. Implementors (especially those that contributed to the working draft) are encouraged to verify the validity of the technical specification by implementing them. The verification review period is the most critical part of the development process as problems and issues are identified. The editing group collects the problems and issues identified from the implementors, in order to further refine and improve the specification. As changes are made, the updated document and disposition log will be forwarded to the implementors, as well as being re-published at the web site. This step will be completed when least two independent implementations report successful implementation which is confirmed by the project team.

Step 7 - Final Technical Specification Release

After the successful verification the Working Group releases the work as a UN/CEFACT Technical Specification available for download at UN/CEFACT's web site. The specifications are published as part of the "UN/CEFACT Technical Specification Series". These printed versions, translated into various languages, will be available world-wide at moderate cost from the UN/CEFACT secretariat and/or International Industry User Groups. When the final specification is released, the project team has completed its work and disbands.

Step 8 - Maintenance

As the specification is implemented in various industry and business sectors the responsible UN/CEFACT's Working Group may receive feedback that points out problems or suggests improvements. Maintenance of the specification is handled by forming a new project team and editing group (where deemed necessary by the Working Group) and restarting the process at step 2 with the errata and suggestions forming the core of the new requirements list. The Working Group will maintain a list of problems, errors and misprints at their web site so that the public can access them as easily as the Technical Specifications.

Additional Comments and Notes

Intellectual Property Rights

To satisfy UN/CEFACT s goal of openness, everyone that makes a contribution to must agree to remove any IPR constraints or restrictions that might be associated with their contribution.

Consensus

The preferred way of reaching decisions shall be by consensus. (Consensus is characterized by the absence of significant and sustained opposition). However, the Project Team Leader (WG Chair) shall have the authority to call for a vote if, in the Project Team Leaders's/Chair's view, consensus cannot be reached on a particular issue. A vote may be called for in a physical meeting or electronically. If in a meeting, the meeting must be quorate and only those members present may vote. For a decision to be approved, a qualified majority of 75% of the votes cast is required and abstentions shall not count as votes. If electronically, the Project Team Leaders's/Chair shall give able notice of the intention to call for a vote. For a decision to be approved, a qualified majority of 75% of the votes is required and abstentions shall not count as votes.

Role of the Project Team Leader and Project Editor

In order to separate the responsibilities of managing the project, running the meetings (both virtual and physical), and editing (creating and updating) the technical specifications two separate roles are identified for each Project team. The role of the project team leader is to be managing the project's time table and conduct the teams meeting. The role of the project editor is to head up the editing team and conduct its editing session. The Project Team Leader and Project Editors shall work closely together in determining the Project Teams consensus.

Format for Technical Specification out for Review, Comments against the Specification and Disposition Log

Technical Specifications out for review shall have each line start with a unique line number to allow reviewers to place their comments against them.

Reviewers commenting shall format their comments by providing for each comment, the specifications line number range, the comment itself, the rational for the comment, and suggestion for change.

The disposition log shall contain all comments received, ordered by line number progression. The comments shall also include the name of the reviewer, the rational and suggestion for change. In addition the editing team and/or project teams action against that comment shall be included.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC