Solutions will be posted to GitHub:
studio-XX-solutionfor some value of XX (Ex:
The studio summaries are intended to be a dialog with students. It’s an opportunity for us to:
As you review students’ work, please try to keep in mind that the goal here is enhancing their learning via great feedback (not “assessing” their understanding).
When reviewing be sure that ever group gets some kind of personalized feedback. It would be best to give some sort of acknowledgment of good/bad on most changes, but that may be excessive in many studios. Be sure that some aspect of each groups work has something more than just cursory good/bad feedback.
It should go without saying that you should be reasonably professional, but
Most Studios will have:
process/Debrief.md: Questions / answers that merit replies.
process/SessionNotes.md: Do a quick read of content and give feedback if you’d like. If it’s empty, indicate that the recorder should have recorded something!
process/Roles.md: Indicate if it’s empty (and mention that they should use full names if they didn’t)
README.md: Actual studio qustions. Be sure to review them.
You will be provided with a “key” for all assignments, but large classes are a fantastic opportunity to crowdsource good ideas. Often there are great insights, suggestions, or solutions that weren’t obvious when the solution was written. In addition, there are often common errors and oversights that can be given a common response.
Before grading in earnest, do a quick survey of several different groups work. See if there are any things that stand out. This could save a lot of back-and-forth adjustments later. Feel free to share great insights among groups (but never directly share student work).
Some people prefer grading a single question for all groups, then the next question for all groups, etc. Others prefer to grade all of a single group’s work, then the next group, etc. Use whichever you are most comfortable with, but it’s best if you don’t commit any work until you are completely done grading all questions for all groups (see below on committing). This gives you a chance to go back-and-forth as necessary to ensure that you are being consistent and aren’t overlooking anything significant.
It’s often helpful to open a text editor and keep a log of common responses or particularly long responses that you may need to give to many groups. Then just copy/paste the response when needed (and possibly edit a little).
The basic process will involve:
Browse the Repository at this Pointbutton for the most recent “bsiever” commit.
Treedropdown and enter the name
originalto create a branch.
New Pull Requestbutton.
originalbranch to compare to it.
Feedbackand click on
Create pull request.
Rich Diffmode. This may help you read work when there is a lot of formatting (tables, images, etc.)
Start a review(or
Add Review Commentif a review is already started) (NOT
Add single commentnor
Review changesdropdown, then enter the credit and/or description if there are lost points (only if huge omissions) in the comment box, enter the grade in the PowerApp Form but be sure to only enter grades for students who were present for the studio (check the studio grades) (If they completed the
process/Roles.mdfile the names will show up in the review), then click