| layout | shields_io_query_params | pr_id | rfc_feature_name | title | rfc_author_username | rfc_author_name | impl_issue_id | impl_issue_repo | last_modified_date |
|---|---|---|---|---|---|---|---|---|---|
default |
label=issue%20state&logo=github&style=flat-square |
0 |
name-of-my-feature |
RFC-0000: name-of-my-feature |
yourUsername |
Firstname Lastname |
0 |
iver-wharf/wharf-api |
YYYY-MM-DD |
- RFC PR: iver-wharf/rfcs#{{page.pr_id}}
- Feature name:
{{page.rfc_feature_name}} - Author: {{page.rfc_author_name}} (@{{page.rfc_author_username}})
- Implementation issue: {{page.impl_issue_repo}}#{{page.impl_issue_id}}
- Implementation status:
Max one paragraph long description to fill in context and overview of this RFC.
Why do we need this? What's the problem you are trying to solve?
Explain it as if you're writing documentation for an already existing feature. This is where you would add code samples, such as:
type MyType struct {
text string
number int
}
func (mt MyType) String() string {
return fmt.Sprintf("%q %d", mt.text, mt.number)
}Bring up compatibility issues and other things to regard. How will this interfere with existing components (providers, database, frontend)? Does this break backward compatibility?
You pronounce one solution in this RFC, but keep the other alternatives you can think about in here.
Does this lay groundwork for some future changes? If so, what?
Questions you [RFC author] want help resolving from the reviewers.