GSoC 2015 Guidelines

Summary

• Don't commit directly, use logically named branches and pull requests
• All code must use Drupal coding standards and use the existing project structure
• Include instructions on how to test each pull request
• Address all feedback either with a commit or a reply
• Use the labels on PRs and issues to request help or to show that it's ready for review again

Details

Branches

• Do not commit directly on the 7.x or 8.x branches.
• All work should take place on a branch, one per issue.
• Branch parents should be the latest commit on the 7.x or 8.x branch
• Branches should be logically named with semantic context, like cron-report
• Commit your work often and push to GitHub.
• Branches should only be merged through pull requests.
• Branches should only be merged by the mentor and after passing functional and code review.
• Branches will be deleted post merge.
• Merge the parent branch in with the child if it's out-of-date.

Coding standards

• All code should adhere to Drupal coding standards
• All code must pass PHP_CodeSniffer using the relevant sniffs for the major version of Drupal
• The directory structure should maintain the layout established in the 7.x version of site_audit

Acceptance criteria

Each pull request should have the following:

• Link to the Issue
• Instructions for testing check and report, including how to pass and fail each test.
  • Drush instructions are preferred
  • The ability to copy and paste commands is optimal
  • Use GitHub Flavored Markdown for readability

For example:

---

Issue #14 - best practices

• Fast 404
  • Warn - use unaltered settings.php
  • Pass - uncomment $config['system.performance']['fast_404']['exclude_paths'] $config['system.performance']['fast_404']['paths'] and $config['system.performance']['fast_404']['html'] in settings.php

---

And so forth.

In addition, the code must pass PHP_CodeSniffer.

Reviewing

As I review each pull request, I'll give feedback either inline on the code, or respond to the issue itself. Please take time to address each piece of feedback, either by changing the code in question or by replying to the comment. You don't have to do both; if the code change resolve the concern, no reply is needed.

Labels

I've set up labels for issues and pull requests: https://github.com/fluxsauce/site_audit/labels

• help - Please use this on an issue or PR if need help with something or aren't sure how to proceed.
• needs work - I'll apply this if there's a problem or a question that is preventing me from merging your changes. Feel free to remove the label when you've addressed the concerns.
• passes code review - I'll apply this if a PR passes code review; please do not apply this label yourself.
• passes functional review - I'll apply this if a PR passes functional review; please do not apply this label yourself.
• priority - Apply this if something is very important.

If a story has both passes code review and passes functional review, then it's ready to be merged.