Rnformatcheck-request-lib

All RNs need to be format checked by Pubs Editors, whether for on-premises RNs, Genesys Multicloud hosted RNs, and Genesys Multicloud private edition RNs. Pubs Editors check different things depending on whether the release note is online or HTML and also if the HTML is General, Restricted or a Pre-release. Here are few things to look for before sending an RN for a format request.

When to Request a Format Check

You can request an RN format check any time after you have had your RN approved by your team and peer edited, ideally.

Important

Be aware of the following:

• With changes to IX resources, starting in January 2022, there will be no Pubs Editor located in California. As such, if you can’t send an RN for format checking prior to 5 pm Eastern time and the RN has to be published that day, publish the RN and then get the format check done the next day. In November 2021, we added Brian Marshall to the Pubs Editors group, who works out of Toronto, Ontario, Canada, and Santhosh Annamalai, who works out of Chennai, India.
• Follow this same approach if no one from Pubs Editors is available due to other work or holidays for example. In other words, just publish the RN and a Pubs Editor will check it when one is available.

Online RN

• Validation tool "Page Status:" Does the tool indicate a check mark? If not, the tool has identified some blockers that you need to fix before requesting a format check. Note that the tool will display a check mark if there are minor errors. So, you may want to click Page Status to see if there are minor errors to fix.

  Be aware that there may be situations where the draft page is clean but the published page is not. Here are a few scenarios:

  • When you edit the published page manually.
  • When the published page links to a draft version that the customers cannot access
  • When the published page links to a page that does not exist in a published version, but the page exists in a draft version (so the link worked for the draft). As a result, customers click the link and get redirected to the start page – very bad user experience.
  • When the published page (in particular, an RN) contains an option that is a draft in progress. The customer will not see the draft but the widget will detect change bars in the rendered page.
    • It only says for now that there are change bars somewhere, but Sophie will implement a fix soon so that it says “an option with change bars has been detected.”
    • It can be an issue if the option has not been published at all and so, the customer will not see any text for this option.
• Pink links.
• For on-premises RNs, does SOE link point to the new SOE both on the main page and if you are adding support to a new OS, DB, and so forth?
• Is there any excessive white space in the What's New section?
• Are items separators correctly paired and is the JIRA number listed in the Resolved Issues section?
• Are items separators correctly paired on the Known Issues page?

HTML RN

• Does the file name match the existing RN?
• Does the copyright date start with the year of the first release and end with the year of the most current release?
• Does the copyright banner have the new Genesys name, Genesys Cloud Services, Inc. instead of Genesys Telecommunications Laboratories, Inc?
• In the Contents section, is the release date and version correct and do they match what's in the release section?
• Does the introduction section reflect that release type? For example, the restricted boilerplate is the following: “This release note applies only to the X.X releases of <Name of Component> that are specified in the Contents, above.”). A General, Hot Fix, or Update version boiler plate is the following: “This release note applies to all X.X releases of <Name of Component>.”
• In the New in this Release section,
  • Does the intro boiler plate reflect the release type? (General and Update: “There are no restrictions for this release.” Hot Fix: “This is a hot fix for this product.” )
  • Are the New in this Release section formatted as square bullets?
  • If you are adding support for any SOE items, like OS, browser, or database, have you added the correct wording per SOE Information in RNs?
  • Are there items separators correctly paired for Corrections and Modifications and Known Issues and Recommendations?

Sending an email to Pubs Editors

When your RN has been peer edited and has received all required PCT approvals, send an email to the Pubs Editors alias requesting a final format check/approval. In the subject line, include the words "RN FORMAT CHECK". In the body of the email, include a link to the RN or, if it is an HTML file, attach a copy. If the RN is either Restricted or Pre-release, be sure to tell Pubs Editors, as these types of RNs require special handing.

To allow the gathering of metrics, provide the number of new features/enhancements included in the release, using the features table Joe provided in an email. The table looks something like this:

Note the following:

• We no longer count support of new operating systems, databases, or Java versions in our new feature metrics. So, don't include the number in the table.
• By features, we mean any new feature or enhancement to an existing feature.

RN Format Check email examples

Example One

To: Pubs Editors Subject: RN FORMAT CHECK

Hello,

The attached RN has been approved by the PCT and peer edited.

Thanks,

Writer's name

Example 2

Another example of appropriate text.

To: Pubs Editors Subject: RN FORMAT CHECK

Hello,

2 RNs for format check. Both RNs have been approved by the PCT and peer edited.

• link to draft RN 1
• link to draft RN 2

Thanks,

Writer's name