Document Contribution Guide
Overview
This article describes the various types of documentation included in the HySDS wiki, and guidelines for creating additional documents following the best practices outlined below.
Who is Your Intended Audience?
First ask how knowledgeable your target audience is? The answer to this question will help direct you to the most appropriate documentation format.
A true beginner: they can’t formulate specific questions yet → Tutorial
Infrequent or new user: have enough knowledge to ask a specific question → Step-by-Step Guides
Regular user who needs targeted information → Cheat Sheets (Reference)
Regular user looking for context or background information → Discussions (Stack Overflow)
Source: https://www.youtube.com/watch?v=t4vKPhjcMZg&feature=youtu.be
Step-by-Step Guides (Problem-Oriented)
Step-by-Step Guides that the reader through a series of steps required to solve a common problem.
Elements of a Step-by-Step Guide
Section | Contains | Examples |
Audience |
|
|
Scope & Level of Detail |
| “How to create a ___” |
Title & Description |
| “Create, Edit, & Delete Trigger Rules” “Submit an On-Demand Job in Facet Search” |
Formatting |
| Step 1: Do this. Step 2: Now do that. |
Voice and tone
Enough openness that user can see how this can be applied to a slightly different case. Practical usability is more important than completeness. |
Writing principles
Start at the beginning. Begin the documentation at a reasonable starting point |
Do |
Achieve some practical goal that solves the user’s problem |
Do |
Provide unnecessary explanations or extra details |
Do n’t |
A Little Flexibility
Step-by-Step Guides provide a user with guided directions on how to achieve a specific outcome. However, some flexibility is OK; a user should be able to see how to apply these steps to another similar situation.
Good Naming
Both the title of the document, and each step listed should describe the actions taken within them. Give the user a preview of what they will accomplish in each step with good naming.
Tips and tricks
Most useful when doing the work/coding (same as Reference)
Cheat Sheets (Information-Oriented)
Cheat Sheets (Reference) gives users technical descriptions of the machinery and how to operate it. They only have one job: description.
Elements of a Cheat Sheet
Section | Contains | Examples |
Audience |
| HySDS Ops Team |
Scope & Level of Detail |
| |
Title & Description |
| “HySDS Log File Overview” “HySDS GUI Overview” |
Formatting |
| See Cheat Sheet Template |
Declaration & Syntax |
|
|
Voice and tone
Austere and to the point. Cheat sheets are direct and lack unnecessary context or explanations. |
---|
Writing principles
Structure
Structure is formulaic and consistent. If appropriate, provide the user with a table to quickly access information. Reference material should have the same structure as the code base.
Explain basic concepts in reference guides |
Don't |
Just give reader the facts (include examples if its useful) |
Do |
Consistency
Language, tone, and structure are as consistent as possible. Eg a dictionary.
Description
Only job is to describe things clearly and completely. Anything else is a distraction.
Accuracy
Reference material is prone to deprecation. Documentation should clearly note when the information was last confirmed for accuracy.
Tips and tricks
Most useful when doing the work/coding (same as Step-by-Step)
Tutorials (Learning-Oriented)
Lessons that take the reader by hand through a series of steps to complete a project. they show a beginner how to achieve something meaningful. The point of a tutorial is to get your learner started.
Elements of a Tutorial
Section | Contains | Examples |
Audience |
|
|
Scope & Level of Detail |
|
|
Title & Description |
|
|
Formatting |
|
|
Declaration & Syntax |
|
|
Parameters |
|
|
Example |
|
|
Voice and tone
Tutorials are informative. They guide a true beginner through a series of steps for the purpose of learning. They provide context, explanation, and are bullet-proof. |
---|
Writing principles
Inspire Confidence
The goal of a tutorial is to provider learners with the tools and knowledge to do a specific task. A successful tutorial will turn your learned into a user.
Learning by Doing
Tutorials should create a learning opportunity for the reader. Explanations should support a specific outcome which builds confidence.
Provide any explanations that don’t absolutely need to be explained |
Don't |
Create an immediate sense of achievement |
Do |
Concrete, not abstract
Tutorials deal with the particular not the general; they’re built around specific outcomes.
Repeatability
A reader should be able to recreate the outcomes of the tutorial on their own.
Tips and tricks
Tutorials are designed to get new users started with the technology. Ideal topics are those which provide a strong foundation for deeper understanding of the material.
Discussions (Understanding-Oriented)
Explanations that clarify and illuminate a particular topic. This material will live mainly at Stack Overflow.
Elements of a Tutorial
Section | Contains | Examples |
Audience |
|
|
Scope & Level of Detail |
|
|
Title & Description |
|
|
Formatting |
|
|
Declaration & Syntax |
|
|
Parameters |
|
|
Example |
|
|
Voice and tone
Discussion material should be conversational yet specific. They provide a high-level overview of concepts, or specific details to troubleshoot issues. |
---|
Writing principles
Making Connections
Good discussion responses help a user fill knowledge gaps and make broader connections about how a component fits into the broader whole.
Provide additional details beyond what is needed to learn and resolve a problem |
Don't |
Use technical descriptions. Maintain a casual voice meant to help a user understand. |
Don't |
Offer high-level context for general understanding if appropriate |
Do |
Understanding Oriented
The purpose of discussion posts are to help a user understanding a specific problem or concept.
Tips and tricks
Most useful when we’re studying (same as Tutorials)
Style Guide
This section provides an overview of the styling for wiki documentation. The goal of this guide is to provide a useful reference while creating new documentation while standardizing the wiki’s content.
Voice
Tone | Documentation written for the public HySDS wiki uses a conversational tone, though not at the expense of utility or clarity. |
Audience | Wiki documentation can assume a baseline technical background of your audience. Foundational computing concepts normally covered in a four year university education do not need to be explained. However, specific use cases or adaptations of technologies may require some contextualization. Most HySDS wiki readers hold at least a bachelor’s degree in a technical field, and have 1-2 years of related work experience. |
Clarity | Avoid unnecessary technical jargon, excessive use of JPL specific acronyms, ambiguous terms, and buzzwords. Your writing should be clear and specific while maintaining a brisk pace. |
Sentences | When context or explanation is necessary, provide it using full and natural sentences. Do not present information in code-like fragments of text; utilize complete sentences and thoughts. |
Page Elements
Screenshots | Screenshots communicate valuable visual context to the user. If your documentation requires navigating a GUI at any point, screenshots will be an essential part of your documentation. All screenshots should be annotated for specific actions a user takes while proceeding. {be aware of screen load time and too many screenshots…hard to notice text between} {put them into expands!! this lets us see the high level overview} All IP addresses should be cropped our or digitally blurred. No images from JPL internal resources should be shared on the public wiki. |
Code | Code helps guide the user through critical steps in your documentation. All code should use |
Diagrams | Diagrams are helpful in certain situations. They provide a visual map to quickly understand how various concepts interface. Not everything should be represented in a diagram however. If users have difficulty immediately understanding it, or have many follow-up questions, then the diagram probably isn’t suitable. |
SME | Subject Matter Experts are JPL employees deemed highly knowledgeable about each page’s subject matter. They are a good resource for questions on the topic. Often, but not always, the original author of new documentation will be the SME for that page. |
Labels | Page labels are another important navigation and usability feature of the HySDS wiki. Labels are used to populate the “Related Articles” box in each page’s footer. They are also used to identify documentation gaps, and perform wiki maintenance. It is your responsibility to properly label your documentation. |
Page Maintainers | A designated point of contact responsible for maintaining the format and accuracy of a page. Doesn’t necessarily need to be the most knowledgeable person on the topic. |
Tables | Information with multiple parameters should be displayed in a table format. Each column should be intuitively labeled and tables should fill the width of the page for optimal readability. |
Page Element Examples
Screenshots
Tips and tricks
Sequential steps should be clearly numbered and associated with a button, text field, menu, etc.
Arrows should denote clickable elements
Rounded boxes highlight drop-down menus or text fields
If helpful, 1-2 words can be added to the screenshot for clarity. Eg “Click here”
Code
Tips and tricks
All code should be presented in a copy and paste format for users
Large blocks of code need to use the “Expand” page macro and a “Code snippet” macro nested within it. See sample below
Large blocks of sample code syntax should follow the same requirements
Small code blocks (<5 lines) can be included directly onto the page using the “Code snippet” macro.
Multiple steps of code should each use the expand and code snippet macro. Users can expand each individually as they progress through the steps.
Page source: Job and HySDS IO Specifications
source ~/verdi/bin/activate
~/verdi/ops/hysds/scripts/ingest_dataset.py <product_dir> datasets.json
Page source: How to manually ingest a dataset into GRQ/S3
Wiki Content Labels
Labels are an important component of each page. They improve navigation and usability of the wiki. Every document has a combination of stateful and content-related variables.
Part 1: Open Label Window
i.) In the upper right corner, click the “…”
ii). Click “add labels”
iii.) In the pop-up window, apply the appropriate labels from Part 2 and Part 3 below:
Part 2: Select Stateful Labels
Assign exactly one label from each column (3 total from the blue table):
Content Type: | Subject Matter Expert: | Page Maintainer: |
---|---|---|
step_by_step_guides | needs_sme | needs_pm |
reference | sme_assigned | pm_assigned |
cheatsheets | update_sme | update_pm |
development |
|
|
|
|
|
Part 2: Select Content Labels
Apply any of the following labels that are applicable to your document:
Tech Labels: | HySDS Specific: | Content Variables: |
---|---|---|
aws | tosca | hysds_setup |
linux | figaro | operations_manual |
python | mozart | diagram |
elasticsearch | factotum | onboarding |
kibana | verdi | troubleshooting |
logstash | grq | version_3.0 |
rabbitmq | job_management | Version_2.0 |
celery | tasks | version_1.0 |
supervisord | workers |
|
jenkins | sdswatch |
|
docker | pge |
|
github | provenance |
|
terraform | metrics |
|
sciflo | chimera |
|
json | tasks |
|
api | pleiades |
|
yaml | pcm |
|
azure |
|
|
Have Questions? Ask a HySDS Developer: |
Anyone can join our public Slack channel to learn more about HySDS. JPL employees can join #HySDS-Community
|
JPLers can also ask HySDS questions at Stack Overflow Enterprise
|
Page Information: |
---|
Was this page useful? |
Contribution History:
|
Subject Matter Expert: @Marjorie Lucas @Lan Dang |
Find an Error? Is this document outdated or inaccurate? Please contact the assigned Page Maintainer: @Marjorie Lucas |