Changes as per review.

.github/CODEOWNERS

@@ -646,11 +646,11 @@ peps/pep-0765.rst  @iritkatriel @ncoghlan
 peps/pep-0766.rst  @warsaw
 peps/pep-0767.rst  @carljm
 peps/pep-0768.rst  @pablogsal
+peps/pep-0769.rst  @facundobatista
 # ...
 peps/pep-0777.rst  @warsaw
 # ...
 peps/pep-0789.rst  @njsmith
-peps/pep-0790.rst  @facundobatista
 # ...
 peps/pep-0801.rst  @warsaw
 # ...

peps/pep-0769.rst

@@ -41,7 +41,8 @@ This approach maintains simplicity and avoids the complexity of assigning
 individual default values to multiple attributes or items. While some
 discussions considered allowing multiple defaults, the increased
 complexity and potential for confusion led to favoring a single default
-value for all cases (more about this below in Rejected Ideas).
+value for all cases (more about this below in `Rejected Ideas
+<PEP 769 Rejected Ideas>`__).
 
 
 Specification
@@ -142,12 +143,14 @@ Using ``default``::
     ('bar', 'XYZ')
 
 
-About Posible Implementations
------------------------------
+.. _PEP 769 About Possible Implementations:
+
+About Possible Implementations
+------------------------------
 
 For the case of ``attrgetter`` is quite direct: it implies using
 ``getattr`` catching a possible ``AttributeError``. So
-``attrgetter("name", default=XYZ)(obj)`` would be like:
+``attrgetter("name", default=XYZ)(obj)`` would be like::
 
     try:
         value = getattr(obj, "name")
@@ -170,7 +173,7 @@ understand: attempting ``__getitem__`` and catching a possible exception
     except (TypeError, IndexError, KeyError):
         value = XYZ
 
-However, this would be not as eficient as we'd want for particular cases,
+However, this would be not as efficient as we'd want for particular cases,
 e.g. using dictionaries where particularly good performance is desired. A
 more complex alternative would be::
 
@@ -183,7 +186,7 @@ more complex alternative would be::
             value = XYZ
 
 Better performance, more complicated to implement and explain. This is
-the first case in the Open Issues section later.
+the first case in the `Open Issues <PEP 769 Open Issues>`__ section later.
 
 
 Corner Cases
@@ -206,6 +209,8 @@ The same applies to any user built object that overloads ``__getitem__``
 or ``__getattr__`` implementing fallbacks.
 
 
+.. _PEP 769 Rejected Ideas:
+
 Rejected Ideas
 ==============
 
@@ -276,6 +281,8 @@ but requires further discussion and for sure is out of the scope of this
 PEP.
 
 
+.. _PEP 769 Open Issues:
+
 Open Issues
 ===========
 
@@ -285,8 +292,9 @@ Behaviour Equivalence for ``itemgetter``
 We need to define how ``itemgetter`` would behave, if just attempt to
 access the item and capture exceptions no matter which the object, or
 validate first if the object provides a ``get`` method and use it to
-retrieve the item with a default. See examples in the About Posible
-Implementations subsection before.
+retrieve the item with a default. See examples in the `About Possible
+Implementations <PEP 769 About Possible Implementations>`__ subsection
+above.
 
 This would help performance for the case of dictionaries, but would make
 the ``default`` feature somewhat more difficult to explain, and a little
@@ -318,9 +326,9 @@ doing ``getitem(obj, name, default)`` would be equivalent to::
     try:
         result = obj[name]
     except (TypeError, IndexError, KeyError):
-        resutl = default
+        result = default
 
-(however see previous open issue about special case for dictionaries)
+(However see previous open issue about special case for dictionaries)
 
 
 How to Teach This