This post describes ongoing activity involving our community information project (based on our knowledge base #4, “The El Dorado Hills Handbook.” The original content was created in 2003 (using unstructured FrameMaker), and in 2025 we are preparing it for a hypothetical update.

“Hypothetical,” because we no longer have the time, local knowledge, and expertise to complete the information update  ourselves. However, we think the project still makes a good model and teaching tool, and we hope it inspires others, both in El Dorado Hills and other communities, to create and maintain similar information collections about the places where they live.

As people who have moved around quite a bit, we can appreciate how nice it would have been for us, as we arrived in El Dorado Hills, to have been given access to such a “handbook” to introduce us to the community. Not only the services (for example, health, safety, and educational services), but also community lore (for example, answers to questions like “What are those painted rocks on the highway bearing social media-type messages?”) and history (for example, answers to questions like “What role did EDH play in the Gold Rush?).

We’re converting the 2003 project to DITA/xml using oXygen and its AI Assistant, Positron. so it can be published in WebHelp Responsive format, as a PDF, and in other formats. We’re relying on various additional AI Assistants, including Perplexity, to help us out with research and content creation.

Our project focus is on collaboration, transparency, “future-proofing” for automation… and explaining “how we did it “

Here are some of our key goals, objectives, and focus areas:

1. The project involves both humans and AI assistants, and all participants and interested parties (including stakeholders) should be kept closely informed. Decisions and status information should be integrated into the project and instantly and transparently available.
2. During this update cycle, we assume that most of the workflow steps would likely be carried out manually and sequentially. In future cycles, some parallelization and automation would undoubtedly occur. Our initial setup should anticipate future changes and improvements, so that expensive and time-consuming rework would not be necessary.
3. Key decisions and project history from this update cycle should be easy to archive and make available to collaborators for the next information update cycle.
4. And, speaking of future collaborations, wouldn’t it be nice if community members themselves could join the fun? Future, AI-based scenarios could allow the collaboration team to expand without sacrificing the reasonable level of editorial control illustrated here.
5. The boundaries between “project content” and “background information about the project” need to be transparent and flexible to allow us, the creators and editors, to easily explain, mostly by example, what we are doing and why.

How we set up this project

The rest of this post illustrates and explains how we have set up  the project to achieve our goals and objectives. Future posts will add breadth and depth to these initial efforts.

WebHelp Responsive output file for the community “Name” topic

The example topic for this post is “Name,” which explains to end-user readers the history and significance of the name “El Dorado Hills.”

The following image shows the most current output version of the Name file, published as part of our WebHelp Responsive collection.

Highlighted in red are parts of the three sections that all topics in the collection have:

• The main content (in this case, with a title of “Name”), which contains content meant for the target audience.
• “For More information,” which is empty for this topic, but which will eventually contains the names and probably URLs of the major sources of information.
• “About this topic,” which contains notes, requests, questions, and answers from and to the project collaborators. For example, this file has a request from the editor (that would be me) to Perplexity (playing the roles of researcher and updater) to review the existing topic, make revisions, and offer suggestions for further changes.

In the notes, the collaborators are identified, and the request or question is dated (and sometimes timestamped). Actions and completed tasks are noted (“Requested updated made.”) Suggestions for possible further changed are recorded. (The editor will make the decision as to whether any further changes are to be made for this cycle.)

In the transition from “draft” to “published,” the “About this topic” section will be removed from the live file and archived. Perhaps at the time of the next update the editor will want to reconsider Perplexity’s suggested changes.

DITA/xml input file for the “Name” topic

Prolog section

Here is the prolog section of the DITA input file for “Name”:

It has the following features:

• For those humans and AI Assistants making changes to the input file, there are clear and helpful notes and instructions. For example, the editor is instructing the reviser not to include a short description, and to use the ISO 8601 format for dates.
• The collaboration team (and the role of each member) is identified.
• The reviser is asked to include both keywords and index terms.

“For more information” section

Although content has not yet been added to the “for more information” section, the internal notes provide guidance to the person or AI assistant who will be updating the file.

“About this topic” section

The EDH project team members can use the kind of custom tagging techniques shown above to provide clear requests, responses, questions, and answers in the individual files and for the project as a whole.

This example, along with others shown above, almost eliminate the need for a formal prompt to make task requests to either human or AI participants.

Two example templates for “For more information”

Here are two information presentation styles that we have tried so far for the “For more information” sections in the project topics.

We didn’t want to be too formal or verbose in our information sourcing, but we wanted to provide both an audit trail and possible sources of additional information for anyone interested in pursuing a particular topic.