Handovers

Logo >_ is not inclusive if we are to expand our audience to all of unsw

I would only consider expanding when all features have been put in place

• Focus on a smaller audience, make it popular and then it will grow well.

• Going too big could make it flop, idk

• Also less embarrassing if there is a bug you know, CSE people know how easily bugs can happen, but others won’t and will create bad look for CSESoc

Use the same database as all projects - ask James and Vicky

write tests so that changes to master aren’t fucked - ask james and Vicky for help setting up git hooks

really need lazy loading - we skipped and as such it's not scalable rn

Optional: I would recommend using TypeScript. 100% better dev experience, but it means ur team members shouldn’t be learning JavaScript, they should be already comfortable in it to learn Typescript. Only keep JavaScript if u intend to be a beginner friendly team I reckon

DITCH SEMANTIC UI. At least use the same components style as the other projects for a uniformed CSESoc look.

• Semantic ui is not used in industry. It is really only used for beginner level websites because of its simplicity and good documentation. However it is very inflexible. Cant even change colour easily.

• Bootstrap or Material UI, but would recommend using a CSESoc component.

  • If no team starts this project, I think that it’s within your teams capacity to start making them and share around! Cselectives really shouldn’t take too long- you also have a year :)

Reddit integration :)

• embed the thread

Combining normal and advanced course reviews, or at least linking them together with a toggle

• MATH1131 <--> MATH1141

• exclusion course

Esther said our team was pretty successful compared to others. Pri said so too.

• Group sprint sessions like we did during lockdown holidays. Everyday work on it for a bit

• Sub teams meet up during term weekly at a time that suits them. would not recommend solo people unless they really want to - and if you trust that they will get things done themselves

• I also held people’s hand a lot, and I guess people were always able to sense progress. Like nothing was really stagnant because all the bugs went away automatically.

  • This might not be the case later - there’s two of you so feel free to pair program if you want, but most bugs will get escalated to you. You need to be prepared and know how to debug - JavaScript console, print statements etc.

  • Be prepared to find a way to motivate people again. For us it was less of a problem since everything kinda fell in place - we all had time and we all knew each other. But your new team won’t know each other and lockdown won’t be happening. James and Vicky will help u guys make bonding events, but remember you guys are responsible for your team atmosphere

  • If you reallly need to u can ask me and hopefully I’m free :)

Hiring:

• Get someone interested in design/ ask someone in creative to be ur designer

• Willing to learn backend :)

Organise the directory - just look how fucked up components/ is.

Think about your code style - it's now your decision. ESLint config file is in directory, there are so many settings you can set, have a play.

Things Ive abstracted from the team

• Verify API - u should be able to understand what an api does from comp1531 (I hope ;-;)

  • verifier.js

• Firestore - yikes. But basically just a few api calls. Firestore also changed to v9 halfway through our project. I adopted v9 just cuz why not haha.

  • db.js

• React router - spend a day or two learning. It’s really easy.

  • App.js

• React contexts. Basically a global state. Remember states should be minimal representation possible of data - so NO components in state, even though you can put a component in state.

• Object oriented programming isn't a must, but it helps encapsulate certain functions