Long-term: create an officers/team page

[mattxwang]

ACM is getting ... really huge, but I still want to make sure that people know who's who within our giant org. Plus, I think it'd be good to have some single (public-facing) source of truth of who's in our org and who's contactable: it makes it easier for us to interact with UCLA institutions/clubs, alumni, affiliates and other corporate partners, and prospective students.

The bare minimum of what I'm thinking of:

• map our current officer directory (in the ACM shared drive) into a JS-interpretable data file (ex JSON, CSV)
• create a React component for one officer: takes in props for things like name, pronouns, grad year, position, major, etc.
• then, .map people from the JS-interpretable data file to the above React component
• let people filter by some queries (likely committee, role, name, grad year) - can be done with a .map .filter chain
• slap everything on to a page 😄
• document how to add new officers, and the mandatory/optional parts of the data structure

Some problems you'll have to resolve while implementing this:

• what fields are relevant? what if someone doesn't fill out a text field? what about photos? what's too much information?
• how do we handle officers who hold multiple positions without duplicating code? this year, we have a triple-officer!
• how do we handle officer name collisions? ex Matthew Wang, Justin Li
• in some cases, including emails is a good idea; can we do this without introducing spam to public-facing emails?
• how can we optimize this for performance?
  • we may be reading a JSON/CSV with hundreds of elements; can we ensure there are no network requests?
  • depending on design, we may be rendering upwards of hundreds of photos (of varying resolutions). what can be done to make sure the page renders in a reasonable amount of time and images load in sync?

Some bonus goodies to think about:

• can we automate converting the officer directory to JSON/CSV into a script? for future-proofing! probably the most important goodie 😄
• can we include past officers and tag them somehow? emeritus, alumni, etc.
  • if we include past officers, how do we handle people who change roles every year (most officers)? can we reduce duplication? what does this data structure look like?
  • additionally, how do we organize the multitude of past officers on the page? Do we want it to look like a continuous timeline, or do we want to preserve the look we have now (each year has a new set of officers)?
• should we include (longer-form) role descriptions?
• should we have individual pages for each officer? this is probably very expensive!
• is there a way we can let people edit/add themselves with minimal code friction?
  • What might this updating process look like? Will a future officer have to manually update a JSON file? Or do we want to consider adding a simple updating / management interface?

Some examples of existing team pages in student orgs:

• Hack
• Teach LA
• ICPC
• Creative Labs

Supersedes #5.

[mattxwang]

@advaithg @annaguo1012 going to quote-reply something I wrote for another ticket:

To me, this seems like a mini-project (maybe you can put two interns to work on it together). I can help provide relevant information, but I think the design/dev should be up to you two.

Particularly good since it's some interesting data-structures thinking!

[advaithg]

Sounds good! Going to block this until we finish the officers card ticket though, since I think the issue works well with having an officer card component ( #333 ) + it being an intern project means it's a winter thing. I'm going to prioritize this over the history page since I think it's a clearer and more fun ticket, but which one we end up doing as an intern project depends on what they're interested in!