OpenWetWare steering committee/Community development ideas

Please post any ideas you have about OpenWetWare community development here.

Community Portal

• An improved OpenWetWare:Community Portal would go a long way towards encouraging the growth of the "back-end" user community. We could use the wikipedia community portal as a model.

Seminar Series

• Can embed google video on a site (without even a google logo on it or anything) and they will stream for free, so we could host videos there if we wanted.
• At the last steering committee meeting we brought up looking into the Singapore/MIT alliance rooms that already have the built-in AV equipment.

User pages

• Not sure if this belongs here, but it would be great if we could get people to put at least a small amount of info on their user pages, particularly those who contribute regularly. I think accountability for/credibility of info on OWW kind of depends on this. Otherwise, we should just allow editing to be anonymous. Not too much info is required for this, just a short bit about who they are.--Kathleen
  • We've been trying to encourage this as much as possible. Every email that goes out to a new user includes a line encouraging them to start editing their user page. In fact, with many new users, we put a line on their user page for them when we create the account. However, many of the recent influx of OWW users are BE.109 students, and so I haven't been doing this because they are supposed to put something on their user page as part of their assignment. Regardless, I agree that this is a good idea. --RS

Custom Recent Changes

At the sub-group meeting on 2/22/06, we discussed having the ability to track changes for customized groups of pages. One thought is to have all the possible namespace in the drop-down list on the recent changes site. There are a variety of things we could do, here are just a few to begin.

1. Use Existing Functionality. We can track categories by going to a particular category page and tracking related changes. Thus, the endy lab could have a category of all its pages, and have a link to the related changes page for that category.
   • Advantages
     • Pages can have multiple categories
     • No additional coding (don't have to worry about updates, et cetera)
   • Disadvantages
     • Recent changes page is unchanged. Harder to figure out where to go.
     • Must categorize pages that you want searched. Causes ugly categorization thing at bottom.
       • Is there a way to make categories visible only in the code, not on the page?
2. We can use an existing extension, such as this to encode custom recent changes functionality. What this does is makes a particular page a recent changes page for all pages with a specified prefix. This would, to a first approximation, let us track changes for all the different spaces that material is on.
   • Advantages
     • Don't have to label each page with a category
   • Disadvantages
     • Each page will have only one possible recent changes
     • Won't work with redirects (I think).
     • Could become broken every time we update
3. We could write our own functionality.
   • Advantages
     • Could customize whatever we wanted
   • Disadvantages
     • Lots of work
     • Needs maintenance, yet another thing we need to worry about.

Anyways, let me know what you think --Sri Kosuri