[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Voting [was: Passing UMOs]
Alexey Parshin wrote:
> IMHO, only one version of the UMO should be available at the time.
What would be the point of versioning then?
> 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.
> 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