This is true - but highlights a weakness in our "contributor based help system". We need to keep finding ways for users - particularly newer ones - to quickly find their way to solutions that enable them "to do genealogy" rather than wade through discussions of esoteric aspects of FH.
Background
Some of these discussions can attract a lot of interesting (and mainly useful, if not fully immediately relevant) discussion. Some of us may read everything on particular sub-forums - or at least the whole of threads that interest us. But we are the geeks!
But that may not help someone who is "just looking for an answer" - which is a valid quest no matter how naive in the context of a flexible program like FH and which has many "camps" of users (lumpers vs splitters, generic template users vs ...)
Some contributor help systems have a means of up-voting useful "answers" which are particularly useful for questions that may have easy answers that do not require much to-ing and fro-ing to understand the OP's issue. And OPs do have a means of marking that the issue is "resolved". With these systems many readers just read the original issue and the most popular solution - and if that works read no further.
We don't "close the loop". I'm not sure how we do that without losing the valuable discussion that can deepen understanding, resolve misconceptions, spawn plug-ins or give rise to wish list requests. And sometimes we are divided on what is a solution - either because of different approaches to using FH or due to different views on the acceptability of a work-around. I think fundamentally our type of forum is best suited to this particular task. But can we tweak the whole system (Forum, KB etc. etc.)?
Yesterday I was working on a bunch of "outliers" - a distinct group sharing my surname but with no apparent link back to the source of my family surname. I visit this project once or twice a year - usually when I spot the availability of some useful records becoming available on-line. I realised that in my multiple visits I had created a lot of duplicate "micro-families" (couples and children). I wanted to find them. I know how to merge them (and their family records etc.!) - I just wanted to find them in an easily presented form, so I could check my current work against them and merge as appropriate.
Naively I went to the fhug help and looked for "duplicate names". I had expected a more direct bit of help! The forum results look potentially more helpful even if the posts are quite old. The "abstracts" shown when you hover don't actually help - at least not in this case.
But then you get into your waders and start ploughing through the posts. Well I find such discussions interesting because "systems" are almost as much of an interest as "genealogy" - but I fear for the sanity of someone who just wants an answer!
The fifteenth posts of those listed in the search is probably where I want to start (searching for "find duplicate names" may have been a better start - but I am old school with internet searching where I was taught "less is more")
The answer to find duplicate names does seem to be a plug-in - but to get there involves a lot of wading through old discussion and old versions of plug-ins (where hopefully the links are dead).
Possible Solutions
1. Can we get the plug-in store included within the scope of search? If we can't (because it is on a different domain - technically not impossible but potentially difficult politically), can we maintain a list of plug-ins with abstracts and a plain link to the plug-in store somewhere within the indexed knowledge base so if someone searches the knowledge base for a phrase that near as not matches a plug-in name, the existence of that plug-in gets reported?
2. How can we define some form of curation process that, because it is unlikely to be automate-able, is neither time consuming nor contentious? For instance, what is involved in adding ("after the event") as say the second post (position wise) in selected (say 5% to 10%) of all forum topics a TLDR post? This would enable many readers to quickly decide if they want/need to read the whole of a possibly multi-page topic.
A "Too long, didn't read" post:
- Could be from:
- possibly a mod (more work),
- possibly the originator (can we/should we enable OP's to edit their original post well after the edit window has closed?) or,
- one of a group of "semi-mods" or area experts who have a particular interest in the subject area (e.g. "working with diagrams" or grouped by KB major heading). Is it possible to define adequate access rights? How do you assign the role - probably on a thread by thread basis?
- It would contain:
- A brief summary of the actual (clarified) issue
- A brief summary of the consensus on potential solutions - with links to the KB
- Keywords, to catch the indexing engine's eye.
3. Some way to get learning points from threads back into the Knowledge Base? This is no easy task and updating the KB for V7 was a massive task (to which I only made a small contribution before that and other activities lead to fatigue that just laid me out). One of the issues was that the old KB had become complex and a confusing place to navigate - we don't want that to happen to the new one. So we probably don't want people just throwing in additional paragraphs to crafted articles in the light of a forum thread.
But if we had TLDR's being added to the more significant forum topics, we could link those topics (as part of the TLDR creation process) to the "Related Forum Discussions" section of KB articles. This would mean that people reading the KB would be aware of the thread and when editors of individual pages occasionally review their work they can see new relevant threads which may trigger a revision of a KB article.
Would it be easier from a systems point of view if the TLDR content was actually in the form of a free-standing micro article actually in the KB and the TLDR post in the Forum was just a link to (or even an embed of ?) the micro article? Those micro articles could then be linked to KB topics such as Diagram Tips. In due course they might get incorporated into the main articles.
I think we are missing a few tricks in assisting some users. The question is what is the most economical (time wise) to improve what we have?