Technical Writing Portfolio

Type: Procedural content

This is documentation I wrote as a product manager for Inkling. Inkling, by design, does not allow copy paste, PDF generation, or printing to PDF, so this is a compilation of screenshots taken from publicly available content and placed in this document. This content was for Featured Content. It is written in a topic-based approach to introduce the basic concepts to users.

  • Who is the target audience? Administrators and authors in Inkling.

  • How much of the content did you write? 100%

  • Does the document represent original writing or existing content that you revised? Original content.

  • How did you source the content? I was the product manager for this. I created screenshots, planned, wrote, edited, and published all the content.

  • Did you follow a style guide? Sort of. Since I wasn’t a technical writer at this company, but they also did not have any technical writers, I had created a simple style guide that I used for this. Plus, there were many principles that I have internalized from years of technical writing. The style I have created and implemented at many companies is generally quite similar across the board.

  • Was the document edited? No.

  • How did you obtain any code samples? N/A

  • How did you verify the content? I was the product manager so I was the SME and author for this content.

Inkling
Incorta Product Documentation Site

Type: Overview and conceptual material for something complex

This content was originally created in Markdown, stored in Git, then rendered through Gatsby. They may not use this today. The content is available via web output at the links below, and I have copied/pasted part of the configuration content below, as well. Please note that the copied/pasted content does not retain formatting.

  • Who is the target audience? Network administrators.

  • How much of the content did you write? At least 75%.

  • Does the document represent original writing or existing content that you revised? Original writing, mostly. There may have been some pieces pulled out of previous content or internal engineering content.

  • How did you source the content? Because configuration can be complex, I met directly with the engineers to ensure I got this right and didn’t miss anything. I also used specs, Jira tickets, Confluence pages, and the customer success team to help with making sure I got it right.

  • Did you follow a style guide? Yes. Absolutely. I created one for this company when I arrived and used it for all content.

  • Was the document edited? No.

  • How did you obtain any code samples? Usually directly from the engineers, at least initially. Then I verified it on my own.

  • How did you verify the content? I successfully tested it myself. I double-checked with the engineers and triple-checked with the solutions consultants to ensure there wasn’t anything I was missing.

Available at these links:

https://docs.incorta.com/latest/spark

https://docs.incorta.com/latest/spark-config

Type: API Reference content

This document is from an SNMP MIBs manual I wrote for Ericsson. It’s not exactly an API, but it is highly technical, reference material, and quite similar in structure and purpose. I have the XML version only and the DTD to render it is long gone. I cleaned it up a bit, but it isn’t pretty. Still, I hope it gives you a sense of what I can do in writing API reference content.

  • Who is the target audience? Network administrators

  • How much of the content did you write? 75%

  • Does the document represent original writing or existing content that you revised? Original writing and some revisions.

  • How did you source the content? From feature specs and the command line interface.

  • Did you follow a style guide? Yes. Definitely. It’s highly structured. There was a robust style guide that I followed for all documentation. Since this was technical reference material it had a specific structure and styles.

  • Was the document edited? I can’t recall. We did have technical editors, but I don’t remember if they reviewed this reference content.

  • How did you obtain any code samples? I generated them myself or used examples from specs.

  • How did you verify the content? For this, it was an engineer reviewer as it would not have been possible to test each MIB. Each one represents a different use case that would have to be set up, which would have been time-consuming for little benefit.

Content

The contents of this document are an example only of the author's

work and are in no way intended to resemble existing documentation

for any specific product. Any resemblance to existing documentation

past, present, or future is purely accidental.

SNMP MIB Notifications

Simple network management protocol (SNMP) Management Information

Bases (MIBs) contain notifications. Some MIBs contain numerous notifications.

Others contain none. To use notifications:

Use a tool to integrate SNMP in your network and access

the MIBs. You must download the MIB file that comes with your system

in order to use the MIBs with your network.

Enable notifications that are not enabled by default.

Refer to this Guide when a notification raises or clears

a flag in the interface to identify the meaning of the notification

and any necessary solution.

The product supports notifications for IETF-standard MIBs described

in the following sections.

SNMP examples in this document utilize the open source tool

Net-SNMP. Depending on the product you use to monitor your network,

the examples may appear different from your system.

Setting up SNMP Alarm Models for Notifications

You can use ALARM-MIB to create alarm models to specify the types

of alarms and alarm states to raise for existing notifications. To

configure an alarm model:

Use the snmp alarm command

to enter the SNMP alarm model command mode.

Use one of the following commands to set up the SNMP alarm

model with additional parameters:

description

eventtype

notify

probablecause

res-prefix

sp-pointer

vb-index

vb-subtree

Use the following show commands to display information

about SNMP alarm models:

show snmp alarm model to display information

about each alarm model.

show snmp alarm active to display information

about active alarm models

show snmp alarm cleared to display information

about cleared alarm models

show snmp alarm stats to display general

statistics about all alarm models, including how many have been configured

Enable debugging for snmp alarm models by using the debug snmp mib alarm command.

Entity Notifications

This section organizes the relevant notifications into two

tables. The first table lists the event, Object Identifier (OID),

description and cause, recommended action, reporting module (the location

where the event will be raised or cleared), the severity of the event,

and the related events and interface commands. The second table lists

the OIDs identified in each notification and the associated values.

lists notifications generated by the

router to indicate entity notification as defined in RFC 2037, Entity MIB using SMIv2.

Entity Notifications

Event and OID

Description and Cause

Recommended Action

Reporting Module

SeverityThe recommended severity level.

Related Events and Commands

entConfigChange

1.3.6.1.2.1.47.2.0.1

ENTITY-MIB

The system generates this event when the entity configuration

changes. It can be utilized by an NMS to trigger logical and physical

entity table maintenance polls.

This notification signifies that a physical entity of a chassis

changed in the last 5 seconds (for example, card addition or removal),

and the SNMP manager can reread the entity and act on the change.

Cause: Hardware has been inserted or removed, or a card has failed.

Use the show hardware, show diag, and show log commands to identify any failed or

missing hardware.

Node

Minor

Events:

coldStart

cardAlarm

Command: None

describes the objects for system management

notifications.

Entity Objects

Notification

Objects and Values

entConfigChange

ENTITY-MIB

See RFC 2037, Entity MIB using SMIv2

RMON Notifications

This section organizes the relevant notifications into two

tables. The first table lists the event, Object Identifier (OID),

description and cause, recommended action, reporting module (the location

where the event will be raised or cleared), the severity of the event,

and the related events and interface commands. The second table lists

the OIDs identified in each notification and the associated values.

lists notifications generated by the

router to indicate RMON notifications as defined in RFC 2819,

RMON Notifications

Event and OID

Description and Cause

Recommended Action

Reporting Module

SeverityThe recommended severity level.

Related Events and Commands

fallingAlarm

1.3.6.1.2.1.16.0.2

RMON-MIB

The system clears this notification when

remote monitoring (RMON) falls.

Cause: The value of a MIB object decreases. For example, you can

monitor whether the temperature of the router decreases.

Dependent upon which MIB object you set up for this notification

to monitor.

Node

Warning

Events: risingAlarm

Commands: None.

XML version available here.

Redback Ericsson Network Routing Documentation
LiveFyre/Adobe Product Documentation
  • I inherited this doc set from another writer. Then, any additional content was 100% originally written by me. I did not work from specs. I did not work from any existing content.

  • I developed it by reading through Jira tickets, PRDs, wiki pages, and usually a brief meeting with product managers, CSMs, or developers to verify that my understanding was correct.

  • There was no editor for this content besides me and any technical reviewers who may have caught a spelling or spacing error, at maximum.

  • I wrote, organized, maintained, and updated this entire doc set by myself (and migrated the content to two separate platforms, twice.

This content was removed after the Adobe acquisition in 2015.