What Documentation Do I Write?
Doc or No Doc?
No Doc with One-Liner or No One-Liner
Doc QANs
100

There is a tiny behind-the-scenes change that does not affect workflows (ex. small performance fix).

No doc.

100

Fix is not Staying Current, does not require build, and users do not need to be trained.

No doc!

100

Hyperspace used to crash and now it doesn't (and that's the only change).

No one-liner.

100

Fix timeline for ITF Nova QANs

Within two weeks of assignment
200

Trainers must train users on your change (and is not an SU).

Release note, training slide, MAYBE a tip sheet (if there is a new workflow with multiple steps).

200

There is no existing guide content, there are no new options with the development, we are retiring a feature no one uses.

Doc! (Release note with a Galileo search). Any time we retire or remove a feature, this is the documentation required.

200

Foundation system changes

No one-liner. FS changes never use them. 

200

Fix timelines for ITF galaxy QANs

Within one month of assignment

300

There is a bug in the system and we "fix" it by providing a way to update the system (ex. run a utility, change a setting, etc.).

Release note, in rare occasions a Galaxy update.

300

There is already an existing tech note.

9/10 times doc! In the rare instance where no additional documentation is required, then you should create a no doc record and attach the tech note (this should be approved by the Upgrade Specialist Group before doing so).

300

Reportable fix that would typically be a no doc.

No one-liner, this is already documented in Sherlock.

300

The point at which you may close a doc QAN as fixed

Once you send your edits to review, if review is required! If your change is small enough to not warrant review, close the QAN as soon as you publish the updates. 
400

Analysts might use a new option or tool in their workflows.

A targeted notification and an update to the Admin Enhancement Directory.

400

There is FS development that we created an add-on Turbocharger for but do not expect live customers to take on their own.

No doc! Since this is for installing customers only and they will need TS assistance, we do not need to add this to the enhancement directory.

400

SUs

SUs no longer receive one-liners.

400
The best way to tell if other customers have left similar feedback for a release note in regards to a QAN you are assigned to fix
In Nova, look at the QA Notes tab in the lower right hand section that also shows related info, timeline, audit trail, etc. This tab compiles all other feedback given for a note and can help you determine the impact of a change/prioritization. 
500

Your change is a Recommended If Foundation System update.

Release note with a training slide.

500

We are moving or automatically changing the way a piece of data is stored in Chronicles.

Doc! This is a Data ACEB. It requires a release note - there is a Wiki specifically for this situation.

500

Data Courier - the log is fixing an issue where we weren't logging a version skew error consistently.

One-liner.

500

The most clear-cut strategy to determine the impact of a change to a published release note - i.e., how many customers will actually see the edits if you make them

In Nova, the Statistics tab will tell you the percentage of customers who have already reviewed it (available for Required Reading and Staying Current notes). You must first open the note in the EMC2 view and then click on the open in Nova link to see the statistics tab. 

M
e
n
u