ShareSource » Help us: Donate money!

Contribute to ShareSource

Ways To Contribute and Participate

You do not have to just contribute code! There are other ways you can contribute:

• Communicate - Use the Mailing Lists to communicate with other ShareSource contributors
  
  
• Test - Download and try out beta releases; provide bug reports, experiences, feedback. Sign up to the beta mailing list to see new features early!
  
  
• Develop - Contribute bug fixes, new features, developer cycles. Contributing code is far easier than you might think!
  
  
• Prototype - The best way to gain support for an idea is to build and share prototype code

Don't be shy!

Source contributions don't have to be 100% polished or perfect; no one will think any the less of you. "Share early, share often" is a well-known open source mantra. The sooner you contribute something, the sooner others can help with the polishing!

If You Want to Contribute

The overriding mantra is share early, share often. Here are a few things to consider:

• Announce your effort on the sharesource-dev list before embarking on any sizable development effort. This will ensure you achieve your goals in a way that is consistent with the ShareSource architecture and plans of the rest of the community. This will minimise the chances of a scenario where you have invested a large amount of time and effort into a body of code that does not fit in with the ShareSource architecture or the consensus of the community, meaning that you need to spend further time refactoring your code.
  
  
• Develop incrementally; try and implement and contribute a basic form of your feature as soon as possible, rather than aiming to implement a complete and 'polished' solution. This will help ensure you're on the right track with regards to the rest of the ShareSource community and platform. The sooner your code is part of the core code base, the less time you will have to spend 'chasing' the main code base, i.e. keeping your changes up-to-date with that core code base. Obtain the ShareSource code using Mercurial. This will make code management much easier. It's very simple to do.
  
  

Getting the Source

The ShareSource code can be retrieved by using a version control system called "mercurial". Mercurial is a distributed version control system, and as such, works even when not conected to the internet. On a *nix machine, do something similar to this:

# mkdir ~/Source/
# cd ~/Source/
# hg clone http://hg.sharesource.org/sharesource/
# cd sharesource
# cat www/index.php  | grep ShareSource | grep '[0-9]*\.[0-9]*\.'
header('X-Powered-By: ShareSource 1.98.5');

Your source tree is now ready to be hacked upon!

Contribution Checklist

When you contribute to ShareSource, please be sure that your submission adheres to the points in this checklist. The ShareSource committers need you to do this to keep quality of the ShareSource code high and their work manageable.

• You must agree that your contribution will automatically be licensed under the AGPL
  
  
• Your contribution should be a patch against the sharesource 'default' branch
  
  
• Examples or Use Cases should be submitted to help committers understand and adequately test the patch prior to applying it to the core code
  
  
• Patches must be small diffs (no large all encompassing patches!) using the unified output format (see Submitting a Patch below for flags)
  
  
• Any new features must be configurable. Be careful in particular with the `config.php` file. Make sure you only patch this if you change involved new configuration parameters in it, and make sure you have good default values for them. Don't accidentally include your own local configuration parameters (e.g. host name etc) in the patch! If the new feature is in any way specific to a particular application (e.g., open access, theses), it should be switched off by default
  
  
• If you add new configuration parameters, name them appropriately. Also, they should not be required to be in config.php - if the parameters are omitted, ShareSource should continue to operate as before.
  
  
• DBMS schema changes must first be signed off by another developer of ShareSource, before being pushed to ShareSource.
  
  
• Your contribution should be a patch against the sharesource 'default' branch
  
  

Submitting the Patch

Submit the patch to the sharesource-dev mailing list. Be sure to describe the modification, including the numbers of any bug/feature request items that the patch relates to.

What Happens Next

Once you have produced and submitted your patch to the mailing list, it must be reviewed, tested and approved by one of the committers. Comments regarding the submission can be posted to SourceForge and you will receive email notification of any feedback. If and when your patch becomes stable and approved it will be integrated into ShareSource by one of the committers.

During the normal release cycle a feature freeze will be declared for a given date, and normally only patches submitted prior to that date will be considered for the upcoming release. Any patches submitted after this will be in time for the feature freeze of the following release. The date of submitted patches may be flexible depending on the time available for testing and integration and the urgency/usefulness of the patch. Patches which fix bugs will also generally be considered until much closer to the final release date.