Working with Each Other

Core Work Hours

Core work hours are between 10:00 AM - 3:00 PM EST

During core hours, team members are expected to:

• Respond to messages (within a reasonable time)
• Attend meetings
• Be available for huddles or team programming sessions

Flexibility and Conflicts

Core hours enable synchronous collaboration, but personal demands don’t always align with work schedules. Team members should proactively communicate any conflicts to keep things running smoothly.

---

Communication

We prioritize asynchronous communication to accommodate our team distributed across different time zones and respect individual schedules:

• Slack: Most discussions happen in Slack. Use specific channels for updates, announcements, and roadblock discussions. When a problem needs quick resolution, huddles are an effective way to collaborate in real time.
• Pull Requests (PRs): Code reviews are our primary method for discussing, refining, and approving code changes. Share feedback constructively, and be mindful of your tone to encourage positive collaboration. If a comment is likely to lead to an extended discussion, consider moving the conversation to Slack or a huddle for a more immediate feedback loop.

---

Respect What Came Before

While team members may have different views on how code should be written (especially newer team additions), it’s important to respect the existing conventions, patterns, and decisions in the codebase. Understanding the rationale behind current implementations helps prevent introducing new bugs. And if you're unsure or disagree, discuss it with the team members who worked on the code. This ensures that team members’ contributions are valued, and decisions are made thoughtfully, fostering pride in the work.

Formatting and Code Conventions

Team members shouldn't spend time worrying about formatting details (tabs vs. spaces, anyone?) or nitpicking minor code style conventions. The project enforces consistent formatting and coding conventions automatically, so you can focus on writing great code.

The codebase uses Prettier and ESLint to ensure consistency and cleanliness:

• Prettier takes care of formatting rules like indentation and quote styles (double vs. single).
• ESLint flags certain code decisions and may occasionally throw errors. A warning highlights a potential issue or best practice violation without blocking the code, like the use of any. An error indicates a more significant issue, such as unused variables, and must be resolved before the code is committed to the main branch.

Team members should aim to submit PRs that are free from ESLint warnings or errors. ESLint errors will automatically fail the PR.

Adding New Rules

If you'd like to propose a new ESLint/Prettier rule (e.g., should boolean variables adhere to a naming convention?) or update existing configurations:

1. Discuss it with the team to ensure alignment and avoid disruptions.
2. Once approved, update the ESLint configuration or Prettier configuration and include the new rule in code reviews.