I'm very intruiged by this idea of a github for OERs. Thanks for the denerdification and examples Pat, very helpful. I guess the issue we come back to is the one Greg raised.
"Is it better for everyone to maintain their own versions of OERs, or join them all together?"
And he's right, we don't know the answer yet. I suspect the tendency is still for teachers and learners to maintain their own version of the educational resources they are using but whether that holds true of OERs I am less sure. It's certainly an interesting idea though and definitely worth exploring further.
Cheers
Lorna
________________________________________
From: Open Educational Resources [[log in to unmask]] On Behalf Of Pat Lockley [[log in to unmask]]
Sent: 15 April 2011 16:30
To: [log in to unmask]
Subject: Re: Comments on Mini Projects
As a nice example of github at work please see
https://github.com/cameronmcefee/Image-Diff-View-Modes/commit/8e95f70c9c47168305970e91021072673d7cdad8
scroll down to 1_normal.jpg, then say click on difference, or click on
onion skin and swipe the control along - this shows the differences
between the files, and the github software would know this.
On Fri, Apr 15, 2011 at 4:27 PM, Greg DeKoenigsberg
<[log in to unmask]> wrote:
>
>
> On Fri, Apr 15, 2011 at 11:14 AM, Alex Lydiate <[log in to unmask]> wrote:
>>
>> I second Pat's suggestion to stick everything in Subversion and have done
>> with it :)
>>
>> And if we aren't going to do that, and stay on the Web and all, then lets
>> do this:
>>
>> Greg, you're speaking of versioning, great, if that's what you're after we
>> can do that with OAI-ORE - it supports both the relation
>> thisAggregation->IsAggregatedBy->thatAggregation.
>
> If I were just talking about versioning, we could do everything in RCS, lol.
> No, what I'm talking about is the entire Github experience. The ability to
> easily find stuff that's interesting. The ability to make a complete fork
> of a project. The ability to contact the originator of the project and make
> a request to merge changes back into the original. The ability to reliably
> track provenance in a bulletproof way.
> Of course, the important difference between code and content is the relative
> value of forking. In code, the expense of forking and maintaining a
> usefully evolving codebase separate from the originating project has been
> demonstrated conclusively to be very high, which is why Github is so
> valuable -- whereas in content, the expense of forking and maintenance is
> still indeterminate. Is it better for everyone to maintain their own
> versions of OERs, or join them all together? We don't know. We're still
> guessing.
> --g
|