Monologue
As I write this question I have already prepared myself psychologically that very soon this question will be flagged and closed as being too broad and general than specific. I am prepared for that as I feel the same too. Nonetheless I must ventilate my doubts to the community which has been indispensable to my survival in IT.
Context
Designing a ticket based knowledge management system
Problem
While reading about ITIL V3 and IT Service Desk I pondered that if I were to build a trouble ticket based knowledge management system where users can raise tickets for any problem/incidents and get its resolution which can then translate to a knowledge base then what could be the approach?
The traditional ITIL V3 jargons of Incident/Problem---> Service---->Resolution------> Knowledge actually are too conservative and cumbersome to my opinion.
When I compare that to the Stackoverflow design of handling questions/answers I find the latter to be far impressive. Stackoverflow has the same concept of Questions (read tickets) and corresponding answers (read resolutions) to a question (again read ticket).
What are some of the good designs for knowledge management against a trouble ticket? Isn't stackoverflow another great knowledge management system against tickets (questions)?