> I greatly enjoyed your youtube post.  I think you make lots of good
> points, and I'd encourage you to continue to develop these ideas and
> to start to capture them in writing.

Thanks, Greg - sorry for the belated reply here. I've been doing a lot 
of thinking and reflecting on my own work with TOS in the past few weeks 
as I've been working through POSSE South Africa stuff.

> One area that jumps out at me as requiring additional attention is
> the notion of a course catalog.  I think that's the right concept to
> start with, but there are many layers of issue there that make it
> hard to have the impact you might want (e.g., reuse by others)

Hrm. My initial motivation for a course catalog (which Ryan Rix has 
picked up on now - thanks, Ryan!) was actually pretty selfish - I wanted 
a way for *me* (because I'm lazy ;) to keep track of all the TOS classes 
going on, to simplify going around to folks and asking "hey! how is it 
going? can we get you resources? how can we help?" So reuse by others 
would be nice, but is (atm) secondary... scratching our itch comes first.

> 1. Academic culture isn't supportive of contributing resources to
> share, curating collections, or using shared material

I must admit I'm somewhat confused by this point - I thought the 
scholarly tradition was all about building upon the knowledge of others, 
and that people would... collaborate on research and articles, and 
whatnot - and at the same time, there's a sense of centralization and 
not-invented-here syndrome that... puzzles me. How would this be 
something that academic culture wouldn't support? (What would you, as a 
professor - or maybe your administration - rather see instead?)

> 2. Making
> collections visible to potential users and providing effective
> support for finding and retrieving materials is hard.  Even when
> people know about a collection, they're more inclined to Google the
> Web than to go search the collection.

Oh yes. Not sure to get around this one.

> 3. There are issues related to
> the granularity of resources.  That is, collections may be stored at
> one level of granularity, but people want to retrieve at another
> level.  (e.g., the collection stores a course, but you want a
> lecture; the collection stores a lab, but you want an example from
> the lab)

Right now, we have few enough courses in the TOS universe that a 
manually curated wiki page is okay (imo); at some point, when it scales 
beyond what a person can handle, then we'll have a scalability problem 
to solve, but we'll know a lot more about the requirements.

I think about it the same way I'm thinking about POSSE applications; so 
far, every single app has been forwarded to my inbox and processed by 
hand. This way, when Ian sits down and codes posseapp, we know *exactly* 
what repetitive pain points we want to relieve.

Of course, I could be wrong. :) So pushback/suggestions are 
super-appreciated - I'm sure people have done all these things before, 
and would rather not reinvent the wheel.

> All this is not meant to discourage your effort - I think it's an
> excellent step.  But just to point to an area that will require a lot
> of thought down the line.

It is pretty non-scaleable. :) Trying out experiments right now before 
figuring out how to mass-produce a prototype down the line, so we'll 
have more data when that day comes.

--Mel
_______________________________________________
tos mailing list
[email protected]
http://teachingopensource.org/mailman/listinfo/tos

Reply via email to