[contestms-dev] Re: Separate users and tasks from contests
- From: Stefano Maggiolo <s.maggiolo@xxxxxxxxx>
- To: contestms-dev <contestms-dev@xxxxxxxxxxxxx>
- Date: Thu, 14 Aug 2014 08:59:07 +0100
[This email represents also Giovanni and Luca.]
Wrapping up this discussion:
- we will be happy to receive pull requests for the users<->contests
separation;
- we won't accept tasks<->contest separation where editing a task in a
contest would change a task in another contest;
- if you want to go for the compromise (*), I don't see much problems in
accepting it.
Compromise (*) (idea):
- task may be not associated to any contest;
- there is an interface in aws to clone tasks; cloned tasks retain a parent
- children relationship with the original one;
- there is an interface in aws to compare a task with its parent and allow
easy synchronization;
- if you like, you can also implement an "autosync with all children" for
your convenience;
- there will be some tool (not sure if complementary or substituting what
we have now) for importing single tasks.
Let us know when you made a decision, and we'll be happy to help / review
code and design.
-- Stefano
On 14 August 2014 08:04, Stefano Maggiolo <s.maggiolo@xxxxxxxxx> wrote:
> On 13 August 2014 22:22, William Di Luigi <williamdiluigi@xxxxxxxxx>
> wrote:
>
>> On Tue, Aug 12, 2014 at 6:21 PM, Stefano Maggiolo <s.maggiolo@xxxxxxxxx>
>> wrote:
>>
>>> No, I'm *not* proposing something like:
>>> - creating task A;
>>> - cloning A to B;
>>> - changing field alpha of B (no change to A.alpha);
>>> - changing field beta of A (this change B.beta too);
>>> - changing field alpha of A (conflict, decide what to do).
>>>
>>> I'm proposing something like:
>>> - creating task A;
>>> - cloning A to B;
>>> - changing field alpha of B (no change to A.alpha);
>>> - changing field beta of A (no change to B.beta);
>>> - changing field alpha of A (no change to B.alpha);
>>> - you can see the differences between A and B in a "graphical diff tool"
>>> and move field values from A to B and vice versa with one click.
>>>
>>> This last point is what I think it would be useful for datasets too (it
>>> is now difficult to see what are the differences between datasets).
>>>
>>
>> I think this might be OK. Anyway, what do you think about Luca's
>> proposal? It seems similar to this. The only difference is that he proposes
>> to clone only the dataset when associating a task to a contest (storing
>> dataset_id in the TaskContest table). It seems equivalent, but cleaner. It
>> would, however, require the task-contest separation.
>>
>
> I don't like it too much, sorry
> - you can see that datasets are designed for another reason, because they
> provide the ability to change the fields that are not (too?) visible to the
> users; maybe now you have the same needs, but in the future might diverge
> and we will have problems;
> - in particular, there would still be the objection due to the fact that
> changing one task in one contest would change another contest (when you
> change the statement, for example);
> - we will have a single object doing two things.
>
Other related posts:
