Skip to main content
Humanities LibreTexts

5.10: Strategies for Peer-Reviewing and Team Writing

  • Page ID
    51555
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)

    ( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\id}{\mathrm{id}}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\kernel}{\mathrm{null}\,}\)

    \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\)

    \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\)

    \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    \( \newcommand{\vectorA}[1]{\vec{#1}}      % arrow\)

    \( \newcommand{\vectorAt}[1]{\vec{\text{#1}}}      % arrow\)

    \( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vectorC}[1]{\textbf{#1}} \)

    \( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)

    \( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)

    \( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)

    \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \(\newcommand{\avec}{\mathbf a}\) \(\newcommand{\bvec}{\mathbf b}\) \(\newcommand{\cvec}{\mathbf c}\) \(\newcommand{\dvec}{\mathbf d}\) \(\newcommand{\dtil}{\widetilde{\mathbf d}}\) \(\newcommand{\evec}{\mathbf e}\) \(\newcommand{\fvec}{\mathbf f}\) \(\newcommand{\nvec}{\mathbf n}\) \(\newcommand{\pvec}{\mathbf p}\) \(\newcommand{\qvec}{\mathbf q}\) \(\newcommand{\svec}{\mathbf s}\) \(\newcommand{\tvec}{\mathbf t}\) \(\newcommand{\uvec}{\mathbf u}\) \(\newcommand{\vvec}{\mathbf v}\) \(\newcommand{\wvec}{\mathbf w}\) \(\newcommand{\xvec}{\mathbf x}\) \(\newcommand{\yvec}{\mathbf y}\) \(\newcommand{\zvec}{\mathbf z}\) \(\newcommand{\rvec}{\mathbf r}\) \(\newcommand{\mvec}{\mathbf m}\) \(\newcommand{\zerovec}{\mathbf 0}\) \(\newcommand{\onevec}{\mathbf 1}\) \(\newcommand{\real}{\mathbb R}\) \(\newcommand{\twovec}[2]{\left[\begin{array}{r}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\ctwovec}[2]{\left[\begin{array}{c}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\threevec}[3]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\cthreevec}[3]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\fourvec}[4]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\cfourvec}[4]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\fivevec}[5]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\cfivevec}[5]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\mattwo}[4]{\left[\begin{array}{rr}#1 \amp #2 \\ #3 \amp #4 \\ \end{array}\right]}\) \(\newcommand{\laspan}[1]{\text{Span}\{#1\}}\) \(\newcommand{\bcal}{\cal B}\) \(\newcommand{\ccal}{\cal C}\) \(\newcommand{\scal}{\cal S}\) \(\newcommand{\wcal}{\cal W}\) \(\newcommand{\ecal}{\cal E}\) \(\newcommand{\coords}[2]{\left\{#1\right\}_{#2}}\) \(\newcommand{\gray}[1]{\color{gray}{#1}}\) \(\newcommand{\lgray}[1]{\color{lightgray}{#1}}\) \(\newcommand{\rank}{\operatorname{rank}}\) \(\newcommand{\row}{\text{Row}}\) \(\newcommand{\col}{\text{Col}}\) \(\renewcommand{\row}{\text{Row}}\) \(\newcommand{\nul}{\text{Nul}}\) \(\newcommand{\var}{\text{Var}}\) \(\newcommand{\corr}{\text{corr}}\) \(\newcommand{\len}[1]{\left|#1\right|}\) \(\newcommand{\bbar}{\overline{\bvec}}\) \(\newcommand{\bhat}{\widehat{\bvec}}\) \(\newcommand{\bperp}{\bvec^\perp}\) \(\newcommand{\xhat}{\widehat{\xvec}}\) \(\newcommand{\vhat}{\widehat{\vvec}}\) \(\newcommand{\uhat}{\widehat{\uvec}}\) \(\newcommand{\what}{\widehat{\wvec}}\) \(\newcommand{\Sighat}{\widehat{\Sigma}}\) \(\newcommand{\lt}{<}\) \(\newcommand{\gt}{>}\) \(\newcommand{\amp}{&}\) \(\definecolor{fillinmathshade}{gray}{0.9}\)

    Learning Objectives

    Upon completion of this chapter, readers will be able to:

    1. Explain and apply strategies for peer reviewing.
    2. Explain and apply strategies for team writing.

    Strategies for Peer Reviewing and Team Writing

    Be a thoughtful reviewer; be a good team member

    Peer reviewing (also called peer-editing) means people getting together to read, comment on, and recommend improvements on each other's work. Peer-reviewing is a good way to become a better writer because it provides experience in looking critically at writing.

    Team writing, as its name indicates, means people getting together to plan, write, and revise writing projects as a group, or team. Another name for this practice is collaborative writing—collaborative writing that is out in the open rather than under cover (where it is known as plagiarism).

    Strategies for Peer Reviewing

    When you peer-review another writer's work, you evaluate it, criticize it, suggest improvements, and then communicate all of that to the writer. As a first-time peer-reviewer, you might be a bit uneasy about criticizing someone else's work. For example, how do you tell somebody his essay is boring? Read the discussion and steps that follow; you'll find advice and guidelines on doing peer reviews and communicating peer-review comments.

    Initial meeting

    At the beginning of a peer review, the writer should provide peer reviewers with notes on the writing assignment and on goals and concerns about the writing project (topic, audience, purpose, situation, type), and alert them to any problems or concerns. As the writer, you want to alert reviewers to these problems; make it clear what kinds of things you were trying to do. Similarly, peer reviewers should ask writers whose work they are peer-reviewing to supply information on their objectives and concerns. The peer-review questions should be specific like the following:

    Does my expanation of virtual machine make sense to you? Would it make sense to our least technical customers? In general, is my writing style too technical? (I may have mimicked too much of the engineers' specifications.) Are the chapter titles and headings indicative enough of the following content? (I had trouble phrasing some of these.) Are the screen shots clear enough? (I may have been trying to get get too much detail in some of them.)

    Peer-reviewing strategies

    When you peer-review other people's writing, remember above all that you should consider all aspects of that writing, not just—in fact, least of all—the grammar, spelling, and punctuation. If you are new to peer-reviewing, you may forget to review the draft for things like the following:

    • Make sure that your review is comprehensive. Consider all aspects of the draft you're reviewing, not just the grammar, punctuation, and spelling.
    • Read the draft several times, looking for a complete range of potential problem areas:
      • Interest level, adaptation to audience
      • Persuasiveness, purpose
      • Content, organization
      • Clarity of discussion
      • Coherence, use transition
      • Title, introduction, and conclusion.
      • Sentence style and clarity
      • Handling of graphics
    • Be careful about making comments or criticisms that are based on your own personal style. Base your criticisms and suggestions for improvements on generally accepted guidelines, concepts, and rules. If you do make a comment that is really your own preference, explain it.
    • Explain the problems you find fully. Don't just say a paper "seems disorganized." Explain what is disorganized about it. Use specific details from the draft to demonstrate your case.
    • Whenever you criticize something in the writer's draft, try to suggest some way to correct the problem. It's not enough to tell the writer that her paper seems disorganized, for example. Explain how that problem could be solved.
    • Base your comments and criticisms on accepted guidelines, concepts, principles, and rules. It's not enough to tell a writer that two paragraphs ought to be switched, for example. State the reason why: more general, introductory information should come first, for example.
    • Avoid rewriting the draft that you are reviewing. In your efforts to suggest improvements and corrections, don't go overboard and rewrite the draft yourself. Doing so steals from the original writer the opportunity to learn and improve as a writer.
    • Find positive, encouraging things to say about the draft you're reviewing. Compliments, even small ones, are usually wildly appreciated. Read through the draft at least once looking for things that were done well, and then let the writer know about them.

    Peer-review summary

    Once you've finished a peer review, it's a good idea to write a summary of your thoughts, observations, impressions, criticisms, or feelings about the rough draft. See the peer-reviewer note below, which summarizes observations on a rough draft. Notice in the note some of the following details:

    • The comments are categorized according to type of problem or error—grammar and usage comments in one group; higher level comments on such things as content, organization, and interest-level in another group.
    • Relative importance of the groups of comments is indicated. The peer-reviewer indicates which suggestions would be "nice" to incorporate and which ones are critical to the success of the writing project.
    • Most of the comments include some brief statement of guidelines, rules, examples, or common sense. The reviewer doesn't simply say "This is wrong; fix it." He also explains the basis for the comment.
    • Questions are addressed to the writer. The reviewer is doublechecking to see if the writer really meant to state or imply certain things.
    • The reviewer includes positive comments to make about the rough draft and finds nonantagonistic, sympathetic ways to state criticisms.

    Excerpt from a note summarizing the results of a peer review

    Spend some time summarizing your peer-review comments in a brief note to the writer. Be as diplomatic and sympathetic as you can!

    Strategies for Team Writing

    As mentioned earlier in this chapter, team writing is one of the common ways people in the worlds of business, government, science, and technology handle large writing projects.

    Assembling the team

    When you begin picking team members for a writing project in a technical writing course, choose people with different backgrounds and interests. Just as a diverse, well-rounded background for an individual writer is an advantage, a group of diverse individuals makes for a well-rounded writing team.

    If you are the team leader, you might even ask prospective team members for their background, interests, majors, talents, and aptitudes. These following writing teams combine individuals with diverse backgrounds and interests:

    Project: A report on current cloaking technologies
    Team members Backgrounds, skills, interests
    Shawn S. Electrical engineering major, currently doing basic office-management chores at a law firm
    Tracey K. Senior English major, hoping this course helps with employment prospects
    Sanjiv Gupta Computer science major, currently doing computer graphics at a software development shop
    Jeon Chang Yeon Soon-to-be electrical engineering major, still developing English language skills
    Alice B. Undeclared major with a nontechnical focus, possibly in the wrong course, no stated skills

    Writing Team 1

    Planning the project

    Once you've assembled your writing team, most of the work is the same as it would be if you were writing by yourself, except that each phase is a team effort. Specifically, meet with your team to decide or plan the following:

    Planning Stages
    • Analyze the writing assignment.
    • Pick a topic.
    • Define the audience, purpose, and writing situation.
    • Brainstorm and narrow the the topic.
    • Create an outline.
    • Plan the information search (for books, articles, etc., in the library).
    • Plan a system for taking notes from information sources.
    • Plan any graphics you'd like to see in your writing project.
    • Agree on style and format questions (see the following discussion).
    • Develop a work schedule for the project and divide the responsibilities (see the following).

    Much of the work in a team-writing project must be done by individual team members on their own. However if your team decides to divide up the work for the writing project, try for at least these minimum guidelines:

    • Have each team member responsible for the writing of one major section of the paper.
    • Have each team member responsible for locating, reading, and taking notes on an equal part of the information sources.

    Some of the work for the project that could be done as a team you may want to do first independently. For example, brainstorming, narrowing, and especially outlining should be done first by each team member on his own; then get together and compare notes. Keep in mind how group dynamics can unknowingly suppress certain ideas and how less assertive team members might be reluctant to contribute their valuable ideas in the group context.

    After you've divided up the work for the project, write a formal chart and distribute it to all the members.

    Screenshot 2020-06-19 at 15.30.51.png

    Figure \(\PageIndex{1}\)

    Scheduling the project and balancing workload

    Early in your team writing project, set up a schedule of key dates. This schedule will enable you and your team members to make steady, organized progress and complete the project on time. As shown in the example schedule below, include not only completion dates for key phases of the project but also meeting dates and the subject and purpose of those meetings. Notice these details about that schedule:

    • Several meetings are scheduled in which members discuss the information they are finding or are not finding. (One team member may have information another member is looking everywhere for.)
    • Several meetings are scheduled to review the project details, specifically, the topic, audience, purpose, situation, and outline. As you learn more about the topic and become more settled in the project, your team may want to change some of these details or make them more specific.
    • Several rough drafts are scheduled. Team members peer-review each other's drafts of individual sections twice, the second time to see if the recommended changes have worked. Once the complete draft is put together, it, too, is reviewed twice.
    Individual prototypes due October 1
    Team meeting: finalize the prototype October 1
    Rough-draft style guide due October 5
    Team meeting: finalize style guide October 5
    Twice-weekly team meetings: progress & problems October 5-26
    Graphics sketches due to Jim October 14
    Rough drafts of individual sections due October 26
    Review of rough drafts due October 28
    Team meeting: discuss rough drafts, reviews October 28
    Update of style guide due from Sterlin October 31
    Revisions of rough drafts due to reviewers November 3
    Final graphics due from Jim November 5
    Completed drafts to Sterlin: final edit/proof November 7
    Team meeting: review completed drafts with final graphics and editing November 12
    Completed drafts due to Julie for final production November 15
    Team meeting: inspection of completed project November 15
    Project upload due to McMurrey November 16
    Party at Julie's November 19

    Schedule for a team writing project

    When you work as a team, there is always the chance that one of the team members, for whatever reason, may have more or less than a fair share of the workload. Therefore, it's important to find a way to keep track of what each team member is doing. A good way to do that is to have each team member keep a journal or log of what kind of work she does and how much time she spends doing it.

    At the end of the project, if there are any problems in the balance of the work, the journal should make that fact very clear. At the end of the project, team members can add up their hours spent on the project; if anyone has spent a little more than her share of time working, the other members can make up for it by buying her dinner or some reward like that. Similarly, as you get down toward the end of the project, if it's clear from the journals that one team member's work responsibilities turned out, through no fault of his own, to be smaller than those of the others, he can make up for it by doing more of the finish-up work such as typing, proofing, or copying.

    Setting up a style guide or style sheet

    Because the individual sections will be written by different writers who are apt to have different writing styles, set up a style guide in which your team members list their agreements on how things are to be handled in the paper as a whole. These agreements can range from the high level, such as whether to have a background section, all the way down to picky details such as when to use italics or bold and whether it is "click" or "click on." See the excerpt from a project style sheet in the following.

    Before you and your team members write the first rough drafts, you can't expect to cover every possible difference in style and format. Therefore, plan to update this style sheet when you review the rough drafts of the individual sections and, especially, when you review the complete draft.

    Highlighting
    1. Use bold for interface elements that function like commands (for example, the Exit button).
    2. Use bold for menu options that get you to commands (for example, File>Open).
    3. Use the > symbol to abbreviate menu traversal.
    4. Use Courier New for example text that users type in (for example, myfile.doc).
    5. Use italics for variables--placeholder text for which users substitute their own information (for example, filename.doc).
    Hyphenation
    1. Individual words. Turn automatic hyphenation off. Do not hyphenate words except in tight places like tables or graphics.
    2. Compounds. Mr. Hyphen (Sterlin) will keep the hyphenated-compounds list. Use only those in his list, and submit new ones to him for approval and inclusion on the list. (Hyphenate compounds only for approval and inclusion on the list. [Hyphenate compounds only when they modify (for example, "back-up copy"), not when they act as nouns or verbs (for example, "to back up your files.")]
    Terminology
    1. Use only the words in graph_project.dic. Sterlin approves all new words for that database.
    2. Use the same word for the same object, same process, or same action. No elegant variation, please!

    Excerpt from a style guide for a writing project. The items listed represent agreements team writers have made in order to give their paper as much consistency as possible.

    Reviewing drafts and finishing

    Try to schedule as many reviews of your team's written work as possible. You can meet to discuss each other's rough drafts of individual sections as well as rough drafts of the complete paper.

    A critical stage in team-writing a paper comes when you put together into one complete draft those individual sections written by different team members. It's then that you'll probably see how different in tone, treatment, and style each section is. You must as a group find a way to revise and edit the complete rough draft that will make it read consistently so that it won't be so obviously written by three or four different people.

    When you've finished with reviewing and revising, it's time for the finish-up work to get the draft ready to hand in. That work is the same as it would be if you were writing the paper on your own, only in this case the workloads can be divided up.


    This page titled 5.10: Strategies for Peer-Reviewing and Team Writing is shared under a CC BY license and was authored, remixed, and/or curated by Tiffani Reardon, Tammy Powell, Jonathan Arnett, Monique Logan, & Cassie Race.

    • Was this article helpful?