This is a collection of documents that outline Holiday Extras' culture and developer expectations.
- Coding Principles
- General Javascript Best Practices
- Clientside Javascript (Backbone) Best Practices
- Clientside Javascript (jQuery) Best Practices
- Server Side Javascript Best Practices
- CI Best Practices
- Git Best Practices
- Git Flow Best Practices
- PR Best Practices
- Markdown Best Practices
- SASS Best Practices
- HTML Best Practices
- Accessibility Best Practices
- Application Tracking
- [Nightwatchjs Best Practices] (nightwatchjs-best-practices.md)
- Testing Standard
- Testing Overview
- SEO Best Practices and Principles
- Frontend Performance
- Pest Control Process
- PR Template
- Expedited Procedure
- General Meetings
- Technical Planning Meetings
- Deployment Guidelines
- Publishing to npm
- Definition of Ready and Done
- Contributing to projects
- [Pair programming] (pairing.md)
- Translations
- [Mob Testing] (mob-testing.md)
- Organising Code in Backbone Projects
- CoffeeScript to JavaScript Guidelines
- Javascript Linting Rules
- Technical Resources
- Working with React
- React Troubleshooter
- PR Template
- PR Blog Post Template
- Shortbreaks PR Template
- Shortbreaks QA PR Template
- SEO Technical Principals
- SEO On Page Principals
Anyone associated with Holiday Extras, including our customers and partners, should feel free to create a branch or fork and submit a pull request with additions, updates or deletions. That being said, we do expect anyone contributing to our culture to watch out for a few things.
- Edits should attempt to avoid fallacies and cognitive biases when making their cases for inclusion of contributions. We prefer to follow objective data and arguments.
- We use Markdown syntax to format these documents.
The PR template in this repository is targeted at code changes, so we'd suggest something simpler if you're looking for something to use when opening a pull request to add documentation here:
# What does this change?
# Why?
Pull requests to this repository are open to input / discussion / agreement by all, there is no requirement of approval by a fixed number of people with specific roles as in the template for code changes.
If an update or addition refers to a process or technology which is, or is to be, implemented by the group, please ensure that the PR includes applicable reviewers from of each part of the group and notify a member of the group tech panel to discuss appropriate handling of the change.
If a PR has been open for several days with no unresolved comments, or it's otherwise clear from comments many people have had the chance to read and agree, we should consider it good to merge; further changes can always be raised through additional followup PRs.