Collaborating Developer Requirements

Preface:

This doc will detail the process in which the Ninja Forms team will test and release all new add-ons and updates.

Intro:

The Ninja Forms Development team typically works in two week sprints. At the beginning of each sprint, our dev team will go through our backlog and select the items that will be worked on. All add-ons and updates will be added to the backlog after they have been submitted, and we will do our best to get them into the next sprint that will take place.

Auditing and Testing:

Once the add-on or update is added to the dev team’s sprint, we will audit the code to ensure it meets our code style guide (this can be found here: Add link to code style guide once it’s up). After the code audit, we will start testing the functionality of the add-on, or update. Each add-on/update will be tested for the following.

  • Backwards compatibility
    • Upgrades from 2.9.x to 3:
      • Testing the conversion process to ensure that all fields, settings, and actions are converted properly.
      • That API keys are ported form 2.9.x to 3.
    • New Features:
      • Make sure any new features do not break existing features.
      • Ensure that no submission data is lost.
  • Functionality:
    • Builder:
      • Ensure that the form can be published with your action or fields on the form.
      • Check that the form will load and submit in the preview state.
      • Make sure all settings and options are saving and working properly after the form is reloaded.
    • Front End:
      • Make sure the form will submit.
      • Check that there are no JS errors being thrown in the console before and after submission.
      • Make sure your action is being fired correctly upon submission.
    • Submissions:
      • Ensure the submission data is coming through correctly.
    • PHP Compatibility:
      • All Ninja Forms add-ons must be PHP 5.2 compatible.
  • Style
    • New add-ons will need to follow the styling conventions that are being set by Ninja Forms, this includes:
      • Not creating unnecessary fields in the builder.
      • Using the action system to perform most tasks upon submission.
      • Trying to keep things simple.

If during our testing we find the add-on/update does not meet any of these requirements. We will document the failure we came across, we will notify the developer, the add-on will be removed from the current sprint, and moved to the backlog to be tested in a future sprint. We highly recommend that you test your code to the above criteria before submitting it for review. This is the best way to get your add-on/update out quickly.

Github Repos:

The Ninja Forms team manages all of our repositories on Github. For the sake of unity we ask all devs to follow these rules on their repos.

  • Master is the truth.
    • The master branch should be whatever code is currently out in the wild. Please do not add code that is not ready to ship to this branch.
  • Workflow, Pull Requests and the develop branch:
    • Each Repo should have a develop branch. This is where all new code live. All Pull Requests should be against the develop branch of your add-on. Here is the  workflow our team follows:
      • Create an issue.
      • Make a branch for the issue
      • Create Pull Request merge against the develop branch
      • Merge develop into master
      • Update tag and release.
    • Create an issue
      • Create an issue for the bug your fixing or the feature your adding.
    • Make a branch for the issue.
      • We usually use the issue number as our branch names. This is so it’s easy to tell what we are trying to fix. Bug fix/feature branches should look like this issue#30
    • Create a Pull Request against develop branch.
      • After the bug/feature has been fixed/added and your code has been pushed. Make a Pull Request for the fix/feature and compare it to the develop branch. Please be descriptive in your title and description. Also please add a reference to the issue like so, Fixes #30
      • Make sure when creating the pull request that you are comparing again the develop branch and not the master branch.
    • Merging develop into master.
      • When you are ready to release you’ll need follow these steps in the develop branch.
        • Add changes to the change log.
        • Bump the version number.
        • Add anyone who contributed to your code to the contributors section.
        • Lastly merge the develop branch into master and make a new tag for the version.
    • Release
      • Once tagged let our team know and we will audit and release the add-on.

Updates:

Add-on updates will be added to the sprint backlog, and then processed during each sprint. Once the Ninja Forms dev team has performed a code audit, and tested the functionality of the add-on, we will notify the developer and release the update.

New Add-ons:

If this is a new add-on, once our dev team has audited the code and tested the functionality of the add-on, the dev team will pass the add-on to our Marketing Team; they will then add the add-on to their backlog for their next sprint. Our marketing team also does two weeks sprints. It’s possible for it to take up to six weeks for the add-on to be released, once it’s added to a sprint by our Marketing team. Our marketing team is currently working on ways to improve this process. To expedite the process for your add-on, submit it with the following:

  • Documentation for your add-on (including screenshots).
  • Sales Copy
  • Product Graphics