Update release notes, changesets, and presence README

.changeset/new-hats-learn.md

@@ -1,14 +1,19 @@
 ---
 "@fluidframework/core-interfaces": minor
 "@fluidframework/tree": minor
+"@fluid-internal/client-utils": minor
 ---
 ---
 "section": other
+
+# Since this doesn't affect external users of the framework, exclude from the release notes but
+# include in the per-package changelogs.
+"includeInReleaseNotes": false
 ---
 
 The events library has been moved from the tree package
 
-The tree package contains an events library. The events library's types and interfaces have been moved to
-`@fluidframework/core-interfaces`, while its implementation has been relocated to `@fluid-internal/client-utils`. There are
+In previous releases, the `@fluidframework/tree` package contained an internal events library. The events-related types and interfaces have been moved to
+`@fluidframework/core-interfaces`, while the implementation has been relocated to `@fluid-internal/client-utils`. There are
 no changes to how the events library is used; the relocation simply organizes the library into more appropriate
 packages. This change should have no impact on developers using the Fluid Framework.

.changeset/shy-files-jam.md

@@ -5,41 +5,49 @@
 "section": feature
 ---
 
-Presence updates are now batched and throttled
+Presence updates are now grouped and throttled
 
 Presence updates are grouped together and throttled to prevent flooding the network with messages when presence values are rapidly updated. This means the presence infrastructure will not immediately broadcast updates but will broadcast them after a configurable delay.
 
-The `allowableUpdateLatencyMs` property configures how long a local update may be delayed under normal circumstances, enabling batching with other updates. The default `allowableUpdateLatencyMs` is **60 milliseconds** but may be (1) specified during configuration of a [States Workspace](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#value-managers#states-workspace) or [Value Manager](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#value-managers#value-managers) and/or (2) updated later using the `controls` member of Workspace or Value Manager. [States Workspace](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#value-managers#states-workspace) configuration applies when a Value Manager does not have its own setting.
+The `allowableUpdateLatencyMs` property configures how long a local update may be delayed under normal circumstances,
+enabling grouping with other updates. The default `allowableUpdateLatencyMs` is **60 milliseconds** but may be (1)
+specified during configuration of a [States
+Workspace](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#states-workspace)
+or [Value
+Manager](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#value-managers)
+and/or (2) updated later using the `controls` member of a Workspace or Value Manager. The [States
+Workspace](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#states-workspace)
+configuration applies when a Value Manager does not have its own setting.
 
-Notifications are never queued; they effectively always have an `allowableUpdateLatencyMs` of 0. However, they may be batched with other updates that were already queued.
+Notifications are never queued; they effectively always have an `allowableUpdateLatencyMs` of 0. However, they may be grouped with other updates that were already queued.
 
 Note that due to throttling, clients receiving updates may not see updates for all values set by another. For example,
-with `Latest*ValueManagers`, the only value sent is the value at the time the outgoing batched message is sent. Previous
+with `Latest*ValueManagers`, the only value sent is the value at the time the outgoing grouped message is sent. Previous
 values set by the client will not be broadcast or seen by other clients.
 
 #### Example
 
-You can configure the batching and throttling behavior using the `allowableUpdateLatencyMs` property as in the following example:
+You can configure the grouping and throttling behavior using the `allowableUpdateLatencyMs` property as in the following example:
 
 ```ts
-// Configure a states workspace
+// Create and configure a states workspace
 const stateWorkspace = presence.getStates("app:v1states",
 	{
 		// This value manager has an allowable latency of 100ms.
 		position: Latest({ x: 0, y: 0 }, { allowableUpdateLatencyMs: 100 }),
-		// This value manager uses the workspace default.
+		// This value manager uses the workspace default allowable latency of 60ms.
 		count: Latest({ num: 0 }),
 	},
-	// Specify the default for all value managers in this workspace to 200ms,
+	// Set the default allowable latency for all value managers in this workspace to 200ms,
 		// overriding the default value of 60ms.
 	{ allowableUpdateLatencyMs: 200 }
 );
 
-// Temporarily set count updates to send as soon as possible
+// Temporarily set count updates to send as soon as possible.
 const countState = stateWorkspace.props.count;
 countState.controls.allowableUpdateLatencyMs = 0;
 countState.local = { num: 5000 };
 
-// Reset the update latency to the workspace default
+// Reset the update latency to the workspace default of 60ms.
 countState.controls.allowableUpdateLatencyMs = undefined;
 ```

RELEASE_NOTES/2.11.0.md

@@ -7,13 +7,12 @@
 - [✨ New Features](#-new-features)
   - [Synchronous Child Datastore Creation (#23143)](#synchronous-child-datastore-creation-23143)
   - [Presence-related events now support the `off` event deregistration pattern (#23196)](#presence-related-events-now-support-the-off-event-deregistration-pattern-23196)
-  - [Presence updates are now batched and throttled (#23075)](#presence-updates-are-now-batched-and-throttled-23075)
+  - [Presence updates are now grouped and throttled (#23075)](#presence-updates-are-now-grouped-and-throttled-23075)
 - [🌳 SharedTree DDS Changes](#-sharedtree-dds-changes)
   - [Providing unused properties in object literals for building empty ObjectNodes no longer compiles (#23162)](#providing-unused-properties-in-object-literals-for-building-empty-objectnodes-no-longer-compiles-23162)
   - [Revertible objects can now be cloned using `RevertibleAlpha.clone()` (#23044)](#revertible-objects-can-now-be-cloned-using-revertiblealphaclone-23044)
 - [Other Changes](#other-changes)
   - [API clarifications for devtools packages (#23165)](#api-clarifications-for-devtools-packages-23165)
-  - [The events library has been moved from the tree package (#23141)](#the-events-library-has-been-moved-from-the-tree-package-23141)
 
 ## ✨ New Features
 
@@ -101,41 +100,41 @@ Affected packages:
 
 [⬆️ Table of contents](#contents)
 
-### Presence updates are now batched and throttled ([#23075](https://github.com/microsoft/FluidFramework/issues/23075))
+### Presence updates are now grouped and throttled ([#23075](https://github.com/microsoft/FluidFramework/issues/23075))
 
 Presence updates are grouped together and throttled to prevent flooding the network with messages when presence values are rapidly updated. This means the presence infrastructure will not immediately broadcast updates but will broadcast them after a configurable delay.
 
-The `allowableUpdateLatencyMs` property configures how long a local update may be delayed under normal circumstances, enabling batching with other updates. The default `allowableUpdateLatencyMs` is **60 milliseconds** but may be (1) specified during configuration of a [States Workspace](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#value-managers#states-workspace) or [Value Manager](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#value-managers#value-managers) and/or (2) updated later using the `controls` member of Workspace or Value Manager. [States Workspace](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#value-managers#states-workspace) configuration applies when a Value Manager does not have its own setting.
+The `allowableUpdateLatencyMs` property configures how long a local update may be delayed under normal circumstances, enabling grouping with other updates. The default `allowableUpdateLatencyMs` is **60 milliseconds** but may be (1) specified during configuration of a [States Workspace](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#states-workspace) or [Value Manager](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#value-managers) and/or (2) updated later using the `controls` member of a Workspace or Value Manager. The [States Workspace](https://github.com/microsoft/FluidFramework/tree/main/packages/framework/presence#states-workspace) configuration applies when a Value Manager does not have its own setting.
 
-Notifications are never queued; they effectively always have an `allowableUpdateLatencyMs` of 0. However, they may be batched with other updates that were already queued.
+Notifications are never queued; they effectively always have an `allowableUpdateLatencyMs` of 0. However, they may be grouped with other updates that were already queued.
 
-Note that due to throttling, clients receiving updates may not see updates for all values set by another. For example, with `Latest*ValueManagers`, the only value sent is the value at the time the outgoing batched message is sent. Previous values set by the client will not be broadcast or seen by other clients.
+Note that due to throttling, clients receiving updates may not see updates for all values set by another. For example, with `Latest*ValueManagers`, the only value sent is the value at the time the outgoing grouped message is sent. Previous values set by the client will not be broadcast or seen by other clients.
 
 #### Example
 
-You can configure the batching and throttling behavior using the `allowableUpdateLatencyMs` property as in the following example:
+You can configure the grouping and throttling behavior using the `allowableUpdateLatencyMs` property as in the following example:
 
 ```ts
-// Configure a states workspace
+// Create and configure a states workspace
 const stateWorkspace = presence.getStates(
   "app:v1states",
   {
     // This value manager has an allowable latency of 100ms.
     position: Latest({ x: 0, y: 0 }, { allowableUpdateLatencyMs: 100 }),
-    // This value manager uses the workspace default.
+    // This value manager uses the workspace default allowable latency of 60ms.
     count: Latest({ num: 0 }),
   },
-  // Specify the default for all value managers in this workspace to 200ms,
+  // Set the default allowable latency for all value managers in this workspace to 200ms,
   // overriding the default value of 60ms.
   { allowableUpdateLatencyMs: 200 },
 );
 
-// Temporarily set count updates to send as soon as possible
+// Temporarily set count updates to send as soon as possible.
 const countState = stateWorkspace.props.count;
 countState.controls.allowableUpdateLatencyMs = 0;
 countState.local = { num: 5000 };
 
-// Reset the update latency to the workspace default
+// Reset the update latency to the workspace default of 60ms.
 countState.controls.allowableUpdateLatencyMs = undefined;
 ```
 
@@ -214,21 +213,6 @@ Affected packages:
 
 [⬆️ Table of contents](#contents)
 
-### The events library has been moved from the tree package ([#23141](https://github.com/microsoft/FluidFramework/issues/23141))
-
-The tree package contains an events library. The events library's types and interfaces have been moved to `@fluidframework/core-interfaces`, while its implementation has been relocated to `@fluid-internal/client-utils`. There are no changes to how the events library is used; the relocation simply organizes the library into more appropriate packages. This change should have no impact on developers using the Fluid Framework.
-
-#### Change details
-
-Commit: [`cae07b5`](https://github.com/microsoft/FluidFramework/commit/cae07b5c8c7904184b5fbf8c677f302da19cc697)
-
-Affected packages:
-
-- @fluidframework/core-interfaces
-- @fluidframework/tree
-
-[⬆️ Table of contents](#contents)
-
 ### 🛠️ Start Building Today!
 
 Please continue to engage with us on GitHub [Discussion](https://github.com/microsoft/FluidFramework/discussions) and [Issue](https://github.com/microsoft/FluidFramework/issues) pages as you adopt Fluid Framework!

packages/framework/presence/README.md

@@ -128,21 +128,21 @@ Notifications API is partially implemented. All messages are always broadcast ev
 
 Notifications are fundamentally unreliable at this time as there are no built-in acknowledgements nor retained state. To prevent most common loss of notifications, always check for connection before sending.
 
-### Throttling/batching
+### Throttling/grouping
 
 Presence updates are grouped together and throttled to prevent flooding the network with messages when presence values are rapidly updated. This means the presence infrastructure will not immediately broadcast updates but will broadcast them after a configurable delay.
 
-The `allowableUpdateLatencyMs` property configures how long a local update may be delayed under normal circumstances, enabling batching with other updates. The default `allowableUpdateLatencyMs` is **60 milliseconds** but may be (1) specified during configuration of a [States Workspace](#states-workspace) or [Value Manager](#value-managers) and/or (2) updated later using the `controls` member of Workspace or Value Manager. [States Workspace](#states-workspace) configuration applies when a Value Manager does not have its own setting.
+The `allowableUpdateLatencyMs` property configures how long a local update may be delayed under normal circumstances, enabling grouping with other updates. The default `allowableUpdateLatencyMs` is **60 milliseconds** but may be (1) specified during configuration of a [States Workspace](#states-workspace) or [Value Manager](#value-managers) and/or (2) updated later using the `controls` member of Workspace or Value Manager. [States Workspace](#states-workspace) configuration applies when a Value Manager does not have its own setting.
 
-Notifications are never queued; they effectively always have an `allowableUpdateLatencyMs` of 0. However, they may be batched with other updates that were already queued.
+Notifications are never queued; they effectively always have an `allowableUpdateLatencyMs` of 0. However, they may be grouped with other updates that were already queued.
 
 Note that due to throttling, clients receiving updates may not see updates for all values set by another. For example,
-with `Latest*ValueManagers`, the only value sent is the value at the time the outgoing batched message is sent. Previous
+with `Latest*ValueManagers`, the only value sent is the value at the time the outgoing grouped message is sent. Previous
 values set by the client will not be broadcast or seen by other clients.
 
 #### Example
 
-You can configure the batching and throttling behavior using the `allowableUpdateLatencyMs` property as in the following example:
+You can configure the grouping and throttling behavior using the `allowableUpdateLatencyMs` property as in the following example:
 
 ```ts
 // Configure a states workspace