Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[update] MIP-0 : Introduce status terms and editor role #32

Open
wants to merge 15 commits into
base: main
Choose a base branch
from

Conversation

apenzk
Copy link
Contributor

@apenzk apenzk commented Oct 16, 2024

Summary

The distribution of MIP number seems open to

  • distribution of numbers to non-relevant easy-to-fail MIPs
  • Contributors may feel hindered by the barrier of MIP-numbering.
  • open to conflicting numbering

Editors. This PR introduces editors as an additional actor in the system and who takes responsibility to help with the process of MIPs

MIP-Numbering. The numbering already is not aligned with the PR number when looking at the PRs. In order to provide a more consistent numbering, the MIP should also be intuitive (when looking at a list of MIPs). a different numbering scheme is proposed.

Status terms. To identify the different stages already from the PR title, certain status terms are introduced.

There is also a need for an overview of existing MIPs. This PR is a prelude for the overview introduced in this PR.

Motivation

MIP numbering may not be handled reliably by the authors of an IP. There may be confusion on the numbering, and an author may forget to add a new MIP to the overview list.

EIP has a well established standard : https://eips.ethereum.org/. However, the standard is too complex. Furthermore, the standard relies on a filtering process through a forum, which we do not have.

Inspired by EIP, this PR introduces a modification that can be handled in a small team, yet provides a clear path towards a well managed status of existing MIPs.

@apenzk apenzk changed the title Introduce status terms [update] MIP-0 Introduce status terms Oct 16, 2024
@apenzk apenzk changed the title [update] MIP-0 Introduce status terms [update] MIP-0 : Introduce status terms Oct 16, 2024
README.md Outdated

An MIP should at all times have one of the following statuses:
- **Draft** - (set by author) An MIP that is open for consideration. (It does not yet hold an MIP number)
- **Review** - (set by author) The MIP is under peer review. The MIP should receive an **MIP number** and the MIP should be registered in the MIP overview file.
Copy link

@andygolay andygolay Oct 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@apenzk I like the statuses; they seem like a helpful way to track MIPs.

Could you add more details about how the MIP number is assigned and registered? Specifically what role registers the MIP, how the number is determined, and perhaps more information about or a link to the MIP overview file.

It may be helpful to define or introduce the editor role as well, if that's a new addition to our MIP process?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have removed the mention of the overview file, as it will be included by this [update]

i have added a note to clarify where the MIP number comes from. Essentially it will be fixed by the OVERVIEW file which comes with this PR from Franck.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may be helpful to define or introduce the editor role as well, if that's a new addition to our MIP process?

done.

An MIP should at all times have one of the following statuses:
- **Draft** - (set by author) An MIP that is open for consideration. (It does not yet hold an MIP number)
- **Review** - (set by author) The MIP is under peer review. The MIP should receive an **MIP number** and the MIP should be registered in the MIP overview file.
- **Accepted** - (set by editor) An MIP that has been accepted. All technical changes requested have been addressed by the author. There may be additional non-technical changes requested by the MIP editor.
Copy link

@andygolay andygolay Oct 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One issue that may arise is: suppose an editor has a technical change that the author doesn't agree with. Is there some mechanism that we could add, to resolve such disagreements or disputes?

Likewise, if, say, editors aren't available for timely reviews (which perhaps could happen due to various circumstances), should there be a process for allowing an interim editor to assume editorial responsibilities as needed?

Copy link
Contributor Author

@apenzk apenzk Oct 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suppose an editor has a technical change that the author doesn't agree with. Is there some mechanism that we could add, to resolve such disagreements or disputes

How is this handled with PRs in other repos?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(i have addressed now the second para in the text)

Copy link

@andygolay andygolay Oct 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suppose an editor has a technical change that the author doesn't agree with. Is there some mechanism that we could add, to resolve such disagreements or disputes

How is this handled with code PRs?

For PRs, we have a minimum number of approvals needed (3 for MIPs, 2 for PRs to aptos-core and 1 for PRs to movement).

What about this solution: If an editor requests a change from an author, either the author can make the changes (tacitly approving the editorial feedback), or:

If the author doesn't agree with the rquested changes, then the editor can mandate that the author implements the changes by getting 2 upvotes on their discussion comment mentioning the changes (assuming change requests will be made in the Discussion section of the MIP PR)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds good. added this. thx!

Copy link

@andygolay andygolay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to be a good way to organize the MIPs and where they are in their lifecycles.

README.md Outdated Show resolved Hide resolved
@apenzk apenzk changed the title [update] MIP-0 : Introduce status terms [update] MIP-0 : Introduce status terms and editor role Oct 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants