Is this not what you are advocating?
Yes, but it's also intended to be the opposite of "unwieldy." What is it about what you are imagining that is unwieldy?
Unless the moderator (you) reads every single post in a topic and takes relevant info out and puts it into 1st post, then users have to read through potential crap to get to the bit that explains how to do something...
This is circular/false logic. You're assuming topics are not going to be maintained, and therefore users will have to wade through many posts to find the information they need. Why can't you imagine the thing as I've proposed it? Initially, a topic would consist of the best available documentation we have—perhaps something compiled from existing wiki content. Obviously, users will then instantly find the information their looking for. And, if they need to ask a question about that material or suggest an improvement or addition to it, they can do so right there. Then, regardless of who is going to make the necessary change or addition, it couldn't possibly be easier than it would be with this arrangement—where the help topic in question is always the first post in the thread.
But the ease of maintenance is secondary to the main benefit and purpose of the proposal. The help file could be a significant gateway to the forum for users—particularly those who need help but are reluctant to participate here (or just expect to be able to find the help they need on their own). This should be a highly effective way to bring the "help seeker" here and say to them, "Here's the information available on this topic. If you need any further assistance, please ask." Even if this is not going to be as pretty as alternative forms of help documentation (and it's not), it's very well suited to our circumstances. I think many would even consider it revolutionary. A tiny little freeware app—with help fully integrated with its user community. Awesome!
...and it means a lot of work for moderator (you) in editing posts.
This is another reason why this is a "trial balloon." I'm not going support or take any action on anything that simply means more work for me and is of no interest to anyone else. I already do more that enough here. I think it's a good idea because it's an effective and manageable solution to the documentation problem, and would improve the synergy between the application and its user forum. But it's not going to work if I'm the only one who believes this. It's also not going to work if there's even the expectation I (or someone like me) is going to maintain it. Restricting the ability to modify posts to moderators is a necessary evil. That doesn't mean there can be only one moderator. Moderators are designated by forum. For this help forum, I would suggest any experienced user should be made a moderator simply by asking.
But i would like to see a small trial to see if it would work in principle.
A trial can be used to see if something works
in practice, but we're not there yet. We're still discussing whether it will work
in principle. I'm certain I've described the principles well enough already. You've already made a good case for the impact of another principle. The idea may fail simply because users don't understand it, or believe another approach would be better and therefore choose not to support it.
I see no reason why nostra would choose not to implement the help file capability. Even if the context hooks are not feasible or too much work, there's no good reason for not adding the simple capability of launching an HTML help file from the program. Once that is done, starting with a small trial is probably the way to go. It's already clear this will work "in principle." The significant part of the experiment will be to see if users embrace and support it. If it fails, the program will still have a help system. There will still be the option of adding a few links to a view online tutorials, or put such things directly in the help file...
I think I will implement some kind of tutorial or online help in version 1.
The reason I'm bringing this up now is the release of version 1 is going to require a relatively massive update to the help documentation. It seems highly unlikely that's going to happen by people volunteering to update the wiki. Or create another one. This is an opportunity to do it in a way that's more likely to be effective.
I have no idea when version 1 might be released. If it's some time off, and we have some agreement ("in principle"), it may make sense to do a trial in advance. That might include...
1. A 0.9.9.x release in which the help file capability has been added.
2. The addition of a new "Help" forum for which anyone interested in getting this going is given moderator permissions.
3. The creation of a sample/abbreviated table of contents for the help forum—where each item is linked to a separate topic.
4. The creation of a help file with an identical table of contents—where each item is link to its corresponding forum topic.
5. Moderators could start by "dumping" existing wiki content into the application topics. These could then be discussed—if necessary—then edited into appropriate form, cross-indexed to other existing topics, etc.
If we had the basic structure in place, it would be a much less daunting task to document the changes in version 1. Version 1 could also be released with a help file that at least got users into the help forum. Or, nostra would have the option of adding topics for brand new features. These might initially be just very brief descriptions (the kind nostra is famous for), but would be a cool way to inform users of new features, while providing a permanent link to their help topics. In many cases, fuller documentation would naturally (and probably very quickly) evolve from users asking questions and others explaining how the feature works and how it can be used.
