Where should help appear for LDS.org apps?

Currently help for LDS.org apps is somewhat scattered. For Study Notebook, Calendar, and Directory, help is in another wiki at https://tech.lds.org/ldshelp. For maps, it's on the standard LDSTech wiki. For LDSTech Jobs, it's on an external WordPress site.

There has been an interest in bringing help for LDS.org directly into LDS.org. However, this removes the benefit of the wiki and community edits. We could centralize all the help materials on this LDSTech wiki, but some product managers prefer to maintain the LDS.org branding and official nature of the content. Help locations for the Leader and Clerk Resources section (which will eventually contain all MLS functionality) is still undecided. I'm just wondering if forum members have any thoughts on this. Should help for LDS.org be centralized on LDSTech, or should it appear on LDS.org?

I see "help" and "wiki" as two separate, if overlapping things. Help tends to be official documentation written by the developers. The Wiki tends to be more of a community supported FAQS based on real-life problems that get asked about in the forum. The genesis of the clerk wiki (on a mailing list a long time ago) was to distill the knowledge of the list in a format that was easier to search, and to create a complete answer rather then have people re-writing the answer every time a particular question came up.

Keeping the branding separate may be desirable for "Content found in this wiki may not always reflect official Church information" reasons.

As long as the wiki continues, I'm happy to let the product managers work out the details of help amongst themselves. Where it's located doesn't matter as much as being able to find it when it's needed.

I think the help system should be centralized. That will create a common look and feel for all these help systems.

I don't like the idea of putting help in the general LDSTech wiki. There are links from the application to the wiki which might be inadvertently broken by community editors. We've already had a few problems like that with the LDS Maps help system. I also think it needs to to look more official than than a community wiki -- your point about the "may not always reflect official Church information" warning is a good one.

That said, I think the separate wiki used for LDS Help works fine. It allows standard editing procedures; permissions can be given to only those people who are authorized to make changes; it is easier to update than a website such as lds.org; and it allows for linkage between articles in a simple, standard way. It also allows for a top-level index of all the help systems, which is sometimes helpful.

A wiki with restricted edit permissions doesn't have any of the downsides of a community wiki; it can thus be an official repository of help and support information. There are some limitations on how such a wiki can be styled, but I think the current LDS Help wiki is styled pretty well -- it looks like part of lds.org, but is different enough that you can easily tell that you are in a help system that is not in the regular flow of lds.org.

So my vote is to expand the current LDS Help wiki to include help systems for more applications, but keep editing access restricted.

RusselHltn and aebrown have covered my thoughts. I like the look of the separate wiki for LDS Help. I also like the restricted permissions for that wiki.

Thanks for sharing your thoughts on the help location. There is another solution that we might lean towards. We're currently piloting Author-it as an enterprise-wide help authoring solution. This help authoring tool holds stores all content in a central database. Authors can then add, edit, and publish that content using an instance of Author-it on their desktop that connects into the database. For those without the software, authors can also edit content inline in the browser. We would have a set number of these inline browser-editing licenses that could be available for anyone who would like to author. This effort is still new, so we don't have any finished solutions yet, but we will soon.

Being able to provide a standard authoring methodology and toolset across the church would be a huge boon to the many departments who want to create help but don't have the resources or time to tap into a more robust solution. Author-it also works really well for translation, which is a big driver for this tool. Regardless of the tool, I agree with Russell that "Where it's located doesn't matter as much as being able to find it when it's needed."