This document illustrates the workflow users should undertake to contribute to the Inbound Now public codebase.
Part I – Getting Started
Step 1. Installing a local server.
Step 2. Installing SourceTree for git management
Step 3. Downloading the Repository
Note: Inbound Now Employees will treat this process differently from non employee contributors. See below for details.
A. For contributors
Fork the Inbound Now repository you would like to contribute towards into your github account.
Download your forked repository locally.
Make changes locally.
Commit changes locally.
Push changes to your forked repository.
Create Merge Request with original repository.
How to Re-Synchronize Forked Repositories with Parent Repositories:
Over time a forked repository can become significantly out of sync with repository it was forked from, in these cases we will need to re-synchronize.
B. For Employees
Connect a local repository using our main public repos and use SourceTree’s GitFlow for addressing issues.
Part II – Standards and Guidelines
In order to operate under standard of quality the following items must be considered when contributing code changes to Inbound Now:
1. Creating Issues
First search our issues database on GitHub and discover if an issue exists for your problem. If it doesn’t exist create it. When creating an issue follow these three steps:
2. Referencing Issues in Commits
Adding a full URL link to your git commit message will ping the issue and update it automatically with a reference to the commit. If you are working with a forked repository reference the issue(s) you are addressing in the merge request message.
3. Documenting & Proving Solution
After completing a solution for an issue please use video to document your solution in action and notify a lead developer (Hudson Atwell or David Wells) that the issue requires a final review before closing.
Part III – Important considerations
Below you will find information that is important to understand when contributing to the Inbound Now codebase.
1. Working inside the /shared/ directory.
The /shared/ directory contains identical code components that are shared between our three major free plugins, Landing Pages, Calls to Action, and Leads.
Load priority: Calls to Action, Landing Pages, Leads
When we improve code that exists in the /shared/ directory we always will make these improvements to the calls to action repository and then administration will propagate those changes to Leads and Landing Pages.
2. Working with Gulp
Installing Gulp and NodeJS
Calls to Actions
When editing our InboundAnalytics source js files in /cta/shared/assets/js/frontend/analytics-src/ shared we use gulp to combine and minify our source files in /analytics-src/ into /analytics/
If you are a full time developer for Inbound Now you will have to use gulp in the development and deployment of the Inbound Pro plugin.
In our Inbound Pro component we use Gulp to pull in the files from Calls to Action, Leads, Landing Pages, Mailer, Marketing Automation. We also use gulp to delete the shared folders from these files and import the Calls To Action’s /shared/ folder (as the master shared folder) and places it into /_inbound-pro/shared/
This setups a watch on the /plugins/cta/shared directory and any changes made to files in that direcotry will be reflected in /_inbound-pro/core/shared/ directory.
(Visited 210 time, 28 visit today)