2022 Reflections

i’m not lewis or evan but here are my thoughts:

What we did this year

• The MVP is mostly done, with most of the critical parts based on the initial specs working (i.e., dashboard, applying, marking/ranking candidates, sending acceptance/rejection emails)

• The initial version of the frontend used MUI (cringe) with a mix of different types of custom styling - the entire frontend is currently undergoing a redesign with Tailwind CSS using twin.macro (this design may or may not change again next year)

• The frontend was originally written in pure JavaScript using PropTypes (typescript but worse) (cringe), and has since been rewritten to be completely in typescript

• There has also been an aim to improve accessibility in the frontend with the redesign

• Backend written in Rust with Rocket and Diesel

Team and Recruitment

• Our team changed a lot throughout the year, after the initial handover and recruitment we started with 7? members and 3 of them left

• We need to make sure members who aren’t as experienced don’t feel uncomfortable/imposter syndrome if the rest of the team seems cracked - this can be a major problem

• We didn’t really recruit “properly” throughout most of the year - Chaos was never advertised until T3, and the only members who joined before then were just grabbed from regular recruitment/other teams

  • This means people who might be interested might not know about it, and it might be a bit jarring to people who come in who didn’t know anything about the project before getting put into it

• Need to be mindful that members might have too many other commitments to be able to contribute long term

  • Even if they don’t have other commitments you should still make sure they’d be committed to this!! Ideally they should be intrinsically motivated and interested in the project, and not just there because of the team or because rust cool

• Hard to find people interested in Chaos because it doesn’t have as much impact for most students as other projects like Circles/Notangles, and they’ve never seen it before → perhaps if MVP gets used then there might be a bit more interest

• Finding people for backend is doomed, because not many people know Rust, and not many people think they can learn it

  • Hopefully this will be better with COMP6991

  • How can we make it seem less intimidating?

  • The other option if it’s too hard to find enough people and we don’t want to teach everyone Rust from the ground up is to rewrite backend in a different language → recommendations have been to not rewrite, and just to recruit generally and teach what’s needed

• It’d be good to have more people more familiar with web development (both frontend and backend) and best practices - I (michael) was the only person really familiar with it for most of the year, and this reflects in some of the code. Having people who are just generally good at programming can be good, and they can just pick up the specific things needed, but you also need some people who know how things should work on the web, and things like general structure, accessibility, API design, etc.

Getting Shit Done

• Communication is important, check in on members if things seem uncertain, and make sure they don’t feel lost

• If needed, can set soft deadlines on tasks, but we don’t want to stress people out - this is just a volunteering position after all

  • But we don’t want to be too lax - people are here for a reason and ideally they should be actually contributing

• Try to make tasks well-defined, and try to have things digestible for the members and easily broken down

• Ask if members need help with tasks if it seems doomed or they’re taking a while

• If a task is too doomed or a member is going to be too busy and it needs to be done soon, feel free to ask if they want you to take over from where they’ve left it - but we don’t want to just do this with everything

• Things should be planned properly - have concrete ideas for what you need and what tasks should be done next. Have an end goal/vision, and think about how it’s going be achieved

• Don’t be too perfectionist, especially for MVPs - sometimes you need to just get shit out, but try not to make it too doomed

Plans for Next Year

• Finish frontend redesign (some pages are quite doomed visually and functionally)

• Change how role-question association works

  • Right now, a question can be associated with any (non-zero) number of roles, and the applicant’s answer will be duplicated for that question across all roles

  • This is unintuitive, and there aren’t many situations where you need a question in a subset >1 of roles but not all of them

  • We want to instead have questions that belong to the entire campaign, and then questions for role

• More question types (numerical, multiple choice, order/sorting (e.g., project preferences), etc)

• Redo how admin reviewing works

  • Currently, every reviewer gets the whole list of candidates for a role, assigns numeric marks, and ranking candidates is done with the whole list in a drag and drop interface

  • This is doomed - there will be a lot of candidates - directors don’t all want to look at every single one, giving a numeric mark is difficult (especially with different directors/execs having different standards), and the ranking page is going to be doomed

  • Jared had some cool ideas

    • instead of giving a numeric mark to candidates, you get a pair of 2 candidates and you choose which one you prefer over the other. This repeats with other combinations of candidates and each candidate should be compared at least ~3 times against other candidates. We can then use some algorithm (something like elo) to determine rankings - this makes things a lot easier only needing to compare 2 candidates at a time instead of everyone at once, and removes the problems of trying to give a subjective numeric mark and different people having different standards

    • The backend would also partition the candidates across the directors/people reviewing (there’ll usually be more than 1, right?) so directors don’t get the burden of having every single candidate to review

• Move email templating to the backend - code for this is mostly already there

  • Let admins save templates for the emails they’re going to send to candidates in the database, so when we fire a “Send All”, the backend can render all of these and send them off, instead of the frontend having to render them all and send all of the rendered bodies all at once to the backend.

  • When we toggle previews, we can send a request to the backend to render it - we can render in the frontend as well but it’d be good to make sure that we’re always seeing exactly how the backend is going to render it so there’s no discrepancies

• Interview scheduling

  • Applicants and interviewers should be able to give their availability (like when2meet/talloc), and there should be some way to organise interviews (or at least make it easier) - can we integrate this with the google calendar/zoom APIs?

  • Auto scheduling??? (OR-Tools??)

• Better authentication

  • Don’t use google oauth?

  • SSO???

  • Use cookies instead of localStorage for auth tokens

• Jared wanted the backend rewritten with Actix Web and SeaORM?

• Lots of refactoring

• Use a state management library (probably MobX)

• Caching? (in the frontend)

• Move images out of the database???

• Start using ON CASCADE DELETE for foreign keys in the database??? (this should be trivial migration)

Misc

• Refactor early!!! Don’t put things off and just say you’ll clean things up later, do it now - tech debt builds up really fast and if you don’t keep things clean then everything else using it is also going to be shit. Don’t make it harder for yourself in the future

  • This might seem like it contradicts with a previous point I made but you need to find a balance

  • Refactoring immediately/keeping things clean and doing things well also means it’s less likely to need changes later that might conflict with other people’s PRs and require some coordination or rewriting of other changes that are in the same area

• Try to have good PR reviews

  • Again, we want to avoid building up tech debt

• It’d probably be good to have tests (but holy shit this is so much effort)

• Linting

  • Have good linting configs (we have a pretty strict eslint config) to ensure good code quality and to make sure things are consistent. We use this in combination with prettier (prettier-plugin-eslint to get prettier integrated into eslint so discrepancies from its autoformat results show up as linting errors)

  • Make sure everyone in the team has eslint integration set up in their editor - otherwise code might become a little doomed although this should be caught in CI anyway (I think linting has stopped being checked during builds tho - maybe from Vite migration, this needs to be fixed)