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. Shorter code is almost always better.
2. Every time you fix a bug, update the code AND the test harness AND the man page.
3. Every time you fix a bug, consider if there are more instances of the same fault AND fix them all.
4. Deal with things immediately. Avoid putting things off for another day. There will never be more time than today.
5. 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
6. 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 enum or a #define to give it a symbolic name.
4. Be consistent. This 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 free software licensed under the GPL version 2. Contributions of code and/or test images or data will need to be licensed under the terms.

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 and 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
4. Knowledge of MetaData, Photography, Photo/Video applications from Adobe/Apple/Google/Microsoft

• Robin Mills