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

Finalize CAP/SEP Process #247

Open
wants to merge 8 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@theaeolianmachine
Copy link
Contributor

theaeolianmachine commented Jan 31, 2019

Added additional clarity to the CAP process, and added the new SEP process.

theaeolianmachine added some commits Feb 1, 2019

Add multiple updates.
* Move existing drafts to the new format.
* Use email username of the committer as the unique identifier for a
  draft.
* Move drafts into independent folders for CAPs and SEPs.
* Update templates accordingly.
repository. You should make sure to adhere to the following:

* Use the following format for the filename of your draft
`cap_{email_username}_{hyphen-separated-cap-title}.md`.

This comment has been minimized.

@MonsieurNicolas

MonsieurNicolas Feb 6, 2019

Contributor

sep_? in general, given that this is under the "sep" folder already, I don't know if we need sep in the filename anyways.

This comment has been minimized.

@tomquisel

tomquisel Feb 8, 2019

Contributor

I think it makes sense, it's only in the ecosystem/draft folder. It's good to be explicit about what the file is.

@MonsieurNicolas

This comment has been minimized.

Copy link
Contributor

MonsieurNicolas commented Feb 6, 2019

If we're going to use a folder like "draft" to track state, we should be consistent and use folders for all other possible "states" that exist. I see that abandoned proposals go into some "archive" state for example, and we have "final" that is quite important.

That said, I think the reason we need a draft folder with the current process is because of the first PR: yet, the first draft should be a first draft of the final document (relative high bar), and as such should have a number.

In Ethereum they just assign the number before merging, by using for example the pull request ID as ID generator, so the burden on editors is low.

tomquisel added some commits Feb 8, 2019

@tomquisel
Copy link
Contributor

tomquisel left a comment

This is great! The buddy idea is a good call. I added a few comments.

3. SEP number assigned (`ACCEPTED`) or SEP rejected (`REJECTED`).
4. Discussion and changes.
5. SEP merged (`FINAL`) or SEP rejected (`REJECTED`).
See [CONTRIBUTING](CONTRIBUTING.md) for more information.

This comment has been minimized.

@tomquisel

tomquisel Feb 8, 2019

Contributor

How about: See [CONTRIBUTING](CONTRIBUTING.md) to learn how to contribute. just to be more clear.

back into a Draft state.
* **Accepted** — A CAP that has been formally accepted and is ready for implementation. It is
expected to be included in a future version of the protocol.
* **Finalized** — A CAP that has been implemented in Stellar Core in the version specified.

This comment has been minimized.

@tomquisel

tomquisel Feb 8, 2019

Contributor

What happens to rejected CAPs? Archived?

should be surgical, and minimal invasive. As a result, changes that affect lower levels of the
implementation have a higher bar for acceptance.
* In order from the highest level to the lowest level systems, the systems are:
* Historical / Ledger XDR

This comment has been minimized.

@tomquisel

tomquisel Feb 8, 2019

Contributor

This list looks reversed?


* Make sure to place the draft in the `core/drafts` folder.
* Use the following format for the filename of your draft
`cap_{email_username}_{hyphen-separated-cap-title}.md`.

This comment has been minimized.

@tomquisel

tomquisel Feb 8, 2019

Contributor

Maybe github username instead of email? Email is a little longer / more awkward and may feel exposing to submitters.


## SEP Status Terms
* **Archived** - A SEP that did not head towards a disposition due to a lack of consensus _and_
support. Generally open to revival with additional edits.

This comment has been minimized.

@tomquisel

tomquisel Feb 8, 2019

Contributor

Is this also where rejected SEPs go?

repository. You should make sure to adhere to the following:

* Use the following format for the filename of your draft
`cap_{email_username}_{hyphen-separated-cap-title}.md`.

This comment has been minimized.

@tomquisel

tomquisel Feb 8, 2019

Contributor

I think it makes sense, it's only in the ecosystem/draft folder. It's good to be explicit about what the file is.


## Abstract
A short (~200 word) description of the technical issue being addressed.

## Motivation
Should clearly explain why the existing protocol specification is inadequate to address the problem that the SEP solves. SEP submissions without sufficient motivation may be rejected outright.

## Specification
The technical specification should describe the syntax and semantics of any new feature.

## Rationale

This comment has been minimized.

@tomquisel

tomquisel Feb 8, 2019

Contributor

Having both Motivation and Rational is confusing for me. Maybe make it more clear how they're different?

* **Archived** - A SEP that did not head towards a disposition due to a lack of consensus _and_
support. Generally open to revival with additional edits.
* **Draft** - A SEP that is currently open to discussion and feedback.
* **FCP** - A SEP that has entered the Final Comment Period (FCP), and has one week remaining

This comment has been minimized.

@vcarl

vcarl Feb 19, 2019

Contributor

My experiences implementing SEP-6 says that there needs to be more feedback after a final draft has been reached. We made several significant changes to the spec (data shape, /fee endpoint) due to issues discovered during implementation.

It might be worth gating "ready for wide adoption" behind a limited number of prototype implementations to try to discover needs that weren't anticipated. A hands-on implementation with a key partner and members of the SEP team seems like it would give a lot of opportunity to optimize and clarify the spec text.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment