Contributing to Exiv2¶
All help is appreciated. All contributors are unpaid volunteers. If you really want to see something added to Exiv2 - volunteer!Principles:
- Make code as simple as possible. Shorter code is almost always better.
- Every time you fix a bug, update the code AND the test harness AND the man page.
- Every time you fix a bug, consider if there are more instances of the same fault AND fix them all.
- Deal with things immediately. Avoid putting things off for another day. There will never be more time than today.
- Always inspect the build server when you've submitted code to be sure it has built and passed the test suite.
- If you break the build on the trunk, please fix it immediately or revert the build breaker.
- Look for patterns in the code and refactor them into functions.
- Only use MACROs for simple things. Professor Stroustrup would say NEVER use macros.
- Eliminate constants in the code. Put them into a header file as enum or a #define to give it a symbolic name.
- Be consistent. This mostly follows from refactoring into functions.
- Robin is available on Saturday afternoon in England for 1-to-1 with team members via Skype/Hangout/FaceTime/Messenger.
- If you have to delay anything by more than a day, log an issue in Redmine to be certain it isn't forgotten.
- Read the Forum and contribute. Everybody who asks a question might become a contributor. Courtesy earns rewards.
- New contributors are asked to provide changes by sending a patch file.
- You'll be granted write access when we know each other.
- We have four servers: Apache, Redmine, SVN and Jenkins.
- 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.
- Most of the code in Exiv2 is beautiful and for that we have to thank Andreas. Read the code. Copy the style.
- If in doubt, please ask for help. Remember, Exiv2 is used by millions of people. As a team our strength comes from working together.
- Always execute your assignments or ask for help. Never promise and proceed to do nothing. That's not team work.
- 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.
- You don't need to be a C++ Expert.
- Testing, forum correspondence, documentation, build, test and other skills are all very useful.
- C++ to work on the core code
- Knowledge of MetaData, Photography, Photo/Video applications from Adobe/Apple/Google/Microsoft