 | Manufacturing Technology a Industrial Systems Task Force |  |
| | Manufacturing Technology a Industrial Systems Task Force | |
This page is created as a working page for teams evaluating Technology Submissions on behalf of the Manufacturing Technology and Industrial Systems Task Force. This itself is not a chartered working group of ManTIS. Each of the Evaluation Teams is chartered for each technology evaluation.
The Evaluation Team:
Since each RFP and submission situation is different, the Evaluation Teams are each responsible for determining their approach to the organization of the material, the report, and the recording of issues.
[However, evaluation guidelines are provided in this page.]
Goals: It is important to note that changing the submissions is not the goal, but rather to ensure that the submissions:
Membership: Any OMG members that show up and contribute to the Evaluation Process is a member of the team (the same way membership in a Task Force is determined). In each of the teams listed below we start with a list of folks who have committed themselves to make a contribution and actively participated in the evaluation. The list will be updated from meeting lists and memo logs. The Evaluation Team Chair will keep the WebEditor apprised of the participants and the need for any other updates to this Web Page.
The Task Force thanks these people who make the process work!
The Task Force approval portion of the adoption process was made a two meeting process in March of 1998… immediately after the adoption of the PDM Enablers. (coincidence?… remember what a madhouse that was?). The reason is to make the process more considered and deliberate.
At Meeting A (the Review Meeting), a pre-organized ManTIS Evaluation Team heads up the review of the submissions and provides feedback to the general Task Force and to the Submission Team in the form of an Submission Issue Log. The submission teams take the feedback and prepare Errata which are posted before the three-week rule of Meeting "B". The Errata include those things that the Submission Team agrees needs adjustment. The Submission Team prepares a response to all issues, including those with which it disagrees and does nothing. The time between meetings A & B is used for submission team and task force discussion of issues brought up in the review.
At Meeting B (the Approval Meeting), The Evaluation Team presents its Evaluation Summary. The taskforce takes this summary under advisement as it reviews the Errata and the Issue Log Repsonses and makes any final recommendations (that may result in the errata being revised). The TF then votes on recommending one of the submissions for adoption (together with its respective errata). If there is only one Submission, it is voted up or down. The vote is restricted to those on the Voting List for the RFP. If the vote passes, the AB reviews the submission. (Additions to the errata may be required to gain their approval.) If the AB approves it, the recommendation for adoption by the TF is passed on to the DTC plenary and the 10-week vote begins. If no submission is recommended by the Task Force (changes required are beyond what should be done through an Erratum), a new Revised Submission date can be established by those on the Voting List of the pertinent RFP.
The 2-meeting cycle for adoption can be short-circuited by a "Vote-to-Vote". In this scenario, the TF votes in Meeting A to consider recommendation in this first meeting. If this vote succeeds (requiring 3/4... yes, 75%... of those Voting List members who are present, subject to Voting List Quorum), there can be a vote in "Meeting A", sending the adoption to DTC plenary. This is for submissions that have an over-whelming consensus (with little or no contention) and very little feedback in the Task Force.
The Evaluation Team keeps an Issue Log for each Submission. This log is very similar to the FTF/RTF reports and contains the following information for each issue (note there is no Revised Text as in an FTF/RTF report because this is recorded in the Erratum to the Submission.
The Submission Team takes the Issue Log prepared for it by the Evaluation Team and answers each issue. Issues that are one of the "accepted" dispositions will result in errata that address that issue. The other issues are disposed through explanation in the "Resolution".
| Issue Disposition | Disposition Explanation |
|---|---|
| Open | (Not yet addressed... shouldn't be in final version of response.) |
| Accepted | Errata accommodate changes as requested. |
| Accepted in principle | Errata fix the Problem cited, but not necessarily in the manner suggested. |
| Accepted in Part | Errata fixes part of the Issue... the rest of it can be considered Rejected. |
| Resolved in Issue n | This was rolled up with another issue and is fixed as part of that. |
| Resolved by reference/clarification to nnn | This is an issue that indicates the Evaluation Team does not understand or missed something in the Submission. The Resolution contains the explanation of why nothing needs to be done in the Erratum, citing the Submission. |
| Unclear | We couldn't figure out what was wanted (and the source of the issue couldn't be identified or reached.) |
| Rejected | We agreed NOT to do what was requested, or anything like it. |
| FTF | This is an issue which must be accommodated, but some additional thought (or implementation experience) is required. This sort of disposition is somewhat frowned on, but it happens. These are fed forward to the OMG Issue Log on acceptance of the specification and formation of the FTF. |
| RFP | A good issue, but falls primarily outside of the scope of the RFP being addressed by this submission and can only be addressed through another RFP. The Task Force often folds these into the Roadmap. The evaluation team may wish to record this issue and give it this disposition at the outset. This helps feed the roadmap. |
The Revised Submission is posted on or before the 3-week rule for an OMG TC Meeting that is to be the Review Meeting. Immediately the Evaluation Team begins its task. As the Submission becomes more widely scrutinized, many "nits & gnats" are uncovered. The Submission Team begins to develop an Errata to the Revised Submission. The Errata describes the changes required to correct the discovered problems.
The Errata should be relatively minor changes, such as:
Major changes are frowned on and can cause the Submission to be turned down, even if it is the only one. Major changes can include:
What constitutes changes beyond what should be undertaken in an Errata is left to the judgement of the Task Force and the Architecture Board (and ultimately, the overarching Technical Committee).
As the Errata are being compliled, the Submission Team edits their Revised Submission according to the directions of the Errata to produce a Change Bar Marked document. This is a convenience document that is used for assessing the submission. However, the documents that are voted on in the process are the normative documents, the Revised Submission together with its Errata
[Note: Submission Editors should ensure that all tracked changes have been accepted in their Revised Submission (no longer marked as a change) and that "Change Tracking" is On when applying each Erratum]
In the Approval Meeting, before the Vote to Recommend Adoption, the Evaluation Team presents its report to the Task Force on its assessment of the Submissions and its recommended course of voting.
Reports in the Past have included:
The recommendation of the Evaluation Team is not binding on the Task Force. Based on all information and personal assessment, the members of the RFP Voting List will make their recommendation to the over-arching Technical Committee.
Under Construction.
Last updated on: 11/09/2007