Summary of Meeting
There were 3 major things decided at the meeting.
- Labs that are interested will be added by a one-by-one basis. Labs outside of MIT are allowed to join. There will begin being a requirement, especially for any newly added labs, that they put up contact information for each user.
- The server will be switched to the BioMicro Center. openwetware.org and .com will point to this new site. openwetware.mit.edu will continue to be operational.
- We will add the Enotif extension when we switch servers.
A proposed meeting to discuss future issues that are pending for OpenWetWare.
The current pending issues to discuss include:
- Should people from outside of MIT be able to join OpenWetWare?
- Should we move the server and upkeep to the BioMicro Center?
- How can we better organize the information on the Wiki? E.g., do we need an organizational editor?
- Can we combine the resources of the Wiki with email- or IM- or RSS-based messaging (so that folks can quickly ask questions and get answers)? Will this debase the need to add information into the Wiki?
Time/Date and attendance
Thursday, 8/11/05, 4pm -- Room 68-574
- Drew Endy
- Jason Kelly
- Sri Kosuri
- Ilya Sytchev
- Jeff Gritton
- Amy Keating - for ~1/2 hour
- Kathleen McGinness (not sure how long I can stay, but would like to put my 2 (4, 6, 8,...) cents in)
- Austin Che
- Jay Copeland
- Jennifer Braff
- Sean Clarke
Scope of OpenWetWare
There has been interest by groups outside of MIT to join OpenWetWare. The question we should consider is whether we should begin allowing participation by individual labs outside of MIT.
- There are a number of labs that have expertise in areas that relate to any of the individual labs. It seems that combining those resources would provide an even greater resource for ourselves and to the greater community.
- The alternative is the rise of a number of disparate communities. This seems foolish at it fragments the user base, ends up in tons of recapitulated effort.
- The wiki structure is morphable enough to easily organize and accomodate hundreds if not thousands of labs (see wikipedia).
- The success of a wiki is largely dependent on achieving a critical mass of motivated contributers - increasing the number of participants improves our chances of finding these contributors.
- There is a possibility in the future that too many labs that are physically separated will make it become hard to find useful information to any one group. The nice part of having it be all MIT, is that for example, if there is a piece of equipment listed, we know it belongs to a lab here.
- This is a definite possibility. If we do open it to outside groups, there will be an increased reliance on a larger group of people than currently exists that update and actively change the organization of information.
- We lose the MIT branding of the site. Outsiders looking at the information presented won't really know where that information came from and possibly would trust it less.
- There is also an opportunity cost for MIT researchers by not allowing others to join that is far larger than any cost to others looking at the site from the outside
- Once we start adding friendly labs, it will become impossible to justifiably prevent any other lab from joining. Even those labs that certain labs on OpenWetWare have scientific controversies with. Those original labs dilute their story by having to share space with their enemy labs.
- One could easily create their own spaces for the two competing camps. The interesting thing that may come out of a larger community is that often these controversies are due to lack of reasoned communications. The Wiki may be a good place for that.
We think that as we expand, it may behoove the community to switch to faster, more reliable hardware. Currently, we are running OpenWetWare on an over 5 year old server. The usage on the server has been growing at quite a clip. It may help us to move over to a faster server, more backups, and more reliable service. That being said, we have had zero problems so far with reliablity, speed, or administration.
- Faster computers
- BioMicro handling fixes
- More backups
- Redundant power and cooling
- System monitoring
- If it ain't broke, don't fix it.
- The easiest way to implement this would cost us to lose model.mit.edu IP address. That said, the only things that now point to this server are broken links. In addition, no one really uses labbase or other things.
Organization & Editing
We've a lot of new groups adding and editing information on the wiki. The search function is grossly imperfect (i.e., it sucks). Thus, it is sometimes hard to find stuff via the built-in text search, even if you 100% know that it's in the Wiki! Should we have a single protocol page? Should we have a single equipment page? One simple mechanism for doing this would be to (a) change nothing but (b) add an editor who would search the Wiki and drive the development of meta-pages. One more complicated mechanisms for doing this would be to switch over to a more structured "engine" that would support the organization of protocols and so on. Squid Lab and PLoS are starting to work on something like this, and would like us to beta-test it when it's ready Endy 11:15, 10 Aug 2005 (EDT)
- My concern about an 'editor' who would be responsible for developing meta-pages is that it adds a bottleneck to development of those pages. (i.e. If I want to add something to a meta-page, I may now feel that it should be run by the editor first. Or, worse, I may not even consider improving meta-pages because that is the 'job' of the editor.) I do think that users will need to actively push to aggregate information in the most productive ways, but this should happen at many levels.
Sometimes, it's useful to be able to ask "everybody" whether or not somebody has a plasmid, a reagent, or a piece of equipment. Right now, MIT Bio does not have an active mailing list (that the faculty know about) for doing stuff like this. Is there some way to combine the "power of the Wiki" with an email list, IM system, or RSS-feed to pull this off? Should we? Endy 11:18, 10 Aug 2005 (EDT)
- As long as there is a way to remove yourself from the email list, this would be a good idea. Potentially it could be combined with the Help forum page, and wiki folk could "subscribe" to the help email list. Simultaneous wiki posting and emailing would be best. Especially because sometimes it's hard to see what has been added to something (like this page!) without checking the history. --kathmc 12:11, 10 Aug 2005 (EDT)
- Is there any way to associate emailing with the watchlist function?--kathmc 13:22, 10 Aug 2005 (EDT)
- Still another idea would be to have a "chat room" function, where you could type live text via a window associated with the Wiki.
- Not so sure about chat rooms, IM, etc. Those require you to be "logged on", don't they? At that point, things might as well just be posted on the wiki if you have to check them all the time. To me, email sounds like the best option because people typically check their email several times a day for other reasons. Seems like a less wiki-centric option to me that will be likely to get the quickest response, since wiki participation amongst members will be variable. You could still set up a chat room for the "hard core" OWWers if you think this would provide resources not already provided by the wiki.--kathmc 14:29, 10 Aug 2005 (EDT)
We decided to open the wiki up to other groups local to MIT and that openwetware was not a crappy name.
Before we bring other labs on board we decided that it would be good to have an example of a protocol page (or several pages) as we would like to see them develop. The (somewhat of a) consensus on this was:
- A general page such as DNA Ligation which gives background information as well as a version of the protocol where each step is explained with the relevant biology. Also, the "biological lore" which is usually not written down in standard protocol books could accumulate on this page. The version of the protocol on this page could be imagined as stepping towards a "standard" protocol or be imagined as a beautiful information resource about the biology behind the steps, depending on your philosophy.
- Links within that page to individual (or user) protocol pages. This will enable labs/users to be more likely to participate/view the general page and would be a source to glean information to be put into the general page (such as identify points where the protocols differ).
To Do list: (before inviting labs):
- Perfect the DNA Ligation protocol (and some others)
- Make a good openwetware front page
- Put my/sri's comments on Talk:Main Page
- Add an "ettiquette" type of page
- Done: Etiquette -- need to work on formatting of this page.
To Do list: (additional ideas): --Reshma 11:29, 27 Jun 2005 (EDT)
- Develop a logo to replace the media wiki logo in the top left corner of each page (perhaps just a simple OWW from the logo on the Main Page).
- Been working on it. I have one that might work perhaps. I'll put up a few options. --Sri Kosuri 11:49, 27 Jun 2005 (EDT)
- Add a redirect from the old Endipedia site to the new OpenWetWare site.
- There already is one:  --Sri Kosuri 11:49, 27 Jun 2005 (EDT)
- Perhaps there should be a redirect from http://model.mit.edu/endipedia/index.php?title=Main_Page as well? --Reshma 12:18, 27 Jun 2005 (EDT)
- There already is one:  --Sri Kosuri 11:49, 27 Jun 2005 (EDT)
- Add a google search of OpenWetWare pages only to the Main Page to improve search functionality.
- This might take some hacking. We also should change the sidebar on the left. --Sri Kosuri 11:49, 27 Jun 2005 (EDT)
Also, we gave some thought to a stable lab protocol resource, potentially independent of the wiki. I think this could potentially be useful but needs to be better specified. For instance, I think that Endy:Protocol could serve a similar purpose and live on the openwetware wiki. We could then create a locked version of these once a year (or whenever) to be sued locally by people who wanted a stable resource.
I will also be adding the BEiNG (biological energy interest group) front page in next couple days, and give them user access on Monday of next week. I don't think they will be creating many protocols at least to start; they'll probably just be adding content to their space. --Jasonk 20:11, 22 Jun 2005 (EDT)