You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First, thanks a lot for wanting to help! Make sure you have read [Jeremy's notes on fastai coding style](
4
-
https://docs.fast.ai/dev/style.html) first. (Note that we don't follow PEP8, but instead follow a coding style designed specifically for numerical and interactive programming.)
3
+
First, thanks a lot for wanting to help! Make sure you have read the [doc on code style](
4
+
https://docs.fast.ai/dev/style.html) first. (Note that we don't follow PEP8, but instead follow a coding style designed specifically for numerical and interactive programming.) For help running and building the code, see the [developers guide](https://docs.fast.ai/dev/develop.html).
5
5
6
6
## Note for new contributors from Jeremy
7
7
@@ -15,44 +15,66 @@ It can be tempting to jump into a new project by questioning the stylistic decis
15
15
16
16
## How to get started
17
17
18
-
Before anything else, please install the git hooks that run automatic scripts during each commit and merge to strip the notebooks of suerpfluous metadata (and avoid merge conflicts). After cloning the repository, run the following command inside it:
19
-
```
20
-
nbdev_install_git_hooks
21
-
```
18
+
Here are some ways that you can learn a lot about the library, whilst also contributing to the community:
19
+
20
+
- Pick a class, function, or method and write tests for it. For instance, here are the tests for [fastai.core](https://github.com/fastai/fastai1/blob/master/tests/test_core.py). Adding tests for anything without good test coverage is a great way to really understand that part of the library deeply, and have in-depth conversations with the dev team about the reasoning behind decisions in the code.
21
+
- Document something that is currently undocumented. You can find them by looking for the “new methods” section in any doc notebook. Here’s a [search](https://github.com/fastai/fastai/search?q=%22new+methods%22&unscoped_q=%22new+methods%22) that lists them
22
+
- Add an example of use to the docs for something that doesn’t currently have an example of use. We’d like everything soon in the docs to include an actual piece of working code demonstrating it. Currently, we’ve largely only provided working examples for stuff higher up the abstraction ladder.
22
23
23
24
## Did you find a bug?
24
25
25
26
* Nobody is perfect, especially not us. But first, please double-check the bug doesn't come from something on your side. The [forum](http://forums.fast.ai/) is a tremendous source for help, and we'd advise to use it as a first step. Be sure to include as much code as you can so that other people can easily help you.
26
-
* Then, ensure the bug was not already reported by searching on GitHub under [Issues](https://github.com/fastai/nbdev/issues).
27
-
* If you're unable to find an open issue addressing the problem, [open a new one](https://github.com/fastai/nbdev/issues/new). Be sure to include a title and clear description, as much relevant information as possible, and a code sample or an executable test case demonstrating the expected behavior that is not occurring.
28
-
* Be sure to add the complete error messages.
27
+
* Then, ensure the bug was not already reported by searching on GitHub under [Issues](https://github.com/fastai/fastai/issues).
28
+
* If you're unable to find an open issue addressing the problem, [open a new one](https://github.com/fastai/fastai/issues/new). Be sure to include a title and clear description, as much relevant information as possible, and a code sample or an executable test case demonstrating the expected behavior that is not occurring.
29
+
* Be sure to add the complete error messages as well as the result of the line `import fastai.utils.collect_env; fastai.utils.collect_env.show_install(1)`.
29
30
30
31
#### Did you write a patch that fixes a bug?
31
32
32
33
* Open a new GitHub pull request with the patch.
33
-
* Ensure that your PR includes a test that fails without your patch, and pass with it.
34
+
* Ensure that your PR includes [tests](https://docs.fast.ai/dev/test.html) that fail without your patch, and pass with it.
34
35
* Ensure the PR description clearly describes the problem and solution. Include the relevant issue number if applicable.
35
36
* Before submitting, please be sure you abide by our [coding style](https://docs.fast.ai/dev/style.html) and [the guide on abbreviations](https://docs.fast.ai/dev/abbr.html) and clean-up your code accordingly.
36
37
37
38
## Do you intend to add a new feature or change an existing one?
38
39
39
-
* You can suggest your change on the [fastai forum](http://forums.fast.ai/) to see if others are interested or want to help.
40
-
* Before implementing a non-trivial new feature, contain it a new notebook, like those in [nbs](https://github.com/fastai/nbdev/tree/master/nbs). It should show step-by-step what your code is doing, and why, with the result of each step. Try to simplify the code as much as possible. When you're happy with it, let us know on the forum (include a link to gist with your notebook.)
41
-
* Once your approach has been discussed and confirmed on the forum, you are welcome to push a PR, including a complete description of the new feature and an example of how it's used. Be sure to document your code in the notabook.
42
-
* Ensure that your notebook includes tests that exercise not only your feature, but also any other code that might be impacted.
40
+
**Please take note that we are in the midst of making several breaking changes with the preparation of v1.1 so we suggest you wait a little bit before starting coding it.**
41
+
42
+
* You can suggest your change on the [fastai forum](http://forums.fast.ai/) to see if others are interested or want to help. [This topic](http://forums.fast.ai/t/fastai-v1-adding-features/23041/8) lists the features that will be added to fastai in the foreseeable future. Be sure to read it too!
43
+
* Before implementing a non-trivial new feature, first create a notebook version of your new feature, like those in [dev_nb](https://github.com/fastai/fastai_docs/tree/master/dev_nb). It should show step-by-step what your code is doing, and why, with the result of each step. Try to simplify the code as much as possible. When you're happy with it, let us know on the forum (include a link to gist with your notebook.)
44
+
* Once your approach has been discussed and confirmed on the forum, you are welcome to push a PR, including a complete description of the new feature and an example of how it's used. Be sure to document your code and read the [doc on code style](https://docs.fast.ai/dev/style.html) and [the one on abbreviations](https://docs.fast.ai/dev/abbr.html).
45
+
* Ensure that your PR includes [tests](https://docs.fast.ai/dev/test.html) that exercise not only your feature, but also any other code that might be impacted. Currently we have poor test coverage of existing features, so often you'll need to add tests of existing code. Your help here is much appreciated!
46
+
47
+
## How to submit notebook PRs?
48
+
49
+
* If your PR involves jupyter notebooks (`.ipynb`) you must instrument your git to `nbstripout` the notebooks, as explained [here](https://docs.fast.ai/dev/develop.html#stripping-out-jupyter-notebooks).
50
+
43
51
44
52
## PR submission guidelines
45
53
46
54
* Keep each PR focused. While it's more convenient, do not combine several unrelated fixes together. Create as many branches as needing to keep each PR focused.
55
+
47
56
* Do not mix style changes/fixes with "functional" changes. It's very difficult to review such PRs and it most likely get rejected.
57
+
48
58
* Do not add/remove vertical whitespace. Preserve the original style of the file you edit as much as you can.
59
+
49
60
* Do not turn an already submitted PR into your development playground. If after you submitted PR, you discovered that more work is needed - close the PR, do the required work and then submit a new PR. Otherwise each of your commits requires attention from maintainers of the project.
61
+
50
62
* If, however, you submitted a PR and received a request for changes, you should proceed with commits inside that PR, so that the maintainer can see the incremental fixes and won't need to review the whole PR again. In the exception case where you realize it'll take many many commits to complete the requests, then it's probably best to close the PR, do the work and then submit it again. Use common sense where you'd choose one way over another.
51
63
64
+
65
+
### Code PRs
66
+
67
+
* If your PR is a bug fix, please also include a test that demonstrates the problem, or modifies an existing test that wasn't catching that problem already. Of course, it's not a requirement, so proceed anyway if you can't figure out how to write a test, but do try. Without having a test your fix could be lost down the road. By supplying a test, you're ensuring that your projects won't break in the future.
68
+
69
+
* Same applies for PRs that implement new features - without having a test case validating this new feature, it'd be very easy for that new feature to break in the future. A test case ensures that the feature will not break.
70
+
71
+
52
72
## Do you have questions about the source code?
53
73
54
74
* Please ask it on the [fastai forum](http://forums.fast.ai/) (after searching someone didn't ask the same one before with a quick search). We'd rather have the maximum of discussions there so that the largest number can benefit from it.
55
75
56
76
## Do you want to contribute to the documentation?
57
77
58
-
* Docs are automatically created from the notebooks in the [nbs](https://github.com/fastai/nbdev/tree/master/nbs) folder.
78
+
* Docs are automatically created from the notebooks in the `/nbs` directory.
79
+
* To switch the `docs` submodule to ssh, `cd docs && git remote set-url origin git@github.com:fastai/fastai-docs.git`
0 commit comments