1 | [Bug Reports](#bugs) | [Features Requests](#features) | [Submitting Pull Requests](#pull-requests) | [Running Local Demo](#running-local-demo) | [Running Tests](#running-tests)
|
2 |
|
3 | # Contributing to this project
|
4 |
|
5 | Please take a moment to review this document in order to make the contribution process easy and effective for everyone involved.
|
6 |
|
7 | Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project.
|
8 | In return, they should reciprocate that respect in addressing your issue or assessing patches and features.
|
9 |
|
10 | ## Using the issue tracker
|
11 |
|
12 | The issue tracker is the preferred channel for bug reports but please respect the following restrictions:
|
13 |
|
14 | * Please **do not** use the issue tracker for personal support requests (use [Gitter](https://gitter.im/bvaughn/redux-devtools-filterable-log-monitor)).
|
15 | * Please **do not** derail or troll issues. Keep the discussion on topic and respect the opinions of others.
|
16 |
|
17 | <a name="bugs"></a>
|
18 | ## Bug reports
|
19 |
|
20 | A bug is a _demonstrable problem_ that is caused by the code in the repository.
|
21 | Good bug reports are extremely helpful - thank you!
|
22 |
|
23 | Guidelines for bug reports:
|
24 |
|
25 | 1. **Use the GitHub issue search** — check if the issue has already been reported.
|
26 | 2. **Check if the issue has been fixed** — try to reproduce it using the latest `master` or development branch in the repository.
|
27 | 3. **Isolate the problem** — create a [reduced test case](http://css-tricks.com/reduced-test-cases/) and a live example (using a site like [Plunker](http://plnkr.co/)).
|
28 |
|
29 | A good bug report shouldn't leave others needing to chase you up for more information.
|
30 | Please try to be as detailed as possible in your report.
|
31 | Which versions of formFor and Angular are you using?
|
32 | What steps will reproduce the issue? What browser(s) and OS experience the problem?
|
33 | What would you expect to be the outcome?
|
34 | All these details will help people to fix any potential bugs.
|
35 |
|
36 | Example:
|
37 |
|
38 | > Short and descriptive example bug report title
|
39 | >
|
40 | > A summary of the issue and the browser/OS environment in which it occurs.
|
41 | > If suitable, include the steps required to reproduce the bug.
|
42 | >
|
43 | > 1. This is the first step
|
44 | > 2. This is the second step
|
45 | > 3. Further steps, etc.
|
46 | >
|
47 | > `<url>` - a link to the reduced test case
|
48 | >
|
49 | > Any other information you want to share that is relevant to the issue being reported.
|
50 | > This might include the lines of code that you have identified as causing the bug,
|
51 | > and potential solutions (and your opinions on their merits).
|
52 |
|
53 |
|
54 | <a name="features"></a>
|
55 | ## Feature requests
|
56 |
|
57 | Feature requests are welcome.
|
58 | But take a moment to find out whether your idea fits with the scope and aims of the project.
|
59 | It's up to *you* to make a strong case to convince the project's developers of the merits of this feature.
|
60 | Please provide as much detail and context as possible.
|
61 |
|
62 |
|
63 | <a name="pull-requests"></a>
|
64 | ## Pull requests
|
65 |
|
66 | Good pull requests - patches, improvements, new features - are a fantastic help.
|
67 | They should remain focused in scope and avoid containing unrelated commits.
|
68 |
|
69 | **Please ask first** before embarking on any significant pull request (e.g. implementing features, refactoring code, porting to a different language),
|
70 | otherwise you risk spending a lot of time working on something that the project's developers might not want to merge into the project.
|
71 |
|
72 | Please adhere to the coding conventions used throughout a project (indentation, accurate comments, etc.) and any other requirements (such as test coverage).
|
73 |
|
74 | Follow this process if you'd like your work considered for inclusion in the project:
|
75 |
|
76 | 1. [Fork](http://help.github.com/fork-a-repo/) the project, clone your fork, and configure the remotes:
|
77 |
|
78 | ```bash
|
79 | # Clone your fork of the repo into the current directory
|
80 | git clone https://github.com/<your-username>/redux-devtools-filterable-log-monitor
|
81 | # Navigate to the newly cloned directory
|
82 | cd redux-devtools-filterable-log-monitor
|
83 | # Assign the original repo to a remote called "upstream"
|
84 | git remote add upstream https://github.com/bvaughn/redux-devtools-filterable-log-monitor
|
85 | ```
|
86 |
|
87 | 2. If you cloned a while ago, get the latest changes from upstream:
|
88 |
|
89 | ```bash
|
90 | git checkout master
|
91 | git pull upstream master
|
92 | ```
|
93 |
|
94 | 3. Create a new topic branch (off the main project development branch) to
|
95 | contain your feature, change, or fix:
|
96 |
|
97 | ```bash
|
98 | git checkout -b <topic-branch-name>
|
99 | ```
|
100 |
|
101 | 4. Commit your changes in logical chunks.
|
102 | Please adhere to these [git commit message guidelines](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
|
103 | or your code is unlikely be merged into the main project.
|
104 | Use Git's [interactive rebase](https://help.github.com/articles/interactive-rebase)
|
105 | feature to tidy up your commits before making them public.
|
106 |
|
107 | 5. Locally merge (or rebase) the upstream development branch into your topic branch:
|
108 |
|
109 | ```bash
|
110 | git pull [--rebase] upstream master
|
111 | ```
|
112 |
|
113 | 6. Push your topic branch up to your fork:
|
114 |
|
115 | ```bash
|
116 | git push origin <topic-branch-name>
|
117 | ```
|
118 |
|
119 | 7. [Open a Pull Request](https://help.github.com/articles/using-pull-requests/)
|
120 | with a clear title and description.
|
121 |
|
122 | **IMPORTANT**: By submitting a patch, you agree to allow the project owner to license your work under the same license as that used by this project (MIT).
|
123 |
|
124 | <a name="running-local-demo"></a>
|
125 | ## Running Local Demo
|
126 |
|
127 | You can run the local demo with NPM like so:
|
128 |
|
129 | ```bash
|
130 | cd <root>
|
131 | npm start
|
132 | ```
|
133 |
|
134 | The local app will then be available at http://localhost:3001
|
135 |
|
136 | <a name="running-tests"></a>
|
137 | ## Running Tests
|
138 |
|
139 | All unit tests must pass before a pull request will be approved.
|
140 | You can run unit tests with NPM like so:
|
141 |
|
142 | ```bash
|
143 | cd <root>
|
144 | npm test
|
145 | ```
|