CommunityData:Critique and Feedback Session: Difference between revisions

From CommunityData
No edit summary
Line 1: Line 1:
=== Procedures ==
=== Procedures ===


For the '''critique and feedback''' sessions we're expecting everybody who wants to participate to submit (a) something in writing (e.g., a paper, a [[Matsuzaki outline]], an extended abstract) and (b) a list of questions or types of feedback you want. Please only submit something you want feedback on!
For the '''critique and feedback''' sessions we're expecting everybody who wants to participate to submit (a) something in writing (e.g., a paper, a [[Matsuzaki outline]], an extended abstract) and (b) a list of questions or types of feedback you want. Please only submit something you want feedback on!

Revision as of 22:45, 17 April 2020

Procedures

For the critique and feedback sessions we're expecting everybody who wants to participate to submit (a) something in writing (e.g., a paper, a Matsuzaki outline, an extended abstract) and (b) a list of questions or types of feedback you want. Please only submit something you want feedback on!

If you want to participate, you need to email something to collective@communitydata.cc by the end of day on the Monday before the weekend of the C&F session. Not everybody needs to participate but anybody who does participate should only submit one thing.

We're expecting that everyone attending will have read all the material submitted and will bring notes to the meeting. When we meet, everyone who has submitted something will get at least half an hour (more if possible).

When we meet, these sessions will be run with no presentations and no formal introductions. The plan to just jump in and start answering the questions and talking about thing we've all already read."


Session Norms

These are our general norms:

  • Take the entire group as an audience: the best feedback is beneficial or thought-provoking to the group as a whole, prompts group discussion/consideration, asks a question, etc.
  • If the author is your only audience, be practical and actionable for the project's current stage. Early-stage work is expected to be a little unpolished and crunchy, and proposing a large new branch of analysis for a nearly-complete work should be approached with a scoping statement (Must this be done for the work to be valid? Or are you proposing a follow-up line of inquiry to be stated in the Future Work section?)
  • Don't dogpile -- time is short, so even positive plus-ones should be brief: don't repeat what others have said, don't feel the need to chime in or pile on a critique: it is assumed that you read the paper and are supportive of the author.
  • Avoid vaguebooking. "Framework needs some work" or "Lacking some flow" isn't as useful as "I don't think you're getting a lot out of using Foucault, Latour, and Habermas here, and explaining them is pretty heavy -- maybe you can get away with just invoking Benkler and moving on" and experience-grounded comments like "When you transitioned from section 2 to section 3, and half-way through section 4, I ended up flipping back to the abstract to figure out what was going on".
  • Don't narrate the typo you found on line 156: feedback best conveyed via a marked-up draft should be delivered via a marked-up draft.

Jit.si / teleconference norms and tips

  • If you want to voice feedback, please type your initials in the chat. The moderator will call on people to speak on a first come, first serve basis.
  • Mute your microphone unless you've been called on to speak by the moderator.
  • If you're having connectivity issues, consider directly connecting to your router and / or turning off your video feed.
  • Use the etherpad / shared document to give feedback if we run out of time and don't get to your feedback.
  • Please be mindful of your own time when you have the mic. Make your points quickly and point to examples.