User Tools
The teleconference notes for April 15, 2010 include the following topic:
Terms of Reference (ToR), including: a. Develop guidelines for machine readable files that must accompany submissions b. Minimal set without which submissions and F/RTF reports will not be considered complete enough for consideration at the meeting. c. Assistance that can /needs to be provided in the way of tooling and best practices d. Any additional items e. Resulting changes in SMSC processes for acceptance of documents and publishing of documents.
I would add the following:
f. guidelines for using configuration management techniques at the level of machine-readable files & specification documents resulting in accurate traceability of all changes made
Without (f), it is difficult to do (a), (b) and © above.
Change management starts when someone commits to develop a resolution for an issue and propose it for consideration to the FTF, RTF…
Our current practices and processes depend on email, the lowest common denominator we have. There is clearly better technology for issue management than email. Until the OMG commits to adopting a better technology for issue management, we will have an OMG cottage industry of ad-hoc processes. – BMI, BPMN, UPDM, SysML, UML, ODM, OCL, …
Additional topics for the ToR:
g. issue acceptance/editing
Anyone can submit an issue to the OMG; we lack the distinction between accepting to resolve an issue vs. clarifying an issue with the submitter. Why should we waste scarce resources formally resolving bogus issues that shouldn't even have been accepted in the first place if we had done an acceptance review? The burden of proof that there's a legitimate issue should be with the submitter, not with the OMG working group resolving it.
h. Know your OMG history.
The “Work in Progress” page is great for tracking current work – intermediate submissions, reports, etc.. These pages are still around but they are not easily accessible. In particular, if someone wants to look for, e.g., the report for a previous version of a given spec, then it's “good luck to you”. That's inefficient. We need to catalog both the specifications and their machine readable artifacts as well as the issues, the issue resolutions, the ballots and the reports.
i. SUnit
The current acceptance criteria is that implementations of a spec must exist. Many engineering disciplines use a concept of unit test case, e.g., JUnit, CppUnit, etc.. in software engineering. We should have SUnit for Specification Unit Test case and do continuous integration/build/execution of SUnit test suites.
