Developers

Reporting Bugs

Reporting bugs is a very easy way to help contribute to any project. MonoDevelop bugs are be filed at bugzilla.novell.com.

To report a bug, follow the steps below:

1. Create a Bugzilla account.
2. Ensure the bug you are reporting hasn't already been fixed. Install the latest version of MonoDevelop using the "Current Development" instructions on the download page.
3. Review the open MonoDevelop bugs and make sure that your bug hasn't been submitted already.
4. If it hasn't been submitted, submit a new MonoDevelop bug.

Error traces gathered by running MD from a terminal are often helpful in tracking down a bug. For more information read the article on logging.

Submitting Patches

Patches have to be submitted by using the Pull Request mechanism that github provides. Here is a summary of how it works:

1. If you don't already have one, you have to create your own fork of the MonoDevelop repository. You can do it using the Fork command available in the main page of the project in github.
2. Make and commit your changes in your forked repository.
3. In the main page of your forked repository, click on the Pull Request command.
4. In the Pull Request dialog, enter a descriptive comment of the change and add a recipient. You can use following users as recipients:
   
   • mhutch: ASP.NET, Mac port, MonoTouch, Moonlight, MonoMac, XML, T4
   • mkrueger: Text editor, C#, refactoring operations
   • slluis: everything else 

Commit Rules

There are a few rules to follow when committing code:

1. Enter a meaningful explanation in the commit log message.
2. When entering a message describing a change, take into account that the goal is to explain why the change was done, rather than what was changed. For example, the message "Added property X" is in general useless since it is obvious looking at the patch.
3. All changes included in a commit should be related and as atomic as possible. Here are some examples:
   • You do an API change that affects several projects across the source tree. All changes can go in a single commit.
   • You implement a new feature A, for example, in MonoDevelop.Projects. Then you implement another new feature B that uses A in MonoDevelop.Ide. Although those changes are related (B needs A), they should be committed separately, since they belong to two different features.
4. Don't do reformatting commits, unless you're the original author of the code.
5. Never remove copyright notices from the code.
6. Never remove licensing info from code.
7. Never commit code you didn't write yourself or code that doesn't have a suitable license.

Coding Guidelines

New code written for MonoDevelop should follow the generic Mono Coding Guidelines.

with the following exceptions:

• it is allowed to use camel case for field names.
• code must be indented using tabs, not spaces

You should also follow our Human Interface Guidelines when designing windows and dialogs.

A Note on Licensing

All new code must be licensed under either a MIT X11.

Code and libraries licensed under version 2 of the LGPL license are acceptable under extraordinary circumstances.

Code licensed under the GPL cannot be accepted.

Although addins that do not follow these rules cannot be accepted into the MonoDevelop source repository, they can be hosted elsewhere. However, this generally means that they are much less likely to be maintained and distributed.

Working on the Website

We are always looking for help on developing the Monodevelop web site. If you're interested, please contact lluis at ximian dot com. Currently, we're are looking for the following:

• Tutorials
• Screenshots
• Content writers

Any contributions you may have though would be appreciated. The list above is in no way all inclusive.