Write `CONTRIBUTORS.MD` file for telling people how to contribute

[alexng353]

Please treat this thread as an RFC. Comment on what standards we should hold people to and what you would like to see moving forward with this project.

Some suggestions:

1. All commits should be done through pull requests
2. All pull requests require reviews
3. Project Management done via GitHub Issues
4. WIP Commits, or Dead Commits should be squashed via rebase before being merged into the main.

UPDATE: I will be reading the comments on this post throughout the week. If something specifically requires my attention, message me on Discord. Otherwise, use this as a brainstorm with each other.

[lamettrist]

Utilizing GitHub Actions to be able to stage and test the components of the website to make sure that it works and will not error out in-production.

Utilizing main branches and development branches, with the development branches being prioritized for staging and then the main branch for production.

[sresri2]

Maintaining a master branch, main branch, and development branches. Using the development branches for additions, merging to the main branch when an addition is completed. Development branch is what we build off of. Push to master for production.

Use GitHub Pages off of the master/production branch to see the website in its current production state. This doesn't need to be an advertised link, only to see the current built version of the site.

[elijah-wright]

Project Management done via GitHub Issues

I think we can incorporate GitHub Issues and GitHub Projects. we should create issue labels, everything from governance to product to docs, milestones for issues, and a roadmap and sprint board that incorporates both labels and milestones

Every PR will be squash-merged

this philosophy might work for most pull requests, but for major features that multiple people worked on, having that history is useful. individual commits could be squash merged by person (by rebasing them), but that would be in the Git command line

I don't believe we need a separate branch for development. we should create branches on the main repository from the main branch for pull requests, prefixing our GitHub usernames could work to organize that

[alexng353]

GitHub Issues and GitHub Projects

Probably a good idea to use both together

issue labels

Good. Please make suggestions for specifically which ones you want

this philosophy might work for most pull requests, but for major features that multiple people worked on, having that history is useful.

You bring up a good point here. We can add this to the CONTRIBUTING.MD and require people to squash dead commits into larger ones.

branches on the main repository from the main branch for pull requests, prefixing our GitHub usernames could work to organize that

I'm a bigger fan of people making their own fork of the repository to work on it that way, and prefixing branches with your last name or another tag. Personally, I use the format alex/mm-dd-yyyy-descriptive-name-for-branch, and format all of my pull requests in that way as well.

Image related

[alexng353]

Use GitHub Pages off of the master/production branch to see the website in its current production state.

This will be difficult since the nature of the application is data-driven and statically generated, with incremental static regeneration. If there is a way GitHub pages can host a proper full-stack NextJS site, I'm all for it, but I don't believe any hosting provider other than Vercel and Cloudflare supports this feature.

Maintaining a master branch, main branch, and development branches. Using the development branches for additions, merging to the main branch when an addition is completed. Development branch is what we build off of. Push to master for production.

This probably won't be happening. Potentially there can be a staging branch, but otherwise, all coding should be done on forks and pull-requested into either staging or main. For simplicity's sake, I think that the best course of action would be to use one main branch only, but this is debatable.

[alexng353]

Utilizing GitHub Actions to be able to stage and test the components of the website to make sure that it works and will not error out in-production.

Utilizing main branches and development branches, with the development branches being prioritized for staging and then the main branch for production.

Both of these are good. I don't know how much you guys would enjoy doing front-end testing, but I think that back-end testing is definitely a good idea. GHA for checking build, lint and testing status is definitely possible, but I'm not sure what you mean by "stage" the website. Please clarify.

[flatypus]

I don't know how much you guys would enjoy doing front-end testing, but I think that back-end testing is definitely a good idea.

Not gonna lie, due to the nature of what we're building here, there's probably not going to be anything complex enough to warrant front end testing

And about squash merges, I...can't say I like how it works. I'd rather have people more careful about how they commit and keep that history (and I guess if you want a clean tree you could rebase...) but squashing is just annoying. If it breaks something, I have to search through my old branch history (if it hasn't been deleted already), or someone can read through the entire single squash commit

Again, this applies in certain scenarios only, and I don't know how big this project will grow/how big the team will get

[flatypus]

Also, yes you can deploy nextjs to github pages, but no it looks like a painful process. Nextjs was built for vercel, and vercel was built for nextjs.

[flatypus]

I would hope that if the project management is done here, we set up some sort of tagging system for issues, tasks, PRs (like [bug], [feature], [help wanted], etc) to direct development.

[elijah-wright]

Please make suggestions for specifically which ones you want

sure:

• Design
• Iteration
• Research
• Scope
• Product
• Content
• Eng

I'm a bigger fan of people making their own fork of the repository to work on it that way, and prefixing branches with your last name or another tag.

that's what I said

[alexng353]

that's what I said

Sorry for misunderstanding

[alexng353]

Nextjs was built for vercel, and vercel was built for nextjs

Cost $$$

Cost is probably too high considering this is a volunteer and open source project with no cash flow right now.

[alexng353]

and I guess if you want a clean tree you could rebase

Rebasing within a single branch and then regular merging is probably a good idea.