How to Contribute

The Simile Project follows the principles of Open Source software development and releases all the software it creates under the BSD license. This means there are many ways to contribute to the project - either with direct participation (coding, documenting, answering questions, proposing ideas, reporting bugs, suggesting bug-fixes, etc..) or by resource donations (money, time, publicity, hardware, software, conference presentations, speeches, etc...).

To begin with, we suggest you to subscribe to the Mailing lists (follow the link for information on how to subscribe and to access the mail list archives). Listen-in for a while, to hear how others make contibutions.

Subversion Usage Precis

All software development in the SIMILE project is done on a Subversion repository that provides storage, version control and publishing capabilities for the source files.

First of all, do not be afraid: you cannot accidently destroy the actual code repository, because you are working with a local copy as an anonymous user. Therefore, you do not have the system permissions to change anything. You can only update your local repository and compare your revisions with the real repository.

Further general Subversion usage information is at subversion.tigris.org. Other resources include "Version Control with Subversion" and a fast introduction.

Refer to each project page for specific instructions on where their repositories are located and what URL to use to check them out.

How to Create a Patch

To contribute your modifications, you need to produce a plain-text file containing the differences between the master copy and yours. You will submit this to the issue tracker along with an explanation of why it is required, and perhaps discuss it on the mailing lists. One of the authorised maintainers of the repository will review the patch and then apply it to the relevant branch.

svn diff > my_contribution.diff

Contribution Notes and Tips

This is a collection of tips for contributing to the project in a manner that is productive for everybody.

• Every contribution is worthwhile. Even if the ensuing discussion proves it to be off-beam, then it may jog ideas for other people. Don't be afraid to speak up!
• Use sensible and concise email subject headings. Search engines, and humans trying to browse a voluminous list, will respond favourably to a descriptive title.
• See Tips for how to write email messages on a public mail list and Message Editing and Quoting Guide (with Examples).
• Start new threads with new Subject for new topics, rather than re-using the previous Subject line.
• Keep each topic focussed. If some new topic arises then start a new discussion. This leaves the original topic to continue un-cluttered.
• Whenever you decide to start a new topic, then start with a fresh new email message window. Do not use the "Reply to" button, because threaded mail-readers get confused (they utilise the In-reply-to header). If so, then your new topic will get lost in the previous thread and go un-answered.
• Prepend your email subject line with a marker when that is appropriate, e.g. [Vote], [Proposal], [RT] (Random Thought which quickly blossom into research topics :-), [STATUS] (development status of a certain facility), etc. Consider those a way to "tag" a particular email message (and keep in mind that computer programs might make use of this information in the future!)
• Please follow up with a final posting when your issue is solved. Thisshould summarise your problem and its solution. Add [SUMMARY] to the subject line. This will ease the FAQ generation and searching of the list. Note that some people tend to ignore questions from those that never follow up.
• Remember that some people are participating in development on a volunteer basis and in their "spare time". These enthusiasts will attempt to respond to issues. It may take a little while to get your answers.
• Research your topic thoroughly before beginning to discuss a new development issue. Search and browse through the email archives - your issue may have been discussed before. Do not just perceive a problem and then rush out with a question - instead, delve.
• Try to at least offer a partial solution and not just a problem statement.
• Take the time to clearly explain your issue and write a concise email message. Less confusion facilitates fast and complete resolution.
• When sending a patch, you usually do not need to worry about which branch it should be applied to. The maintainers of the repository will decide and might also apply it to the trunk. Please indicate on the Bugzilla entry which branch you have used to prepare your patch.
• If an issue starts to get bogged down in list discussion, then it may be appropriate to go into private off-list discussion with a few interested other people. Spare the list from the gory details. Report a summary back to the list to finalise the thread.
• Become familiar with the mailing lists. As you browse and search, you will see the way other people do things. Follow the leading examples. Or, if not sure, ask and don't be shy!