Naepic-seminar-notes

Nitpick and Line by Line Critique Seminar

  • Today, we will be learning to identify drafts that are eligible for line-by-line critique, differentiating them from drafts that aren't, and how to effectively and efficiently go about giving this type of critique.
  • Taking into account how the forums actually work (butterfly squad priorities, actual functionality, etc), what kinds of threads, without looking at the draft, might already be more eligible for nitpick-critique than others?
    • Experienced users (those with authorial experience)
      • A more experienced author is more likely to know where to take their draft, right?
    • Clearly conveyed ideas or ideas with promise
    • Those with a list of specific areas of concern for their draft. Usually means they know how the crit process works, and thus have a decent idea of how to write an SCP.
    • Drafts with lots of replies from both critters and OP, as it generally is of higher quality (each reply is either new crit or the author responding to critique)
      • If a draft has already received criticism, the author has had a chance to act on it, revise their draft, and make it better.

What are some key features of the draft itself that might make it eligible for nitpick or line-by-line critique?

  • No or few SPaG errors
  • I like to be able to read the first paragraph or section of the description and have a decent idea of what they're talking about, shows they can write concisely
  • Formatting
    • Good formatting shows they took the care and time to correctly and interestingly format the article
    • even if its a format screw, you want consistency (if that's the desired effect of the format screw, at least!)
  • Good dialogue
  • Narrative - one that's engaging and interesting.

Dealbreakers

  • no clear direction or narrative
  • zero clinical tone
  • fundamentally flawed concepts won’t be helped by a line by line critique

Exercise

  • General consensus chose the one that is slightly more refined
  • Start with ConProcs
    • You'll often see critters saying "these can save someone's life in-universe, so make sure everything is clear and precise." So we want to make sure everything in the containment procedures is *absolutely* necessary
    • Over-explaining, like some_author_dude said, is a really big thing that a lot of people mess up with. ConProcs (and entire documents, tbh) are all about being cold and concise.

containment procedures are not testing procedures. And while it's not technically incorrect to include either of these lines in the containment procedures, there's also no reason they can't go somewhere else.
* Fluff Text is Unnecessary
* Very oddly specific things definitely shouldn't be included unless absolutely necessary, because they add nothing new
* it's implied that the Foundation is going to feed things that need to be fed, give them water.
* 'To ensure safety', 'as per standard protocol', 'for extra measure', etc
* Unnecessary as it is all implicit
* we're aware this is all to ensure safety, or if something is standard protocol, why would we need to list it as such?
* Also, redacting or blackboxing stuff in the containment procedures is usually a big no-no, except for possibly doing it to a Site location.
* `Scp-x appears to be`
* Phrase is basically kryptonite
* There is absolutely 0 reason to tell us what your anomaly *appears* to be when you could tell us what it is.

Description

  • Now a lot of people will try to focus on their narrative more than describing the actual anomaly - this is a common pitfall I've encountered in a lot of drafts.
  • Make sure that the article is actually telling you what the anomaly is - you don't want that as a part of the mystery, unless that's the point of the article

Addenda

  • Usually Logs and Reports
  • Progresses the narrative
    • Needs to be there for a reason
    • If it isn't then it's fluff. And fluff does nothing but add pointless reading.
  • If it's an interview, make sure it's got solid dialogue

Nitpicking

  • When you give critique, you want to be explaining WHY what you've pulled has issues in it.
  • Don't just say 'this is a problem', tell them why it's a problem and if you can, offer a way that the author might be able to actually fix it.
  • Additionally, remember to be kind.
  • Go through every detail, make sure you get core SPaG errors, tear apart the narrative if you have to - make sure everything works, everything is flowing together, there aren't any major potholes, etc.

This concludes the seminar - I know it was a bit short today, but this concept is much more free-form than quick-crit, it's much more geared towards spelling, grammar, necessity of work, etc.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License