Hi Folks.
We spent quite a while talking through the Troubleshooting topic. First let me say that Bob Thomas did an excellent job of describing the new approach and providing sufficient resources and examples to get prompt and thorough feedback from the experts on the
call. Great work, Bob!!
Michael Priestly quickly understood the design intent and found no "technical" issues with this approach. The conversation switched quickly to the business cases and requirements. Michael has been discussing with Robert Anderson about how to re-architect "steps"
in a way that makes the structure available in all topic types. Our SC was quick to encourage further work. (See official TC minutes for details and actions.)
For now, I want to enumerate some relevant topics that we should be prepared to cover in next meeting (2 weeks from now):
- Archetypical considerations: I relayed Rob Hanna's concern that specializing Troubleshooting from Task "demotes" it in such a way that it's not considered a "top-level" archetype/infotype. We spent some time asking, "Is Troubleshooting a type of
Task?" Most of the vocal participants sided with "yes." However, I asked whether a specialization must follow a semantic inheritance when it is very likely that structural requirements will make it impossible to follow this philosophy. Michael's response was,
"practicality trumps philosophy every time." So, while it's desirable to have a clean semantic inheritance model, it's not necessary, which--to me--means that we should not put any archetypical weight on the inheritance model.
- Steps as a domain: If Michael and Robert decide to enable steps to appear in other topic types (as a child of "section"), then we have more options in the Troubleshooting specialization. Bob's proposal already shows "remedy" as a "section" specialization,
which means the existing proposal (from general task) could be tweaked OR we could choose to specialize from "topic", though that was not a popular option. Regardless, there is an option, so let's be prepared to give our recommendation in 2 weeks.
- Programming SC is closing down: In response to an OASIS request to close down SCs that are not active, the TC is planning for how to deal with the Programming SC, which was approved, has completed work, but never fully launched. First preference
is to find a new Chair and fire up the SC. If that doesnt work, the API specialization and some unfinished work would need a new home. We should be prepared to accept or reject this work in 2 weeks.
|