Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Headings

The highest level is Heading 2; never use Heading 1. Why? Because we like smaller headings...

It is OK to have a singleton Heading at any level

Do not use a Heading (n+1) unless it is under a Heading n

Capitalization

  • First word on each line of a bulleted list
  • The following are proper nouns that in many cases have a specific meaning in OpenECOMP and should be capitalized:
    • Application Controller
    • Infrastructure Controller
    • Network Controller
    • Offer
    • Product
    • Resource
    • Service (note: use "service" in generic contexts; use "Service" for a Service Design & Creation tool object)
  • "Order Lifecycle Management"? <<NN>>
  • BSS (Business Support System) and OSS (Operational Support System) - these are standard telecomm industry terms. See Acronyms treatment, below.
  • Lowercase:  "service" "service request" "controllers" (when referring to the explicit 3 in list above, write them out as above. You can say "Application, Infrastructure, and Network Controllers" if you are mentioning all 3 of them at once (likewise for 2 of them) 

...


Usage

ingredients: avoid

onboarding:

  1. taking a Virtual Network Function (VNF) from a source or supplier and integrating it into the OpenECOMP platform
  2. (avoid this usage) telling a potential developer/contributor what they need to know about tools, policies, processes, etc. to start using or contributing to Open ECOMP. Instead, use a title such as "Developer Starting Guide" rather than "Developer Onboarding Guide".

recipe: try to avoid - use alternative like workflow and configuration information related to a Resource, Service, Product, or Offer

orchestration: The coordination of facilities and lower-level services in a software-defined networking context to define and provide higher-level services


recipe: try to avoid - use alternatives like "workflow and configuration information", when related to a Resource, Service, Product, or Offer


run-time vs. execution-time (adjective)

...

: prefer run-time

...

ingredientssubsystem: a large component; avoid "module" when referring to OpenECOMP subsystems such as MSO

Other

Acronyms:  Write out in first instance on a page, immediately followed by the acronym in parenthesis. Then use the acronym on the rest of the page.  In diagrams, if space allows, use full name.  Example: Operational Support System (OSS). Plural of acronyms, for instance, to mean "Operational Support Systems."  Add For plurals, add an "s" but do not use "es", such as OSSs. "  (This is how it's done in OpenECOMP.pdf.) 

Incomplete items: Denote text that requires additional work using "<<" (easily searchable) and preferably italics:

<<Link to security-related APIs here>>

Word choice:

...

Replace "&" with "and", except for acronyms such as A&AI, OA&M

<<TBD: fonts/indications of code,  user input, system outputoutput>>

Figure numbering and labeling - start with Figure 1 on each page

foreign Foreign phrases and abbreviations  (avoid, and what to substitute)
     -e.g.  >  for example, such as
     - i.e. >  that is (or rephrase)
    - via  (through, or sometimes by) 

if you DO use "e.g." and "i.e.", use commas after these

quote marks - avoid <<can we drop this? We're using quote marks on this page, and we need to.>>

Try to keep sentences 25* words or less.  If very lengthy, consider rephrasing and breaking into a bulleted list.
     * Sometimes impossible but worth shooting for.

treatment <<treatment of certain keywords like “project” (OSS vs. customer vs. ?) (BILL : I am and MIKE: Nancy, we are not sure here what this means; please elaborate )prefer run-time to execution-time (adjective)or drop)>>