Improve Acrolinx score

Author: chcomley

docs/extend/develop/public-project.md

@@ -1,7 +1,7 @@
 ---
 title: Develop extensions for public projects
 titleSuffix: Azure DevOps Services
-description: Learn how to develop Azure DevOps Services extensions that support non-member and public users in public projects.
+description: Learn how to develop Azure DevOps Services extensions that support nonmember and public users in public projects.
 ms.subservice: azure-devops-ecosystem
 ms.assetid: 3fa22433-150b-428c-8e10-3ffb4d832c20
 ms.topic: how-to
@@ -17,31 +17,31 @@ ms.date: 04/03/2026
 
 [!INCLUDE [version-eq-azure-devops](../../includes/version-eq-azure-devops.md)]
 
-Azure DevOps Services supports both private and public projects. Private projects restrict access to authenticated users with explicit permissions. Public projects allow non-member users to view project contents in a read-only state.
+Azure DevOps Services supports both private and public projects. Private projects restrict access to authenticated users with explicit permissions. Public projects allow nonmember users to view project contents in a read-only state.
 
-A non-member user can be either:
+A nonmember user can be either:
 - **Anonymous**: Not authenticated to Azure DevOps Services
 - **Public**: Authenticated to Azure DevOps Services but not a member of the organization
 
-Non-member users see the same views as authenticated users, but Azure DevOps hides or disables non-public functionality such as settings, actions, and build queue operations.
+Nonmember users see the same views as authenticated users, but Azure DevOps hides or disables nonpublic functionality such as settings, actions, and build queue operations.
 
 [!INCLUDE [allow-public-project-policy](../../organizations/projects/includes/allow-public-project-policy.md)]
 
-## Extension visibility for non-members
+## Extension visibility for nonmembers
 
-As an extension developer, you can make all or part of your extension available to non-member users. These users can only use your extension from within public projects. If you choose not to make your extension available to non-member users, you need no changes and the decision has no impact on members who use your extension within public projects.
+As an extension developer, you can make all or part of your extension available to nonmember users. These users can only use your extension from within public projects. If you choose not to make your extension available to nonmember users, you need no changes and the decision has no effect on members who use your extension within public projects.
 
-Use this checklist to help decide if you should make your extension available to non-member users:
+Use this checklist to help decide if you should make your extension available to nonmember users:
 
 > [!div class="checklist"]
 > * Your extension presents data that is relevant to non-member users
 > * Your extension contributes capabilities at the project level
 > * Your extension contributes to product areas that non-member users can access
-> * Your extension doesn't extend or rely on features that non-member users cannot access, such as the Extension Data Service or certain Azure DevOps Services REST APIs. For more information, see the [Limitations](#limitations) section.
+> * Your extension doesn't extend or rely on features that non-member users can't access, such as the Extension Data Service or certain Azure DevOps Services REST APIs. For more information, see the [Limitations](#limitations) section.
 
 ## Configure contribution visibility
 
-By default, Azure DevOps shows contributions only to organization members. To give non-member users visibility to a contribution, set the `restrictedTo` attribute on that contribution. The value is a string array that lists which user types should see the contribution. The possible values include:
+By default, Azure DevOps shows contributions only to organization members. To give nonmember users visibility to a contribution, set the `restrictedTo` attribute on that contribution. The value is a string array that lists which user types should see the contribution. The possible values include:
 
 * `member`: An authenticated user who is a member of the organization
 * `public`: An authenticated user who is **not** a member of the organization
@@ -123,24 +123,24 @@ You can also set the default visibility for all contributions in your extension
 
 <a name="limitations"></a>
 
-## Non-member limitations
+## Nonmember limitations
 
 If you want to make some or all aspects of your contribution available to public users, consider the following limitations.
 
 ### VSS SDK method restrictions
 
-The core SDK script, VSS.SDK.js, enables web extensions to communicate with the parent frame to perform operations like initializing communication and getting current user context information. The following VSS SDK methods do not support non-member users:
+The core SDK script, VSS.SDK.js, enables web extensions to communicate with the parent frame to perform operations like initializing communication and getting current user context information. The following VSS SDK methods don't support nonmember users:
 
 * `VSS.getAccessToken()`
 * `VSS.getAppToken()`
 
 ### Extension data service limitations
 
-Because the [extension data service](./data-storage.md) manages data that isn't scoped or secured to a project, non-member users cannot read or write any type of extension data.
+Because the [extension data service](./data-storage.md) manages data that isn't scoped or secured to a project, nonmember users can't read or write any type of extension data.
 
 #### Handle data access errors
 
-When the data service cannot access data due to permission limitations by the calling user, the promise returned from the call to `getValue` gets rejected. The error passed to the reject function has a name property, which helps you understand why the call failed to read or write data.
+When the data service can't access data due to permission limitations by the calling user, the promise returned from the call to `getValue` gets rejected. The error passed to the reject function has a name property, which helps you understand why the call failed to read or write data.
 
 ```javascript
 VSS.getService(VSS.ServiceIds.ExtensionData).then(function(dataService) {
@@ -156,9 +156,9 @@ VSS.getService(VSS.ServiceIds.ExtensionData).then(function(dataService) {
 
 ### REST API access
 
-Azure DevOps Services provides a limited set of REST APIs to non-member users. These APIs include most organization-level and project-level APIs for features that non-member users can generally access. Consider this information when you decide whether to make your extension available to non-member users.
+Azure DevOps Services provides a limited set of REST APIs to nonmember users. These APIs include most organization-level and project-level APIs for features that nonmember users can generally access. Consider this information when you decide whether to make your extension available to nonmember users.
 
-We recommend that you use version 5.0 and later APIs, as Azure DevOps makes certain APIs available to non-member users only starting with version 5.0.
+Use version 5.0 and later APIs, as Azure DevOps makes certain APIs available to nonmember users only starting with version 5.0.
 
 #### Identity references
 
@@ -170,7 +170,7 @@ Use permissions to decide whether to surface or enable a capability in your exte
 
 #### Check build queue permissions
 
-This example shows how to use the Security REST client to check whether the user has permissions to queue builds in the current project. By default, non-member users don't have this permission.
+This example shows how to use the Security REST client to check whether the user has permissions to queue builds in the current project. By default, nonmember users don't have this permission.
 
 ```javascript
 VSS.require(["VSS/Service", "VSS/security/RestClient"], function(VSS_Service, Security_RestClient) {
@@ -196,7 +196,7 @@ VSS.require(["VSS/Service", "VSS/security/RestClient"], function(VSS_Service, Se
 
 ## Dashboard widget requirements
 
-Just like other types of contributions, the `restrictedTo` contribution property controls the visibility of dashboard widget contributions. For example, to make a widget visible to both non-member and member users:
+Just like other types of contributions, the `restrictedTo` contribution property controls the visibility of dashboard widget contributions. For example, to make a widget visible to both nonmember and member users:
 
 ```json
 {
@@ -222,9 +222,9 @@ Just like other types of contributions, the `restrictedTo` contribution property
 
 ### Configure widget settings
 
-When you control widget visibility to non-member users, the dashboard framework also provides an optional, open-form storage mechanism for widget settings. Two mechanisms indicate whether widget settings are available for non-member users in public projects.
+When you control widget visibility to nonmember users, the dashboard framework also provides an optional, open-form storage mechanism for widget settings. Two mechanisms indicate whether widget settings are available for nonmember users in public projects.
 
-A widget with configurable settings that is visible to non-member users **must** follow one of the following patterns. Not following these patterns blocks the widget from appearing to these users.
+A widget with configurable settings that's visible to nonmember users **must** follow one of the following patterns. Not following these patterns blocks the widget from appearing to these users.
 
 ### Project-specific settings (extension level)
 
@@ -243,7 +243,7 @@ Set the widget contribution's `canStoreCrossProjectSettings` property to `false`
 
 ### Project-specific settings (instance level)
 
-Individual widget instances can also indicate that their settings are project-specific and available to non-member users. When saving the settings, the widget should set `hasCrossProjectSettings` to `false` in the stringified JSON string:
+Individual widget instances can also indicate that their settings are project-specific and available to nonmember users. When you save the settings, the widget should set `hasCrossProjectSettings` to `false` in the stringified JSON string:
 
 ```json
 {
@@ -259,27 +259,27 @@ If your extension contributes a build or release task, you need no changes to us
 
 ## Work item tracking considerations
 
-Extensions don't work for non-member users in the context of a public project without changes. This includes the work item form, other work item experiences, and interaction with work item tracking REST APIs.
+Extensions don't work for nonmember users in the context of a public project without changes, including the work item form, other work item experiences, and interaction with work item tracking REST APIs.
 
 ### Work item form limitations
 
-Azure DevOps fails all work item updates or deletes for non-member users.
+Azure DevOps rejects all work item updates or deletes for nonmember users.
 
 ### Identity handling
 
-In Azure DevOps Services REST API version 5.0 and later, the service returns identities as `IdentityRef` objects instead of strings. As described previously, Azure DevOps doesn't return certain fields, like `uniqueName`, in these objects if a non-member user makes the API call.
+In Azure DevOps Services REST API version 5.0 and later, the service returns identities as `IdentityRef` objects instead of strings. As described previously, Azure DevOps doesn't return certain fields, like `uniqueName`, in these objects if a nonmember user makes the API call.
 
 ### API scope restrictions
 
-Extensions can invoke only project-scoped REST APIs when the current user isn't an organization member. Azure DevOps rejects any REST API calls not scoped to a project.
+Extensions can invoke only project-scoped REST APIs when the current user isn't an organization member. Azure DevOps rejects any REST API calls that aren't scoped to a project.
 
 ### Query limitations
 
-Non-member users face the following limitations related to work item queries:
+Nonmember users face the following limitations related to work item queries:
 
-* Non-member users can run known queries by ID or path only
-* Queries must be scoped to the current project. Azure DevOps excludes any work items that don't belong to the current project
-* Non-member users cannot create new queries or execute WIQL queries
+* Nonmember users can run known queries by ID or path only.
+* Queries must be scoped to the current project. Azure DevOps excludes any work items that don't belong to the current project.
+* Nonmember users can't create new queries or execute WIQL queries.
 
 ## Related content