Grading Rubric: INTRO: 10 pts EDA: 25 pts, as follows: EDA on Y: 3 pts EDA on each X: 9 pts total EDA on relationship between Y and each X: 9 pts total EDA other (depends on the dataset and types of variables): 4 pts MODELING: 40 pts, as follows: residual plot: 4 pts discuss residual plot: 6 pts qqplot: 4 pts discuss qqplot: 3 pts discuss linearity assumption between Y and Xs: 4 pts discuss interactions: 3 pts discuss multicollinearity: 3 pts other valid reasons for choice of model (depends on your dataset and what you tried): 4 pts showing final model summary: 5 pts discussing significance: 4 pts PREDICTION: 15 pts CONCLUSION: 10 pts.

Advice: Save enough time to do the writing. Don't spend the whole week coding and trying models. Writing takes time, and we can only grade what you submit. Keep a balance between complexity and simplicity/interpretability. When working with real data, there isn't such a thing as a perfect model, but there can be useful ones. It's very unlikely that a model will fit your data perfectly; these datasets aren't as ‘nice' as those in homeworks/labs/lectures/example-project, and your regression diagnostics/p-values/R2 values/etc won't necessarily be very good. Transformations can be considered, but you should balance the tradeoff between making things look maybe only a little better versus more complicated interpretations. Always justify your actions regardless.

Read your knitted report before you submit. Be sure that after you knitted your final version, you read the full report. Check if your conclusions match the presented model, and that you didn't accidentally use a discarded model for your conclusions. Check if the text and figures are all there and there is a nice flow when reading it. Write as if it is a report you would submit to a client or an academic journal, not like a homework or class assignment or a snapchat to a friend: Your title should be something interesting and meaningful that captures the reader's attention and has something to do with the topic and the work (not "my project" or something similar that you might title a piece of course work).

The motivation you give in the introduction should suggest why the topic is of interest in the larger world and to the reader, not just to you personally. It is common in academic writing to use third person ("we", not "I"). The "we" typically implies the author and the readers (as if you are leading the readers together with you through the discovery process). Be professional in your writing; don't use emoticons, memes, online shorthand, or colloquialisms. This is practice for professional writing. [On the other hand, "professional" doesn't mean "artificially and unnecessarily complicated." Be clear and concise.]

The report should have sentences that introduce what you present, motivate how it is connected to the larger report, and then discuss what was shown. So for instance, don't just show a set of graphs, without some surrounding phrases or sentences connecting them to the "flow" of the paper.5.Be consistent in your writing style. Don't switch between past tense (like, "we did the following analysis") versus present tense (like, " we do the following analysis").

Don't copy verbatim sentences, phrases, or title from our posted topic prompts. You can paraphrase but not copy. Also the motivation for the topic that we wrote in the posted prompts aren't the only possible motivation. You don't need to "echo" all of the code. In the markdown template formatting, we have set the "echo" to TRUE, which will make all your code chunks show up in your knitted document (it "echoes" the code chunks in the knitted document), since seeing your code can sometimes help us in grading. But in published research you generally would not show all the code (it might be in an appendix). And regardless, we don't want to see all the test code you may have produced and ended up not using, or all the discarded models you tried and decided not to use (unless you want to refer to them).

If you want specific code chunks to not show up in the knitted document you can open that particular chunk with that will make the raw code not show up in your knitted document (but it would still get evaluated -- if you also want code to not get evaluated, you can either comment-out the lines of code inside the chunk [i.e., by putting the pound sign to the left of each line of code] or else add the argument eval=FALSE in the opening curly brackets of the code chunk). Don't copy/paste from other text editorsinto R. This could cause your document to not knit, if the text editor used different character encoding.

Be cautious copy/pasting between text areas and code chunks. This could similarly cause your document to not knit, for instance if some text character isn't understood in code, or if some code symbol isn't understood by the math font editor in the text area. Put extra line breaks (i.e., hit "enter" a few times) between graphs and text as needed. If, when you knit the document, you find that graphs or text seem to be pushed off the sides of the page, it's probably because the knitter is interpreting some graphs and text as being on the same line. Extra line breaks between them will solve this. Let me know if you have any questions.