User:Macowell/Registry Development meetings

From 2007.igem.org

< User:Macowell(Difference between revisions)
(→Action Items)
 
Line 164: Line 164:
MC:
MC:
 +
* Documentation screen guidelines
* Podcast: explain the whole process (w/ Izadora)
* Podcast: explain the whole process (w/ Izadora)

Latest revision as of 15:37, 6 August 2007

Contents

08-01-07

Crystallization of goals for Short Term: Do the things within our reach to make the registry better and make the iGEM teams more successful.

Registry

To do this, we need to have a good picture and understand how the teams are doing, how they are working, how they are using the registry now.

  • Devices & Systems - unclear to teams what they do with the big parts of their projects
    • if you make a project, what part type/device/category is that; imagine a "projects done by iGEM teams" page or table on the registry
    • have a "rethink Devices & Systems" meeting
  • Featured parts - Focus on the next user
    • perhaps ask team to make an abstract for logical sets collections of their parts that could be used in the featured part page; perhaps related to Devices & Systems
  • Favorite part button - don't overhaul part promotion process, just simplify process of making parts "favorited"
  • Tools: Sequence analysis 90% done; teams could use it to verify their parts quickly by uploading their sequencing runs to the registry
  • Documentation of parts - need guidelines; (and must make sure they are effective; randy thinks they won't be "by themselves")
    • Need published guidelines for doing good documentation
    • Need clear incentive for team to make good documentation for its parts
    • Need clear examples of good documentation & bad documentation
    • Rework part types (back to the devices & systems)
  • Part Promotion Process - Quick fix by tying it to the favoriting process, or spend 1.5 weeks building the real promotion mechanism?
  • Part DNA
    • Acquisition of DNA - how do we optimize getting it
    • Sequence analysis

iGEM Teams

  • Psuedo Ambassador Program - everyone acts as an ambassador to their own subset of all the teams, figuring out what their status & progress is
    • Have meeting twice a week to review, decide how to help
  • Silent teams - figure out what teams are "silent"
    • intervention

08-03-07

Today's topics are: 1. draft workflow of part promotion process 2. list of structured data commonly curated for protein coding regions in other databases.

(Ask randy what he means when he says the community can't afford for us to try and develop a web of registry)

Action Items

  • All: Think about effort and timing of part lifecycle; Imagine the workflow in as great a detail as you can and then identify the hotspots and points of failure you think they would encounter. Bring this to Monday's Meeting.
    • What would a BioBrick Note like? Where would it come from? A wiki page? A PDF in D-SPACE?
  • All:Imagine how to identify (the few) iGEM participants that would be likely to continue to be proactive and stay involved as alumni.
  • Mac: examine 10 other bioinformatics databases and determine common span of extra info about CDS / protein coding regions

Preliminary Part Lifecycle

  1. Sandbox (supports 'favorites' organization)
  2. Submitted for review (necessary for jamboree)
    1. Documentation screened for completeness
    2. DNA sent to registry
  3. Accepted (for Judging at Jamboree, for review by Editorial Review Board)
  4. Reviewed - reviews published in biobrick notes
  5. Confirmed - it's high quality and in successful usage (perhaps graduates to BioBrick Review Journal)

Part Promotion Process

  • Identify and provide High quality parts (sort them out, make them explicit, separate from rest of parts)
  • Provide high quality parts (do things necessary to take lesser parts and make them better). Incentivize part documentation process.

TK: How do teams typically work on parts? What is the lifecycle of a part?

  1. System Idea - plan for the project
    1. what do we have to work with? What's in the Registry?
  2. Idea for a part that inevitably isn't available (subpoints cyclic)
    1. included Literature search, usually
    2. Design for a part
    3. Make good documentation based on idea, understanding
    4. Get DNA, Verify DNA, (Send to Registry eventually) - good feeling reward also occurs here.
  3. Functional expression experience
  4. System Functionality experience
    1. Reward here: Paper publication, maybe poster

Randy's paper lifecycle list:

  1. Get idea
  2. Do research
  3. Get result -> give talks, posters
  4. Decide to write paper
  5. goof off / delay
  6. deadline
  7. draft
  8. make draft better (informal peer review)
  9. submit paper (this process is cyclic):
    1. paper into queue
    2. assigned to reviewers
    3. get comments
    4. make changes
  10. published

Randy's Technical Standard lifecycle list:

  1. ideas + desires
  2. proposal for standard
  3. official working group forms
  4. meetings, drafts 1, 2, 3, 4...
  5. review period
  6. voting to accept
  7. publish
  8. post-published modifications

When do people submit information to Genbank or PDB? Not because they just feel like it - because doing so is required to get their publication, because it is tied to their reward.

We can leverage our own reward system by highlighting the judging of parts at the jamboree and by establishing The Annual Proceedings of Standard Biological Parts, which should get a kick start from establishing the part review board.

We need to clarify the part submission process not so that it only takes 2 minutes, but so that each data field is explained, logical, and makes sense - even if that adds a bit more time.

TK: We want to be collecting the needs of the community, and if that includes things that the community can't build, we need to try and save that. We capture this right now in the form of unbuilt parts, but they frankly are not parts... they are ideas. Maybe we shouldn't be treating them like parts and asking people to use the registry to define it as a part before being successful with it.

Names for promoted parts:

  • Verified, Certified
  • Silver, Platinum Gold
  • Proposed parts, Designed parts, Constructed & Sequenced parts, or Fabricated, or Built
  • Perhaps just use Stages or Levels: stage 1, stage 2, stage 3... Level 1, Level 2, Level 3
  • Conceived, Designed, Fabricated, Available, Reviewed / Certified

protein coding region structured data

Do homework about protein coding regions and figure out what structured data might be appropriate.

  • For instance, we don't carry info for parts such as: this coding region came from yeast, or e. coli - there is probably a list we can make by looking at the span of structured data collected in other databases.
  • Madrid guys have a cool way of showing related info for proteins...
  • Most important structured data: three most useful papers for understanding this system (TK). Maybe capture the DOIs?
  • Ask John from Science Commons his perspective (other experts?)

08-06-08

Preliminary Part Lifecycle v.2

  1. Sandbox (supports 'favorites / selected' organization)
    • buttons to optionally hide sandbox from world
    • "Teams do whatever" - lots of debris in the sandbox
    • "Favorites / selected" - helps teams organize the parts they are interested in actually making & sending to the registry
    • Sandbox page should act like a dashboard. 3 tables: Submitted parts, Selected parts, and All parts. Selected parts should be any parts from anywhere in the registry the team is interested in using, including it's own parts. Parts need to have a button that lets teams make them selected. Submitted parts are to be reviewed.
    • TK: The path between Favorites to submitted should be painless for people with well designed parts that want to add them to the registry
  1. Submitted for review (necessary for jamboree)
    1. Documentation screened for completeness - status of this presented w/ part in dashboard somewhere
    2. Documentation screen
      1. Completeness
      2. Categorization
      3. References
      4. Source
      5. MTA, Patents
      6. Design Notes
      7. Experience (yours)
      8. Standards Compliance
    3. DNA sent to registry - status of this presented w/ part in dashboard somewhere
  2. Accepted (for Judging at Jamboree, into queue for Review Board)
    1. part gets one star of excellence
    2. may need another button to indicate that the team intentionally requests the part be Reviewed
  3. Reviewed - reviews published in biobrick notes
    1. Part gets two stars of excellence
    2. Documentation good
    3. Motivation for making part and utility of part clear
    4. Some evidence that it works
  4. Confirmed - it's high quality and in successful usage (perhaps graduates to BioBrick Review Journal article, which publishes articles about parts being used together; systems.)
  5. Part gets three stars of excellence
    1. Documentation good
    2. Utility is clear
    3. Proven to work and is measured / characterized

Action Items

All:

  • Categorization

TK:

  • Write BioBrick Notes #0
    • What does it take to make one of the BB notes worthy of putting on your resume?
    • How do BB notes get updated?
  • Determine documentation of existing standards

RR:

  • write down complete part submission process

ML:

  • Structure of DNA submission form & button, what info is needed:
    • Plasmid, cell strain, standard used...

MC:

  • Documentation screen guidelines
  • Podcast: explain the whole process (w/ Izadora)
Retrieved from "http://2007.igem.org/wiki/index.php/User:Macowell/Registry_Development_meetings"