Merge branch 'main' into update/glossary-terms-workshop

GLOSSARY.md

@@ -27,7 +27,7 @@ An entity that monitors L1 **and** L2 to understand token supply.
 ERC-20 type token for the Movement Network with the source contract on L1. See also \$MOVE. > [MG-39](./MG/mg-39/README.md)
 
 **\$L2MOVE**
-Native token on L2. Used to pay for L2 gas. > [MG-39](./MG/mg-39/README.md)
+Native token on L2. Used to pay for L2 gas. Wrapped version of the \$L1MOVE token. > [MG-39](./MG/mg-39/README.md)
 
 **L2Block**  
 A block of transactions that is processed by the FFS protocol. It contains information about the state root produced by the transactions in the block.
@@ -36,7 +36,7 @@ A block of transactions that is processed by the FFS protocol. It contains infor
 ERC-20 type token for the Movement Network with the source contract on L1. See also \$L1MOVE. > [MG-39](./MG/mg-39/README.md)
 
 **Native Bridge**
-Native bridge that permits to exchange of \$L1MOVE into \$L2MOVE, and vice versa. This bridge mints \$L2MOVE.
+The bridge that allows the transfer of tokens between L1 and L2, which hold \$L1MOVE and \$L2MOVE token, respectively. The native bridge has the capability to mint \$L2MOVE tokens. > [MG-39](./MG/mg-39/README.md)
 
 **Postconfirmation**  
 The process of confirming a (sequence of) blocks after it has been processed by the FFS protocol on L1.

MD/md-0/README.md

@@ -2,16 +2,8 @@
 - **Description**: Provide formal structure for proposing non-trivial improvements to Movement.
 - **Authors**: [Liam Monninger](mailto:[email protected])
 
-
-<!--
-  This template is for drafting Desiderata. It ensures a structured representation of wishes, requirements, or needs related to the overarching objective mentioned in the title. After filling in the requisite fields, please delete these comments.
-
-  Note that an MD number will be assigned by an editor. When opening a pull request to submit your MD, please use an abbreviated title in the filename, `md-draft_title_abbrev.md`.
-
-  TODO: Remove this comment before finalizing.
--->
-
 ## Overview
+
 Provide formal structure for proposing non-trivial improvements to Movement. This should be used for specifying complex changes to Movement technologies--particularly those that may require third-parties to adjust their usage of said technologies.
 
 ## Definitions
@@ -20,51 +12,20 @@ Provide definitions that you think will empower the reader to quickly dive into
 
 ## Desiderata
 
-<!--
-  List out the specific desiderata. Each entry should consist of:
-
-  1. Title: A concise name for the desideratum.
-  2. User Journey: A one or two-sentence statement focusing on the "user" (could be a human, machine, software, etc.) and their interaction or experience.
-  3. Description (optional): A more detailed explanation if needed.
-  4. Justification: The reasoning behind the desideratum. Why is it necessary or desired?
-  5. Recommendations (optional): Suggestions or guidance related to the desideratum.
-
-  Format as:
-
-  ### Desideratum Title
-
-  **User Journey**: [user] can [action].
-
-  **Description**: <More detailed explanation if needed (optional)>
-
-  **Justification**: <Why this is a significant or required desideratum>
-
-  **Guidance and suggestions**: <Any specific guidance or suggestions (optional)>
-
-  TODO: Remove this comment before finalizing.
--->
 ### D1: Draft and publish standardized proposals
+
 **User Journey**: Proposer/Researcher can adhere to a standardized template for proposing changes to Movement technologies.
 
 **Justification**: Offering a standardized means for researching a proposing changes to Movement technologies will help guide research both in written structure and by facilitating engagement. The likelihood of producing successful proposals from such a structure should be expected to be higher than otherwise.
 
 ### D2: Implement against clear and accountable specifications
+
 **User Journey**: Developers can confidently implement complex systems against a clear and accountable specification.
 
 **Justification**: The standardization and review process should produce clearer specifications. The contributors responsible for these specifications should be--encouraging higher quality.
 
 **Guidance and suggestions**:
-- As referenced above, the formalized proposals supported by the desired process should be reserved for changes to Movement technologies that are of the highest complexity and quality. Otherwise, the effort of the standardization will likely be counterproductive.
-
-## Errata
-<!--
-  Errata should be maintained after publication.
-
-  1. **Transparency and Clarity**: An erratum acknowledges any corrections made post-publication, ensuring that readers are not misled and are always equipped with the most accurate information.
 
-  2. **Accountability**: By noting errors openly, we maintain a high level of responsibility and ownership over our content. It’s an affirmation that we value precision and are ready to correct oversights.
-
-  Each erratum should briefly describe the discrepancy and the correction made, accompanied by a reference to the date and version of the desiderata in which the error was identified.
+- As referenced above, the formalized proposals supported by the desired process should be reserved for changes to Movement technologies that are of the highest complexity and quality. Otherwise, the effort of the standardization will likely be counterproductive.
 
-  TODO: Maintain this comment.
--->
+## Changelog

MD/md-15/README.md

@@ -48,15 +48,4 @@ In order to communicate with more specificity in all contexts, Movement Labs sho
 **Recommendations**:
 - MD can also introduce MG to further aid in clarity, but they will not be ratified until they have been supported in an MIP.
 
-## Errata
-<!--
-  Errata should be maintained after publication.
-
-  1. **Transparency and Clarity**: An erratum acknowledges any corrections made post-publication, ensuring that readers are not misled and are always equipped with the most accurate information.
-
-  2. **Accountability**: By noting errors openly, we maintain a high level of responsibility and ownership over our content. It’s an affirmation that we value precision and are ready to correct oversights.
-
-  Each erratum should briefly describe the discrepancy and the correction made, accompanied by a reference to the date and version of the desiderata in which the error was identified.
-
-  TODO: Maintain this comment.
--->
+## Changelog

MD/md-3/README.md

@@ -67,15 +67,4 @@ These and other phenomena are listed in the desiderata below.
 **Recommendations**:
 - Start by reviewing the [Asynchronous Upgrades, Fork Creation, and Fork Stake Problems](./asychronous-upgrades-problem.md).
 
-## Errata
-<!--
-  Errata should be maintained after publication.
-
-  1. **Transparency and Clarity**: An erratum acknowledges any corrections made post-publication, ensuring that readers are not misled and are always equipped with the most accurate information.
-
-  2. **Accountability**: By noting errors openly, we maintain a high level of responsibility and ownership over our content. It’s an affirmation that we value precision and are ready to correct oversights.
-
-  Each erratum should briefly describe the discrepancy and the correction made, accompanied by a reference to the date and version of the desiderata in which the error was identified.
-
-  TODO: Maintain this comment.
--->
+## Changelog

MG/mg-0/README.md

@@ -1,4 +1,4 @@
-# MG-0: gloss
+# MG-0: Gloss Example
 
 - **Authors**: [Liam Monninger]([email protected])
 - **Introducing Document: [MIP-0](../../MIP/mip-0/README.md)**
@@ -10,19 +10,12 @@ A **gloss** is a short description of a term as would feature as an entry in a g
 
 ### Related Work
 
-<!--
-    Enumerate key usages of the term or related terms in other contexts.
--->
 1. [Merriam-Webster's Definition of "gloss"](https://www.merriam-webster.com/dictionary/gloss)
 
 ### Example Usages
 
-<!--
-    Provide examples of the term's usage in context.
--->
 1. He updated the **gloss** to include a more detailed explanation.
 
 ### Changelog
-<!--
-    Document any post-publication corrections to the glossary entry.
--->
+
+2025-01-15: Updated the **gloss** to include a more detailed explanation. [#45](https://github.com/movementlabsxyz/MIP/pull/45)

MIP/mip-0/README.md

@@ -1,60 +1,131 @@
-# MIP-0: MIPs
-- **Description**: Movement Improvement Proposals standardize and formalize specifications for Movement technologies.
-- **Authors**: [Liam Monninger](mailto:[email protected])
+# MIP-0: Formalize Movement Proposals
+- **Description**: A process through with Movement Improvement Proposals standardize and formalize specifications for Movement technologies.
+- **Authors**: [Liam Monninger](mailto:[email protected]), [Andreas Penzkofer](mailto:[email protected])
 - **Desiderata**: [MD-0](../MD/md-0)
 
 ## Abstract
 
-Movement Improvement Proposals (MIPs) serve as a mechanism to propose, discuss, and adopt changes or enhancements to Movement technologies. By providing a standardized and formalized structure for these proposals, MIPs ensure that proposed improvements are well-defined, transparent, and accessible to the wider community.
+This document formalizes the process through which Movement Improvement Proposals standardize and formalize specifications for Movement technologies, through MIPs (Movement Improvement Proposals), MDs (Movement Desiderata), and issues.
 
 ## Motivation
 
 Movement technologies continually evolve, and there's a need to ensure that the process of proposing and adopting changes is both organized and standardized. By establishing MIPs, we aim to facilitate the introduction of new features or improvements, making sure they are well-vetted, discussed, and documented. This ensures the integrity of Movement technologies, making it easier for third parties to adopt and adapt to these changes.
 
 ## Specification
 
-A Movement Improvement Proposal (MIP) is a design document that provides information to the Movement community, describing a new feature or improvement for Movement technologies.
-
-- **Structure**: Each MIP must adhere to the given template, which requires details like title, description, author, status, and more. A MIP also includes sections like Abstract, Motivation, Specification, Reference Implementation, Verification, Errata, and Appendix. 
+### Extensions to this MIP
 
-    - An md-template is provided in the [MIP Repository](https://github.com/movemntdev/MIP) which further specifies this structure. This MIP is an example of said structure.
-
-- **Lifecycle**: An MIP starts as a draft, after which it undergoes discussions and revisions. Once agreed upon, it moves to a 'published' status. An MIP can also be deprecated if it becomes obsolete.
+We treat the following documents as extensions to this MIP:
+
+- [root README](../../README.md)
+- [MD template](../../md-template.md)
+- [MIP template](../../mip-template.md)
+- [MG template](../../mg-template.md)
+
+### High-level Lifecycle
+
+The lifecycle of a proposal should be
+
+1. create a [new issue](https://github.com/movementlabsxyz/MIP/issues) to register the intent to write an MD/MIP and its scope.
+2. If 1. is approved by governance (this may require some discussions), start writing an MD and create a PR for it using [this Draft](../../md-template.md).
+3. The author MAY start an MIP using [this Draft](../../mip-template.md) in the same PR as the MD. However, doing so may slow down the governance approval of the MD. A preferred approach is to start with the MD, then await governance approval and only then start the MIP in a separate PR.
+
+#### Status terms
+
+An MIP/MD is proposed through a PR. Each MIP/MD PR should have a status. For additional specification, see the [root README](../../README.md#status-terms).
+
+### Roles
+
+#### Governance
+
+A governance body is responsible for overseeing the Movement Improvement Proposal process. This body is responsible for approving or rejecting proposals, and for ensuring that the process is followed correctly. The governance body is also responsible for maintaining the Movement Improvement Proposal repository, and for ensuring that the proposals are kept up-to-date.
+
+#### Editor
+
+The motivation for the role of the editor is to ensure the readability, layout correctness, and easy access of content. The editor is responsible for the final review of the MIPs. The editor is responsible for the following:
+
+- Ensures a high quality of the MIPs/MDs, e.g. checking language while reviewing.
+- Removes content from the MIPs/MDs that is commented out. (e.g. content within <!- -> brackets)
+- Ensures the MIP/MD numbering is correct.
+- Ensures the MIP/MD is in the correct status.
+- Ensures the authors have added themselves to [CODEOWNERS](./.github/CODEOWNERS), see [Code owners](#code-owners).
+
+The editor is NOT responsible for the content.
+
+**Conflict resolution**: In the unlikely case, where an editor requests a change from an author that the author does not agree with and communication does not resolve the situation
+
+- the editor can mandate that the author implements the changes by getting 2 upvotes from reviewers on their discussion comment mentioning the changes.
+- Otherwise the author can merge without the editor requested change.
 
-- **Storage**: MIPs should be stored in the MIPs directory at [MIP Repository](https://github.com/movemntdev/MIP). 
+#### Code owners
 
-- **Definitions** : Provide definitions that you think will empower the reader to quickly dive into the topic.
+An author commits to becoming the owner of the MIP/MD they propose. This means that for any future changes to the MIP/MD the author will be notified.
 
-## Reference Implementation
+The author MUST add themselves as a code owner in [CODEWONERS](.github/CODEOWNERS).
 
-A reference implementation or a sample MIP following the MIP template can be provided to guide potential proposers. This MIP (MIP-0) serves as a practical example, aiding in understanding the format and expectations.
+### Proposal Stages
+
+The Movement Improvement Proposal process is divided into three stages: Issue, MD, and MIP.
+
+#### Stage Issue
+
+Issues are used to propose trivial changes or improvements to Movement technologies. They are used to discuss and document the rationale behind a proposed change, and to gather feedback from the community. Issues are not formalized and do not require a specific structure. They are used to gauge interest and to start discussions.
+
+#### Stage MD
+
+Movement Desiderate (MDs) are used to request new features, highlight new requirements, or propose new ideas. MDs are formalized and require a specific structure. They are used to provide a standardized means for requesting changes to Movement technologies, and to guide in written structure and by facilitating engagement.
+
+We provide a [template](../../md-template.md) for MDs, which should be used for specifying complex changes to Movement technologies.
+
+**Lifecycle**: An MD starts as a draft, after which it undergoes discussions and revisions. Once agreed upon, it moves to a 'published' status. An MD can also be deprecated if it becomes obsolete. The available statuses are listed in the [root README](../../README.md).
+
+**Storage**: MDs should be stored in the [MDs directory](../../MD/). For each MD a separate directory should be created, containing the MD in markdown format, and any additional files required for the MD.
+
+**Structure**: Each MD must adhere to [this template](../../md-template.md), which requires details like title, description, author, status, and more. An MD also includes sections like Overview, Desiderata and Changelog.
+
+#### Stage MIP
+
+Movement Improvement Proposals (MIPs) serve as a mechanism to propose, discuss, and adopt changes or enhancements to Movement technologies. By providing a standardized and formalized structure for these proposals, MIPs ensure that proposed improvements are well-defined, transparent, and accessible to the wider community.
+
+A Movement Improvement Proposal (MIP) is a design document that provides information to the Movement community, describing a new feature or improvement for Movement technologies.
+
+**Lifecycle**: An MIP starts as a draft, after which it undergoes discussions and revisions. Once agreed upon, it moves to a 'published' status. An MIP can also be deprecated if it becomes obsolete. The available statuses are listed in the [root README](../../README.md).
+
+**Storage**: MIPs should be stored in the [MIPs directory](../). For each MIP a separate directory should be created, containing the MIP in markdown format, and any additional files required for the MIP.
+
+**Structure**: Each MIP must adhere to [this template](../../mip-template.md), which requires details like title, description, author, status, and more. A MIP also includes sections like Abstract, Motivation, Specification, Reference Implementation, Verification, Changelog, and Appendix, see next.
+
+**Section Reference Implementation**: A reference implementation or a sample MIP following the MIP template can be provided to guide potential proposers. This MIP (MIP-0) serves as a practical example, aiding in understanding the format and expectations.
+
+**(Optional) Section Definitions**: Provide definitions that you think will empower the reader to quickly dive into the topic.
 
-## Verification
+**Section Verification**
 
-1. **Correctness**: Each MIP must convincingly demonstrate its correctness.
+1. Correctness: Each MIP must convincingly demonstrate its correctness.
 
 This MIP is correct insofar as it uses a structure established by Ethereum for Improvement Proposals which has hitherto been successful.
 
-2. **Security Implications**: Each MIP should be evaluated for any potential security risks it might introduce to Movement technologies.
+2. Security Implications: Each MIP should be evaluated for any potential security risks it might introduce to Movement technologies.
 
 The primary security concern associated with this MIP is the exposure of proprietary technologies or information via the ill-advised formation of an MIP which the MIP process might encourage.
 
-3. **Performance Impacts**: The implications of the proposal on system performance should be analyzed.
+3. Performance Impacts: The implications of the proposal on system performance should be analyzed.
 
 The primary performance concern associated with this MIP is its potential for overuse. Only specifications that are non-trivial and very high-quality should be composed as MIPs.
 
-4. **Validation Procedures**: To the extent possible, formal, analytical, or machined-aided validation of the above should be pursued. 
+4. Procedures: To the extent possible, formal, analytical, or machined-aided validation of the above should be pursued. 
 
 I'm using spellcheck while writing this MIP. You can verify that I am using valid grammar by pasting this sentence into Google Docs.
 
-5. **Peer Review and Community Feedback**: A section should be included that captures significant feedback from the community, which may influence the final specifications of the MIP.
+5. Peer Review and Community Feedback: A section should be included that captures significant feedback from the community, which may influence the final specifications of the MIP.
 
 The Movement Labs team is currently reviewing and assessing this process.
 
-## Errata
+**Section Appendix**: The Appendix should contain references and notes related to the MIP.
 
-Post-publication corrections, if any, to the MIPs should be documented in this section. This ensures transparency and provides readers with accurate and up-to-date information.
+**Section Changelog**: Post-publication changes, if any, to the MIP should be documented in this section. This ensures transparency and provides readers with accurate and up-to-date information.
 
-## Appendix
+## Changelog
 
-The Appendix should contain references and notes related to the MIP. Materials referenced in the MIP should be marked with specific labels (e.g., ⟨R1⟩) for easy tracking and understanding.
+- 2024-12-18: Add information about the process and structure of MDs.
+- 2025-xx-xx: Incorporate updates on the process from SF. [PR#76](https://github.com/movementlabsxyz/MIP/pull/76)