gslab-econ / ra-manual-archived Goto Github PK

@gentzkow what would you think about revising our process so that once a pull request for an issue is opened the issue is closed unless there is a reason to expect further work beyond the pull?

I find we often track essentially the same issue in multiple places, e.g.
issue
pull

On this model, "pull request" would essentially become our notation for "under peer review," which is probably more consistent with git style anyway.

Just a thought, not wedded to this.

GitHub's recent switch to CommonMark created some formatting problems, especially with our use of bullets. This task fixes the formatting.

As part of #1, we decided on hour guidelines for the different components of production that are now reflected in the RA manual here. Looking back at these, they seem to me like some of them may be high, and I'd like to check in on how they compare to reality.

Steps:

(1) Go back through the time logs for the last 4 or so papers we've put through production and record the actual time spent on each task.

(2) Make a list of the places where you think it would be most efficient to cut back total hours if we needed to do so.

From there we can discuss whether we should make revisions to the guidelines.

@jmshapir fyi

We have switched from Google Drive and the gdrive tool to Dropbox and rclone. The goal of this task is to update our storage page to current practice.

Hello @jmshapir @gentzkow,
I have been setting up a new repository on Sherlock these past days and have run into some errors/issues most of which are related to not knowing how to do it and implied more than needed time spent on this.
I believe that it might be worth updating the cluster section of the manual to provide more accurate/ guidance on how to run repos on Sherlock (also because some of the links in that section are broken/no longer relevant). This would allow future RA/users to turn to the manual and have accurate information plus avoid running into similar issues.

If you are fine with updating the section, I can propose some amendments to you and if you agree I can go ahead and ammend.

• Read Schwabish 2014 on data visualization.
• Add reference to the paper in an appropriate place.
• Make other lab members read the paper.

Jesse and I [Matt] wanted to have a quick debrief about the TRANS production process to see if there's anything we can tweak to make the process more efficient going forward. Overall, we were extremely happy with the work you all did.

Two small things I thought of:

(1) In PROOF, I would like the RAs to go ahead an correct any clear typos or other errors that you are ~100% sure we would want to correct, and for which there is no uncertainty about how they should be corrected. This would include things like "...Texas and and Massachusetts," misspellings, etc.

(2) In a couple of cases you were producing "big" deliverables containing all the output from a task and then a subset flagged for our attention. From our perspective, it's only the attention part that matters, and we want to make sure you're not spending extra time making the big deliverables pretty. You should view the deliverable of the tasks as the handoff to us of info we need to see; how everything is organized on the backend is up to you and should be as efficient as possible.

Let us know if you agree with these points and whether there are any other changes you guys see that would make the process more efficient.

gslab
gentzkow