First stab at gating/regression for project 2#4
Conversation
Add gating logic (attempting to do so tidily, may have to resort to apply())
just use apply .
|
Nb. It will probably be a good idea to merge my first stab (this pull request) into the main repo before you plural take off to the races for project 2. Although some of your solutions may be better than mine... ! |
|
I think this may be ready for prime time. First three votes tank or float it. |
There was a problem hiding this comment.
On Line 454 of code "library(coefplot)"
Error message: Error in library(package, pos = pos, lib.loc = lib.loc, character.only = TRUE, :
there is no package called ‘coefplot’
Suggested edit
install.packages("coefplot")
library(coefplot)
OR
Add this to one of our group packages
|
I confirm the error conveyed by @Goralsth: "library(coefplot)" |
|
Error yielded for code: suggested fix (though trivial): |
kate-t-48
left a comment
kate-t-48
left a comment
There was a problem hiding this comment.
Having a chunk/ separate file with all the packages we need to install first would be useful as I think I'm missing some and come across errors and have to go hunting! I think the work around you're suggesting for Complexheatmap will help with this with regards to Project 2 though!
9 participants
What's all this?
This pull request corresponds to changes in my fork of the repository, specifically, the changes that constitute my markdown chunk for project 2. At present, these changes are awaiting your approval to be merged into the main repository for you to sync up!
What am I asking to add to the main repository?
In short, a worked (mostly complete) solution to project 2.
Why should you review this?
Because it will make your life a lot easier if you can sync this example into your fork of the project.
At that point, all you need to do is make a copy of it, edit to answer some of the questions, commit your changes (hopefully in a file named something like project2_yourName.Rmd) and the results of knitting them (which should look something like project2_yourName.md), open your own pull request (see figure below), and get a review.
We will collate them as child documents once it's clear that every subsidiary piece works. Also, this makes it easier for reviewers to review your code that way. Last but not least, it ends up being really obvious what each person did individually and how that fits into the overall results. Not entirely unlike a proper research project...
Practical matters, or why "first three yes votes win"
If you (individual or plural) wish to use my stab as a basis for your chunks, we should probably approve this pull request and merge it into the main repository so that you can pull it down into your own forks. It will take a lot less time for you to sync up your fork, create a copy of my Rmarkdown, edit to explore the bits you find interesting, and commit/pull request if you're all working from the same basic structure. (Note: you do not have to use my code as the basis for your own! Although you're welcome to, if you like.) The sooner it's merged, the sooner you can decide how you want to use it and the easier it will be to conduct the downstream reviews.
Grading for code reviews
This is pretty simple: if you're reviewing someone's code, it needs to run (or get to the point where it can), and it needs to make sense. Your job as a code reviewer is to enforce that. So far, all reviewers have indeed done so, and the fixes have been relatively straightforward to address reviewer concerns. (This is roughly modeled after the JOSS review principles.)
Opening a pull request and requesting a code review for your own chunks
Last but not least, to spawn your own code review, commit your changes to your own fork of the package, then open a pull request against the main VanAndelInstitute repository and look on the right hand side for a little gear that allows you to request reviewers. (Or I can assign them, that's fine too)