Skip to content

Commit

Permalink
Merge branch 'newrelic:develop' into develop
Browse files Browse the repository at this point in the history
  • Loading branch information
nr-jbiggley committed Nov 2, 2021
2 parents 9d64112 + 08adb08 commit d149da9
Show file tree
Hide file tree
Showing 3 changed files with 75 additions and 43 deletions.
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
---
subject: Infrastructure agent
releaseDate: '2021-11-02'
version: 1.20.7
---

## Fixed
* Make the `td-agent-bit` dependency required for SLES 12.5 [#786](https://github.com/newrelic/infrastructure-agent/pull/786)
* Send inventory on secure forwarder mode [#796](https://github.com/newrelic/infrastructure-agent/pull/796)
Original file line number Diff line number Diff line change
Expand Up @@ -6,38 +6,45 @@ template: basicDoc

This doc explains required styles and recommended phrasings for pricing-related requirements.


## Explanations of philosophy

If you haven't already, please read [Overview of pricing plans](/docs/accounts/original-accounts-billing/original-product-based-pricing/overview-changes-pricing-user-model/) to understand our two different pricing plans, as it helps understand our pricing language guidelines.

We should attempt to minimize reference to pricing and billing impacts in the docs, with these two main exceptions:

* We put a good amount of pricing and billing detail in the [pricing/billing-related docs](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/new-relic-one-pricing-billing/).
* When a feature requires a pricing edition (Standard, Pro, Enterprise), we should place that in the requirements of a feature's doc. [Learn more about documenting pricing edition.](#edition-guidelines)

Here are some reasons behind this philosophy of minimizing pricing-related docs mentions:
If you haven't already, please read [Overview of pricing plans](/docs/accounts/original-accounts-billing/original-product-based-pricing/overview-changes-pricing-user-model/) to understand our two different pricing plans. This will help you understand our guidelines around pricing-related language.

### New Relic One pricing plan [#nr-one-plan]
We attempt to minimize reference to pricing/billing impacts in the docs, with these two main exceptions:

For the New Relic One pricing plan, there are several pricing factors involved. As a general approach, the only pricing factor we document is that related to the editions (Standard, Pro, and Enterprise).
* We have a high level of pricing/billing detail in the [pricing/billing-related docs](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/new-relic-one-pricing-billing/).
* When a feature requires a pricing edition (Standard, Pro, Enterprise), we should place that in the requirements of a feature's doc. Because there are only a few things in the Pro and Enterprise editions, this should be an infrequent need.

This is because the New Relic platform is much more open on the New Relic One pricing plan. The user type (basic user versus full user) or roles/capability limitations are the main factors in gating platform functionality. And in those cases, it should usually be fairly obvious (via UI upsells, or general knowledge that product gating is often due to roles/permissions) why things are off-limits.
## Style and formatting [#style-format]

### Pro and Enterprise editions [#exceptions]
Some notes on style and formatting for pricing-related language:

The main exception to New Relic One pricing factors is for features provided by Pro and Enterprise editions; for example:
* Pricing plans:
* Use the word "plan" to refer **only** to our two pricing plans: New Relic One pricing plan, and our original pricing plan. Our pricing editions (Standard, Pro, Enterprise) are not "plans"; they are "editions". Our "free tier" is also not a "plan."
* Examples of referring to plans:
* *If you're on our New Relic One pricing plan...*
* *If you're on our original pricing plan...*
* When referencing a plan, it's good practice to point to either the doc for that plan, or else the [doc explaining the differences between the plans](/docs/accounts/original-accounts-billing/original-product-based-pricing/overview-changes-pricing-user-model/#pricing-user-table), whichever makes more sense.
* "usage-based." The New Relic One pricing plan can be referred to as “usage-based” or “consumption-based,” but “usage-based” is the most commonly used and most preferred term.
* Editions:
* Our pricing editions are formatted with title case: Standard, Pro, and Enterprise. Example use: *If your organization is on the [Pro edition](https://newrelic.com/pricing)...*
* Do **not** use "tier" to refer to the concept of "edition."
* For recommendations for how to mention the edition in feature requirements docs, see [edition guidelines](#edition-guidelines).
* Free tier. The so-called New Relic One pricing plan's [free tier](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/new-relic-one-pricing-billing/#free) isn't actually a specific plan or a specific edition. There's nothing special about it. It is simply a situation where an organization is on the Standard edition but isn't yet paying money (either because they haven't put in a credit card or because they're under the free limits of usage).
* Usage plans:
* The New Relic One pricing plan has two usage plans: pay-as-you-go and annual pool of funds.
* Example use: *On the pay-as-you-go usage plan, your organization...*
* Internally, we sometimes use abbreviations for these usage plans (PAYG and APoF) but do not use those in public-facing communication.
* Billable users. For how to reference basic users and full users, see [User-related language guidelines](/docs/style-guide/writing-guidelines/user-related-language-guidelines).

* Admin functionalities like SAML SSO set up, or the ability to create custom user roles
* More synthetic monitor checks
* Increased data retention periods
## Exception for agreement- and contract-related language [#license-docs]

Because there are only a few things in the Pro and Enterprise editions, this should be an infrequent need.
Our license docs ([like this one](/docs/licenses/license-information/usage-plans/new-relic-one-usage-plan-descriptions)) use a different style and formatting than what we recommend above. Those docs are more legal/agreement-oriented. One different is that they use title case (e.g., "the Usage Plan") to reference agreement/contract terms they have specifically [defined](/docs/licenses/license-information/product-definitions/legacy-product-definitions).

## Guidelines for mentioning pricing edition [#edition-guidelines]
## Recommendations for referencing edition in requirements [#edition-guidelines]

When you document a pricing edition-related restriction, use the following approach:

* **Requirements section:** When documenting features that require the Pro or Enterprise edition, add edition requirements in a "requirements" section of the doc, with wording like: "This requires Pro or Enterprise edition." Only add pricing-related wording for the specific features that Pro and Enterprise edition give access to; this is a fairly small set of features.
* **Requirements section:** When documenting features that require the Pro or Enterprise edition, add edition requirements in a "requirements" section of the doc, with wording like: "This requires a Pro or Enterprise edition." Only add pricing-related wording for the specific features that Pro and Enterprise edition give access to; this is a fairly small set of features.
* **Pricing requirements in one section:** As a general rule, attempt to place any pricing edition requirement in a single location and avoid putting it in multiple paragraphs.
* **Original pricing plan:** At this point, only add edition-related requirements for the New Relic One pricing plan editions, not original pricing plan editions. The original pricing plan will be more and more de-emphasized over time, as more customers get on the new pricing plan, so there shouldn't be much need to mention original pricing aspects or edit those docs.

0 comments on commit d149da9

Please sign in to comment.