Participation is possible on many different levels. If you find a bug report it to our Jira bug tracking system. Enhancement requests are best discussed on the sipX users list first. Would like to participate in our documentation effort on the sipX Wiki? 

Localization is in process and we are looking for help to translate the user interface as well as localize the voicemail and auto-attendant system. The German translation is well on its way; Polish and French are following. Both the user interface, dial plan, and voice prompts are adapted using plugins.

Support for plug & play management for additional phones & gateways is easy to build based on a plugin framework that auto-generates most of the required user interface in sipXconfig. You don't have to be a coder.

What do I really need to do to get my contributed code accepted into the project?   We don't have complicated rules and you do not need to sign away your rights to do so. Essentially you need to comply with our coding practices, in particular you need to accompany your code with an appropriate unit test. We also would like to know who you are so that we can keep track of who contributed what. Therefore we ask you to execute an online contributor agreement. You share the copyright of your code and give SIPfoundry the right to distribute it under the project's open source license. That's it. 

If you are more on the development side, please refer to the sipX Project Process to understand how we reach concensus on things and organize and track development work.

• Coding Standard. All the sipX family projects are using a single coding standard.
• Filesystem Conventions. How to name files and directories in the development and installation trees.
• C/C+ Unittesting HOWTO. Guidelines for creating, running and debugging unittests for sipX projects.

How To Contribute

There are a number of ways that you can participate in and contribute to the sipX projects. For most of them, you need to create an issue tracker account, which anyone can do.

Use and Test

Checkout the latest version of source from the repository or download the latest tarball, build, use and test your project(s) of interest. More users means more testing and perspectives on a project that help to make it higher quality. We suggest that you join one or more of the sipX mailing lists, and strongly recommend joining the (low volume) SIPfoundry announce list.

Report Issues

Please be sure to report any issues whether they are functional, ease of use, install, configuration or build related. Have a look through the list archives and the open issues to see if your problem has already been reported; the solution may already be there. If you are not sure whether or not it is a real problem, posting your question on one of the sipX lists is a good way to find out. When you post your question, whether on the list or the tracker, please be sure to give a description that will allow someone to reproduce and verify a solution for the issue.

Suggest New Features

If your use (or desired use) would be improved if sipX provided a feature it doesn't now, you can contribute by suggesting it. Please search the issue tracker first to be sure it is not already there. If it is, you can vote for it and comment on it. If it is not there, please create an issue to suggest it. Please be sure to describe the rationale and requirements for the feature, not just a description of the solution. This gives the rest of the community the information they need to evaluate other approaches as well, and to verify that the solution addresses the requirements.

Fix Bugs

The issue tracker provides several ways to find issues that need attention. Find an issue that is not assigned to anyone and Assign it to yourself (if you don't have the access required for this, contact the project coordinator) and start coding and testing. It is a good idea to also post a note to the sipX developer list to let people know you're working on it, and outline your understandinf the issue and how you are approaching a fix. When you believe that you have a change that meets the submission criteria for the branch, you can submit it.

Implement Features

It is best to make a short proposal (paragraph or two) to the sipx-dev list describing your suggested approach to implementing the feature before doing any coding. This allows you to leverage people in the community who may have prior experience or thoughts related to the feature or code and can alert you to potential pitfalls. It will also allow you to coordinate with the project coordinator regarding what branch would be best for the work, and how it might fit into planned releases.

Engage others to contribute to the design, development, review, testing, and use of the feature; collaboration is what open source is all about.

Your improvements need not be code; among the most valuable and appreciated of contributions will improvements to documentation and unit or component tests (tests are, of course, also code, but you get the point). These have a huge impact on the overall quality of our collective work.

How To Submit A Change

Before actually sumitting your change, check:

• Have you done a complete build to make sure that your change does not introduce any compilation problems? New compiler warnings are not allowed (and eliminating existing warnings earns good karma). If your contribution is to a library, check whether or not other projects that use the library are affected.
• Will your change have cross-platform impact? This is an area where other developers can help you a lot - send a patch to others to check platforms you can't. If you've added or removed files or changed how they are built, make sure that is dealt with in other build systems.
• Does your change adhere to the sipX coding standard? Existing code in sipX doesn't always follow this standard perfectly (both the standard and the code evolved over time), but we want the evolution to be in that direction, so anything new should follow it as closely as possible.
• Have you included unit tests for what you've done? See the sipX C/C++ Unittesting HOWTO.
• Has your change been reviewed by other members of the community? This is built in if you don't have commit access to the subversion repository, because at least whoever does will have reviewed it, but even (or perhaps especially) if you do, you should still get review from others as often as possible.

To actually contribute your change, you can:

• Post your patch to the issue tracker as an attachment to the issue.
• Post your patch to the sipx-dev mailing list. If your mail program supports attachments, please attach the patch rather than putting it inline in your mail - we have fewer problems with line wrapping and other format-related problems that way. It is a good idea to put 'PATCH' in the subject line to make it consipicuous (and to take it out of the subject when you reply to a message that has it).
• If you have commit access to the subversion repository, check it in. Be sure to reference the tracker issue that is be resolved; putting the full URL to the issue in your checkin comment is the best way to do this.

If you used the tracker or the list to send in your change, the project coordinator or a contributor with write access to the repository will respond to the request to submit the patch, possibly suggesting changes that need to be made prior to applying it.

How To Create A Patch

The best way to communicate your patch is to have started with a subversion working copy, and send the output of the 'svn diff' command. If you started with a release tar file, you can use the output of 'diff -u' (unified format) or, if your diff command is older, 'diff -c' (context format).

To apply a patch created using 'svn diff', look at the first few lines of the patch file to find the path to the first modified file and change directory so that the relative path names are correct, then execute 'patch -p0 < patch-file'.

Main Contributors

sipXpbx could use lots of help in improving ease of installation, porting and packaging for different platforms, and documentation. You don't need to be a coder to help with these problems - being a user who provides clear descriptions of what problems you had using this software (and especially how you overcame them, if you did) is invaluable. Equally important is advise on how to configure other SIP systems (gateways, user agents, etc.) so that they interoperate smoothly with sipXpbx.

Project Committers & Contributors

Mircea Amarascu,
Bob Andreasen, sipXtapi Project Coordinator
Joe Attardi
Michal Bielicki
Mircea Carasel
Laurentiu Ceausescu
Raymond Dans, call resolver Project Coordinator
Mark Gertsvolf
Damian Krzeminski, sipXconfig Project Coordinator
Scott Lawrence, sipXpbx Project Coordinator
Paul McDaid
Paul Mossman
Andrei Niculae
Mardy Marshall
Dan Petrie, sipXtacklib Project Coordinator
Michael Steinmann, Debian & Gentoo Package Coordinator
Kevin Thorley
Raghu Venkataramana
Misha Vodsedalek
Dale Worley

Retired Contributors

Larry Budnick
Alexander Chemeris
Mike Cohen
Walter Gillett
Dong Hsu
Douglas Hubler
Andy Jorde
Hannu Strang
Raghu Venkataramana
Scott Zuk 

In order to contribute code or other source material to the sipXpbx project, you must first sign the Contributor Agreement. Create a new account (or just log-in if you already have an account here), navigate to the developers tab and click on a Contributor Agreement link in the right side menu panel.