Set up some more instructions for new members of the team

Suggest some elements to the front page that reflect something like this draft statement:

Thoughts on extending the introductory material:

Once again, welcome to the OARE project. We're glad you're here!

We communicate using a number of apps. For the code GitHub and Slack. For general stuff (like meetings), WhatsApp. Let us know what your usernames are on those systems so we can include you.

There are a lot of instructions on the GitHub front page for the code for how to get the various packages up and running.

Once again, we're glad you are on the team. The codebase is growing in size and complexity. We understand it's going to take some time for you to adjust. Don't hesitate to reach out if you have questions. And Harrison will do his best to provide support upfront.

If you need to better understand TypeScript, start there first. Log in to the job, and start reading the TypeScript documentation.

Next, you'll get familiar with: node.js (backend), vue.js (frontend), the vuetify package for vue, knex.js (for working with SQL)

You'll have opportunities to work with all of these as you do full-stack development. If you're not sure where to start, have a discussion with Harrison. As soon as you are ready, we'll give you some smaller projects to give you time to learn about different parts of the code.

Because the code is growing, we need to ensure that we keep things as standardized as possible. On a visual level, we enforce strict linting to ensure that no matter where you are in the code, things will look similar. If you use VSCode, there is an extension/plugin that will make this automatic. Else apply yarn lint:fix of the like in CLI.

Please endeavor to code in a way that is similar to the existing code in the project. There are often several ways we could code something, but if there is a way to code something that is similar to the way we have coded it, then endeavor to code that way. If you feel like we can improve some way we are doing something, definitely suggest it, but communicate that first, and let's make sure we keep our code consistent in style and approach. This keeps the code more integrated, and as we have a lot of code yet to write, we need that.

(Some examples...?)

Finally, because there are many pieces, we almost always need to build tests for the code before we deploy. If you are not sure whether to build a test, ask Harrison. We'll get a tutorial up on tests soon.

oaregithub / oare_mono

Set up some more instructions for new members of the team #939