2.1 Set-up

We say goodbye to the repos/packages used for assignments 1-5 (e.g. your version of xyza1). Working with your team, start a new package within a Git/GitHub repo, naming it something short but descriptive of the project you are doing. Follow the R package naming conventions to setup your repo name. This should be a private repo under either one of your profiles, or the agroimpacts organization.

As with your previous assignments, your work should be structured as an R package. That does not mean that you will necessarily need to be writing functions that are native to the package (i.e. documented functions living in the R folder that build with the package), but you should be writing your project up and showing your code and analysis within vignettes.

2.2 Tasks

For this assignment, you should write a single vignette called “overview.Rmd”, which has the following sections:

1. Summary: A brief (up to 250 words) description of the project, and a bullet point or enumerated list of its primary objectives.

2. Approach and Method: An outline of the analytical methods and code you plan to use, including the names of key packages that you will draw on. This section should be composed of the following sub-sections:

3. Data: A brief (~250 words) description and visualization of the datasets you will be using. That means spatial plots of the main datasets and their key values, and, as a bonus, a plot of summary statistics, e.g. a histogram or boxplot of one of the more importants variables in the dataset.

4. Code: A bullet point summary of the analysis and coding approach that you propose to follow. For teams, this section should include a description of which member will be responsible for each bullet point.

5. Timelines: Provide a timeline for when each portion of the analysis will be completed. These timelines should be constructed relative to the time period of presentations (during the last two weeks of class) and final project submission (during exam week). For teams, names should be associated with each step on the timeline.

6. Anticipated outcomes: Briefly describe, as bullet points, the outcomes you expect for each of your primary project objectives

2.3 An additional note for teams

For this last assignment, it doesn’t make sense that team members do separate work in different branches of the repo, with the exception of cases where data fetching and wrangling tasks needed to describe and visualize the data are partitioned between members. In this case, team members should have separate vignettes in their respective branches describing the data gathering and processing steps to date. Otherwise, the expectation is that this assignment is presented as a jointly written vignette that builds with the package in the main branch. Please put your initials next to sections that you were responsible for writing. If you want to get really advanced, you can each jointly work on a version of overview in your own branches, and then do a merge and reconcile of your differing version in the main branch.

3.1 Overall scope

The purpose of the final product is to provide an overview of the results of the project you have been working on during the final unit of the class, building on the work you will have already presented in class during one of the last four sessions. The nature of this product can vary according to the type of project you are pursuing, which I would broadly define into two groups:

1. Those that are more focused on developing a package that provides a set of R functions that will be more broadly useful;

2. Those that are more analytical in nature, i.e. using R to answer particular questions of interest.

In the former case, we will want to see a good presentation of worked examples presented in your package vignette(s). In the latter case, your package vignette(s) should give an informative overview of your key findings and (if applicable) way forward for the project. Some projects may fall somewhere in between these two extremes.

3.2 Structure and content

Regardless of the type of project you are developing, you will submit it as an R package (within the repo you started for your overview assignment), as we have been doing all semester. That R package should be fully reproducible, i.e.

devtools::install_github("agroimpacts/yourproject", build_vignettes = TRUE)
browseVignettes("yourproject")

Works perfectly and gives us results that contain everything we need to evaluate the project. Datasets that are too large to be committed to the package repo should be linked to, but the code used to process them should be clear, and any figures built from them should be committed to the repo and incorporated in your package vignettes.

NOTE on analyses: It is strongly recommend for big datasets and slow-running analyses that you develop and run the analyses within eval = FALSE chunks, which can be accomplished as follows:

• Save smaller intermediate datasets as needed, which can be read back in to downstream eval = TRUE chunks

• Write plots to png files that you then read back in to the vignettes using knitr::include_graphics(). See the Rmds for Unit2, Module 2* as examples

• Following this approach will let you iterate much faster on testing whether your vignettes knit properly.

Vignettes will contain the material we are most interested in, but we will also examine your DESCRIPTION, NAMESPACE, function documentation (if applicable), i.e. the key components of making an R package and delivering it in a reproducible manner.

Jointly authored vignettes in group projects should have team member initials indicating which section each member worked on, specify the particular section. Otherwise, separately authored vignettes should have team member titles at the top.

As stated before, if there are clear, separable tasks that lend themselves to separate development efforts, team members should work on those and make frequent commits within their own repo branches.

R code should follow the style we have been using all along.

The main item in your package that we will assess is/are the package vignette/vignettes.

3.3 Vignette(s)

You can choose to have one or several vignettes, depending on how much sense it makes to break down the information into separate documents. Regardless, your vignette or vignettes should contain the following information (the names of the headings can vary though according to what makes sense)

4.1 Example of past projects

A number of these projects were undertaken by previous classes, but several of them may be built on further.

4.2 New projects