<commit_before>.. _develop:

Developer guide
===============
<commit_msg>Pull requests section in developer docs<commit_after>.. _develop:

Developer guide
===============


Pull Requests
-------------

Pull requests (PRs) are how we submit new code and fixes to Fatiando.
They also serve as a platform for reviewing the code.
Ideally, someone else will go through your code to make sure there aren't any
obvious mistakes.
The reviewer can also suggest improvements, help with unfixed problems, etc.
This is the same as the peer-review processes in scientific publication
(or at least what it should be).

.. warning:: Reviewers should **always be polite** in their **constructive**
    criticism. Rudeness and prejudice will not be tolerated.

See the
`list of completed pull requests <https://github.com/fatiando/fatiando/pulls?q=is%3Apr+is%3Amerged>`__
for examples of how the process works.

PRs will only be merged if they meet certain criteria:

* New code must be have automated tests
* All tests must pass (this will be evaluated automatically by
  `TravisCI <https://travis-ci.org/fatiando/fatiando/>`__
* All new code and changes must be documented with
  `docstrings <http://legacy.python.org/dev/peps/pep-0257/>`__
* New code must not cause merge conflicts (someone will help you resolve this
  in case it happens and you don't know what to do)
* All code must follow the
  `PEP8 <http://legacy.python.org/dev/peps/pep-0008/>`__ style conventions.
  This will also be check automatically by the tests (and TravisCI)

If you don't know what these things are, I recommend that you read through
the `Software Carpentry <http://software-carpentry.org/>`__ lessons.
Particularly the lessons "Testing", "Version control with git", and
"Program design" (all of the lessons are great though).

Even if all of these requirements are met,
features that fall outside of the scope of the project might not be
accepted (but we will discuss the possibility).
So **before you start coding**
open `an issue <https://github.com/fatiando/fatiando/issues>`__ explaining what
you mean to do first so that we can discuss it.
Check if there isn't an issue open for this already.
This way we can keep track of who is working on what and avoid duplicated work.

PRs should be made to the ``master`` branch of the
main repository:
`fatiando/fatiando <https://github.com/fatiando/fatiando>`__

When submitting a PR, explain in the description what the purpose of the PR is.
What changes are you proposing and why?
To help keep track of what you need to do,
copy this checklist to the PR description
(adapted from the
`khmer docs
<http://khmer.readthedocs.org/en/v1.1/development.html#checklist>`__)::

    Checklist:
    - [ ] Make tests for new code
    - [ ] Create/update docstrings
    - [ ] Code follows PEP8 style conventions
    - [ ] Code and docs have been spellchecked
    - [ ] Changelog entry
    - [ ] Documentation builds properly
    - [ ] All tests pass
    - [ ] Can be merged

This will create check boxes that you can mark as you complete each of the
requirements.
If you don't know how to do some of them, contact a developer
by writing a comment on the PR @-mentioning their user name
(e.g., `@leouieda <https://github.com/leouieda/>`__
or `@birocoles <https://github.com/birocoles/>`__).

{'fraction_non_alphanumeric': 0.0904126213592233, 'fraction_numerical': 0.00424757281553398, 'mean_word_length': 3.9728506787330318, 'pattern_counts': {'":': 0, '<': 13, '<?xml version=': 0, '>': 13, 'https://': 6, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4352761', 'n_tokens_mistral': 966, 'n_tokens_neox': 920, 'n_words': 447}