Thank you for contributing to Sagefy! This document covers basic guidelines for contributing to Sagefy.
Not sure where to start our help out? We have some ideas in our Want to Help guide.
To start up your local development environment, please read our Setup doc.
Create and edit content through the discussion section within the Sagefy interface. You will want to get familiar with the Data Structure.
Pull Request Checklist
For each pull request:
- Review and agree to release the code under the terms in the Apache 2.0 license.
- Pass the linters and existing automated tests.
- Document each function.
- Follow the code styleguide, as documented below.
- Write at least one test per function.
- Let another person review the code.
Global Code Styling
- Two spaces per tab.
- No extra whitespace at the ends of lines.
- A single line break at the end of the file.
- A maximum of 80 characters per line.
- Underscores: Database names
- Dashes: Filenames, URLs, CSS, HTML attributes
- Create, Edit, Delete: URLs, Page names, Attributes, User copy
- Create, Update, Delete: Postgres, GraphQL
- Table names are singular.
- Field names are singular, unless an array.
- Join tables use both names, and both in singular form.
- Don't use negative named booleans. Stay positive.
- IDs are always randomly generated strings.
modified, using those exact names, when sensible.
namefor title, name, or subject.
bodyfor body, message, description.
kindfor kind or type.
- When the number of kinds is unknown, use
- Use third normal form unless there's no query requirement.
- Mobile is the first and default styling. Use
@media (min-width...)and never use
- Explain the necessity of each additional styling.
- The least markup possible.
Basic guidelines for automated tests:
1) Tests what matters
It's too easy to get to get caught up in isolating everything for unit testing, writing a sea of esoteric tests, arguing over what type of test a test is, and gaming the coverage tool. Instead, simply tests what matters, and don't test what doesn't. If you don't care that the test fails, then don't write it.
2) Use the context
If it needs to work under a variety of conditions, isolate it. If it has a hard dependency, include it. If it needs to happen in less than 200 ms, ensure that it does. Write the test using the writing styles and tools appropriate for what matters.
3) If something becomes an issue, write a test for it
We don't want issues to recur. That also means we can write fewer tests up-front if we know new tests will be created as needed later.
- Use Markdown when possible as the default.