Skip to content
Malouf Developer Docs

Onboarding Intro

Congratulations on joining the web team! Welcome to our onboarding documentation where you can familiarize yourself with the dev environment, tech stack, task management, and processes.

If you have an questions or concerns along the way, please ask a team member or reach out in the web-dev-central Discord channel.

Where to Begin

We’ve got lots to cover! To get more familiar with our projects, check out the list of sites we currently maintain. After that, please start downloading some of the team’s favorite apps & tools. For a few of the apps/tools we will need to provide you with an account or login information. Please reach out to us if you don’t see any invites in your inbox.

New to Mac?

As a team, we prefer to use Macs. If you are new to the operating system, please check out the links below:

Environment Setup

Moving upwards and onwards 🚀 let’s get your environment set up. Since we use several stacks, this will not be a comprehensive guide. Our guide will help you get started on some of our more regularly updated projects. Don’t worry though, we will help with any unique setups as you are assigned those tasks down the road.

Please refer to the setup guide (and possibly a coworker) to get your environment up and running. Don’t be afraid to ask for help. Contine reading this page once you have completed the environment setup portion.

At Rex Kwan Do, we use the buddy system. No more flying solo. You need somebody watching your back - AT ALL TIMES.

— Rex, Napolean Dynamite

Documentation

As a team, we strive to write as much documentation as we can to help our future-selves as well as the other departments. Any new feature or flow we try to document. You are currently in our developer documentation. The documentation we include here consists of site guides and training.

We also have a doc site for the company where we describe how to update any features or pages made for the content management team. If you find yourself running into issues with an existing BigCommerce/Catalog feature (a widget, for example) the company docs is the place to go. As a member of the team you will be expected to contribute to the docs site(s) for any new features you create or existing features you change. All our documentation is done in Markdown or MDX and built using Astro Starlight.

We write documentation to limit our bus factor. Much important. Very read. 🐕

Task Management and Team Flow

Clickup is where we manage tasks and receive tickets from other departments. If you do not have a login, please request one from Phil. You can learn all about our ticket system and how we work together as a team here.

Team! Team, team, team, team, team. I even love saying the word ‘team’. You probably think this is a picture of my family? No! It’s a picture of The A-Team. Bodie, Doyle, Tiger, the Jewellery Man.

— Denholm Reynholm, IT Crowd

Our Testing & PR Procedures

We have a small team without a QA department. You are your own QA! Just kidding, we will QA your code, too, but you are the first line of defense. If you break something, it will be up to you to fix it.

Dont’t fix bugs later; fix them now.

— Steve Maguire, Writing Solid Code

Testing

For testing locally, we use the follow extensions or tools:

Pull Requests

All pull requests should be a branch from main or master. Your branch should follow the naming convention of taskID_description-of-task. The task id can be found in each Clickup task. We include the id so we can track the task via Clickup. For example, a branch we have made may be named #8684xa1ae_about-page-layout.

If your branch doesn’t have a task, please create one unless it is a hotfix or bug that needs to go out ASAP. For those branches please use hotfix_description-of-fix.

We ask that you commit your code frequently (at least once per day) to your branch or when you complete a feature (even if the task is not done). There is nothing wrong with committing small changes. It is better to commit frequently than lose a day’s worth of code due to a git or machine malfunction. Commit messages should be brief and descriptive. If this is not your final commit to the branch, finish your commit message with “WIP” to designate that it is a Work In Progress for future reviewers.

When submitting a pull request, please add a brief description of the changes you made, how to test, and add two fellow devs as reviewers. Once your PR has been reviewed, you will receive an email with requested changes or approval. Sometimes a reviewer will simply be asking a question as to why a certain decision was made or how the particular item is functioning. If you are asked to make changes, please commit those changes into the same branch as your PR and reach out to the reviewers letting them know you’ve made the requested adjustments. When a PR is approved, it will be merged into main/master and be deployed via github actions.

Do not try to push to master. We rely on PR system to maintain a higher code standard and limit bugs on our live sites. Plus, other devs might have tips, tricks, and notes that help you write the best code. Learning to take feedback is key to becoming a better developer.

Expect to be put as a reviewer on other PRs. Feel free to give feedback and ask questions. As a reviewer, you will need to pull down the branch and test locally in some cases. If it is a widget PR for BigCommerce, you can test in Page Builder. Use your best judgement with testing and interact with the new feature how you think a user would. Please be mindful of other people’s time and try to test or provide feedback within 24 hours of the request.

Learning Resources for Frontend Devs

Now that your brain is on fire, here are some learning resources for frontend development that our team has found helpful. We also have included some links that have made our daily jobs easier.

Expectations

Though we try to make work fun, we also have expecations and goals to meet as a department. We all love learning new things, and we hope you do too! Below you will find a few soft markers we are hoping you will meet in the next few months.

Week 1

  • Finish reading through this awesome onboarding guide
  • Pair-program with your team members to get familiar with the code base and processes
  • Get Malouf VIP running locally
  • Get familiar with the BigCommerce control panel, page builder, and theme stack
  • Dev tools and MDN web docs are your new best friends
  • Ask questions! In the words of Phil, we can’t help if we don’t know there is a problem

Month 1

  • Completes tasks both in a pair-programming setting and solo
  • Shows willingness to learn and contribute to the team
  • Will comment and move tasks appropriately in Clickup
  • Asks questions and takes feedback
  • Tests locally on multiple devices (if applicable) and browsers before submitting a pull request
  • Gives deadline estimates and tries to get tasks done within a reasonable time span
  • Fixes any bugs they introduce in a timely manner once found
  • Has made an effort to learn responsive design (+media queries), semantic HTML, CSS/SCSS, Vanilla JS (ES6), and ADA/WCAG guidelines for web development
  • Has watched the first Tremors movie 🪱 (just kidding)

Month 3

  • Completes larger tasks such as a page design or feature
  • Writes documentation for new pages setup, features implemented, or changes made to existing features
  • Works with other departments and communicates progress and/or questions effectively
  • Continues to ask questions and grow as a developer with more accurate deadline estimates and clean code structure
  • Reviews and tests other team members pull requests as they would their own code
  • Has shown in their code that they build mobile-first, employ semantic HTML, clean CSS/SCSS, Vanilla JS (ES6), and following the ADA/WCAG guidelines for web development

Team Goals

As a team we are in the process of upgrading old sites to have higher code reliability, less points of failure, fast load times, and be WCAG/ADA compliant with high Google Lighthouse Scores. We are calling this upgrade Project Flaming Pigeon because like the Phoenix, we too can rise from the ashes. Or trashes in this case. Our goals as a team are to continue to learn and grow while maintaining a high code standard and meeting deadlines.