Open surchs opened 2 years ago
We want to keep our issues up to date and active. This issue hasn't seen any activity in the last 30 days. We have applied the stale-issue label to indicate that this issue should be reviewed again and then either prioritized or closed.
I think this could be good to include in round 2 after the refactor.
We want to keep our issues up to date and active. This issue hasn't seen any activity in the last 30 days. We have applied the stale-issue label to indicate that this issue should be reviewed again and then either prioritized or closed.
@surchs Still thinking of this for refactor round 2? I'm thinking this might spill over into the next cycle depending on the rest of the phase 2 refactor tasks go from here until end of month.
We want to keep our issues up to date and active. This issue hasn't seen any activity in the last 30 days. We have applied the stale-issue label to indicate that this issue should be reviewed again and then either prioritized or closed.
When #597 is done, we could apply the same logic to validate the input data as well.
We want to keep our issues up to date and active. This issue hasn't seen any activity in the last 75 days.
We have applied the _flag:stale
label to indicate that this issue should be reviewed again.
When you review, please reread the spec and then apply one of these three options:
flag:schedule
label to suggest moving this issue into the backlog nowsomeday
label to show that this won't be prioritized. The stalebot will ignore issues with this
label in the future. Use sparingly!
As a user, when I upload my
participants.tsv
(anddata_dictionary.json
) file to the annotator, I want to receive a visual confirmation that the uploaded files have passed some validation, so that I immediately know whether there are any problems with the files before I start spending time on annotations.When users upload participant.tsv and optional .json data dictionaries with our tool, the file upload interface currently filters available files on the file system by the correct file ending. However, users can either change that or upload a file with the correct file ending but the wrong content (e.g. a .tsv file that is in fact a .csv, etc).
We could validate the supplied file content before we proceed to the categorization page in order to avoid strange breaks when we try to parse the files and they turn out to be something other than what we expect.