Commons talk:Jury tools/WLM jury tool requirements

Feedback

Hi,

Here's my feedback about these requirements, as both a former WLE & WLM juror and software developer:

Technical requirements

• Technical requirements about operational stability are only relevant if the WLM team is planning to host the tool by itself. Operational stability is a requirement. Hosting the tool (hence defining technical requirements) is a strategy, delegating the hosting to a trusted partner (some specific requirements should be defined) is another. Should this option be considered?
• Maintainability requirements are relevant but I don't believe any of the available tools has any developing community at the moment.

UX requirements

• Requirements mandate using a judging method (binary, stars, points...) at specific rounds. The number of rounds, the judging method and the round goal (picking a defined number of pictures, or a fraction of all pictures) should be independant and left to the jury coordinator.
• It would be nice if some "quick sorting" rules could be automated : less than 2 Mpx, missing author emails... and if matching pictures could be a) reviewed separately in the tool b) moved to a Commons category.
• The tool should show the jurors the progression of the round : percentage of pictures reviewed by the current user and by the whole jury. The jury coordinator needs a dashboard showing all the jurors.
• Reviews / ranking should be very efficient, with buttons and keyboard shortcuts to keep / reject / review later, rank 0 to 10, move to previous / next... See Adobe Lightroom "Library" view as an example of efficient UX.
• Pictures should be displayed full screen for review, with an easy access to 1:1 zoom level. The whole description page should be excerpted in user's language. Previous and next pictures should be preloaded to reduce latency.
• The tool should have a "picture of the day" mode. At day D + 1, all pictures uploaded at day D (beware of timezones) get loaded in a pool from which the jurors pick one.
• There should be a chat within each round with easy syntax to link to pictures.

--EdouardHue (talk) 11:47, 9 August 2016 (UTC)

Hi EdouardHue. Thank you for your feedback. Please find my comments below. :)

Technical requirements

• Not all the operational stability issues are related to hosting. For example, if the code is written in a way that each time a round needs to be loaded, all the potentially tens of thousands of photos of a country need to be kept in memory, we won't want to solve this problem with hosting. We just want to have a better code. When it comes to hosting, we are leaning towards hosting on Tool Labs or Labs given the level of support offered by labs team, so the international team won't be involved directly with the hosting.
• Agreed, and this is fine. The goal of making the requirements list is not to exclude tools from consideration if they don't fully meet the requirements, but to understand which tool we want to spend resources on to get it to a stage that it meets these requirements.

UX requirements

Thank you for sharing these. I made a note of them to take them into account when we get to the development phase. Reading your comments, I also realized that the UX requirements we had listed were mostly features and not high level requirements. We updated the UX requirements now to signal that those need to be higher level at this stage, and that we will take into account specific features at a later stage.

--LilyOfTheWest (talk) 06:44, 11 August 2016 (UTC)