Difference between revisions of "Project Transparency"

Line 110: Line 110:
 
Please take note of the <a href="https://2015.igem.org/Wiki_Requirements#perspective">Perspectives from an iGEM veteran</a> that Ana from iGEM HQ wrote as a former team member on an iGEM team. Ana's suggestions are focused on the team members building and maintaining the wiki, and we recommend all teams follow her advice!  
 
Please take note of the <a href="https://2015.igem.org/Wiki_Requirements#perspective">Perspectives from an iGEM veteran</a> that Ana from iGEM HQ wrote as a former team member on an iGEM team. Ana's suggestions are focused on the team members building and maintaining the wiki, and we recommend all teams follow her advice!  
 
<br><br>
 
<br><br>
−
Another member of the iGEM HQ team, Traci, had a few suggestions to add. Traci was the team mentor and instructor for the 2011-2014 Boston University teams, so her perspective is from running an iGEM team.
+
Another member of the iGEM HQ team, Traci, had a few suggestions to add. Traci was the team mentor and instructor for the 2011-2014 competitions, so her perspective is from running an iGEM team.
−
 
+
<br>
 
<div id="kcontainer1">
 
<div id="kcontainer1">
 
<h4>1. Assign weekly tasks for the wiki during lab meetings</h4>
 
<h4>1. Assign weekly tasks for the wiki during lab meetings</h4>

Revision as of 19:25, 11 June 2015

Learn about how to increase your project's clarity here!

  • Read about some general Wiki Tips, including the new changes for the 2015 season
  • Learn about the importance of making sure that your Project Overview is clear and concise
  • Get ideas on how to clearly explain your Project Design and Project Results to your audience
  • Think about adding a specific page listing your Medal Criteria Checklist so judges can quickly reference the page if necessary
  • Get some advice for presenting your Poster at the Giant Jamboree

Introduction

Every year, we have excited team members reach out to the staff at iGEM Headquarters asking us questions about how their project will be judged and if certain items will qualify them for medals. We have created this page as a part of our effort to be more transparent about the judging process and to give teams some ideas on how to improve the clarity of their projects.


The goal of this information is to help teams understand the importance of scientific communication in terms of explaining their work to a larger audience and documentation as it pertains to the iGEM competition for medals and special prizes for the 2015 season. The majority of this advice is centered on the team wiki, but these suggestions should also tell you the type of information the team might want to consider including in their presentations.


General Wiki Tips

Everyone involved with your iGEM team should make sure to read through the iGEM Wiki Requirements and the new material on Standard Wiki Pages for the 2015 season. Making sure that you follow these requirements should not be the responsibility of only a few team members, but rather a shared responsibility throughout the team, including the advisors and mentors.

Remember, your team wiki is a public page and should show of all of your hard work! Everyone on the team should take pride in the wiki and we recommend that everyone on your team help contribute some material for it.

Avoid using copyrighted images! Use original content as much as possible to avoid running into copyright problems.

Please take note of the Perspectives from an iGEM veteran that Ana from iGEM HQ wrote as a former team member on an iGEM team. Ana's suggestions are focused on the team members building and maintaining the wiki, and we recommend all teams follow her advice!

Another member of the iGEM HQ team, Traci, had a few suggestions to add. Traci was the team mentor and instructor for the 2011-2014 competitions, so her perspective is from running an iGEM team.

1. Assign weekly tasks for the wiki during lab meetings

As we all know, team mentors and advisors are invested in their team's project. Remember, a large part of an iGEM project is the team wiki! As a team instructor, I helped students decide on weekly tasks and assignments for the content for their wiki during our regular lab meetings. I often told students to work on the content while they waited for reactions to finish or gels to run in the lab, which seemed to work nicely.

2. Instructors and mentors should be proofreaders for the wiki

As your team creates content and posts it on their wikis, you should make sure to take some time each week to read through the wiki and ensure the content has been proofread for typos, clarity, and accuracy.

3. Assign specific pages to specific people

Ideally, each team member will be creating content for the team wiki with a smaller group responsible for editing the wiki and posting the content to the page. To avoid confusion and possible deletion of content, you should make sure the editing of each page is specifically assigned to one person.

4. Updates done on the Wiki Freeze Day should be minor edits

Every team around the world will be editing and updating their wikis on September 18th. I strongly urge you to only make minor edits and update figures on Wiki Freeze Day. I recommend that the vast majority of your content should be on the wiki a full week before the Wiki Freeze so you have plenty of time to read through everything and make sure you haven't missed any critical item. This will greatly reduce the stress on your team members!



Project Overview

Having a brief, well written project overview is a huge help for anyone interested in reading about your project. The overview should only be a few paragraphs in length and often teams will include a cartoon or diagram to accompany their overview. Ideally, the overview should be understood by scientists and non-scientists alike. We also recommend that you have pages with detailed descriptions for each part of your project, complete with references and links to your results.


Recommended Components for a Clear Overview Page

  • State the Problem: Very briefly, state the problem you are attempting to solve in non-technical terms.
  • State the Solution: Describe how you plan to approach and solve this problem at a high level.
  • List the Goals: If appropriate, briefly give your project goals that will help you achieve your solution. Try to avoid getting into a lot of details.
  • Link to Details: Add links that will take people to the more detailed description of your project, the problem, and your solution. These are sometimes included in the text, shown as drop down menu options, or are links within images.

    • Examples of Well Written Overview Pages


    Overview illustration from the 2013 SYSU China team

    Below are a handful of well done project overviews. These examples show different ways that the project overview can be done on the team wikis. These are all concise, well-written project overviews with links to more detail.

  • 2014 Valencia Biocampus
  • 2014 MIT
  • 2013 SYSU China
  • 2013 Paris Bettencourt
  • 2012 Purdue
  • 2012 Westminster

    • Project Design

    Project design pages should be where you delve into more details about the genetic devices, software, hardware, and anything else you intend to work on and build over the course of your project. You should highlight design elements that are inspired by previous work (and cite the work!) and discuss if you are creating a new DNA part or using a DNA part in a new way. Often, teams will include a diagram of their genetic circuit layout, the GUI design for their software interface, or a schematic of the hardware they're creating, among any other design elements that went into the project. The list of components below focuses more on wet lab teams.


    Recommended Components for a Clear Design Page

  • Show Your DNA Part Design: You should use graphics and text to clearly describe your DNA Part design and where the inspiration for that part and/or design came from, if it's from any sort of previous work (iGEM project, research article, etc.).
  • Cite Previous Work: If you are inspired by previous work of any kind, make sure you cite the work properly. Likewise, if you show images from research articles, make sure they are attributed properly.
  • Graphics Should be Clear: When using any graphics to show your design, make sure the colors and font can be easily seen by everyone. Avoid excessive use of reds and greens in your graphics. Loopy or overly creative fonts can also make it difficult to understand an informational graphic.
  • Sections for Different Elements: If your project has multiple design elements (such as an input biosensor, an output device, etc.), you should keep the design for each of those elements clearly separated, either by having multiple design pages or having clearly defined sections within one page.

    • Examples of Well Done Design Pages


    Software design example from the 2012 Wellesley HCI team

    Below are a handful of well done project design pages. These range from wet lab teams to hardware projects to software designs. These highlight the vast range of ideas and projects undertaken by iGEM teams and should highlight different ways that designs can be conveyed to the general public and to the iGEM judges.

  • 2014 Aachen
  • 2014 UC Davis
  • 2013 SYSU China
  • 2013 Tokyo Tech
  • 2013 Berkeley
  • 2012 Wellesley HCI

    • Project Results

    Make sure you post your results clearly on you wiki! It may sound like an obvious statement, but sometimes teams can forget to clearly state how their experiments ended and discuss what they concluded from that work. It's not enough to post your experimental details in your online wiki notebook - you need to have a section devoted to the results of your work on your wiki.

    We strongly recommend that the results of your work should be posted on your wiki using your assigned standard Results page (https://2015.igem.org/Team:Example/Results). You will want to include a link to this page in your wiki navigation so it's easy to find to someone who will be seeing your wiki for the first time. Finding the team's results can sometimes be challenging when there isn't an obvious button or dropdown menu item on your wiki that is labeled "Results". You want your judges to find the results of your hard work, so make sure it's easy to find the page!


    Recommended Components for a Clear Results Page

  • Restate the Goal: Remind the reader what the particular goal is that you're working towards in a brief phrase or sentence.
  • Summarize the Results: Quickly list or summarize your results for that goal.
  • Show Experimental Data: You will need to display the data that gave you this result. This should include some information about the experiment run or provide a link for full details about the experiment.
  • Links to More Detail: Provide links that can take your reader to a page with more detail on those results, which would most likely include information on how the data was obtained and how you interpreted the results.


    • Examples of Well Written Results Pages


    Results example from the 2013 Paris Bettencourt team

    Take a look at the example Results pages below. These examples represent just a handful of teams who implemented a clear, concise Results page. It can be a difficult task and will take careful planning and hard work to execute it well. These teams all have some variation of the components given above in their pages.

  • 2014 Imperial
  • 2014 LMU Munich
  • 2014 SDU Denmark
  • 2013 TU Munich
  • 2013 Paris Bettencourt
  • 2012 Cornell

    • Medal Criteria Checklist

    Another page teams should consider having on their wikis is a Medal Criteria Checklist page. This is not one of the new standard pages, but we recommend teams create one and have it easily visible for the judges to find.


    Recommended Components for a Checklist

  • List the Requirements: For each medal that you are trying to achieve, re-list the requirements for that medal. It will help you remember the checklist as well as help people read through the list.
  • Add Checkmarks to Completed Tasks: For each item you believe you have completed, mark it in some way. Many teams include a check mark or something similar a they go down the list of requirements.
  • Link to the Relevant Pages: Within the text of each list item, if you have a page you can link out to, then include it. Some of them will not have links (ex: Register a team for iGEM in the Bronze medal requirements). For your Bronze, Silver, and/or Gold medal part requirements, you should include a link to the direct Registry page for your part.
  • Document Your Registry Pages: One of the major criteria for convincing the judges that you tested your part and showed that it is functional is the data that should be posted on the part's Registry page. It is not enough to just post it on your wiki - this data must be included on your Registry pages!

    • Examples of Medal Criteria Pages


    Gold medal checklist from the 2014 BostonU team

    Below are a handful of ways that teams have highlighted their work towards the medal requirements. The chosen teams were all awarded gold medals during the competition and were chosen because they showed a completed checklist of items for their year.

  • 2014 BostonU
  • 2014 Aachen
  • 2013 ETH Zurich
  • 2013 Manchester
  • 2012 UNITN Trento
  • 2012 UC Chile

    • Poster Presentation

    Below is some general advice for teams to consider as they start preparing their poster presentations. This does not mean other methods of discussing your poster are discouraged; but rather, these are just some ideas that we hope you think about, particularly if you've never presented a poster at a conference before.


  • Prepare Short, Medium, and Long Poster Presentations: Since judges and other attendees are often trying to chat with many teams during the poster sessions, you should practice three different length talks: 1 min, 3 min, and 5 min. It's very easy to get lost in the details of your project and talk with a judge or other attendee for 10 or more minutes, but oftentimes for judges they don't have a lot of time to spare. Try to keep this in mind when they come to your poster.

  • Let People Read Your Poster: When someone new comes up to the poster, ask them if they would like a minute or two to read the poster before you start presenting. Sometimes people are stepping closer to read the poster and other times they have already looked at it during one of the breaks and have come back to talk to you. It's polite to ask if they need some time to look things over before you being discussing your work.

  • Use Large Font Sizes: You should be able to read the poster easily from a few feet away. If you need to be right in front of it to clearly read the text, the font is probably too small. A good way to check font size is this: print a copy of your poster and have it "fit to page" on a standard A4 or 8.5"x11" page, and if you can read the font clearly when you hold it out with your elbows locked, then it will probably be large enough on the poster.