Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Commenti Review2 #15

Open
mzanella opened this issue Oct 12, 2017 · 2 comments
Open

Commenti Review2 #15

mzanella opened this issue Oct 12, 2017 · 2 comments

Comments

@mzanella
Copy link
Member

mzanella commented Oct 12, 2017

The proposed tool is interesting and the paper is overall well written. However, I have few 
comments and there are some things that are not completely clear to me.

In Section 3.1, before going into architectural details, a high level description of the 
application should be given, explaining its usage, for example (e.g., comment figure 2.a), so
that the reader can better understand issues and solutions at architectural design level.

It is not clear to me how conflicts are solved: what happens to a tag of one specific image 
that is selected by one user but not by another?

It is not clear to me why (not how) a modified version of the application is needed for tests.

It is not clear to me why authors had to count e-mails (first sentence of sec 5.2), shouldn’t 
they be 150?

Experiments concerning OCR are very limited (as the authors themselves assess) and not 
very meaningful. Maybe they could be cited in one sentence and left for an extended and 
more complete version of this work.
@mzanella
Copy link
Member Author

  • Il primo commento non l'ho molto capito perchè noi diamo la descrizione dell'applicazione prima della descrizione dell'architettura
  • Il secondo probabilmente non ha capito che agli utenti facciamo fare foto che vogliono loro quindi è difficile che inquadrino lo stesso soggetto, e comunque non abbiamo controllato falsi positivi/negativi
  • Il terzo commento metterei perchè l'applicazione principale è pensata come un'applicazione finita mentre poi per i tester abbiamo limitato le possibilità in quanto noi avevamo bisogno di raccogliere i risultati e che non usassero troppo le chiamate ai vari servizi
  • Perchè potrebbero esserci comunque gli utenti che modificano l'indirizzo di invio e perchè non abbiamo gestito gli errori di connessione quindi nel caso il riconoscimento di una foto fallisca bisogna riprovare
  • L'ultimo ok ma non so che dire

@tfederico
Copy link
Contributor

In Section 3.1, before going into architectural details, a high level description of the application should be given, explaining its usage, for example (e.g., comment figure 2.a), so that the reader can better understand issues and solutions at architectural design level.

Non capisco se vuole tipo una descrizione della UX o cosa

It is not clear to me how conflicts are solved: what happens to a tag of one specific image that is selected by one user but not by another?

Alla fine non ci sono utenti che fotografano la stessa cosa, quindi il problema non si pone. Effettivamente però dovremmo controllare falsi positivi/negativi perché non abbiamo delle metriche "riconosciute" come tali nel paper...

It is not clear to me why (not how) a modified version of the application is needed for tests.

Perché altrimenti diventavamo poveri visto che le API sono a pagamento

It is not clear to me why authors had to count e-mails (first sentence of sec 5.2), shouldn’t they be 150?

Sgamati

Experiments concerning OCR are very limited (as the authors themselves assess) and not very meaningful. Maybe they could be cited in one sentence and left for an extended and more complete version of this work.

Sì, direi che l'OCR possiamo metterlo nei future works

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants