Contributing to Exiv2¶

All help is appreciated. All contributors are unpaid volunteers. If you really want to see something added to Exiv2 - volunteer!

1. Make code as simple as possible.
2. Shorter code is almost always better.
3. Every time you find a bug, update the code AND the test harness.
4. Every time you find a bug, consider if there are more instances of the same fault and fix them.
5. Deal with things immediately. Avoid putting things off for another day. There will never be more time than today.
6. Always inspect the build server when you've submitted code to be sure it has built and passed the test suite.
   http://exiv2.dyndns.org:8080
7. If you break the build on the trunk, please fix it immediately or revert the build breaker.

1. Look for patterns in the code and refactor them into functions.
2. Only use MACROs for simple things. (Professor Stroustrup would say NEVER use macros).
3. Eliminate constants in the code. Put them into a header file as a #define or enum to give it a symbolic name.
4. Be consistent. (that mostly follows from refactoring into functions).

1. Robin is available on Saturday afternoon in England for 1-to-1 with team members via Skype/Hangout/FaceTime/Messenger.
2. If you have to delay anything by more than a day, log an issue in Redmine to be certain it isn't forgotten.
3. Read the Forum and contribute. Everybody who asks a question might become a contributor. Courtesy earns rewards.

1. New contributors are asked to provide changes by sending a patch file.
2. You'll be granted write access when we know each other.
3. We have four servers: Apache, Redmine, SVN and Jenkins.
4. Exiv2 is open source. All contributors are required to wave all commercial and intellectual property rights to their contributions.

1. Most of the code in Exiv2 is beautiful and for that we have to thank Andreas. Read the code. Copy the style.
2. If in doubt, please ask for help. Remember, Exiv2 is used by millions of people. As a team our strength comes from working together.
3. Always execute your assignments or ask for help. Never promise and proceed to do nothing. That's not team work.
4. Discuss things openly in an issue report or Forum discussion. If you are confused and uncertain, take the conversation off-line. However you should publicly report the conclusion of an off-line discussion.

1. You don't need to be a C++ Expert.
2. Testing, forum correspondence, documentation, build, test and other skills are all very useful.
3. C++ to work on the core code

• Robin Mills