[review] MD-112: Technology publication strategy

.github/CODEOWNERS

@@ -11,6 +11,7 @@
 /MD/md-5/ @l-monninger @apenzk
 /MD/md-15/ @l-monninger @apenzk
 /MD/md-93/ @andygolay
+/MD/md-112/ @apenzk
 
 ## MIPs
 /MIP/mip-0/ @l-monninger @apenzk
@@ -20,8 +21,8 @@
 /MIP/mip-39/ @franck44
 /MIP/mip-53/ @l-monninger
 /MIP/mip-58/ @primata @apenzk
-/MIP/mip-61/ @apenzk @musitdev
 /MIP/mip-60/ @franck44 @apenzk
+/MIP/mip-61/ @apenzk @musitdev
 /MIP/mip-84/ @apenzk
 /MIP/mip-88/ @apenzk @Primata
 /MIP/mip-91/ @apenzk

.vscode/spellright.dict

@@ -4,10 +4,14 @@ Fastconfirmation
 Fastconfirmations
 Merkle
 multisig
+lightpaper
+lightpapers
 postconfirm
 postconfirmed
 Postconfirmer
 timelock
 timelocks
 trustless
 trustlessness
+whitepaper
+whitepapers

MD/md-112/README.md

@@ -0,0 +1,49 @@
+# MD-112: Technology publication strategy
+
+- **Description**: Require a technology publication strategy for both the vision and current state of the technology.
+- **Authors**: Andreas Penzkofer
+- **Approval**: <!--Either approved (:white_check_mark:) or rejected (:x:) by the governance body. To be inserted by governance. -->
+
+## Overview
+
+Technology vision and current state publication strategy should be communicated to the community. We need a streamlined process for this.
+
+## Desiderata
+
+### D1: Identify the target audience
+
+**User journey (Author)**: The author knows which audience we are writing for.
+
+**Description**: Public documents should be targeted for a specific set of audience. Otherwise they miss their goals.
+
+**Recommendation**: Consider the following audience types:
+
+- Technical audience: Engineers, architects, etc.
+- Business audience: Product managers, sales, etc.
+- Investor audience: Shareholders, potential investors, etc.
+
+### D2: Create a publication product specific for a purpose
+
+**User journey (Author)**: The author knows the purpose of the publication.
+
+**Description**: Publications should be targeted for a specific purpose. Otherwise they miss their goals.
+
+**Recommendation**: Consider the following purposes:
+
+- MIP: Technical excerpt that specify the concrete ideas, technical details and requirements for a technology.
+- Blog post: Informal piece that explain the author's thoughts on a technology, and that may be focused on important MIPs.
+- Litepaper: High-level overview of a technology, and that may include concrete ideas, technical details and requirements. They may be updated when new blog posts are published, or when the technology matures. They are in essence a **live paper**.
+- Whitepaper: A long-form piece that provides a deep dive into a technology, and that may include concrete ideas, technical details and requirements. They are the *north stars*, i.e. the technological distinguishing feature of the technology.
+
+### D3: Create a process to make technological vision updates accessible to the community
+
+**User journey (Author)**: The author understands how to transform the technological vision into a publication of some kind.
+**User journey (Community)**: The community can access the technological vision in an easy and accessible way.
+
+**Description**: There should be a streamlined process to make technological vision updates accessible to the community.
+
+**Recommendation**: Consider the following process:
+
+- Define a clear process to transform MIPs into blog posts, litepapers.
+
+## Changelog

MIP/mip-84/README.md

@@ -179,11 +179,11 @@ The expected time for the completion of the transfer is the time it takes is in
 
 ### A1: Background EigenLayer
 
-In order to protect the protocol from exploits and potential losses, rate limiting is essential. For comparison the white paper [EigenLayer: The Restaking Collective](https://docs.eigenlayer.xyz/assets/files/EigenLayer_WhitePaper-88c47923ca0319870c611decd6e562ad.pdf) proposes that AVS (Actively Validated Services) can run for a bridge and the stake of validators protects the transferred value crypto-economically through slashing conditions. More specifically section 3.4 Risk Management mentions
+In order to protect the protocol from exploits and potential losses, rate limiting is essential. For comparison the whitepaper [EigenLayer: The Restaking Collective](https://docs.eigenlayer.xyz/assets/files/EigenLayer_WhitePaper-88c47923ca0319870c611decd6e562ad.pdf) proposes that AVS (Actively Validated Services) can run for a bridge and the stake of validators protects the transferred value crypto-economically through slashing conditions. More specifically section 3.4 Risk Management mentions
 
 > [...] to restrict the Profit from Corruption of any particular AVS [...] a bridge can restrict the value flow within the period of slashing.
 
-Eigenlayer provides the following definition on strong economic security in their [white paper (EIGEN: The Universal Intersubjective Work Token)](https://docs.eigenlayer.xyz/assets/files/EIGEN_Token_Whitepaper-0df8e17b7efa052fd2a22e1ade9c6f69.pdf):
+Eigenlayer provides the following definition on strong economic security in their [whitepaper (EIGEN: The Universal Intersubjective Work Token)](https://docs.eigenlayer.xyz/assets/files/EIGEN_Token_Whitepaper-0df8e17b7efa052fd2a22e1ade9c6f69.pdf):
 
 > *Formal Definition of Strong crypto-economic Security*
 If [a bridge] acquires more [crypto-economic] security than the harm it can suffer from an attack within the interval $T_{redeem}$ slots, then it achieves strong crypto-economic security, i.e.<br>

md-template.md

@@ -52,7 +52,7 @@
   TODO: Remove this comment before finalizing.
 -->
 
-# Changelog
+## Changelog
 
 <!--
   The changelog should be maintained after publication.