Open source projects thrive on contributions from the developer community. Would you like to get involved? There is plenty that you can do to help!
This is a general guide about how to contribute to Dapper.SimpleLoad. It is not a set of hard and fast rules. Please raise any questions on the Dapper.SimpleLoad Developers List.
-
Documentation - you won't need to read very far to realise that this is something I suck at, so I'd really appreciate your help if you're good at it.
-
Testing - both Dapper.SimpleSave and Dapper.SimpleLoad have been fairly well tested in the context of the app for which they were originally developed. However, their own automated test suites are somewhat lacking - particularly in the case of SimpleLoad. SimpleLoad primarily needs tests that hit a real database and verify what was loaded is what really exists in the database.
-
Support for RDBMS platforms other than SQL Server. In particular: Oracle, PostgreSQL, MySQL; possibly others. In theory this shouldn't be too difficult because it just affects the script generation portion of the process. We can also take advantage of functionality, such as deferred referential integrity checks, offered by platforms such as Oracle.
Bugs and feature requests should be reported in the GitHub Issue tracker if they have not been previously submitted. If there's already an issue filed please feel free to add more detail or contribute to the discussion on that issue.
When reporting a bug or issue, please include all pertinent information. This typically includes:
-
Dapper.SimpleLoad package installed (Example: Dapper.SimpleLoad 1.0.65)
-
Development platform, including .NET and SQL Server versions and web server (if relevant)(Example: .NET 4.5.1 with SQL Server 2014 Developer Edition on IIS Express)
-
Steps to reproduce the bug/example code
-
Any error messages and stack trace
It is also quite helpful to include the relevant portions of your log file since, if you have log4net configured, SimpleLoad will write a record of scripts build and executed, along with any errors, to it. Note that these are logged mostly at INFO level so you may need to tweak your log4net configuration to see them.
Bugs will be addressed as soon as humanly possible, but please allow ample time. For quicker responses, you may also choose to implement and contribute the bug fix via a pull request.
Dapper.SimpleLoad often maintains several issues that are good for first-timers tagged as Jump In on GitHub. If one piques your interest, feel free to work on it and let us know if you need any help doing so.
For those looking to get more deeply involved, reach out to find out about our current efforts and how you can help. Medium or large contributions should begin by sending a message to the Dapper.SimpleLoad Developers List or should start as a basic pull request so that a discussion can be started.
The message should describe the contribution you are interested in making, and any initial thoughts on implementation. This will allow the community to discuss and become involved with you from the get go. If you receive positive feedback on the mailing list, go ahead and start implementation! You should also sign and return the Contributor License Agreement, which is required for the Dapper.SimpleLoad team to accept your contribution.
The Dapper.SimpleLoad team uses the issue tracking features of GitHub which is a good place to look through if you want to get involved but aren't quite sure how.
If you love SimpleLoad, tell others about it! Present SimpleLoad at a company tech talk, your local user group or submit a proposal to a conference about how you are using SimpleLoad.
Documentation is a key differentiator between good projects and great ones. Whether you’re a first time OSS contributor or a veteran, documentation is a great stepping stone to learn our contribution process.
Contributing to SimpleLoad documentation is dead simple. To make it so easy, we're using SimpleLoad's GitHub Wiki as the entry point for documentation - each page within the docs section of the site has a link to take you straight to the page where you can make changes directly. GitHub Wikis provide an online WYSIWYG interface for adding and editing the docs, completely in browser, using Markdown.
SimpleLoad follows a loose set of coding conventions. Chiefly among them:
-
Ensure all unit tests pass successfully
-
Cover additional code with passing unit tests
-
Try not to add any additional StyleCop warnings to the compilation process
-
Try to avoid breaking API changes, unless there is exceptionally good reason for them
-
Stick to the existing code style in terms of spaces, braces, naming conventions, etc. None of these are written down but you should be able to figure them out just by looking at the code.
-
Ensure your Git autocrlf setting is false because we don't like our SCM to modify files.