The officially official Devuan Forum!

chomwitt

Member

From: Greece

Registered: 2019-09-24

Posts: 214  

Website

Exploring Help systems semantics

An effort to explore help system semantics.

I try differentiate what a helping's system main functionality is and how a user or a project's member uses it.  So an irc channel has memoserv but i dont think is a goodidea in irc to tell user to memoserv their issues. Also a wiki can create docs but a user wont use a wiki's main functionality(co-editing). Also using a forum to have a chit chat while being both 'online'  again is not a forum's main functionality.

----online help systems list----

• documentation (man pages, manual, tutorial etc)

• 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 etc

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, markup language used (should email,forum,wiki support the same markup? i think yes), acl (access control lists).

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 .

The system must establish sync comm channels between parties. Semantics are like in a  conversation. If a party dont hear a reply then it may 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 .)

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. 3) A subtle way to balance giving time-critical help to llm-bot spoiled users, avoid losing them for ever, and not overburden resources.

---- 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 documentation. (its dead..and could be written from dead people also)).

Documentation is a catalogue-archive of past common help cases. Documentation could be seen as a long term memory of a project. Artifact that can be delivered in hard copies (the ultimate safe).

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.

Wiki's food is archived discussions from forum,emaillist,irc logs. But a good wiki is not a search engine on archived talks.  A wiki's dead artifacts should excel at pinpointing common cases and offer good descriptions for issues already solved in a level undestandble by various type of users .  Good docs could draw attention from other help systems. That requirement means frequent testing and crossvalidation .

---- Help by ultrahyped AI-bots ---

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. Car? UberNow.. Home?AirBBNow ... Love?Now.. Food?DeliveryNow(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. There are no AI-forums!!! Isnt that strange ? Or that exposes the real motives of the corporations behind that as usually is build hype, promise everything, spoil the consumer and make a fortune ? The best way to make you love another person-service is to present you as alternative the perfect slave. Always there to serve.  So ''AI'' in the greater category of help systems positioned it self  essantialy as an irc bots. Of all the possible incarnations it choosed irc. :-) . Now i think a conman assumes usually that strategy. Position him-herself at a point of the greatest attention (when another human need helps) blocking other commlines and offer him/her promises of everything that he/she will get from someone else...
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

----
refs:

• DW devuanwiki/Chomwitt.HelpSystemSemantics

• @ nYAW has an interesting of email-forum-chat-wiki relations.

Last edited by chomwitt (Today 14:06:49)

---

Devuan(Excalibur)  DS+WM: XorgX11server+StumpWM

@ devuanwiki/Chomwitt

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,682  

Re: Exploring Help systems semantics

Pity to miss "man pages" which is the traditional Unix help system.

Altoid

Member

Registered: 2017-05-07

Posts: 2,047  

Re: Exploring Help systems semantics

Hello:

Pity to miss "man pages" ...

8^)

Best,

A.

chomwitt

Member

From: Greece

Registered: 2019-09-24

Posts: 214  

Website

Re: Exploring Help systems semantics

I think man pages are tied to specific packages. eg: Are there man pages for Devuan installation ,wifi setup ? I think man page is the documentation that each upstream provides for his/her package included in a distro. So i think a distro dont have man pages. In case i am not wrong it'd be good idea a Devuan to has each own man pages and wiki to has options to export to man pages.

man pages is (was) one man(women)'s work . It's missing a use-case context awereness. (most dead artifacts have that i guess). That's why there are all the other help systems.

I added at the help system's list documentation and man pages. Even if generally it was mentioned below :

---- help systems / not time critical (dead responses) ----
dead help / docs
By dead response i mean documentation. (its dead..and could be written from dead people also)).

Last edited by chomwitt (Today 14:38:20)

---

Devuan(Excalibur)  DS+WM: XorgX11server+StumpWM

@ devuanwiki/Chomwitt

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,682  

Re: Exploring Help systems semantics

The man pages help system was invented quite early in the Unix history, so as to ensure binaries (aka programs) are documented intentially in regards to function as well as which command line arguments they use and how these alter or direct the program behaviour. The general rule is that every program has an associated man page with the same name, and in addition there's supposed to be man pages for every configuration file. One were further advised to prepare man pages for distinct use cases where they involved complexity.

I'm trying to suggest to you, that if you want to talk about the meaning of help systems for computer usage, then surely the principles behind Unix man pages would be a foundation and start-point as they sit as the historical first approach to this subject.