Name: rfc
Owner: Basho Technologies
Description: null
Created: 2016-05-24 00:25:10.0
Updated: 2017-11-23 11:26:09.0
Pushed: 2017-04-07 14:08:26.0
Homepage: null
Size: 9671
Language: JavaScript
GitHub Committers
User | Most Recent Commit | # Commits |
---|
Other Committers
User | Most Recent Commit | # Commits |
---|
This repo contains documentation in Markdown format that detail RFCs that require feedback from architecture and other relevant parties.
incoming/
directly on the master
branch.README.md
in the folder on master
.master
to github. Keep editing directly on master
until
you're ready for discussion.rfc
repository.master
.master
.master
.README
to indicate the outcome of the discussion and link to the pull request.README
.Future status updates should primarily be directed to Jira, but it is
perfectly valid to add useful status information in README
without a
new pull request.
Only open new pull requests against the merged RFC when extended
commentary is useful/necessary. Otherwise, just change the document in
place on master
.
All RFCs must go into a dedicated folder as README.md
. The title of
the RFC should be captured (and possibly shortened) in the name of the
folder.
Make the name only as long as is necessary to capture essential
information for findability and discoverability. If it impacts
handoff, make sure Handoff
is in the name.
Use title case for the folder name. Use a space to separate each word. Underscores and hyphens are just visual clutter for a directory structure that won't be processed programmatically.
Here's a skeleton RFC template to use that outlines the key points that need to be addressed when creating an RFC:
C: <Title>
Abstract
paragraph summary of the problem and proposed solution (if any)>
Background
kground information; references to industry work or research; prior work on the problem>
Proposal
tline
For multi-stage tasks
cussion of the work being proposed>
Performance Considerations
this change affect performance of an existing feature, or a new feature that is performance sensitive?
are the performance goals of the change? N requsts per second? Better resource (CPU, IO, locks) usage? Better than X DB?
ires performance testing? yes/no. Which parts are affected. If yes, the Performance Team will need to be notified in advance.
References
ks to existing projects or source code; external references>
ttp://link.to/some_reference](External Reference)
ttp://github.com/owner/project](GitHub Project Reference)
ttp://github.com/owner/project/issues/1](GitHub Issues Reference)
ttp://github.com/owner/project/pr/1](GitHub PR Reference)
It is useful to include source for POCs and prior work inside the directory created for an RFC. Example:
folder>/
src/
rfc_poc/
src/my_poc.erl
Our rfc
repository is closed to the public. When the RFC is
instantiated inside our code base, if the RFC is close enough to the
final implementation to be useful, copy it into an appropriate
documentation folder.
If it needs to be cleaned up before doing so, please make the changes
in the rfc
repository first, then copy it. There is no need for a
pull request to update this repository's copy.
Feedback to the Architecture team is welcome and expected! Send any comments or feedback to arch@basho.com