Contributing

Any open source product is only as good as the community behind it. You can participate by sharing code, ideas, or simply helping others. No matter what your skill level is, every contribution counts.

See http://silverstripe.org/contributing-to-silverstripe for a highlevel overview on how you can help out.

• silverstripe.org/forums: Forums on silverstripe.org
• silverstripe-dev: Core development mailinglist
• silverstripe-documentation: Documentation team mailinglist

If you have created a patch to fix a bug in one the modules - thank you so much! :D To submit the patch, register and attach the patch to the appropriate ticket. Please include in the comment the revision number that the patch is applicable for and a brief outline of what you fixed and how. Only use the provided link to submit patches, as it prefills information about owner and ticket-type:

Submit a patch (requires account on open.silverstripe.org)

The core team is responsible for reviewing the patches and deciding if they will make it into core. If there are any problems they will assign the ticket back to you, so make sure you have an email address loaded into Trac so that it will notify you! The Trac report Active Patches will let you see where all the patches are at.

• Submit your patch in diff -u or diff -c format. See subversion for more information on creating patches.
• Check your patches against a svn checkout of the current trunk. Please not that the latest stable release will often not be sufficient! (of all modules)
• If your patch is extensive, discuss it first on the silverstripe forum (optimally before doing any serious coding)
• Adhere to our coding conventions
• Provide complete unit test coverage - depending on the complexity of your work, this is a required step.
• Describe specifics on how to test the effects of the patch
• It's better to submit multiple patches with separate bits of functionality than a big patch containing lots of changes
• If your patch involves new files, create a compressed archive for them (including any required directory-structures)
• Create patches relative to the working copy (sapphire/main.php instead of /Users/myuser/sapphire/main.php)
• Document your code inline through PHPDoc syntax. See our API documentation for good examples.
• Also check and refer to wiki documentation on doc.silverstripe.com which needs changes. Check for any references to functionality deprecated or extended through your patch. Please don't alter the documentation before your patch is integrated.
• Remember the shortcomings of svn diff: Please document moved files and created/deleted directories separately

Report security issues to security@silverstripe.com. Please don't file security issues in our bugtracker. In the event of a confirmed vulnerability in SilverStripe core, we will take the following actions:

• Acknowledge to the reporter that we’ve received the report and that a fix is forthcoming. We’ll give a rough timeline and ask the reporter to keep the issue confidential until we announce it.
• Halt all other development as long as is needed to develop a fix, including patches against the current and one previous major release (if applicable).
• We will inform you about resolution and announce a new release publically.

You can help us determine the problem and speed up responses by providing us with more information on how to reproduce the issue: SilverStripe version (incl. any installed modules), PHP/webserver version and configuration, anonymized webserver access logs (if a hack is suspected), any other services and web packages running on the same server.

• End-user: userhelp.silverstripe.com:
• Developer Guides: doc.silverstripe.com
• Developer API Docuumentation: api.silverstripe.com

• Search for existing places to put your documentation. Do you really require a new page, or just a new paragraph of text somewhere?
• Leave lowlevel technical documentation to class-level PHPDoc. Remember: Both forms of documenting sourcecode (PHPDoc/wiki) are valueable ressources, one should complement the other.
• Refer to wiki documentation inside your PHPDoc.
• Use the wiki-syntax correctly (syntax)
• Linking your page: A wiki lives by interlinking content, so please make sure your contribution doesn't become an inaccessible island. Check the startpage for common index-repositories to extend.
• Linking other pages: Make sure to refer to related topics (e.g. templates could refer to css).
• Consider namespacing your page to keep things coherent (e.g. “tutorial:customizing-contact-forms” instead of “customizing-contact-forms”). Please contact Silverstripe-staff before adding any new namespaces.
• Image-linking: We'd like to keep all ressources for documentation in one place. DokuWiki doesn't provide a public upload, so please ask Silverstripe-staff to add your image to doc.silverstripe.com. This is preferred to linking files on your own server.#
• Try to avoid FAQs as a replacement of a coherent, well explained documentation. If you've done a good job documenting, there shouldn't be any “frequently asked questions” left ;)
• You don't need to completely finish documentation, as long as you mark areas needing refinement.
• If referring to any technical features, please refer to the Silverstripe-release where they have been introduced.
• Further info: How tech writing sucks: Five Sins and What is good documentation?