Submissions

First and foremost please bear in mind that there is only a pair of overworked, underappreciated developers with both a life and a job so maintaining this project is rarely high up on the priority list. So please don't take offense if I don't immediately respond.

I want to submit a new feature or defect fix

Excellent! Being the sole admin on the project takes a toll so every little bit helps!! You can either send me a patch off the latest trunk or a git pull request.

That said there are a few guidelines to let you know what I look for and will help speed submission of a patch.

1. Tests! I am a big fan of TDD (Test Driven Development) so when I open up a patch I look for the tests that show me how the feature works and its value to the project and/or an example of the defect that the supplied code will fix. Sometimes I apply just the test and if they pass then the fix does nothing (I actually had a couple of those over the years). I look at submissions without tests like most people look at scam artists - promising something that will fix all my problems but not giving any proof. You can look at the opencsv test coverage report to see I am pretty proud of the test coverage so far. I don't care if 100% of the code is covered because your time is just as precious as mine and there is a law of diminishing returns but I do want to see 100% of the business cases covered (If you state your code does A, B, and C then there should be tests for all three with negative tests also).
2. Don't break existing tests! Alot of the tests were created to duplicate issues so if your tests breaks one of them you are reintroducing an old bug.
3. Don't change existing tests!! One of my favorite patch submissions came in the first year I was maintaining this project that stated "I am having a problem with the CSVReader. Attached is the patch to fix it. When I compiled the change there were three failed test. I fixed one test and deleted the other two because they were stupid." I kid you not - someone sent me that. Test that have issue or feature numbers are considered pretty much gospel. As stated above the tests are there to document the applications behavior and to prove defects are fixed. Test that have issue and feature numbers in the name I consider contracts to the users that the issue is resolved and I will make sure it stays resolve. If you are modifying existing test that means you are changing existing behavior and that is unacceptable (read on and I will explain why).
4. Don't change existing functionality - Honestly if you can do this without breaking the existing test then we need more tests. So if you are creating a new feature make sure it does not change existing functionality. If you have a bug...
5. Let us discuss together what is a bug before you spend time fixing it. There is a big difference between a bug in the code and code that bugs you. Just because something bugs you or is an incovenience does not mean you can change the behavior of the system because...
6. Keep in mind the other users. There are over a hundred downloads a day of openCSV just from sourceforge (I cannot even imagine the number from nexus). Features that may inconvience you might be neccessary for other users. I learned several times the hard way managing this project.
7. For features extension over modification is the way to go. For an example of this the new IterableCSVToBean. Instead of making the CSVToBean class iterable I copied the code to a new class with that functionality. My main plan is to go back and gut the existing CSVToBean class to contain an IterableCSVToBean using the existing tests to prove all functionality is still there but I want to make sure it is stable first because
8. People will use your code in the most unexpected, wildest, imaginative, and innovative ways. The code should be open to such usage instead of forcing them down a narrow path.
9. Please do a full maven build - I am surprised I never documented this before as pretty much every submission I have recieved I can tell they have done a mvn clean install. But please do a mvn clean install site:site to generate the site documentation - especially if you are updating the versions of dependencies in the pom file. I am now commenting in the pom file which versions should not be updated as the newer versions are built in java > 8 and have issues (at the time of this addition it is puppycrawl and asciidoctorj - which are used by the site generation but I am sure as time goes on more and more will be added to this list).

** I have an issue with opencsv or there is a feature I would like to see added **

Again, please bear in mind that this project has only a couple of developers wearing all the hats. With the limited amount of time we have to be very picky about what we work on so there are a couple of things that would really help speed things along.

1. Test data - Send a couple of lines of data that will cause the error and what you believe should be the expected result and the result you are getting. This will help me craft more tests and come up with a final solution.
2. Code example - a unit test or a small sample of the code that shows the reader/parser or writer that you are using.

One thing I will pretty much delete the request for (after explaining why) are "fixes" to make opencsv compliant to some standard. Bear in mind all the points I made to people creating new features and defect fixes. There are tens of thousands of users of opencsv so to me the defaults are pretty much a standard in their own right. Besides opencsv should have more than enough configuration options to support the standards. If not and/or the fact that the default settings don't match a beloved standard then submit a patch with a new RVC4180CSV or CSV1203 classes that extend the existing classes but follow desired standard without effecting the existing classes. I would consider that a win/win and there would have to be something seriously wrong with it (like little to no tests) for me to reject it.