Comment contrôler la file d'annotation ?
phileas-condemine opened this issue · 3 comments
Bonjour,
J'aimerais contrôler précisément l'enchaînement des assets à annoter.
Pour cela j'ai utilisé la fonction update_properties_in_asset() en ajustant d'une part le responsable to_be_labeled_by_array et la priorité priorities que j'ai mise à 1 (j'ai compris qu'elle est à 0 par défaut).
Pourtant lorsque je passe sur le Studio d'annotation, je choisis un verbatim dans le tableau "Explore", je l'annote et le document suivant est un document avec une priority à 0 et qui n'est assigned to personne !
Je choisis un document depuis l'interface Explore :
Après l'avoir annoté et cliqué sur Submit, voici le document qu'il m'est demandé d'annoter :
Je retourne dans la vue Explore pour vérifier la priorité et la personne à qui ce document est affecté :
Le problème ne vient pas du statut puisqu'après la préannotation, j'ai bien veillé à remettre tous les documents en statut TODO
Quels critères sont utilisés pour définir le prochain verbatim à annoter ? Comment modifier ce critère ?
project_id : clbgd78ic00sw0k3a0y0dcbgv
FRENCH ANSWER (English below)
Bonjour Philéas,
Vous trouverez ci-dessous un récapitulatif de nos échanges et de notre call réalisé vendredi dernier:
Nous vous confirmons qu'assigner plusieurs assets et leur donner une priorité plus élevée que les autres (ici 1 car la valeur par défaut des autres assets est de 0) permet en effet lors du clic sur le bouton "Label" de récupérer ces assets en premier dans la file d'annotation.
Documentation: https://docs.kili-technology.com/docs/queue-prioritization
Il s'avère également après investigations que vos assets possèdent des labels de type DEFAULT, uploadés via l'API avec la méthode append_to_labels
. Cela a eu pour effet de passer les assets en statut LABELED ou TO_REVIEW, ce qui n'était pas désiré car incohérent avec votre process. Vous avez donc utilisé la méthode update_properties_in_assets
pour basculer le statut de ces assets en TODO.
Cette manipulation perturbe malheureusement la file d'annotation.
Nous allons donc regarder avec le reste de l'équipe technique pour ne pas la rendre disponible via le SDK car elle est trompeuse.
Pour vous débloquer, nous vous conseillons donc de renvoyer tous les assets sur lesquels vous avez apposés des labels DEFAULT dans la queue d'annotation avec la méthode send_back_to_queue
(cf documentation). Ils seront dès lors en premiers dans la file.
Si vous avez la moindre question ou remarque n'hésitez pas à nous les partager,
ENGLISH ANSWER (French above)
Hi Philéas,
Please find below a summary of our discussions and of the call from last Friday:
We do confirm that assigning multiple assets to a user and setting their priority a higher value than the other assets (here 1 since the default value equals 0) enables you to see these assets first once you click the "Label" button.
Documentation: https://docs.kili-technology.com/docs/queue-prioritization
However, it appears that some of these assets have at least one DEFAULT label, uploaded through the SDK method append_to_labels
. Thus, the status of these assets was temporarily switched to LABELED or TO_REVIEW, which you did not want to happen. To fix this, you have used the update_properties_in_assets
method to get them back as TODO.
Unfortunately, such a manipulation disturbs our annotation queue.
We will then discuss with the technical team to make the status_array
parameter unavailable in this method since it can be misleading.
As a workaround, we advise you to send the assets you have applied a DEFAULT label on back to the queue. To do so, a method named send_back_to_queue
does exist in the SDK (cf documentation). These assets will then come first in your labeling queue.
Feel free to let us know if you have any questions/remarks to share,