Managing Release Notes

Context:

Every technical writer has endured the frustration of having to chase their product development team for time-sensitive information. When a few releases happened in this manner, with information for release notes arriving late and threatening the doc publishing timeline, I had to improve the process to make sure it worked for everyone, not just the developers.

The Work:

The feature work completed by the development teams impacted on the work of several other teams:

• Documentation (to develop content for new features)
• User experience (to conduct user studies for the effectiveness of those new features)
• Marketing communication (to prepare proper messages for our customers)
• Release Note management (to update and publish release-specific information)

Often, information would come in too late, incomplete, or in haphazard ways.

I proposed a new solution for all these teams:

• I worked with the release coordinator to fix a documentation deadline for each release in their calendar. These dates would be available at the start of every development cycle.
• Information about completed features that targeted a release had to be provided by that deadline.
• Priority would be given to fully complete information requests that were filed by the doc deadline.
• I made sure that developers also stick to a single format to provide that information. To help them adopt the format, I created a sample request and shared completed examples.
• I clarified roles and responsibilities for the preparation of release notes so that incomplete work could be tracked easily.
• To make sure that new developers could learn about these improvements, I documented these processes in the same location where the rest of the release process was explained. After all, a product is incomplete without its technical content.

Result:

These changes dramatically improved the release preparation process. Existing and new developers quickly embraced the process, and for the first time in years, doc tickets were filed well before their deadline.

Because several contributions for feature docs came in from teams other than the development team, I created a microsite as a hub for all information about documentation processes for my product group. On this site, I described:

• The documents I managed
• Current roles and responsibilities
• The documentation development process
• Information about filing a doc ticket
• A pipeline for other content contributions, so that those contributors could track the status of their requests

This microsite quickly became a one-stop hub for the development team to get their doc questions answered.