Update links to open discussion minutes archives (#1873)

docs/design/classes.md

@@ -1863,7 +1863,7 @@ There are some opportunities to improve on and simplify the C++ story:
     aren't friends of the base class.
 
 **References:** This was discussed in
-[the open discussion on 2021-07-12](https://docs.google.com/document/d/1QCdKQ33rki-kCDrxi8UHy3a36dtW0WdMqpUzluGSrz4/edit?resourcekey=0-bZmNUiueOiH_sysJNqnT9A#heading=h.40jlsrcgp8mr).
+[the open discussion on 2021-07-12](https://docs.google.com/document/d/14vAcURDKeH6LZ_TQCMRGpNJrXSZCACQqDy29YH19XGo/edit#heading=h.40jlsrcgp8mr).
 
 #### Interop with C++ inheritance
 

proposals/p0818/regular_equivalence_classes.md

@@ -221,6 +221,6 @@ endlessly.
 See these notes from discussions:
 
 -   [Regular equivalence classes 2021-09-23](https://docs.google.com/document/d/1iyL7ZDfWT6ZmDSz6Fp8MrLcl5nOQc4ItQbeL3QlVXYU/edit#)
--   [Carbon minutes (rolling): Open discussions: 2021-09-27](https://docs.google.com/document/d/1cRrhRrmaUf2hVi2lFcHsYo2j0jI6t9RGZoYjWhRxp14/edit?resourcekey=0-xWHBEZ8zIqnJiB4yfBSLfA#heading=h.qh4b1gy7o5el)
--   [Carbon minutes (rolling): Open discussions: 2021-09-28](https://docs.google.com/document/d/1cRrhRrmaUf2hVi2lFcHsYo2j0jI6t9RGZoYjWhRxp14/edit?resourcekey=0-xWHBEZ8zIqnJiB4yfBSLfA#heading=h.9a1r39mla9ho)
+-   [Carbon minutes (rolling): Open discussions: 2021-09-27](https://docs.google.com/document/d/1UelNaT_j61G8rYp6qQZ-biRddTuGcxJtqXxrVbjB9rA/edit#heading=h.qh4b1gy7o5el)
+-   [Carbon minutes (rolling): Open discussions: 2021-09-28](https://docs.google.com/document/d/1UelNaT_j61G8rYp6qQZ-biRddTuGcxJtqXxrVbjB9rA/edit#heading=h.9a1r39mla9ho)
 -   [Regular equivalence classes 2 2021-10-01](https://docs.google.com/document/d/1xGDRSV6q534-CoDZnzuZJmzhty2yPki2ZfDDPLSHYek/edit#)

proposals/p0920.md

@@ -354,5 +354,5 @@ deduced? In particular we were worried about evolution, and allowing users to
 add functions to an interface as long as they had defaults.
 
 These problems were discussed in
-[2021-12-08 open discussion](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.njnqpdcjp5h0).
+[2021-12-08 open discussion](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.njnqpdcjp5h0).
 We concluded that we will later find other mechanisms to support this use case.

proposals/p0950.md

@@ -96,8 +96,8 @@ This design was the conclusion of a number of discussions and proposals:
     [Member lookup in generic and non-generic contexts](https://docs.google.com/document/d/1-vw39x5YARpUZ0uD2xmKepLEKG7_u122CUJ67hNz3hk/edit#)
 -   Nov 4, 2021 document by `josh11b` and `mconst` titled
     [Carbon: facets exposed from generics](https://docs.google.com/document/d/1C1eIzd6JY0ooE1rDjW1vx7e3i7sgGugCA9bPMRhwWM0/edit#)
--   [Open discussion on 2021-11-08](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.ec285oam2okw)
--   [Open discussion 2021-11-11](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.8vuatm82d1mk)
+-   [Open discussion on 2021-11-08](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.ec285oam2okw)
+-   [Open discussion 2021-11-11](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.8vuatm82d1mk)
 
 The main alternatives we evaluated are summarized below.
 

proposals/p0981.md

@@ -74,7 +74,7 @@ This proposal advances Carbon's goals:
 Alternatives were considered in:
 
 -   [question-for-leads issue #710: Default comparison for data classes](https://github.com/carbon-language/carbon-lang/issues/710)
--   [open discussion on 2021-11-29](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.6komy889g3hc)
+-   [open discussion on 2021-11-29](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.6komy889g3hc)
 
 ### Field order is not significant
 

proposals/p0983.md

@@ -164,5 +164,5 @@ as we determined there was a need for the greater expressivity of being able to
 mark individual items as `final`. This discussion occurred in:
 
 -   [Document examining an extended example using specialization](https://docs.google.com/document/d/1w-kRC338Jc1ibTu7Vf0pOlGKdrpumfz63bzUIxEj9jY/edit)
--   [2021-11-29 open discussion](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.6komy889g3hc)
+-   [2021-11-29 open discussion](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.6komy889g3hc)
 -   [Carbon's #typesystem channel on Discord](https://discord.com/channels/655572317891461132/708431657849585705/910681126236987495)

proposals/p1084.md

@@ -193,7 +193,7 @@ some experience with it.
 ### Allow function bodies using incomplete interfaces
 
 We
-[considered](https://docs.google.com/document/d/1cRrhRrmaUf2hVi2lFcHsYo2j0jI6t9RGZoYjWhRxp14/edit?resourcekey=0-xWHBEZ8zIqnJiB4yfBSLfA#heading=h.oqmpxtubjmkm)
+[considered](https://docs.google.com/document/d/1UelNaT_j61G8rYp6qQZ-biRddTuGcxJtqXxrVbjB9rA/edit#heading=h.oqmpxtubjmkm)
 allowing a function definition to use an incomplete interface. One concern was
 whether the criteria for when the function body depended on something in the
 interface's definition would be too subtle for developers to reason about. We
@@ -216,7 +216,7 @@ declarations for a few reasons:
     expect to associate with a function.
 
 This was discussed in
-[open discussion on 2022-03-14](https://docs.google.com/document/d/1cRrhRrmaUf2hVi2lFcHsYo2j0jI6t9RGZoYjWhRxp14/edit?resourcekey=0-xWHBEZ8zIqnJiB4yfBSLfA#heading=h.oqmpxtubjmkm)
+[open discussion on 2022-03-14](https://docs.google.com/document/d/1UelNaT_j61G8rYp6qQZ-biRddTuGcxJtqXxrVbjB9rA/edit#heading=h.oqmpxtubjmkm)
 and
 [question-for-leads issue #1132](https://github.com/carbon-language/carbon-lang/issues/1132).
 
@@ -228,6 +228,6 @@ to deduced parameters for consistency. We may in the future allow some rewrites
 between equivalent expressions, such as between `Vector(T:! Type)` and
 `[T:! Type] Vector(T)`, but for now we are starting with the more restrictive
 rule. This was discussed in
-[open discussion on 2022-03-24](https://docs.google.com/document/d/1cRrhRrmaUf2hVi2lFcHsYo2j0jI6t9RGZoYjWhRxp14/edit?resourcekey=0-xWHBEZ8zIqnJiB4yfBSLfA#heading=h.w4zgqvarhnbn)
+[open discussion on 2022-03-24](https://docs.google.com/document/d/1UelNaT_j61G8rYp6qQZ-biRddTuGcxJtqXxrVbjB9rA/edit#heading=h.w4zgqvarhnbn)
 and in
 [#syntax channel on Discord](https://discord.com/channels/655572317891461132/709488742942900284/953798170750615622).

proposals/p1144.md

@@ -124,7 +124,7 @@ motivate changes in the future, is to prioritize the different implementations
 generated by the `like` shortcut separately in `match_first` blocks.
 
 This was discussed in
-[open discussion on 2022-03-24](https://docs.google.com/document/d/1cRrhRrmaUf2hVi2lFcHsYo2j0jI6t9RGZoYjWhRxp14/edit?resourcekey=0-xWHBEZ8zIqnJiB4yfBSLfA#).
+[open discussion on 2022-03-24](https://docs.google.com/document/d/1UelNaT_j61G8rYp6qQZ-biRddTuGcxJtqXxrVbjB9rA/edit#).
 
 ### Where are the impl definitions from `like` generated?
 
@@ -145,7 +145,7 @@ This was discussed in
 ### Support marking interfaces or their members as `external`
 
 We
-[discussed on 2022-03-28](https://docs.google.com/document/d/1cRrhRrmaUf2hVi2lFcHsYo2j0jI6t9RGZoYjWhRxp14/edit?resourcekey=0-xWHBEZ8zIqnJiB4yfBSLfA#heading=h.sk06n1ggoa3o)
+[discussed on 2022-03-28](https://docs.google.com/document/d/1UelNaT_j61G8rYp6qQZ-biRddTuGcxJtqXxrVbjB9rA/edit#heading=h.sk06n1ggoa3o)
 the idea that operator interfaces might be marked `external`. This would either
 mean that types would only be able to implement them using `external impl` or
 that even if they were implemented internally, they would not add the names of

proposals/p1154.md

@@ -51,13 +51,13 @@ Destructors interact with inheritance, which was introduced in proposal
 
 Destructors were discussed in open discussion on these dates:
 
--   [2021-07-12](https://docs.google.com/document/d/1QCdKQ33rki-kCDrxi8UHy3a36dtW0WdMqpUzluGSrz4/edit?resourcekey=0-bZmNUiueOiH_sysJNqnT9A#heading=h.40jlsrcgp8mr)
--   [2021-08-30](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.4dobu6v1cdam)
--   [2021-10-04](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.a0rffns9r10n)
+-   [2021-07-12](https://docs.google.com/document/d/14vAcURDKeH6LZ_TQCMRGpNJrXSZCACQqDy29YH19XGo/edit#heading=h.40jlsrcgp8mr)
+-   [2021-08-30](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.4dobu6v1cdam)
+-   [2021-10-04](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.a0rffns9r10n)
     discussed not all types being destructible, and that some types are
     `TriviallyDestructible`
--   [2021-10-18](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.uz59mgk5ezch)
--   [2022-03-24](https://docs.google.com/document/d/1cRrhRrmaUf2hVi2lFcHsYo2j0jI6t9RGZoYjWhRxp14/edit?resourcekey=0-xWHBEZ8zIqnJiB4yfBSLfA#heading=h.cy8m79pgct1v)
+-   [2021-10-18](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.uz59mgk5ezch)
+-   [2022-03-24](https://docs.google.com/document/d/1UelNaT_j61G8rYp6qQZ-biRddTuGcxJtqXxrVbjB9rA/edit#heading=h.cy8m79pgct1v)
 
 As part of
 [proposal 777: Inheritance](https://github.com/carbon-language/carbon-lang/pull/777),
@@ -109,11 +109,11 @@ downsides that we ultimately decided were too large:
     type-of-types were implemented.
 
 This was considered in the open discussions on
-[2021-08-30](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.4dobu6v1cdam)
+[2021-08-30](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.4dobu6v1cdam)
 and
-[2021-10-18](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.uz59mgk5ezch).
+[2021-10-18](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.uz59mgk5ezch).
 We decided to go with the proposed approach in
-[the open discussion on 2022-03-24](https://docs.google.com/document/d/1cRrhRrmaUf2hVi2lFcHsYo2j0jI6t9RGZoYjWhRxp14/edit?resourcekey=0-xWHBEZ8zIqnJiB4yfBSLfA#heading=h.cy8m79pgct1v).
+[the open discussion on 2022-03-24](https://docs.google.com/document/d/1UelNaT_j61G8rYp6qQZ-biRddTuGcxJtqXxrVbjB9rA/edit#heading=h.cy8m79pgct1v).
 
 ### Prevent virtual function calls in destructors
 
@@ -137,13 +137,13 @@ transitively calls. We would consider this as a potential future extension. As
 noted in the design, this could be achieved by using the `partial` type.
 
 This was considered in the open discussions on
-[2021-08-30](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.4dobu6v1cdam)
+[2021-08-30](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.4dobu6v1cdam)
 and
-[2021-10-18](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.uz59mgk5ezch).
+[2021-10-18](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.uz59mgk5ezch).
 
 ### Allow functions to act as destructors
 
-[We considered, on 2021-08-30](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.4dobu6v1cdam),
+[We considered, on 2021-08-30](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.4dobu6v1cdam),
 how we might support returning a value, for example a failure, from a
 destructor. This would require that the destructor be called explicitly, rather
 than implicitly as part of a `Allocator.Delete()` call or a variable leaving
@@ -183,7 +183,7 @@ is particularly concerning if whether a type implements a constraint depends on
 which function is the enclosing scope.
 
 This was considered in the
-[open discussion on 2021-08-30](https://docs.google.com/document/d/105GsfmxOwcZ_iHkCXFnALB7e-_R3IgMpGKfeT84h1mc/edit?resourcekey=0-h3uVHObsJwChVg1MdaWfKQ#heading=h.4dobu6v1cdam).
+[open discussion on 2021-08-30](https://docs.google.com/document/d/1YhwNKLxQsWf8NPVaRm9PvgPmSM3PIK_KlD1gpNuUfwY/edit#heading=h.4dobu6v1cdam).
 
 ### Allow multiple conditional destructors
 
@@ -270,7 +270,7 @@ does not have a virtual destructor, but may be pointing to a derived value. We
 as part of
 [proposal 777: Inheritance](https://github.com/carbon-language/carbon-lang/pull/777).
 We decided to go with the proposed approach in
-[the open discussion on 2022-03-24](https://docs.google.com/document/d/1cRrhRrmaUf2hVi2lFcHsYo2j0jI6t9RGZoYjWhRxp14/edit?resourcekey=0-xWHBEZ8zIqnJiB4yfBSLfA#heading=h.cy8m79pgct1v).
+[the open discussion on 2022-03-24](https://docs.google.com/document/d/1UelNaT_j61G8rYp6qQZ-biRddTuGcxJtqXxrVbjB9rA/edit#heading=h.cy8m79pgct1v).
 
 #### Don't distinguish safe and unsafe delete operations
 
@@ -299,7 +299,7 @@ This option was considered in the
 #### Allow final destructors
 
 One option we
-[considered early on](https://docs.google.com/document/d/1QCdKQ33rki-kCDrxi8UHy3a36dtW0WdMqpUzluGSrz4/edit?resourcekey=0-bZmNUiueOiH_sysJNqnT9A#heading=h.40jlsrcgp8mr)
+[considered early on](https://docs.google.com/document/d/14vAcURDKeH6LZ_TQCMRGpNJrXSZCACQqDy29YH19XGo/edit#heading=h.40jlsrcgp8mr)
 for extensible classes with non-virtual destructors, was to require the same
 thing we do from non-virtual methods. That is, require that the implementation
 in the base class is appropriate for derived classes. We ultimately decided on a