Migrating data to a CMS for accessibility

[BryanPan342]

[Use Case]
As this project grows, I think it will be more important to have the contents of the site be edited by anyone.

opensource/data/projects.ts

Lines 1 to 17 in cb1af1f

	import { Language, Project } from '../util';
	// TODO(mattxwang): do we need this to be an array?
	// a map? etc.
	const projects: Array<Project> = [
	{
	name: 'Buffer Buffet',
	description: 'All of our projects are open-source! Literally, all of them.',
	repo: 'https://github.com/uclaacm/buffer-buffet',
	link: 'https://bufferbuffet.uclaacm.com/',
	image: '/projects/buffer-buffet.png',
	alt: 'buffer buffet landing splash',
	lang: Language.JS,
	tech: [
	'react', 'x86',
	],
	},

I believe these contents can be integrated into a CMS like Contentful, Netlify CMS, or Strapi. It would make it easier for committees to edit the site AND wouldn't require cluttered PR's that's soul purpose is changing site content.

[Proposed Solution]

• Migrate data to CMS
• call data in getStaticProps
• pass projects data to page

[TimothyGu]

It would seem wise to wait for additional use cases before such a migration is justified. Spinning up a new system is a lot of work, and maintaining it is even more work (what happens if Netlify gets acquired and shuts down?). I suggest two additional options to consider, if we want to make the process more contribution-friendly:

• Migrate the file to YAML or some other easier to read format (as an example, Hack uses YAML for their Workshop Archive, which contains all their events for the past twelve quarters, without much problem)
• Creating a Google Form for people to submit their own projects, which allows exporting to a tabulated/structured format like YAML, JSON, or a JavaScript object literal.

[BryanPan342]

Very insightful! I'm writing an issue documenting a bigger and more expansive scope project that would make this CMS idea make more sense.

But I understand committing data into a repo. My preference and theory behind scaling a big project is to have the commits be geared towards features, fixing bugs, and documentation. And allow the content updating happen outside the realm of the project itself.

I'm outlining it all in an issue atm and hopefully can get it up by tonight :)