[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Voting [was: Passing UMOs]
2007/1/4, sergey@total-knowledge.com <sergey@total-knowledge.com>:
>>
>> Alexey Parshin wrote:
>> > IMHO, only one version of the UMO should be available at the time.
>> What would be the point of versioning then?
>
>
> The point of versioning is to allow the UMO creating and modification
> support, and the ability to switch between versions. However, from the
> point
> of the author, there is only one current version of UMO that author
> considers necessary to study. Otherwise, there is no point to create a new
> version if people can still use the old one.
>
I think all versions should be available for studying.
Imagine a situation when student or teacher bought a course today and will
see something completely different tomorrow if one of the authors decides
to create new version of this course.
Yes, and it's exactly the point of the new version - it replaces the old one. I can imagine the situation when someone open a course and sees 20 different versions of the same UMO. When an author creates a new version, his goal is to fix the problems in the old one, isn't it? Or, he may want to extend the old one with something new. In any case - I don't see why it would make any sense to keep the old versions active (unless the student tries to pass an old one).
>> Otherwise, it's chaos. The voting should belong to UMO itself and not
>> > to a particular version.
>> This is certainly simplest solution, but doesn't allow authors to judge
>> effect of
>> changes they make too well.
>
>
> If an author is really interested to see the difference - then he can
> simply
> see the difference between old rating (before new version) and after. For
> instance, the rating was 4.5 and became 4.7 with the new version.. After
> all, people who passed that UMO can't vote for another version because it
> requires 'em to pass that version again. BTW, this also means that
> students
> can only pass the UMO once regardless of version..
>
>> Otherwise, the voting that doesn't affect anything in UU therefore
>> > isn't too important - requires too much attention from people. Did I
>> > already vote for version XYZ? May be not? Let's try to vote.. Oh, it
>> > says I did it already..
>> Making it easy in interface is important, you are definitely right, but
>> I don't see how
>> is the problem you describe different whether we have single counter or
>> per-version
>> counter...
>
>>
>> > 2007/1/4, sergey@total-knowledge.com
>> > <mailto:sergey@total-knowledge.com
> <sergey@total-knowledge.com
>> > <mailto:sergey@total-knowledge.com>>:
>> >
>> > Yes, but imho it's something we can compromise. I don't think it's
>> > going
>> > to be any significant amount of "returning customers" for the same
>> > UMO.
>> > On the other hand...
>> > Qualified users will see a "Vote" link that invites them to vote
>> > for this
>> > UMO. Returning users will probably see something like "You already
>> > voted"
>> > message. If they return to the new version of the UMO and they
>> > submitted
>> > their vote for any previous version of it, they may be invited to
>> > revote
>> > again. I think it's not going to be hard to check if returning
>> > user _that_
>> > _voted_ looks at newer version of the object and update his vote
>> if
>> he
>> > decides to revote.
>> >
>> >
>> > > That would mean users that voted on version X wouldn't be able
>> to
>> > > vote on version Y.
>> > >
>> > >
sergey@total-knowledge.com <mailto:sergey@total-knowledge.com>
>> > wrote:
>> > >> I was thinking of having the same usage and vote count for the
>> new
>> > >> version
>> > >> as for previous version. If we implement it this way, authors
>> > will see
>> > >> the
>> > >> difference which their recent versioned change made to the UMO
>> by
>> > >> comparing usage and voting of both versions from the date new
>> > version
>> > >> was
>> > >> created. And we'll avoid the problem that you mentioned
>> regarding
>> > >> discouraging authors from creating new versions
>> > >>
>> > >>
>> > >>> If we have separate counters for different versions, we'll
>> have
>> > >>> new versions will have vote count of zero, which will
>> discourage
>> > >>> authors from creating new versions.
>> > >>>
>> > >>>
>> > >>> sergey@total-knowledge.com <mailto:sergey@total-knowledge.com
>
>> > wrote:
>> > >>>
>> > >>>>> let's keep voting discussion in a separate thread.
>> > >>>>>
>> > >>>>>
sergey@total-knowledge.com
>> > <mailto:sergey@total-knowledge.com> wrote:
>> > >>>>>
>> > >>>>>
>> > >>>>>> Another thing regarding voting that imho may be important.
>> > >>>>>> UU may have different versions of the same UMO available
>> for
>> > >>>>>> studying.
>> > >>>>>> Are
>> > >>>>>> we taking into consideration an UMO version when counting
>> user
>> > >>>>>> votes?
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>
>> > >>>>> Good question. I was thinking about that for a while, and
>> > didn't come
>> > >>>>> to any conclusion.
>> > >>>>>
>> > >>>>>
>> > >>>> Imho we should have separate "use counters" that you
>> > mentioned in your
>> > >>>> response and student votings for each UMO version.
>> > >>>> Any versioned change to the object may change votings and
>> usage
>> > >>>> significantly. If we keep track of it in the UU, it will help
>> > authors
>> > >>>> with
>> > >>>> the improvements of their UMOs and students with better
>> > selection of
>> > >>>> objects from Repository.
>> > >>>>
>> > >>>>
>> > >>> --
>> > >>> Ilya A. Volynets-Evenbakh
>> > >>> Total Knowledge. CTO
>> > >>> http://www.total-knowledge.com
>> <
http://www.total-knowledge.com>
>> > >>>
>> > >>>
>> > >>>
>> > >>
>> > >>
>> > >>
>> > >
>> > > --
>> > > Ilya A. Volynets-Evenbakh
>> > > Total Knowledge. CTO
>> > >
http://www.total-knowledge.com <http://www.total-knowledge.com>
>> > >
>> > >
>> >
>> >
>> >
>> >
>> >
>> > --
>> > Alexey Parshin,
>> > http://www.sptk.net
>>
>> --
>> Ilya A. Volynets-Evenbakh
>> Total Knowledge. CTO
>> http://www.total-knowledge.com
>>
>>
>
>
> --
> Alexey Parshin,
>
http://www.sptk.net
>
--
Alexey Parshin,
http://www.sptk.net