Brake down of main goals listed in job description

Update the package.

1. update the package.
   1. curate: decide what functions are useful and worthwhile keeping. DONE
   2. document: improve help files.
      1. titles, description and details.
      2. argumets (reuse templates)
      3. authors
      4. group related functions in one place
      5. add examples
      6. build a website
   3. validate: validate inputs or warn and err accoridingly. This helps users to understand what went wrong.
   4. test: This helps developers to notice that something went wrong so they can promptly fix it.
      1. regression tests: check old and new versions of a function output the same.
      2. test that functions do what they are expected to do.
      3. checks: devtools::check()
      4. lintr to check for style
      5. goodpractice::gp() to check for general good practices
      6. TravisCI to check package builds on all platforms.
   5. refactor: re-write code to improve it. E.g.
      1. names: make them more elocuent, consistent
      2. arguments:
         1. name arguments more elocuently
         2. order arguments more sensibly (data, details)
         3. give arguments most common or safest defaults
      3. code:
         1. improve style for better readability and consistency with modern style guides.
         2. improve safety
         3. reduce complexity
            1. reduce nestedness (mostly unnecessary if blocks)
            2. remove the boilperate code of for loops by replaceing for loops by functional programming approaches (most generally, calls to lapply(X, FUN))
         4. improve clarity

Optimize the package.

1. Human brain(human brain): make useful code easier to find and use.
   1. naming functions better.
   2. grouping functions coherently.
   3. writting more complete and clearer documentation (goepen)
   4. facilitating access to documentation via websites
   5. announcing advances on twitter, workshops
   6. facilitating disussions on GitHub
   7. building capacity via code reviews, workshops, seminars, tutorials.
2. Access to data:
   1. provide easy access to data for examples (bci, bciex).
   2. help the community to develop their own data packages.
   3. help the community to develop a friction-less workflow
3. Code speed
   1. provide light data for examples and tests to run fast (bciex)
   2. identify speed bottlenecks (profviz)
   3. replace slow by fast code. E.g. compare base vs. dplyr vs. data.table

Establish a framework for future maintenance and expansion.

1. build R packages sensu stricto
2. create platforms for:
   1. github.com/forestgeo:
      1. hosting code repositories, packages and package websites
      2. discussing current issues, proposed changes, collaboration, etc.
      3. managing collaboration
   2. (rpubs.com/forestgeo): publishing R products publicly
   3. bookdown.com/forestgeoguest: publishing R products with privileges control
   4. @forestgeo, #forestgeo, #forestr, etc.: announcing developments.