Re:

[Anatoly Volynets <av@total-knowledge.com>]

We do have some voting ideas in specs. It is necessary feature in
community building environment and UU is app of that kind. It is about a
specific community of authors, teachers and students, but still a
community (like EBay - it is a marketplace, but also is kind of
community, which cemented, mostly, by voting, although it is different
voting than that we need).

Yes, as of today voted DL and Author's DL does not affect access to an
UMO or any other functionality (I need to check it; as far as I
remember, there are hints of the kind in the Repository management and
few other ideas regarding contests) and thus DL is pure number(s) on the
screen. However, it may affect communication and behavior of uu users,
and this is what it is for, at the first place.

Alexey Parshin wrote:
> A question, before I start implementing this structure. We agreed that
> difficulty level doesn't affect access to UMO. So, from any
> standpoint, it
> is just a number on the screen. Implementing this number, however,
> requires
> the vote counter and average vote. This, in turn, requires a table per
> UMO
> type. Now, the question:
>
> Does implementing a community difficulty level worth implementing 5..7
> tables plus corresponding stored procs?
>
> I can, of course, make an economy class implementation - all UMO'
> votes in
> the single table (victimize the data integrity).. But still? I'm starting
> after your command.
>
> 2006/12/16, Anatoly Volynets <av@total-knowledge.com>:
>>
>> I don't remember that agreement, but I need two part difficulty level
>> (one part set for Repository by community, another  set within the
>> course or between courses of this author by this author) as I described
>> it.
>>
>> sergey@total-knowledge.com wrote:
>> > If i understood it correctly, we agreed that difficulty level
>> should be
>> > bound to a Course. Imho it's reflected in the latest DB schema.
>> >
>> >
>> >
>> >> I have added study_course, study_course_acl, and study_course_payment
>> to
>> >> support our discussion results.
>> >> However - I'm not really sure if the relation between topic (TLT) and
>> >> study_course is right. Currently, top-level-topic owns course. The
>> >> alternative is - course owns all the topics inside.
>> >> Also, I'm not sure yet how to control access to payments.
>> >>
>> >> 2006/12/14, sergey@total-knowledge.com <sergey@total-knowledge.com>:
>> >>
>> >>>
>> >>>>>> 3. Assign Course or any other UMO within a Course to a Student.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>> What that means? Recommendation or administration? If latter - see
>> >>>>> above.
>> >>>>>
>> >>>> I'd like to know that too :)
>> >>>>
>> >>> For example, assign a Problem to a Student
>> >>>
>> >>>
>> >>>>>> 4. Set grades(ratings) to a Student.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>> Same story. We don't have grades in specs.
>> >>>>>
>> >>>> We do have some ideas at least as far as grading problem solving
>> goes.
>> >>>> Most of it is automatic, but at least some is human-controlled. I
>> >>>>
>> >>> don't
>> >>>
>> >>>> care too much about grading abilities, but we'll need it
>> eventually.
>> >>>>
>> >>> We
>> >>>
>> >>>> need better definition though. Or at least some definition, since
>> >>>>
>> >>> there
>> >>>
>> >>>> really isn't anything specific in the spec.
>> >>>>
>> >>>>>> 5. Assign Students to certain difficulty levels within a
>> >>>>>> Course.(Student
>> >>>>>> will be able to see only UMOs of certain difficulty level)
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>> All the same. It is all for student's discretion as of today.  We
>> can
>> >>>>> probably think about some specific channels where students can
>> find
>> >>>>> recommendations not from teacher only. I am not sure there is need
>> >>>>>
>> >>> for
>> >>>
>> >>>>> this. We can discuss it though.
>> >>>>>
>> >>>>>
>> >>>>>> 6. Ability to change any UMO difficulty level within a Course(No
>> new
>> >>>>>> version should be created)
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>> np
>> >>>>>
>> >>>> No. Difficulty levels are author's responsibility.
>> >>>>
>> >>>>>> 7. Sets the price for a Course
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>> It is necessary feature. I believe we have it in specs.
>> >>>>>
>> >>>> Teacher or Author?
>> >>>>
>> >>> Teacher sets the price, students buy it. Author? I don't know how
>> >>> authors
>> >>> make money, maybe teachers buy courses from authors then sell it to
>> >>> students? No need to teach anything, just make a couple of
>> transactions.
>> >>>
>> >>>
>> >>>>>> 8. Chooses his prefered language(s) for the Course from the
>> list of
>> >>>>>> available languages for this Course.
>> >>>>>>
>> >>>> Preferred for what? Expand on this please.
>> >>>>
>> >>> I mean his language(pl_preferred_language column in person_list
>> table).
>> >>> Course may have several languages available, Author selects the
>> one he
>> >>> speaks. You don't want, for example, students send an Author
>> problems
>> >>> solutions in language different from the one he speaks.
>> >>>
>> >>>
>> >>>>>> 9. Ability to hide(not update) from Student certain UMOs in the
>> >>>>>>
>> >>> Course
>> >>>
>> >>>>>> that he teaches.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>> Don't need it. Actually, there is one more issue here postponed
>> for
>> >>>>> future versions: work flow. It relates to administration, but not
>> >>>>> entirely.
>> >>>>>
>> >>>> --
>> >>>> Ilya A. Volynets-Evenbakh
>> >>>> Total Knowledge. CTO
>> >>>> http://www.total-knowledge.com
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >> --
>> >> Alexey Parshin,
>> >> http://www.sptk.net
>> >>
>> >>
>> >
>> >
>> >
>>
>> -- 
>>
>> Anatoly Volynets, Co-Founder
>> total-knowledge.com
>> culturedialogue.org
>>
>>
>
>

-- 

Anatoly Volynets, Co-Founder
total-knowledge.com
culturedialogue.org