Re: Teachers

["Alexey Parshin" <alexeyp@gmail.com>]

I'm not sure if we are talking of the same thing. Study_course is an administrative object, currently for course-wide permissions and payments. It refers to top-level-topic (TLT) that is a course. Now, TLT has the difficulty level, content, etc.. May be, study_course isn't the best name for the object?

2006/12/16, sergey@total-knowledge.com <sergey@total-knowledge.com>:

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
>

-- 
Alexey Parshin,
http://www.sptk.net