drop duplicated guides (#864)

* drop duplicated guides

* prevent copy to git

.gitignore

@@ -15,6 +15,8 @@ test_tube_exp/
 # Documentations
 docs/source/pl_examples*.rst
 docs/source/pytorch_lightning*.rst
+docs/source/tests*.rst
+docs/source/*.md
 tests/tests/
 
 # Byte-compiled / optimized / DLL files

docs/source/BECOMING_A_CORE_CONTRIBUTOR.md

@@ -1,59 +0,0 @@
-# How to become a core contributor
-
-Thanks for your interest in joining the Lightning team! We’re a rapidly growing project which is poised to become the go-to framework for DL researchers! 
-We're currently recruiting for a team of 5 core maintainers. 
-
-As a core maintainer you will have a strong say in the direction of the project. Big changes will require a majority of maintainers to agree.
-
-### Code of conduct  
-First and foremost, you'll be evaluated against [these core values](https://github.com/PyTorchLightning/pytorch-lightning/blob/master/.github/CONTRIBUTING.md). Any code we commit or feature we add needs to align with those core values.
-
-### The bar for joining the team   
-Lightning is being used to solve really hard problems at the top AI labs in the world. As such, the bar for adding team members is extremely high. Candidates must have solid engineering skills, have a good eye for user experience, and must be a power user of Lightning and PyTorch.
-
-With that said, the Lightning team will be diverse and a reflection of an inclusive AI community. You don't have to be an engineer to conntribute! Scientists with great usability intuition and PyTorch ninja skills are welcomed!
-
-### Responsibilities:
-The responsibilities mainly revolve around 3 things.
-
-#### Github issues
-- Here we want to help users have an amazing experience. These range from questions from new people getting into DL to questions from researchers about doing something esoteric with Lightning
-Often, these issues require some sort of bug fix, document clarification or new functionality to be scoped out.
-
-- To become a core member you must resolve at least 10 Github issues which align with the API design goals for Lightning. By the end of these 10 issues I should feel comfortable in the way you answer user questions
-Pleasant/helpful tone.
-
-- Can abstract from that issue or bug into functionality that might solve other related issues or makes the platform more flexible.
-
-- Don’t make users feel like they don’t know what they’re doing. We’re here to help and to make everyone’s experience delightful.
-
-#### Pull requests
-
-- Here we need to ensure the code that enters Lightning is high quality. For each PR we need to:
-- Make sure code coverage does not decrease
-- Documents are updated
-- Code is elegant and simple
-- Code is NOT overly engineered or hard to read
-- Ask yourself, could a non-engineer understand what’s happening here?
-- Make sure new tests are written
-- Is this NECESSARY for Lightning? There are some PRs which are just purely about adding engineering complexity which have no place in Lightning. 
-Guidance
-- Some other PRs are for people who are wanting to get involved and add something unnecessary. We do want their help though! So don’t approve the PR, but direct them to a Github issue that they might be interested in helping with instead!
-- To be considered for core contributor, please review 10 PRs and help the authors land it on master. Once you've finished the review, ping me 
-for a sanity check. At the end of 10 PRs if your PR reviews are inline with expectations described above, then you can merge PRs on your own going forward,
-otherwise we'll do a few more until we're both comfortable :)
-
-#### Project directions
-There are some big decisions which the project must make. For these I expect core contributors to have something meaningful to add if it’s their area of expertise.
-
-#### Diversity
-Lightning should reflect the broader community it serves. As such we should have scientists/researchers from 
-different fields contributing!   
-
-The first 5 core contributors will fit this profile. Thus if you overlap strongly with experiences and expertise as someone else on the team, you might have to wait until the next set of contributors are added.
-
-#### Summary: Requirements to apply
-- Solve 10 Github issues. The goal is to be inline with expectations for solving issues by the last one so you can do them on your own. If not, I might ask you to solve a few more specific ones.
-- Do 10 PR reviews. The goal is to be inline with expectations for solving issues by the last one so you can do them on your own. If not, I might ask you to solve a few more specific ones.
-
-If you want to be considered, ping me on gitter and start [tracking your progress here](https://docs.google.com/spreadsheets/d/15D58gp8DvI0Z6qbbYVRuaWioiwzafcP58-UlbuO_CMU/edit?usp=sharing).

docs/source/CODE_OF_CONDUCT.md

@@ -1,76 +0,0 @@
-# Contributor Covenant Code of Conduct
-
-## Our Pledge
-
-In the interest of fostering an open and welcoming environment, we as
-contributors and maintainers pledge to making participation in our project and
-our community a harassment-free experience for everyone, regardless of age, body
-size, disability, ethnicity, sex characteristics, gender identity and expression,
-level of experience, education, socio-economic status, nationality, personal
-appearance, race, religion, or sexual identity and orientation.
-
-## Our Standards
-
-Examples of behavior that contributes to creating a positive environment
-include:
-
-* Using welcoming and inclusive language
-* Being respectful of differing viewpoints and experiences
-* Gracefully accepting constructive criticism
-* Focusing on what is best for the community
-* Showing empathy towards other community members
-
-Examples of unacceptable behavior by participants include:
-
-* The use of sexualized language or imagery and unwelcome sexual attention or
- advances
-* Trolling, insulting/derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or electronic
- address, without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
- professional setting
-
-## Our Responsibilities
-
-Project maintainers are responsible for clarifying the standards of acceptable
-behavior and are expected to take appropriate and fair corrective action in
-response to any instances of unacceptable behavior.
-
-Project maintainers have the right and responsibility to remove, edit, or
-reject comments, commits, code, wiki edits, issues, and other contributions
-that are not aligned to this Code of Conduct, or to ban temporarily or
-permanently any contributor for other behaviors that they deem inappropriate,
-threatening, offensive, or harmful.
-
-## Scope
-
-This Code of Conduct applies both within project spaces and in public spaces
-when an individual is representing the project or its community. Examples of
-representing a project or community include using an official project e-mail
-address, posting via an official social media account, or acting as an appointed
-representative at an online or offline event. Representation of a project may be
-further defined and clarified by project maintainers.
-
-## Enforcement
-
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the project team at waf2107@columbia.edu. All
-complaints will be reviewed and investigated and will result in a response that
-is deemed necessary and appropriate to the circumstances. The project team is
-obligated to maintain confidentiality with regard to the reporter of an incident.
-Further details of specific enforcement policies may be posted separately.
-
-Project maintainers who do not follow or enforce the Code of Conduct in good
-faith may face temporary or permanent repercussions as determined by other
-members of the project's leadership.
-
-## Attribution
-
-This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
-available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
-
-[homepage]: https://www.contributor-covenant.org
-
-For answers to common questions about this code of conduct, see
-https://www.contributor-covenant.org/faq

docs/source/CONTRIBUTING.md

@@ -1,53 +0,0 @@
-# Contributing    
-Welcome to the PyTorch Lightning community! We're building the most advanced research platform on the planet to implement the latest, best practices that the amazing PyTorch team rolls out!   
-
-## Main Core Value: One less thing to remember    
-Simplify the API as much as possible from the user perspective. Any additions or improvements should minimize things the user needs to remember.   
-
-For example: One benefit of the validation_step is that the user doesn't have to remember to set the model to .eval(). This avoids all sorts of subtle errors the user could make.  
-
-## Lightning Design Principles   
-We encourage all sorts of contributions you're interested in adding! When coding for lightning, please follow these principles.    
-#### No PyTorch Interference   
-We don't want to add any abstractions on top of pure PyTorch. This gives researchers all the control they need without having to learn yet another framework.    
-
-#### Simple Internal Code    
-It's useful for users to look at the code and understand very quickly what's happening. Many users won't be engineers. Thus we need to value clear, simple code over condensed ninja moves. While that's super cool, this isn't the project for that :)      
-
-#### Force User Decisions To Best Practices    
-There are 1,000 ways to do something. However, something eventually becomes standard practice that everyone does. Thus we pick one way of doing it and force everyone to do it this way. A good example is accumulated gradients. There are many ways to implement, we just pick one and force users to use that one. A bad forced decision would be to make users use a specific library to do something.    
-
-When something becomes a best practice, we add it to the framework. This likely looks like code in utils or in the model file that everyone keeps adding over and over again across projects. When this happens, bring that code inside the trainer and add a flag for it.
-
-#### Simple External API    
-What makes sense to you may not make sense to others. Create an issue with an API change suggestion and validate that it makes sense for others. Treat code changes how you treat a startup: validate that it's a needed feature, then add if it makes sense for many people. 
-
-#### Backward-compatible API   
-We all hate updating our deep learning packages because we don't want to refactor a bunch of stuff. In Lightning, we make sure every change we make which could break an API is backwards compatible with good deprecation warnings.
-
-You shouldn't be afraid to upgrade Lightning :)
-
-#### Gain User Trust    
-As a researcher you can't have any part of your code going wrong. So, make thorough tests that ensure an implementation of a new trick or subbtle change is correct.    
-
-#### Interoperability  
-Have a favorite feature from other libraries like fast.ai or transformers? Those should just work with lightning as well. Grab your favorite model or learning rate scheduler from your favorite library and run it in Lightning.
-
-## Contribution Types    
-Currently looking for help implementing new features or adding bug fixes. 
-
-A lot of good work has already been done in project mechanics (requirements.txt, setup.py, pep8, badges, ci, etc...) we're in a good state there thanks to all the early contributors (even pre-beta release)!   
-
-## Bug Fixes:  
-1. Submit a github issue.   
-2. Fix it.  
-3. Submit a PR! 
-
-## New Features:  
-1. Submit a github issue.   
-2. We'll agree on the feature scope.     
-3. Submit a PR! (with updated docs and tests 🙃).   
-
-## Coding Styleguide
-1. Test the code with flake8.
-2. Use f-strings.

docs/source/PULL_REQUEST_TEMPLATE.md

@@ -1,16 +0,0 @@
-# Before submitting
-
-- [ ] Was this discussed/approved via a Github issue? (no need for typos, doc improvements)
-- [ ] Did you read the [contributor guideline](https://github.com/PyTorchLightning/pytorch-lightning/blob/master/.github/CONTRIBUTING.md)?
-- [ ] Did you make sure to update the docs?   
-- [ ] Did you write any new necessary tests?  
-
-## What does this PR do?
-Fixes # (issue).
-
-## PR review    
-Anyone in the community is free to review the PR once the tests have passed.     
-If we didn't discuss your PR in Github issues there's a high chance it will not be merged.
-
-## Did you have fun?
-Make sure you had fun coding 🙃

docs/source/debugging.rst

@@ -1,9 +1,9 @@
 Debugging
-==========
+=========
 The following are flags that make debugging much easier.
 
 Fast dev run
--------------------
+------------
 This flag runs a "unit test" by running 1 training batch and 1 validation batch.
 The point is to detect any bugs in the training/validation loop without having to wait for
 a full epoch to crash.
@@ -13,7 +13,7 @@ a full epoch to crash.
     trainer = pl.Trainer(fast_dev_run=True)
 
 Inspect gradient norms
------------------------------------
+----------------------
 Logs (to a logger), the norm of each weight matrix.
 
 .. code-block:: python
@@ -22,7 +22,7 @@ Logs (to a logger), the norm of each weight matrix.
     trainer = pl.Trainer(track_grad_norm=2)
 
 Log GPU usage
------------------------------------
+-------------
 Logs (to a logger) the GPU usage for each GPU on the master machine.
 
 (See: :ref:`trainer`)
@@ -32,7 +32,7 @@ Logs (to a logger) the GPU usage for each GPU on the master machine.
     trainer = pl.Trainer(log_gpu_memory=True)
 
 Make model overfit on subset of data
------------------------------------
+------------------------------------
 
 A good debugging technique is to take a tiny portion of your data (say 2 samples per class),
 and try to get your model to overfit. If it can't, it's a sign it won't work with large datasets.
@@ -44,7 +44,7 @@ and try to get your model to overfit. If it can't, it's a sign it won't work wit
     trainer = pl.Trainer(overfit_pct=0.01)
 
 Print the parameter count by layer
------------------------------------
+----------------------------------
 Whenever the .fit() function gets called, the Trainer will print the weights summary for the lightningModule.
 To disable this behavior, turn off this flag:
 
@@ -55,7 +55,7 @@ To disable this behavior, turn off this flag:
     trainer = pl.Trainer(weights_summary=None)
 
 Print which gradients are nan
-------------------------------
+-----------------------------
 Prints the tensors with nan gradients.
 
 (See: :meth:`trainer.print_nan_grads`)
@@ -65,7 +65,7 @@ Prints the tensors with nan gradients.
     trainer = pl.Trainer(print_nan_grads=False)
 
 Set the number of validation sanity steps
--------------------------------------
+-----------------------------------------
 Lightning runs a few steps of validation in the beginning of training.
 This avoids crashing in the validation loop sometime deep into a lengthy training loop.
 

docs/source/governance.md

@@ -1,8 +0,0 @@
-# Pytorch Lightning Governance | Persons of interest
-
-### Maintainers  
-- William Falcon ([williamFalcon](https://github.com/williamFalcon))   
-- Jirka Borovek ([Borda](https://github.com/Borda))   
-- Nick Eggert ([neggert](https://github.com/neggert))   
-- Jeff Ling ([jeffling](https://github.com/jeffling))   
-- Tullie Murrell ([tullie](https://github.com/tullie))

docs/source/governance.rst

@@ -0,0 +1,10 @@
+Pytorch Lightning Governance | Persons of interest
+==================================================
+
+Maintainers
+-----------
+- William Falcon (`williamFalcon <https://github.com/williamFalcon>`_)
+- Jirka Borovek (`Borda <https://github.com/Borda>`_)
+- Nick Eggert (`neggert <https://github.com/neggert>`_)
+- Jeff Ling (`jeffling <https://github.com/jeffling>`_)
+- Tullie Murrell (`tullie <https://github.com/tullie>`_)