Web Meeting 2023-01-10 (??)

[fozziethebeat]

Agenda Items:

• Admin MVP
  • Any questions on what's needed before MVP deadline?
  • Discuss future changes to design
• Deployment
  • Getting the dev box working with secrets
• Misc high priority fixes
• Acking tasks needs discussion
• /tasks/all, hidden? only admins?
• Discussion
  • Sharing tasks
  • Communicating gamification nudges

[othrayte]

As a lower priority meeting topic, the e2e tests of the website are currently limited because it is hard to check that the results successfully reached the backend, does anyone have any ideas how to improve this situation?

[AbdBarho]

@othrayte by reached the backend you mean processed by the python backend or actually writting into the database?

for the former you can intercept requests and check that for the response's 200 <= status code < 300

for the later, I would argue this is not part of the e2e test, the backend tests should cover this. Although I understand that "it does not hurt check".

[othrayte]

@AbdBarho part of the goal of the e2e tests we added was to act as a smoke test that neither the website or the backend have changed in a way that causes the actual functionality to be broken, we have contract tests for the interaction but the goal of the e2e tests would be to show "if a user does {thing we expect} then {result we expect} happens", for some of our tasks like logging in that is easy to see that it worked, for something like the admin panel we could quite easily write a test that does an action and verifies that the result (which intentionally relies on the backend functioning) happens correctly. The issue is with the e2e tests for the tasks. From both the e2e test and users point of view there isn't any way to know that it worked, it kind of just goes into a black hole. It would be nice to show that it was recorded successfully and could be retrieved, but we don't have and API to check the result as we don't otherwise need one. All this said I just wanted to prompt for ideas, if the best we can do is show that the backend would receive it then I suppose we can find a way to do that. It will just be a shame as it doesn't prove that e2e (frontend to backend and back again) that the system still works which would be the most valuable smoke test. -- ok, this was too long :fearful:

[fozziethebeat]

My Meeting Notes:

• Current Status:
  • Able to get all the tasks
  • Can label messages in tasks
  • Can view messages
  • Can login via Discord & Email
  • Has minimal Admin page for web users
• Still need to do
  • Present random task
  • Given Andreas and Yannic admin access
  • Fetch valid flagging labels for message views
  • Handle peer review task: have user check spam label first and then reveal other labels.
  • Review the labels and figure out which ones have a more complicated interpretation than fits within a checkbox and slider option. Ideally reduce and simplify the set of labels for tagging clarity.
  • Do something meaningful when a user isbanned
  • Make an easier way for the user to abort a task (rather than click app icon): solve by having sidebar everywhere.
• Backend Updates.
  • (breaking change): Regardless of requested task type, backend will always response with most appropriate task. Essentially, everything is random.
  • Introduced mandatory labels for labeling task. Forces a basic peer review phase for task. Means users has to give an answer for a subset of the valid labels before submitting. The mandatory set is provided with the task.
  • Backend team will come to consensus about what to do with the labels that are mandatory.
• Discussion
  • Acking & Nacking: Still required now. Can be dropped once the frontend message id gets discarded. This change would require update interactions to include the original task id instead of the frontend Ack'd message id.
  • How to disable a user? The web can do shadow banning and block access to the website. What should the backend do? How will users react when they get banned? Ideally we only ban clear bots.
  • How much do we need to call out the importance of the spam label? It's debatable.
  • The backend server will start treating task fetching as random all the time. To test if we've built out each task type implementation correctly, we need some way to force data fetching for each specific task type. Options are: do it in storybook with fake data, have some dev config that ensures the stack respects these specific requests.
• To Design Later
  • A way for the backend to say "here's the tasks we want to make available and their ranking" so that the website can show explicit task types in a ranked order.
  • An explicit yes/no labeling task.
  • Limit the ability to create new bot based email based accounts & nvestigate caption systems to limit new account creation.
  • Investigate if the webserver is able to do some webside rate limiting to ensure a botnet can't ddos the web and shutdown the web's API key access
  • In the website provide a "keep live" signal to keep the task pinned to the user
• Things to start designing
  • Summary Stats and Reporting for messages collected
  • Update admin panels to use the backend's admin user API end points.

Future Stuff

• Gamification & Stats
  • Real endpoints coming up later
  • There might eventually be dynamic points associated with each task type.
  • To discuss more after MVP