Create a proposal template. (#423)

* Create a proposal template.

Also update CONTRIBUTING.md to mention use of proposals
This commit is contained in:
bobbyrullo 2016-05-06 12:00:57 -07:00
parent ea4c04fde8
commit e64043dd97
3 changed files with 64 additions and 0 deletions

View file

@ -31,6 +31,7 @@ are very busy and read the mailing lists.
This is a rough outline of what a contributor's workflow looks like:
- Create a proposal (if neccessary - see below) and get an LGTM by someone in [maintainer](MAINTAINERS)
- Create a topic branch from where you want to base your work (usually master).
- Make commits of logical units.
- Make sure your commit messages are in the proper format (see below).
@ -40,6 +41,18 @@ This is a rough outline of what a contributor's workflow looks like:
Thanks for your contributions!
## Proposals
For very simple contributions - bug fixes, documentation tweaks, small optimizations, etc. - a proposal is not neccesary. Otherwise, it's necessary to discuss your proposal with other members of the community and get approval from the maintainers.
To create a proposal, copy the markdown from the [proposal template](PROPOSAL_TEMPLATE.md) and put it in the relevant issue. Once you've gotten an LGTM from a [maintainer](MAINTAINERS), you can proceed with putting together a PR.
Don't worry if you're proposal is not accepted right away; you'll probably need to make some changes, depending on the scope of the proposal.
Here's a link which creates a new issue populated with the proposal link:
[Create a Proposal](https://github.com/coreos/dex/issues/new?body=Proposal%0A%3D%3D%3D%0A%0A%28Feel%20free%20to%20change%20headings%20here%2C%20remove%20sections%20that%20are%20not%20relevant%2C%20or%20add%20other%20sections%29%0A%0A%23%23%20Background%0A%0ADescribe%20what%20problem%20is%20being%20solved%20here%2C%20and%20%28briefly%29%20how%20this%20proposal%20solves%20it.%0A%0A%23%23%20Data%20Model%0A%0ADescribe%20the%20logical%20data%20model%20that%20your%20proposal%20adds.%0A%0A%23%23%20Data%20Storage%0A%0ADescribe%20how%20the%20data%20will%20be%20persisted.%0A%0A%23%23%20API%0A%0ADescribe%20the%20methods%20that%20the%20API%20will%20expose.%20If%20there%20are%20any%20breaking%20changes%20be%20sure%20to%20call%20them%20out%20here.%0A%0A%23%23%20UI/UX%0A%0AIs%20there%20a%20front-end%20component%20to%20this%20work%3F%0A%0A%23%23%20Implementation%0A%0AHere%20is%20where%20you%20can%20go%20into%20detail%20about%20implementation%20details%20like%20data%20structures%2C%20algorithms%2C%20etc.%0A%0A%23%23%20Security%0A%0AWhat%20are%20the%20security%20implications%20of%20this%20proposal%3F%20How%20are%20API%20requests%20authenticated%3F%20Who%20can%20make%20API%20calls%3F%0A%0A%23%23%20OIDC/OAUTH2%0A%0ADoes%20this%20feature%20relate%20to%20any%20spec%3F%20%0A%0A%23%23%20Risks/Alternatives%20Considered%0A%0AWhat%20are%20the%20downsides%20to%20this%20implementation%3F%20What%20other%20alternatives%20were%20considered%3F%0A%0A%23%23%20References%0A%0AIf%20there%27s%20any%20references%20or%20prior%20art%2C%20put%20that%20here.)
### Format of the Commit Message
We follow a rough convention for commit messages that is designed to answer two

44
PROPOSAL_TEMPLATE.md Normal file
View file

@ -0,0 +1,44 @@
Proposal
===
(Feel free to change headings here, remove sections that are not relevant, or add other sections)
## Background
Describe what problem is being solved here, and (briefly) how this proposal solves it.
## Data Model
Describe the logical data model that your proposal adds.
## Data Storage
Describe how the data will be persisted.
## API
Describe the methods that the API will expose. If there are any breaking changes be sure to call them out here.
## UI/UX
Is there a front-end component to this work?
## Implementation
Here is where you can go into detail about implementation details like data structures, algorithms, etc.
## Security
What are the security implications of this proposal? How are API requests authenticated? Who can make API calls?
## OIDC/OAUTH2
Does this feature relate to any spec?
## Risks/Alternatives Considered
What are the downsides to this implementation? What other alternatives were considered?
## References
If there's any references or prior art, put that here.

7
proposal_link Executable file
View file

@ -0,0 +1,7 @@
#!/bin/bash -e
# This creates a URL which will pre-populate an issue with the contents of PROPOSAL_TEMPLATE.md
BODY=$(python -c "import urllib, sys; print urllib.quote(sys.stdin.read()[0:-1])" < PROPOSAL_TEMPLATE.md)
echo "https://github.com/coreos/dex/issues/new?body=$BODY"