Re: UU Courses and classes

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

We need to check all the rules against the idea of openness. At the open
server anyone can make a copy of a course and teach it. Thus, if we want
to arm the author with a control tool it can be only some kind of
approval, meaning that there can be not-approved teachers as well. This
may be only matter of ethics and corresponding marks on class titles
provided by UU/authors.

Ilya A. Volynets-Evenbakh wrote:
> Alexey Parshin wrote:
>   
>> 2007/4/13, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com
>> <mailto:ilya@total-knowledge.com>>:
>>
>>
>>     10. Following class creation rules are available:
>>         - Fully open, accept donations: anyone can create class, if
>>     donation of minimum is given to author, teacher has an option to
>>     show a stamp on his course. Not giving a donation will show up on
>>     course as well.
>>         - Fully open, don't care about money: anyone can create class,
>>     no donation absence marker will be shown.
>>         - Payment required, perpetual: Fixed payment is made, and
>>     class exists indefinitely
>>         - Payment required, periodic: Flat rate payments for defined
>>     period of time.
>>         - Payment required, percentage: Percentage of teacher's income
>>     from this class
>>
>>
>> 1) Currently, a course is created with the TLT. So, who is creating
>> the course? An author?
>>     
> Yeap. Or rather, the user who created a course (it can be anyone)
> becomes an author.
>   
>> 2) If the course is created - who has to pay for that course and when?
>>   I can think of the rules of including into the teachers group: we
>> need 'enroll as teacher screen'.
>>     
> Mmm.. No, payment is set up when class is created. Now, you raise a
> valid question (or even two):
> There can be more then one teacher for the class, so
> 1. Who pays for its creation/continuous existence?
> 2. When students pay their sign-up fees, how do they get distributed
> between teachers?
> I have some ideas, but I'd like to hear others suggestions first.
>   
>>   I can also think of the rules of including to students group: that's
>> enroll as 'student' screen.
>>     
> Yes on this one.
>   
>> 3) Who is actually registering students/teachers/admins?
>>   It may be a scenario that includes an application by the person,
>> that is confirmed by an admin (for teachers) or by a teacher (for
>> students).
>>   Or, it may be that anyone just enrolls if the payment is verified.
>>     
> First course admins:
> 1. Original course creator is an initial admin
> 2. Any admin can add any other UU user as an admin
> 3. Any admin can remove any other admin
> 4. An "application" to become admin is done outside of the system.
>
> Now class admins and teachers:
> 1. Anyone who passes rules for class creation for given course can
> create a class and become class admin
> and teacher.
> 2. Any class admin can add other UU user as class admin
> 3. Any class admin can add other UU user as a teacher
> 4. Any class admin can remove any other class admin
> 5. Any class admin can remove any teacher
> 6. An application to become class admin or class teacher is done outside
> of the system
>
> Students:
> 1. Anyone who passes class sign-up rules  becomes a student
>  
>   
>> 4) How we are going to verify the payment? I suspect that payments
>> should be processed by some online system. Do we have such system in mind?
>>     
> Yes. It's real-time credit card processing. Details outside of the list,
> if you really want them now.
>   
>> 5) We need some structure to store the payment information. At the
>> very least, it should include references to {person, object of
>> payment}, date, amount, payment method, confirmation?
>>     
> Yes. We might, however, store it in separate database, for security
> reasons. I'm open
> to suggestions on this one.
>   
>> The actual methods of subscription (defined by Ilya above) can be
>> implemented as stored procs. I just need to understand - what is the
>> input information.
>>     
> Of course they will be stored procedures. It's up to you to figure out
> what you need as input.
> (Put it other way - I don't understand your question, can you rephrase
> it? ;-)
>   
>> -- 
>> Alexey Parshin,
>> http://www.sptk.net 
>>     
>
>   

-- 

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