LEARN MORE Go to adventureparkinsider.com/current-issue for the extended version of this article with full descriptions of the standards writing processes for each relevant standards developer as well as other resources. Read Part 1, “The Standards You Should Know.”
People reviewing and commenting on standards notice different things based on their experience and views. Certain content is simply more important or relevant to some people than others. For example, designers may focus on the math and harmonization with other con - struction standards, builders and install - ers might focus on the ease or difficulty of application to installation practices, and operators and trainers may not care about the installation or inspection stan - dards at all and focus only on the use of the structures with others.
the content in a section belong in that section, or in the standard altogether? For example, standards regarding re - quirements for training and certification don’t belong in a chapter about design, performance, and inspections. If you are reading draft language that doesn’t seem to belong under a partic - ular scope, you should 1) comment or vote negative on the inclusion of that language, 2) suggest a change to the scope so the topic fits in that section, or 3) suggest the language be incorpo - rated into an appropriate section of the standard that has an applicable scope.
concise, or is there ambiguity? Are there important steps in a process or proce- dure that seem to be missing? As a pro- fessional in the field, you should be able to read and interpret the standard with relative ease if it is a topic you are famil - iar with. If you cannot, never hesitate to suggest clearer, simpler language. “Should” vs. “shall” and similar nuances: Certain words are import - ant to consider when interpreting and commenting. For example, users of the standard will be expected to adhere to all instances of “shall” and “shall not,” while “should” and “should not” are merely recommendations. When you encounter these words—and others that determine permissions and obligations—consider whether the guid - ance in question should be a require - ment or a suggestion. Generally, here are some words to pay attention to: • Shall, or Shall Not = Requirements • Should, or Should Not = Recommen - dations • May, or May Not = Permissions • Can, or Cannot = Capabilities Additionally, “explanatory material” included in a standard is not itself a standard, and the words “shall” or “shall not” generally do not belong in these subsections. Measurements, weights, and listed strengths: These numbers matter, and standards should utilize a consistent measurement system throughout (i.e., metric or imperial). If conversions are provided, have they been checked for accuracy? >> continued
This is why standards developers need to obtain comments from a diverse
Submitting formal written comments on any draft standard is an integral part of the development process.
Terminology: How words are defined and understood is critical to the use of a standard. Definitions clarify the use of words in the context of the document. Have uncommonly used terms been clearly defined? Are there terms that should be defined but are not? If the list of definitions is not included in the document for review, obtain the newest published version of the stan - dards developer’s definitions, and/or use an online legal dictionary to accu - rately read and interpret the standard.
group of stakeholders, and it is also why you needn’t be an expert in every area to participate in the process. Your feedback on the topics in which you do have experience is valuable. Regardless of the areas you choose to provide comment on, here are some common considerations for evaluating draft standards language.
WHAT TO LOOK FOR WHEN REVIEWING STANDARDS
Title/Scope: Does the title and scope match the text of the standard? Does all
Clarity and specificity of language: Is the meaning of the text clear and
Made with FlippingBook Digital Proposal Creator