Easily generate/ view a table of OIDs
What problem(s) will it solve?
It is difficult for trainers to quickly discern the levels at which OIDs are mapped and the direct mapping to topics. Also, the formatting and consistency of the MTTL needs to be ensured across multiple levels - multiple means of validating, reinforcing, and visualizing the implementation of the schema would be helpful.
Who is the intended user(s)?
As a trainer, I want to be able to see a table that shows the relationship between OID(s) and topic, so I can ensure correct mappings and make sure that part_1s and objectives are being created correctly. Product owners and customers might also benefit.
Trainers will use this to ensure that OIDs have correct correspondence at the topic level. Also, they can use it as a 'goto' reference when looking and verifying in the MTTL.
Product owners, developers, and (knowledgable) customers might also use this functionality when considering mappings in the MTTL to training as well as artifact (part_1 and objectives) generation.
Lay out the expected user experience
Given - there is a trainer mapping training to rel-links in the MTTL, or even consolidating groupings, When - that trainer adds mappings and checks artifacts, Then - the trainer should have a means to quickly reference the specific mappings of OIDs
Proposal
A CLI script or perhaps (even better for POs, Customers, Visitors) a link on the MTTL page that generates a table showing how an OID maps to a topic.
| OID | Module | Topic | KSATs | Artifact Path |
|---|---|---|---|---|
| 12345 | IDF | Networking | A0101 | mdbook/src/Wireshark/ |
| K1234 |
Further details
The MTTL schema and its implementation more so has not been as thoroughly documented or as transparent as it could be. For a trainer, especially a new trainer, or a supervisor of trainers and training development a quick overview could be very helpful in understanding the current state of the MTTL especially with regards to training mapping and generation of artifacts.
Permissions and Security
This only reads publicly available information in regards to the MTTL and Training.
Documentation
This should be documented with other aspects of the MTTL. The necessity for documentation will depend on implementation. A CLI script would require more extensive documentation than a link to a web page.
Update User Documentation
- This should be listed in the MTTL documentation. It could be used to support MTTL documentation and its functionality should be documented.
Availability & Testing
This should not affect availability as it basically just reads from the MongoDB.
What does success look like, and how can we measure that?
Success Metrics/Criteria
Trainer proficiency, accuracy, and speed in making adjustments to the mttls and rel-links will be improved.
Supervisors of trainers and perhaps other QA can use this information to ensure the existence and quality of unique OIDs at the 'topic' level.
This solidifies shared understandings of OID use and implementation across all levels i.e.
customer -> trainer -> developer -> product owner -> DO -> etc.
Acceptance Criteria A (new) trainer should be able to quickly (i.e. in less than 2 minutes) be able to generate and view a mapping of OIDs to topics (and artifact paths).