Contributing - DoSomething/legacy-website GitHub Wiki

You'll be making commits and pushes against your local repo. All work being done should correspond to an open Github issue(s).

Where to write code

You should be making changes within the modules/dosomething and themes/dosomething directories in the root, not within anywhere the html directory, which is not tracked by git.

• The changes you make in these directories are applied to your localhost's expected module/theme subdirectories in html via symlinks in the ds build script.

Using git rebase to keep up to date

• Add the main repo as an upstream remote to keep your fork up to date.

  • git remote add upstream [email protected]:DoSomething/dosomething.git

• Regularly rebase upstream to keep up to date:

  • git fetch upstream

From github.com:DoSomething/dosomething
[new branch]      dev        -> upstream/dev
[new branch]      gh-pages   -> upstream/gh-pages
[new branch]      linting    -> upstream/linting

* git rebase upstream/dev
* git push origin dev

Git workflow (draft)

Our workflow is pretty much classic GitHub flow with the exception that instead of 'master', our deployable branch is 'dev'. Note The master branch will be the canonical reference for releases in the future

• Fork the main repo
• Make the fork your origin, and clone locally
• Work from the dev branch. dev is your home base
• Before you start work, update your local dev from upstream/dev
  • git checkout dev
  • git fetch upstream
  • git merge upstream/dev
  • git push origin
  • For more details refer to [Using git rebase to keep up to date](#Using git rebase to keep up to date)
• Branch from dev locally
• Add and commit there
• Push that branch to origin (your fork)
• Create the pull request between that branch and the main repo's dev branch
• After the PR is reviewed and approved, merge into main dev branch
• Delete your feature branch
• Repeat

Writing SimpleTests

Make sure your instance passes tests locally and you create new tests for each function you write.

• For our installation profile, we need to include a protected $profile variable in order for tests to run, per https://drupal.org/comment/4909532#comment-4909532. Example:

class DosomethingUserWebTestCase extends DrupalWebTestCase {
  // Required to test inside the DoSomething profile:
  protected $profile = 'dosomething';

  public static function getInfo() {
    return array(
      'name' => 'DoSomething User Web Test',
      'description' => 'Web tests for DoSomething User',
      'group' => 'DoSomething',
    );
  }

• Another caveat of testing with an installation profile is that things will break if the profile's .info file does not list a module which a listed module depends on.
  ** Example: If dependencies[] = dosomething_campaign is listed, all the modules that dosomething_campaign is dependent on must also be listed. See https://github.com/DoSomething/dosomething/pull/144 for details.

• Write your functions knowing each function should have a unit test associated with it.

  • Split your code out into smaller functions to easily write unit tests for each function.

Coder

Your code must pass the standards set by the Coder module. Assuming that your site instance is already built and the coder module is enabled, there are several ways to confirm that your code passes:

1. From the command line, run codercs YOURFILE. This will run PHP CodeSniffer with the Drupal standards and return a text table of results.

An alternative, run drush drupalcs YOURFILE.

2. Visit http://localhost:8888/admin/config/development/coder and run tests through the UI.

All code will also be analyzed and judged when a new pull request is opened. The hook system will automatically post inline comments to your pull request if there is something wrong.

Open pull request against dosomething/dev

When your changes are ready to go, open a pull request against the dev branch in the main repo.

• All pull requests should reference at least one open issue(s) that it fixes or addresses.
• Pull requests which close out an issue should do so within the description.

Coding standards

The Drupal coding standards apply everywhere. Many editors have helper plug-ins.

If those standards don't cover your situation, document additional standards in this wiki.

Documentation

All modules and functions should include comments that document why and how the code is used, as per Drupal's API documentation standards.

Every new feature should have an issue for writing documentation for the work done. Because this documentation is included in the comments of the codebase, the pull request which adds the documentation should reference the corresponding issue to resolve it.