User talk:Macowell/Registry Development meetings

From 2007.igem.org

08-01-07

Randy: Not providing good enough online documentation and educational materials so that the community does not use the registry in the way we wish, because they don't understand, is a core problem. (And relates to the problem of a significant amount of the community not using the registry "correctly", being "out to lunch", conceptually not getting it, according to randy per monday.) We need the quality of the information that comes from the students to be better.

So I'm having this realization that the best way to address this is to move the registry to an environment that supports a much larger staff, in a more "industrial" position, such as the broad institute or something like that (no elaboration on how to do this transition)

But what do we do in the short term? One plan is to deal with the parts sent in by the teams as usual (duh, we need to do something). Or we could pick just some areas and provide a good example there (Randy's talking about improving the documentation of part typed, i.e. protein coding region parts - and that we need to overhaul the organization / categorization of parts & devices, and bulk up the documentation that defines each category.)

TK: I agree. It's sort of like what I was talking about with cherry picking the parts. It's not that the parts that are not picked are necessarily worse than the parts that are, but that we simply need much better quality parts & documentation, and we can't do them all to begin with.

Another fairly large project, but one that could pay of substantially towards increasing the quality of submitted parts, would be to establish an SB lab manual, particularly full of protocols for characterizing the parts.

Randy: [On Openwetware] These open communities are cool because you pick up outliers, but, for instance, remember the prefix & suffix issue - these communities talked a lot about it, and someone went and edited it up, and then got it wrong (not sure what the issue was). So I think if we have one centralized registry we should canonically or authoritatively establish in a central list the facts about our community.

Part Promotion

• Perhaps email the teams and ask which of their parts they want to be considered by the part promotion committee (need website/registry mechanism, not email)
• There should also be a mechanism when we contact these teams to ask them what parts they didn't develop but really wish they had.
  • More generally, to collect information about what the teams wish they had - what tools, parts, whatever

What we need

• A library of generally-useful, high-quality parts
  • a way to get ideas from the community
• Part promotion process
• Mechanism to reward well-built & well-characterized parts
• A part & device most-wanted wishlist (hopefully interested parties - iGEM teams, labs, JGI, etc - might actually make some)

Randy: My primary goals are to

• not let the Registry "fail/go out of business" - it's a 10-20% chance
• Make sure the registry serves the iGEM community (doesn't lose focus, doesn't pander to all sort of other psuedo-users, i.e. people who are interested but don't actually use or depend on the registry)
• Promote education of SB

Randy: "Originally we were concerned with the sequence quality of the parts. We didn't think we could do all the parts, which led to the idea of tom identifying a list of a couple hundred or so parts to focus on..."

"I think something we have been trying to do is enable the community to do a lot, when in fact the community doesn't function. I think we have to stop trying to enable that, that... I believe we have gotten ourselves into a position where we are a little stuck, because we haven't been very productive. [Scott: We need to provide better examples] - I believe in fact they will not follow good examples, some of them... the thing tom has been suggesting is a break into two sort of registries, a registry for the students, and the professional registry. [Scott: reputation-based motivation to make good parts, follow good examples] My view is that we are running the teams like a class in which the TA is out to lunch, that their are no progress reports or midterm exams, and that there is only one final exam. (and the performance isn't good). All of this stuff about what we should do is actually leading me in the opposite direction, that the key thing we should probably do is have a high quality registry, in which we don't give out the part number until the part has passed through the quality filter. And then we have a different thing, the iGEM registry, where they (the igem teams) can do things, and then propose parts that go into the real registry, very explicitly with example."

"Our ideas of 'the community will do it', 'of open source things', made us think before that any effort we put into having a central registry is wrong." (This seems like a dangerous position)

Agreement: We have to focus on what the community wants now, and not what we think they'll want, and what we want, in the future (in 5 years).

Scott: "when you're overloaded you have to do triage."

Randy: "We have proven we cannot build a community, so we cannot count on that community to do anything for us. Also, I think the registry is pretty good. It does things much different than other similar online services. I think we should do the 10-15 little fixes we just know we need to do."