[Top][All Lists]
[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>