Home Projects Jobs Clientele Contact


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Teachers

I added following to the spec:

3) Has access to check students' solutions of "human-controlled" problems

4) Marked as a teacher on all course-related communication tools.

5) Marking someone as teacher, automatically grants them moderator power
in all course-related communication tools.


See below for more comments.

Anatoly Volynets wrote:
> sergey@total-knowledge.com wrote:
>> I'm opening a new thread for discussing Teachers functionality in the
>> UU.
>> We have some Teacher related stuff in the specs:
>> http://www.total-knowledge.com/wiki/index.php/UU#Teacher
>> but I think it's time to extend it.
>> Here is the list of Teacher's activities that may be available in the
>> UU:
>> 1. Pass the comments to Student after he solves a problems and passes
>> the
>> solution to Teacher.
> We need to juxtapose this  feature  with Communication Tools in the specs
It's definitely related. Question though is if we need a special
feedback tool
or not. If so, how exactly will it be organized? A pure feedback form? A
problem-bound, dialogue, where teacher and student may exchange messages?
What happens if there is more then one teacher for the course?
>>  Ability to see list of all outstanding problems for
>> all Students
> We don't have any administrative functionality in specs for now. There
> is a question whether it makes sense to do it occasionally or  better 
> leave an  administrative tools  (for teachers,  schools, probably
> other entities)  block for future uu versions? Or we can set up some
> generic interface for administrative features and leave it to 
> implement for community?
I'll rephrase that requirement a bit:
Teacher can see all solutions to human-controlled problems that weren't
verified within
a course he is teaching.
Teacher can also see all solutions he verified in the past.
This isn't administrative functionality. This is absolutely required for
problems, and it's even in the spec:
(see point number 5)

>> 2. Add/Remove Students from his Course
> See above + seems unacceptable as such.
Not on open server for sure. Closed server is a different story. It is
not clear what exactly
meant though. i.e. what "add a student" means? When will that happen? Why?
Same goes for "Remove".
>> 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 :)
>> 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?
>> 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.
>> 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

Authoright © Total Knowledge: 2001-2008