Guidance provided by Sunpy developers guide

• Found while reading documentation

• Starting to be utilized while organizing the response modules

I'm really starting to know and love the SunPy developers guide. One guideline, also recommended by Astropy:docs, is setting up a python virtual environment. This makes things easier by allowing for specific versions of packages to be used per environment.

Here's how one would start an environment using conda, which is included in the installation of Anaconda:

>>> conda create name_env python=2.7

Then, any imports for the different requirements match that python, so switching between using python 2.7 (and all of the dependencies that depend on it) to python 3.4 (with new dependencies) is as easy as pie. These commands below are how you quickly go between one environment and another.

>>> source activate name_env

>>> source deactivate

>>> source activate name2_env

Lastly, this first command makes it easy to see what's being loaded in each environment, and the second one is how to install more packages:

>>> conda list

>>> conda install name_of_package

Pretty sweet. This has already helped me in testing ChiantiPy and Sunpy, and by helping me solve a problem I ran into in the first weeks with their respective python versions. I looked into popular/new pythons and found 2.7 and 3.4 are widely used. When I researched more, I found:

- The sunpy documentation states it works best with python 2.7.
- The ChiantiPy documentation has been tested with python 3.3 specifically.

So, I chose to set up an environment with python 2.7 because I've found this loads both modules. Then, I like to run sunpy.self_test() afterwards. 

---

       I also found similar git guidelines while reading the documentation pages provided by Astropy. I've utilized the section on 'How to make code contribution' quite a bit. Last post I mentioned setting up a branch on github, and the guides I've mentioned helped with that process. Mostly, I've used git to save my own repositories, but working with the development version of a code is much more extensive.

       Sunpy has asked that each week the participants of GSoC look into one pull request and check for validity. This is a new process for me, but I welcome the practice of working in the community-developing environment. While scanning the pull requests on Sunpy, I found one that reminded me of the astropy documentation, and sparked this blog post.

Sunpy Pull Request testing: Updates to CONTRIBUTING.md #1656

• First, I recognized .md from my work in preparation for this project where I resolved an issue that led to the development of CITATION.md in Sunpy. 
• For this pull request, I read the full changes to the CONTRIBUTING.md file with and without the notes provided.

• Few things I liked:
• The instant connection to people via recommending the IRC channel. That's awesome. 
• That an example of an issue is provided. Great recommendation.
• Inputs:
• Wafels comments covered quite well any thoughts that I had.

Overall, I feel this is a well developed file that is ready to be implemented. I have not tested this yet, as the build process is unfamiliar.  Looking at the details in other developers builds has allowed me to follow their process. It seems to mirror what I've described in this blog of setting up an environment to test the file, and making sure no errors come out. I'm working through this part, and feel this is something to ask about in the SunPy IRC.

***