categories: help-systems,wiki,forum,Explorations,email-list
discussion : DF Documentation/Exploring Help systems semantics
online help systems
help systems / list
- documentation (man pages @, tutorials, manuals, guides)
- email lists (async,threaded discussion,delete?,bot protection?,)
- instant messaging
- irc (sync,discussions,delete?,linear,short message granularity)
- blogs (async,personal)
- forum (async,discussions,delete,manyusers,archive)
- wiki (async,manyusers,delete,sharing,text co-editing)
- phone (sync,coice,video)
- offline (sync,multidimensional)
- conferences
traits: spam protection, llm-bot crawlers protection , human-comp time-resources requirements (lightweight - heavy axis) , robustness (easy to repair,reproduce) , points of control (centralized - decentralized ), organization options , data formats supported, user-time constraints.
We must recongize types of telecomm functionality and later see how comm-system match them.
help systems / time-critical (minute response)
A user wants help now --> phone,irc,im (Lets say an irc helper always accept memos via memoserv and answer the other day, what would the difference if they used email. The system must establish sync comm channels between parties.Semantics are that you send data, are received and answer is get nearly instantly because otherwise a party can leave. Which is exactly what you would do on the phone!. I think telling a user in irc,im to wait breaks the semantics and moves them toward other types. What's the difference telling her/him to leave a message (memoserv) and thus send an email .)
Interestingly in our times llm-nn bots (continuing a trend from smartphone apps) spoil us in thinking that every help we want is timecritical and can be handled now. (that's how it gathers momentum and attention.. by spoiling us ) NEVER an hyped-ai bot would tell you come back tomorrow for an answer.How it does that magik? (that's its weakness. cant solve new question.Is documentation based, documentation access on steroids.)
Also the user time-critical requirement create schedulling requirement in an organization. Having an irc channel doesnt mean that a project offers near-instant help. That's the easiest part. A project must find 1) members willing to stay alert for certain hours 2) members highly experienced and fast ! Highly experience because you dont have time to ask more help from others . So maybe you need many members specialized.
help systems / not time critical (daily-weekly response)
A user wants not time critical help --> email lists , forums, docs . A user has more time to prepare her/his issue preparation and the helper more time to answer. I think a forum offers better organization-management options and accessibiliy of the posted issues but at the cost of being more centralized . An email-list i think is most robust (to malfunctions), more decentralized (since each user has copies in his email )more easy to maintain , claims less comp-resources on a project's infrastructure and probably more resistant to aggressive crawlers. Since it's less sexy it could be usefull for more aged and experienced users and as a backup help async system. That traits should not be overlooked for libre software projects.
help systems / not time critical (dead responses)
dead help / docs
By dead response i mean docs! (its dead..and could be written from dead people also)) LLM-NN driven bots excel at dead driven help! So a project could say at it's main entry help landing page. For DEAD help you could use a ultra-hyped AI bot. And that would be truth. It's dead help. Humans working on AIcompanies facilitate datacenters at hoarding docs scattered all over the cyberspace but do not process user queries.
Documentation is a catalogue-archive of past common help cases.
dead help / wikis
I argue that a wiki is the main tool what will build the Documentation. A good documentation should be co-edited. A wiki is not for helping user. The documentation produced would help user. BUT!! there are wikis that offer help all over the internet. But a user using eg: the debian wiki wont coedit it!! But a wiki's main functionality is co-editing! So when we say go to visit debian's wiki i think we mean go see the docs produces by a wiki.
Various comm systems match user's attention to devuan sysadms,developers attention.
Could blogs-forum-wiki-email lists get united? What means united ? All are async and text based. A blog system is personai. But i use devuan wiki as personal blog! (but wiki allows others to coedit my pages -permissions permitted-) But anyway a wiki contains a blog functionality. Email-list dont allow editing of past messages. A wiki supports interlinks! (aha) . An email message can contain links to other emails? So for the moment i email-list seems simpler (no login,no links)
wikis systems
wikis / projects
- dokuwiki
- nYAW
- PmWiki
- FossWiki
wikis / semantics
wikis / semantics / in the context of other collaboration systems
@ nYAW has a nice semantics framing of how email-forum-chat-wiki are all essential aspects of a cybercommunity . It aligns with my semantics on the possible mutual help that these communication systems could bring to each other.
wikis / semantics / analogies
I think the best analogy and a good canditade of a current semantics-alignment target is a hospital and a library. What online comm system is best suited for users? developers ? . It's interesting that going to a hospital AO you can experience a reality shock since your case may be lower priority than you thought and have to wait..
At various comm types various comm systems could be more suitable . Here is a very preliminary sketch:
- Admission office of emergencies (AO) <--> irc , instant messaging (could put you in ER if needed)
- Emergency(ER) <--> irc , im , audio-videocalls-conference , offline (you need stuff 24/7 ! .Think how llm-bots are always near you & available like you are always in ER :-) )
- Wards <--> email,forums (a user issue is still open but doesn need immediate attention or tapping on im channels). Periodic monitoring --> forum,issue tracker discussion,email,wiki.
- Outpatient department (wkp@) <--> issue-trackers , email,forums . Time aspect: in Hospitals you close an appointment. Here you async but dedicate channels to stuff-user comm.
- Discussion rooms
- discussion rooms / medical teams <--> forum , wiki
- discussion rooms / training
- discussion rooms / patients consulting
- Hospital's library <--> documentation (precipitates from a wiki system)
- Team size (small-irc, big-wiki,email,forum)
- Structured, form-based comms (issue tracker, email , forum)
- Time-critical (irc)
- Stuff coordination (forum,wiki)
- Reflection , cataloging (wiki)