Metadocumentation
open-collective
open-collective
  • Welcome
  • About
    • Introduction
    • Terminology
    • Company
    • Pricing
    • Community Guidelines
    • Values
    • Team
    • Investors
    • Contributing
  • Product
    • Features
    • Roadmap
    • Comparison
    • User Profile
    • Currencies
    • Log-in System
  • Collectives
    • FAQ
    • Creating a Collective
    • Quick Start Guide
    • Customize Collective
    • Change Core Contributors
    • Tiers & Goals
    • Add Fiscal Host
    • Change Fiscal Host
    • Transparent Budget
    • Expense Policy
    • Approving Expenses
    • Updates & Comms
    • Events
    • Funding Options
    • Data Export
    • Buttons & Banners
    • Integrations
    • Zero Collective Balance
    • Closing a Collective
  • Financial Contributors
    • FAQ
    • Payments
    • Website Badge
    • Organizations
      • FAQ
      • Bulk Transfers
      • Gift Cards
      • Sustainer Resources
    • Collectives
      • Collective to Collective donations
  • Expenses & Getting Paid
    • FAQ
    • Submitting Expenses
    • Expense Comments
    • Edit an Expense
    • Tax Information
  • Fiscal Hosts
    • FAQ
    • Becoming a Fiscal Host
    • Create a Fiscal Host
    • Fiscal Host Settings
    • Invoices
    • Payouts
    • Host Dashboard
    • Add Funds Manually
    • Refunds
    • Host Fees
    • Local Tax Support
    • Agreement Templates
    • Open Source Collective
  • Contributing
    • Design
      • Design Workflow
      • Design Contribution Guidelines
    • Development
      • Contribution Guide
      • Best Practice Guidelines
      • Bounties
      • API
        • Members
        • Users / Emails
        • Collectives
        • Events
      • README Integration
      • Architecture
      • Postgres Database
      • PayPal
      • Post-Donation Redirect
      • Custom Tweets
      • Manual Reporting
      • Github Permissions
      • Translations
      • Testing with Cypress
      • Collective's locations
    • Documentation
      • Style guide
      • Suggesting changes
    • Translation
  • Internal
    • Scope
    • Team Retreats
    • Brussels Summer Team Retreat
    • Host Admin Manual
    • Newsletter
    • Support
    • Issue Labels
    • DNS Troubleshooting
    • Developer Guidelines
    • Architecture
    • Testing
    • Queries
      • Gift Cards
      • Transactions
      • Ops
      • Collectives
      • Hosts
      • Analytics
      • Emails
    • Projects
      • Maintainerati Berlin 2019
      • Season of Docs 2019
    • The Open Collective Way
      • Values
      • Community Guidelines
      • Core Contributors Guidelines
      • Core Contributors: Communication
      • Core Contributors: Expenses
      • Core contributors: Leave
      • Core Contributors: Compensation
Powered by GitBook
On this page
  • Coding Principles
  • Version control (GIT)
  • Javascript coding rules
  • Testing and Continuous Integration
  1. Internal

Developer Guidelines

The goal of this page is to document how we are developing Open Collective. What are the good practices, design decisions, architecture, etc.

Coding Principles

  • Everything we do is open source

  • We should use Github Issues as much as possible. Anyone, inside or outside the organization, should be able to pick up an issue

  • Make pull requests for everything

  • We need to make it easy for anyone to install a local copy and contribute code

  • Any repo should be able to be installed locally with just a npm install and start with npm start

  • The README.md should be kept up to date and should describe how to deploy to the different environments

  • "If you break something, it's not your fault". It's important when you develop a new feature or fix something to have confidence that nothing else will break. If tests pass, you shouldn't have to worry. The opposite is also true: "if someone else broke your code, it's your fault". That's why it's important to write tests. Think about it as a way to protect your code and to avoid having to fix it because someone else broke it.

  • All scripts should be referenced in package.json so that they can be run with npm run $script

  • We use "config" to manage environemnt variables.

  • Production or test environment variables should only be kept on heroku (you can access them using the command heroku config --json --app opencollective-staging-app

Version control (GIT)

  • Make clear pull requests with clear commit messages

To avoid unnecessary commits use git commit --amend instead of regular git commit. If you already pushed, you might have to force push (git push origin --force), it's usually ok if you're on a feature branch. If you need to rewrite the commit history: git rebase --interactive HEAD~5

Javascript coding rules

  • We use ES6 syntax (arrow functions, const, ...) and eslint. Our rules are defined in the eslint-config-opencollective repo.

  • We use string interpolation (const str = `hello ${var}`;)

Testing and Continuous Integration

  • We should thrive to have as much test coverage as possible

  • We use cypress.io for end to end tests

PreviousDNS TroubleshootingNextArchitecture

Last updated 5 years ago