Enhanced SIP Template with Improved Structure and Fixed YAML #8
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,85 +1,220 @@ | ||
| --- | ||
| number: 'XXXXX' | ||
| title: Title of SIP | ||
| authors: | ||
| - First Author's Name (author1@example.org) | ||
| - Second Author's name (author2@example.org) | ||
| sponsors: First Sponsor's Name (expert@example.org) | ||
| created: 'XXXXX' | ||
|
|
||
| type: Standard/Ecosystem/Meta | ||
| status: Draft/Accepted/Implemented/Released/Stagnant/Withdrawn | ||
| supersedes: null | ||
| superseded-by: null | ||
| extends: null | ||
|
Comment on lines
-8
to
+13
Collaborator
There was a problem hiding this comment. same here, please don't remove the template helpers here |
||
| --- | ||
|
|
||
| ## Abstract | ||
|
|
||
| Provide a concise technical summary of the proposal in 2-3 sentences. This should be understandable to someone familiar with the Story Protocol ecosystem but not necessarily the specific problem domain. | ||
|
|
||
|
Collaborator
There was a problem hiding this comment. we have limited length size that is broken here now. |
||
| ## Summary | ||
|
|
||
| Provide a brief summary of this proposal and why it's needed. Keep it concise—details should be provided in the below sections. | ||
|
|
||
|
|
||
| Include links to relevant community discussion threads, Discord conversations, or forum posts. | ||
|
|
||
| ## Motivation | ||
|
|
||
| ### Problem Statement | ||
|
Check failure on line 28 in XXXXX-template.md
|
||
| Does this proposal address an existing problem or create new opportunities? | ||
|
|
||
| If addressing a problem: | ||
| - Who are the affected users (developers, validators, end users, etc.)? | ||
|
Check failure on line 32 in XXXXX-template.md
|
||
| - Why is it problematic? | ||
| - What data or evidence supports this assessment? | ||
| - What is the current workaround, if any? | ||
|
|
||
| If creating opportunities: | ||
| - What new capabilities does this enable? | ||
|
Check failure on line 38 in XXXXX-template.md
|
||
| - What is the potential impact on the ecosystem? | ||
|
|
||
| ### Success Criteria | ||
|
Check failure on line 41 in XXXXX-template.md
|
||
| - What defines a successful solution? | ||
|
Check failure on line 42 in XXXXX-template.md
|
||
| - What are concrete use cases that benefit from this solution? | ||
| - What metrics will be used to measure success? | ||
|
|
||
| ### Scope and Non-Goals | ||
|
Check failure on line 46 in XXXXX-template.md
|
||
| - What is explicitly in scope for this proposal? | ||
|
Check failure on line 47 in XXXXX-template.md
|
||
| - What related issues are intentionally out of scope? | ||
|
|
||
| ## New Terminology (optional) | ||
|
|
||
| Define any new terms, concepts, or terminology introduced by this proposal. | ||
|
|
||
| ## Specification | ||
|
|
||
| This section explains in detail the proposed changes and how they work. Use RFC 2119 keywords ("MUST", "SHOULD", "MAY", etc.) where appropriate. | ||
|
|
||
| ### Technical Design | ||
|
|
||
| Provide detailed technical specifications including: | ||
| - Protocol changes | ||
| - API modifications | ||
| - Data structures | ||
| - Message formats | ||
| - State transitions | ||
|
|
||
| ### Implementation Requirements | ||
|
|
||
| What are the key requirements any implementation must satisfy? | ||
|
|
||
| ### Reference Implementation (optional) | ||
|
|
||
| Provide pseudocode, algorithms, or implementation sketches where helpful. | ||
|
|
||
| ## Rationale and Design Decisions | ||
|
|
||
| ### Alternatives Considered | ||
|
|
||
| List alternatives you considered but rejected, explaining why your chosen approach is superior: | ||
| - Alternative A: Description, pros, cons, why rejected | ||
| - Alternative B: Description, pros, cons, why rejected | ||
|
|
||
| ### Design Trade-offs | ||
|
|
||
| What trade-offs does this design make and why? | ||
|
|
||
| ### Drawbacks | ||
|
|
||
| Why should this *not* be done? What negative impacts might it have? | ||
|
|
||
| ## Impact Analysis | ||
|
|
||
| ### User Impact | ||
|
|
||
| - What changes will end users experience? | ||
| - How will this affect different user personas (developers, validators, IP creators, etc.)? | ||
| - What is the migration path for existing users? | ||
|
|
||
| ### Developer Impact (optional if not applicable) | ||
|
|
||
| - How does this affect SDK development? | ||
| - What new APIs or tools are needed? | ||
| - How will this impact existing development workflows? | ||
|
|
||
| ### Network Impact (optional if not applicable) | ||
|
|
||
| - How does this affect network topology, traffic patterns, or resource usage? | ||
| - What are the implications for network upgrades and governance? | ||
|
|
||
| ### Economic Impact (optional if not applicable) | ||
|
|
||
| - Does this change economic incentives or token economics? | ||
| - What are the cost implications for different network participants? | ||
| - How might this affect network value accrual? | ||
|
|
||
| ## Compatibility | ||
|
|
||
| ### Backward Compatibility | ||
|
|
||
| - Is this change backward compatible? | ||
| - If not, what is the migration strategy? | ||
| - How will legacy systems be supported? | ||
|
|
||
| ### Forward Compatibility | ||
|
|
||
| - How does this design accommodate future enhancements? | ||
| - What extensibility mechanisms are provided? | ||
|
|
||
| ### Ecosystem Integration | ||
|
|
||
| - How will this work with existing tools and infrastructure? | ||
| - What changes are needed in wallets, explorers, SDKs? | ||
| - How does this interact with other protocols in the ecosystem? | ||
|
|
||
| ## Security Considerations | ||
|
|
||
| - What are the security implications of this change? | ||
| - What new attack vectors might be introduced? | ||
| - How are these risks mitigated? | ||
| - What security assumptions does this make? | ||
| - Are there any cryptographic considerations? | ||
|
|
||
| ## Technical Impact (optional if not applicable) | ||
|
|
||
| ### Computational Impact | ||
|
Collaborator
There was a problem hiding this comment. How is this different from Performance Implication |
||
| - Expected changes in CPU usage, memory consumption | ||
| - Gas cost implications for smart contracts | ||
| - Benchmarking methodology | ||
|
|
||
| ### Network Impact | ||
gregsantos marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - Bandwidth requirements | ||
| - Latency implications | ||
| - Scalability considerations | ||
|
|
||
| ### Storage Impact | ||
| - State growth implications | ||
| - Archive node requirements | ||
|
|
||
| ## Documentation and Examples | ||
|
|
||
| ### Migration Guide (optional - required only for breaking changes) | ||
|
|
||
| If this changes existing functionality, provide: | ||
| - Step-by-step migration instructions | ||
| - Code examples showing before/after | ||
| - Timeline for deprecation of old methods | ||
|
|
||
| ## Community Consensus | ||
|
|
||
| ### Discussion Summary | ||
|
|
||
| Document community feedback and discussions: | ||
| - Links to [forum discussions](https://forum.story.foundation/), Discord conversations | ||
| - Summary of key feedback themes | ||
| - How feedback was incorporated into the design | ||
|
|
||
| ### Stakeholder Impact | ||
|
|
||
| - Which stakeholders are most affected? | ||
| - What is their level of support or concern? | ||
| - How were conflicts resolved? | ||
|
|
||
|
|
||
| ## Dependencies | ||
|
|
||
| ### Technical Dependencies | ||
|
|
||
| - Does this require changes to other components? | ||
| - What external libraries or systems are needed? | ||
| - Are there version compatibility requirements? | ||
|
|
||
| ### Process Dependencies | ||
|
|
||
| - What other SIPs must be implemented first? | ||
| - Are there coordination requirements with other teams? | ||
| - What approvals or reviews are needed? | ||
|
|
||
| ## Related Work (optional) | ||
|
|
||
| ### Prior Art | ||
|
|
||
| - Have other networks implemented similar features? | ||
| - What can we learn from their experience? | ||
| - How does this approach differ from existing solutions? | ||
|
|
||
| ### Future Work | ||
|
|
||
| - What related improvements could build on this? | ||
| - What issues are intentionally deferred to future proposals? | ||
|
|
||
| ## Appendices (optional) | ||
|
|
||
| ### A. Reference Materials | ||
|
|
||
| Links to relevant specifications, papers, or documentation. | ||
|
|
||
| ### B. Change Log | ||
|
|
||
| Track major revisions to this document: | ||
| - Version 1.0 (YYYY-MM-DD): Initial draft | ||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe we still keep the details on when to update this number