demexp-dev
[Top][All Lists]
Advanced

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

Handling of new questions (was: Re: [Demexp-dev] Delegation and classifi


From: David MENTRE
Subject: Handling of new questions (was: Re: [Demexp-dev] Delegation and classification subsystems)
Date: Mon, 22 Mar 2004 19:56:43 +0100
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Hello Félix,

address@hidden writes:

>>* tags are added to a question by a group of people recognized by the
>>  demexp system.
>
> Here, I would say "tags are added to an incoming question..." because there
> is a timing issue here (tags should be added before the question is
> submitted 

In fact, and to simultaneously answer the second question in your other
email, we have never defined[1] and specified the question submission
process. What should be done in demexp software, what should be done
through an external system?

When a new question is added:

 1. a participant submit a new question

 2. a set of people within demexp add tags to the question

 3. the question is publicly available for vote

 4. a participant add a new response and/or vote


I propose that all steps 1 to 4 are done in demexp. However:

 - synchronization between the "demexp tagging group" at step 2 is done
   through some external means (mailing list, web site, ...). Demexp
   server only gives facilities to add & remove tags 

 - the new question added in step 1 in not directly available for vote
   and is instead added into a waiting queue

 - the "demexp tagging group" at step 2 unqueue the question when proper
   tagging is done

Of course, the question waiting queue would be public (through the
demexp client or through an external mean, e.g. a web server).

What do you think of it?


> I also remember that we agreed that the number of question askable
> within a time unit (eg number of questions per day) should be limited,
> if only for protection against attacks. This should probably be reflected
> in the specifications.

That would be indirectly done with above scheme.


>>* in case of conflict (tag A delegated to Da, tag B to Db and question Q
>>  contains tags A and B):
>>
>>  - the initial delegation is frozen (i.e. suspended)
>>
>>  - the conflict is stored
>>
>>  - when the participant or delegate at the origin of conflict
>>   reconnects, he solves the conflict by giving an order between tags A
>>   and B (thus one of the two delegates will be chosen for question Q)
>>
>>  - delegation is unfrozen and the initial vote is taken into account
>
> Here, I would add:
> -The order chosen by the participant between tags A and B is stored, to be
> used during future conflicts.

You are right. Spec updated.

Yours,
d.

[1] We have defined it a long time ago, but never updated it.
-- 
 David Mentré <address@hidden>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]