Skip to content

Commit 53ba081

Browse files
BoyaohrbcBoyaohrbc
committed
(doc)add new initial setup files
1 parent bee6751 commit 53ba081

File tree

3 files changed

+605
-0
lines changed

3 files changed

+605
-0
lines changed

Diff for: ‎_CONTRIBUTING.md

+181
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,181 @@
1+
# Contributing
2+
3+
## General Workflow
4+
5+
1. Fork the repo
6+
1. Cut a namespaced feature branch from master
7+
- bug/...
8+
- feat/...
9+
- test/...
10+
- doc/...
11+
- refactor/...
12+
1. Make commits to your feature branch. Prefix each commit like so:
13+
- (feat) Added a new feature
14+
- (fix) Fixed inconsistent tests [Fixes #0]
15+
- (refactor) ...
16+
- (cleanup) ...
17+
- (test) ...
18+
- (doc) ...
19+
1. When you've finished with your fix or feature, Rebase upstream changes into your branch. submit a [pull request][]
20+
directly to master. Include a description of your changes.
21+
1. Your pull request will be reviewed by another maintainer. The point of code
22+
reviews is to help keep the codebase clean and of high quality and, equally
23+
as important, to help you grow as a programmer. If your code reviewer
24+
requests you make a change you don't understand, ask them why.
25+
1. Fix any issues raised by your code reviwer, and push your fixes as a single
26+
new commit.
27+
1. Once the pull request has been reviewed, it will be merged by another member of the team. Do not merge your own commits.
28+
29+
## Detailed Workflow
30+
31+
### Fork the repo
32+
33+
Use github’s interface to make a fork of the repo, then add that repo as an upstream remote:
34+
35+
```
36+
git remote add upstream https://github.com/makersquare-labs/<NAME_OF_REPO>.git
37+
```
38+
39+
### Cut a namespaced feature branch from master
40+
41+
Your branch should follow this naming convention:
42+
- bug/...
43+
- feat/...
44+
- test/...
45+
- doc/...
46+
- refactor/...
47+
48+
These commands will help you do this:
49+
50+
``` bash
51+
52+
# Creates your branch and brings you there
53+
git checkout -b `your-branch-name`
54+
```
55+
56+
### Make commits to your feature branch.
57+
58+
Prefix each commit like so
59+
- (feat) Added a new feature
60+
- (fix) Fixed inconsistent tests [Fixes #0]
61+
- (refactor) ...
62+
- (cleanup) ...
63+
- (test) ...
64+
- (doc) ...
65+
66+
Make changes and commits on your branch, and make sure that you
67+
only make changes that are relevant to this branch. If you find
68+
yourself making unrelated changes, make a new branch for those
69+
changes.
70+
71+
#### Commit Message Guidelines
72+
73+
- Commit messages should be written in the present tense; e.g. "Fix continuous
74+
integration script".
75+
- The first line of your commit message should be a brief summary of what the
76+
commit changes. Aim for about 70 characters max. Remember: This is a summary,
77+
not a detailed description of everything that changed.
78+
- If you want to explain the commit in more depth, following the first line should
79+
be a blank line and then a more detailed description of the commit. This can be
80+
as detailed as you want, so dig into details here and keep the first line short.
81+
82+
### Rebase upstream changes into your branch
83+
84+
Once you are done making changes, you can begin the process of getting
85+
your code merged into the main repo. Step 1 is to rebase upstream
86+
changes to the master branch into yours by running this command
87+
from your branch:
88+
89+
```bash
90+
git pull --rebase upstream master
91+
```
92+
93+
This will start the rebase process. You must commit all of your changes
94+
before doing this. If there are no conflicts, this should just roll all
95+
of your changes back on top of the changes from upstream, leading to a
96+
nice, clean, linear commit history.
97+
98+
If there are conflicting changes, git will start yelling at you part way
99+
through the rebasing process. Git will pause rebasing to allow you to sort
100+
out the conflicts. You do this the same way you solve merge conflicts,
101+
by checking all of the files git says have been changed in both histories
102+
and picking the versions you want. Be aware that these changes will show
103+
up in your pull request, so try and incorporate upstream changes as much
104+
as possible.
105+
106+
You pick a file by `git add`ing it - you do not make commits during a
107+
rebase.
108+
109+
Once you are done fixing conflicts for a specific commit, run:
110+
111+
```bash
112+
git rebase --continue
113+
```
114+
115+
This will continue the rebasing process. Once you are done fixing all
116+
conflicts you should run the existing tests to make sure you didn’t break
117+
anything, then run your new tests (there are new tests, right?) and
118+
make sure they work also.
119+
120+
If rebasing broke anything, fix it, then repeat the above process until
121+
you get here again and nothing is broken and all the tests pass.
122+
123+
### Make a pull request
124+
125+
Make a clear pull request from your fork and branch to the upstream master
126+
branch, detailing exactly what changes you made and what feature this
127+
should add. The clearer your pull request is the faster you can get
128+
your changes incorporated into this repo.
129+
130+
At least one other person MUST give your changes a code review, and once
131+
they are satisfied they will merge your changes into upstream. Alternatively,
132+
they may have some requested changes. You should make more commits to your
133+
branch to fix these, then follow this process again from rebasing onwards.
134+
135+
Once you get back here, make a comment requesting further review and
136+
someone will look at your code again. If they like it, it will get merged,
137+
else, just repeat again.
138+
139+
Thanks for contributing!
140+
141+
### Guidelines
142+
143+
1. Uphold the current code standard:
144+
- Keep your code [DRY][].
145+
- Apply the [boy scout rule][].
146+
- Follow [STYLE-GUIDE.md](STYLE-GUIDE.md)
147+
1. Run the [tests][] before submitting a pull request.
148+
1. Tests are very, very important. Submit tests if your pull request contains
149+
new, testable behavior.
150+
1. Your pull request is comprised of a single ([squashed][]) commit.
151+
152+
## Checklist:
153+
154+
This is just to help you organize your process
155+
156+
- [ ] Did I cut my work branch off of master (don't cut new branches from existing feature brances)?
157+
- [ ] Did I follow the correct naming convention for my branch?
158+
- [ ] Is my branch focused on a single main change?
159+
- [ ] Do all of my changes directly relate to this change?
160+
- [ ] Did I rebase the upstream master branch after I finished all my
161+
work?
162+
- [ ] Did I write a clear pull request message detailing what changes I made?
163+
- [ ] Did I get a code review?
164+
- [ ] Did I make any requested changes from that code review?
165+
166+
If you follow all of these guidelines and make good changes, you should have
167+
no problem getting your changes merged in.
168+
169+
170+
<!-- Links -->
171+
[style guide]: https://github.com/makersquare-labs/style-guide
172+
[n-queens]: https://github.com/makersquare-labs/n-queens
173+
[Underbar]: https://github.com/makersquare-labs/underbar
174+
[curriculum workflow diagram]: http://i.imgur.com/p0e4tQK.png
175+
[cons of merge]: https://f.cloud.github.com/assets/1577682/1458274/1391ac28-435e-11e3-88b6-69c85029c978.png
176+
[Bookstrap]: https://github.com/makersquare/bookstrap
177+
[Taser]: https://github.com/makersquare/bookstrap
178+
[tools workflow diagram]: http://i.imgur.com/kzlrDj7.png
179+
[Git Flow]: http://nvie.com/posts/a-successful-git-branching-model/
180+
[GitHub Flow]: http://scottchacon.com/2011/08/31/github-flow.html
181+
[Squash]: http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html

Diff for: ‎_PRESS-RELEASE.md

+44
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,44 @@
1+
# Project Name #
2+
3+
<!--
4+
> This material was originally posted [here](http://www.quora.com/What-is-Amazons-approach-to-product-development-and-product-management). It is reproduced here for posterities sake.
5+
6+
There is an approach called "working backwards" that is widely used at Amazon. They work backwards from the customer, rather than starting with an idea for a product and trying to bolt customers onto it. While working backwards can be applied to any specific product decision, using this approach is especially important when developing new products or features.
7+
8+
For new initiatives a product manager typically starts by writing an internal press release announcing the finished product. The target audience for the press release is the new/updated product's customers, which can be retail customers or internal users of a tool or technology. Internal press releases are centered around the customer problem, how current solutions (internal or external) fail, and how the new product will blow away existing solutions.
9+
10+
If the benefits listed don't sound very interesting or exciting to customers, then perhaps they're not (and shouldn't be built). Instead, the product manager should keep iterating on the press release until they've come up with benefits that actually sound like benefits. Iterating on a press release is a lot less expensive than iterating on the product itself (and quicker!).
11+
12+
If the press release is more than a page and a half, it is probably too long. Keep it simple. 3-4 sentences for most paragraphs. Cut out the fat. Don't make it into a spec. You can accompany the press release with a FAQ that answers all of the other business or execution questions so the press release can stay focused on what the customer gets. My rule of thumb is that if the press release is hard to write, then the product is probably going to suck. Keep working at it until the outline for each paragraph flows.
13+
14+
Oh, and I also like to write press-releases in what I call "Oprah-speak" for mainstream consumer products. Imagine you're sitting on Oprah's couch and have just explained the product to her, and then you listen as she explains it to her audience. That's "Oprah-speak", not "Geek-speak".
15+
16+
Once the project moves into development, the press release can be used as a touchstone; a guiding light. The product team can ask themselves, "Are we building what is in the press release?" If they find they're spending time building things that aren't in the press release (overbuilding), they need to ask themselves why. This keeps product development focused on achieving the customer benefits and not building extraneous stuff that takes longer to build, takes resources to maintain, and doesn't provide real customer benefit (at least not enough to warrant inclusion in the press release).
17+
-->
18+
19+
## Heading ##
20+
> Name the product in a way the reader (i.e. your target customers) will understand.
21+
22+
## Sub-Heading ##
23+
> Describe who the market for the product is and what benefit they get. One sentence only underneath the title.
24+
25+
## Summary ##
26+
> Give a summary of the product and the benefit. Assume the reader will not read anything else so make this paragraph good.
27+
28+
## Problem ##
29+
> Describe the problem your product solves.
30+
31+
## Solution ##
32+
> Describe how your product elegantly solves the problem.
33+
34+
## Quote from You ##
35+
> A quote from a spokesperson in your company.
36+
37+
## How to Get Started ##
38+
> Describe how easy it is to get started.
39+
40+
## Customer Quote ##
41+
> Provide a quote from a hypothetical customer that describes how they experienced the benefit.
42+
43+
## Closing and Call to Action ##
44+
> Wrap it up and give pointers where the reader should go next.

0 commit comments

Comments
 (0)