Apply suggestions from code review

Co-authored-by: Michele Cyran <michele@redpanda.com>

Author: Feediver1

modules/develop/pages/consume-data/consumer-offsets.adoc

@@ -30,9 +30,9 @@ There are several strategies for managing offset commits:
 
 === Automatic offset commit
 
-Auto commit is the default commit strategy, where the client automatically commits offsets at regular intervals. You can enable this by setting `enable.auto.commit` to `true`. The client will then commit offsets every `auto.commit.interval.ms` milliseconds.
+Auto commit is the default commit strategy, where the client automatically commits offsets at regular intervals. This is set with the `enable.auto.commit` property. The client then commits offsets every `auto.commit.interval.ms` milliseconds.
 
-The primary advantage of the auto commit approach is its simplicity. After it is configured, the consumer requires no additional effort. Commits are managed in the background. However, the consumer is unaware of what was committed or when. As a result, after an application restart, some messages may be reprocessed (since consumption resumes from the last committed offset, which may include already processed messages). The strategy guarantees at-least-once delivery.
+The primary advantage of the auto commit approach is its simplicity. After it is configured, the consumer requires no additional effort. Commits are managed in the background. However, the consumer is unaware of what was committed or when. As a result, after an application restart, some messages may be reprocessed (since consumption resumes from the last committed offset, which may include already-processed messages). The strategy guarantees at-least-once delivery.
 
 NOTE: If your consume configuration is set up to consume and write to another data store, and the write to that datastore fails, the consumer might not recover when it is auto-committed. It may not only duplicate messages, but could also drop messages intended to be in another datastore. Make sure you understand the trade-off possibilities associated with this default behavior.
 
@@ -107,7 +107,7 @@ Follow these best practices to optimize offset commits.
 
 === Avoid over-committing
 
-The purpose of a commit is to save consumer progress. More frequent commits reduce the amount of data to re-read after an application restart, as the commit interval directly affects the Recovery Point Objective (RPO). Because a lower RPO is desirable, application designers may believe that committing frequently is a good design choice.
+The purpose of a commit is to save consumer progress. More frequent commits reduce the amount of data to re-read after an application restart, as the commit interval directly affects the recovery point objective (RPO). Because a lower RPO is desirable, application designers may believe that committing frequently is a good design choice.
 
 However, committing too frequently can result in adverse consequences. While individually small, each commit still results in a message being written to the `pass:[__consumer_offsets]` topic, because the position of the consumer against every partition must be recorded. At high commit rates, this workload can become a bottleneck for both the client and the server. Additionally, many Kafka client implementations do not coalesce offset commits, meaning redundant commits in a backlog still need to be processed.