Java Workflow Toolbox JWT Release review Component Version

Java Workflow Toolbox (JWT) Release review: Component Version Florian Lautenbacher (University of Augsburg, DE) Marc Dutoo (Open Wide, FR) Other committers Confidential | Date | Other Information, if necessary © 2002 IBM Corporation

Notice Documentation about Release Review. Can also be found under: http: //www. eclipse. org/projects/dev_process/release-review. php Code contribution should have been announced under the My. Foundation portal incl. who had been working on that, which license is used, which bug has been opened for this contribution, etc. Eclipse Foundation, Inc. | © 2007 by Open. Wide / University of Augsburg and made available under the EPL v 1. 0 2

Features Summarize the major features of this release as well as any other features that have generated significant discussion amongst the community during the development cycle. Compare the features against the Roadmap to understand the project's conformance or divergence. Eclipse Foundation, Inc. | © 2007 by Open. Wide / University of Augsburg and made available under the EPL v 1. 0 3

Non-code aspects Summarize the state of the non-code aspects of the release including: user documentation, localization/externalization, examples, tutorials, articles, and so on. Have the existing artifacts been updated? Are there new artifacts? Have the obsolete ones been retired or at least marked as pertaining only to older material? Eclipse Foundation, Inc. | © 2007 by Open. Wide / University of Augsburg and made available under the EPL v 1. 0 4

APIs Certify that the APIs in this release are Eclipse Quality. The project lead will personally certify that the requirements for quality have been met and/or discuss any deficiences. Eclipse Foundation, Inc. | © 2007 by Open. Wide / University of Augsburg and made available under the EPL v 1. 0 5

Architectural issues Summarize the architectural quality of the release. Discuss the intrinsic nature of being extensible embodied by this project. Discuss issues such as unresolved overlap with other projects, unpaid "merge debt" from incorporating various components, and so on. Eclipse Foundation, Inc. | © 2007 by Open. Wide / University of Augsburg and made available under the EPL v 1. 0 6

Tool usability Summarize the usability of the tools. Usability in this sense is about using the tools to solve development problems, not the more academic sense of UI evaluation/testing. Eclipse Foundation, Inc. | © 2007 by Open. Wide / University of Augsburg and made available under the EPL v 1. 0 7

End-of-Life Summarize the features (APIs and any significant user features) from previous releases that are being end-of-life'd in this release. End of life includes both deprecation and actual removal. Eclipse Foundation, Inc. | © 2007 by Open. Wide / University of Augsburg and made available under the EPL v 1. 0 8

Bugzilla Summarize the bugzilla situation. How many bug records (defects and enhancements) have been opened/closed/deferred/new, etc? How many P 1, P 2, . . . , bug records are outstanding? Eclipse Foundation, Inc. | © 2007 by Open. Wide / University of Augsburg and made available under the EPL v 1. 0 9

Standards Summarize the standards compliance of this release. If the features are based on defined, pending, or ad-hoc standards, what is the state of those standards and what is the state of the support for those standards in this release. Eclipse Foundation, Inc. | © 2007 by Open. Wide / University of Augsburg and made available under the EPL v 1. 0 10

UI Usability Summarize the user interface usability and the conformance to the Eclipse User Interface Guidelines. Include section 508 compliance, language pack conformance (does the code support multiple languages), etc. Explain any deviations from the user interface guidelines and standards. Eclipse Foundation, Inc. | © 2007 by Open. Wide / University of Augsburg and made available under the EPL v 1. 0 11

Schedule Discuss the initial schedule and any changes to the schedule over the course of the release, i. e. , what the project team achieved. Discuss whether milestones were met or slipped. Eclipse Foundation, Inc. | © 2007 by Open. Wide / University of Augsburg and made available under the EPL v 1. 0 12

Communities Summarize the project's development of its three communities. Consider the interactions on bugzilla, the mailing lists, the newsgroups, public conference calls, blogs, PR activities, code camps, conference tutorials, coordinating with other Eclipse projects and other open source projects (Apache, Object. Web, etc), . . . Eclipse Foundation, Inc. | © 2007 by Open. Wide / University of Augsburg and made available under the EPL v 1. 0 13

IP Issues As per the Eclipse IP Policy, these steps must be done: The project leadership verifies that: . . . that the about files and use licenses are in place as per the Guidelines to Legal Documentation. . . . all contributions (code, documentation, images, etc) has been committed by individuals who are either Members of the Foundation, or have signed the appropriate Committer Agreement. In either case, these are individuals who have signed, and are abiding by, the Eclipse IP Policy. . that all significant contributions have been reviewed by the Foundation's legal staff. Include references to the IPZilla numbers of all clearances. . that all non-Committer code contributions, including third-party libraries, have been documented in the release and reviewed by the Foundation's legal staff. Include references to the IPZilla numbers of all clearances. . that all Contribution Questionnaires have been completed . . . the "provider" field of each feature is set to "Eclipse. org" . . . the "copyright" field of each feature is set to the copyright owner (the Eclipse Foundation is rarely the copyright owner). . that any third-party logos or trademarks included in the distribution (icons, help file logos, etc) have been licensed under the EPL. . . . that any fonts or similar third-party images included in the distribution (e. g. in PDF or EPS files) have been licensed under the EPL. The PMC provides a Project Log that enumerates: every piece of third party software including information on the license Eclipse Foundation, Inc. | © 2007 by Open. Wide / University of Augsburg and made available under the EPL v 1. 0 every major contribution 14

Project Plan If there is a Project Plan (full or even a draft) for the next release, the final issue to cover in the Release Review is the unveiling of the new plan. Eclipse Foundation, Inc. | © 2007 by Open. Wide / University of Augsburg and made available under the EPL v 1. 0 15

Preparing the docuware In any case, the docuware must be/have: Neutral File Format. The docuware must be published in an operating-system neutral file format. PPT and DOC files are not considered neutral. PDF is currently the best choice and thus we require docuware to be published in PDF. The EMO can convert Open Office and Microsoft Office to PDF if you are unable to do so. Archival Quality. The docuware must be comprehensible and complete on its own without requiring explanation by a human presenter. Archival quality is required because the docuware will be available on the eclipse. org website in perpetuity; future Eclipse users, adopters, and even new project committers will consult it long after the review conference call has been completed. Correct Copyright and License. The docuware is being written (and thus copyrighted) by you, not by the Eclipse Foundation, and thus the copyright statement needs to be by you (or your employer). Similarly, the content should be licenses under the EPL. Usable for a Phone Conversation. Remembering that most conversations about the docuware will be done over voice, email, IM, or other electronic media - not in a face-toface situation - the docuware must have page and/or paragraph numbers so that the two parties in conversation can easily refer to the same section or slide. Eclipse Foundation, Inc. | © 2007 by Open. Wide / University of Augsburg and made available under the EPL v 1. 0 16

The Review Process Once the review content has been created, the operational side of a Release Review is: Schedule the review by sending email to emo@eclipse. org. Reviews are scheduled at most twice a month, usually on Wednesdays, usually in the morning (USA)/afternoon (Europe)/night (Asia). Reviews are grouped up to four at a time. At least one week in advance of the review, you (the project lead) sends the docuware to emo@eclipse. org for posting. The EMO posts the docuware via the website (through the wonders of database-driven web pages, the docuware is automatically linked from the review notice). At least one week in advance of the review, the EMO creates a bugzilla entry for discussion and advisory voting by the membership. (See example. ) The EMO announces the reviews: via the eclipse. org/projects web page (as soon as the review is scheduled) via the reviews and announcements RSS feed (as soon as the review is scheduled and again when the docuware is posted) via email to the committers and membership-at-large mailing lists (at least one week in advance of the review conference call) The review conference call is held at the scheduled time. The project lead must attend the call. These calls tend to be short (5 -10 minutes). The purpose of the call is for the team to answer any questions from the community that have not otherwise been answered by the written material and/or discussions in the newsgroup. After the call, a one-to-two week open discussion and advisory vote is held via the previous Eclipse Foundation, Inc. | © 2007 by Open. Wide posted bugzilla. / University of Augsburg and made available under the EPL v 1. 0 17

Notes The Eclipse development process document and the Guidelines document have been read and approved by the project leads and committers of the JWT project. Eclipse Foundation, Inc. | © 2007 by Open. Wide / University of Augsburg and made available under the EPL v 1. 0 18