Address code review comments.

ops/charm.py

@@ -729,7 +729,7 @@ class SecretChangedEvent(SecretEvent):
     a new secret revision, and all applications or units that are tracking this
     secret will be notified via this event that a new revision is available.
 
-    Typically, fetch the new content by calling
+    Typically, the charm will fetch the new content by calling
     :meth:`event.secret.get_content() <ops.Secret.get_content>` with ``refresh=True``
     to tell Juju to start tracking the new revision.
     """
@@ -757,7 +757,7 @@ class SecretRemoveEvent(SecretEvent):
     observers have updated to that new revision, this event will be fired to
     inform the secret owner that the old revision can be removed.
 
-    Typically, call
+    Typically, the charm will call
     :meth:`event.secret.remove_revision() <ops.Secret.remove_revision>` to
     remove the now-unused revision.
     """

ops/framework.py

@@ -224,11 +224,10 @@ def defer(self) -> None:
         better to just wait for the event that indicates the precondition has
         been met.
 
-        For example, if ``config-changed`` is fired, and handling the event
-        cannot complete without a different config, there is no reason to defer
-        the event because there will be a *different* ``config-changed`` event
-        when the config actually changes, rather than checking to see if maybe
-        config has changed prior to every other event that occurs.
+        For example, if handling a config change requires that two config
+        values are changed, there's no reason to defer the first
+        ``config-changed`` because there will be a *second* ``config-changed``
+        event fired when the other config value changes.
 
         Similarly, if two events need to occur before execution can proceed
         (say event A and B), the event A handler could ``defer()`` because B