From 1dc5237ee2324fe5e1cb70c8bf653722a3eabcac Mon Sep 17 00:00:00 2001 From: Michael Boelen Date: Mon, 14 Sep 2015 14:09:36 +0200 Subject: [PATCH] Updated Developer Guide (markdown) --- Developer-Guide.md | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/Developer-Guide.md b/Developer-Guide.md index b4140c1..5130fd9 100644 --- a/Developer-Guide.md +++ b/Developer-Guide.md @@ -22,4 +22,25 @@ Supporting documents and scripts are stored here. Like any programming language, there are different ways to keep a project structured. It ranges from variable names, up to spacing. So we provide some guidelines to keep the structure and flexible enough for further expansion. * Identitation is done with 4 spaces (no tabs) -* Variables are capitalized, optional with an underscore to "split" words \ No newline at end of file +* Variables are capitalized, optional with an underscore to "split" words + + +# Contribute + +## Preparing + +If you use Git already, simply clone the project to your local system. Otherwise work with a local copy. At the GitHub page you can download the master.zip file, containing the latest master release. + +## Making changes + +Next step is making your local changes and test them. + +**Tip:** To simplify testing, you don't have Lynis to perform all tests. Use --tests-category or --tests to specifically decide what tests to run. + +## Testing your changes + +To improve the quality of your changes, tests should limit the amount of screen output. Important details should be logged to the log file, using the `logtext` function. + +## Send in your changes + +Last step is creating a pull request. Provide a clear description on what the pull request is about (and why). If you have multiple changes to different tests, split them into multiple pull requests. This way it is easier to check and implement them in the master branch. \ No newline at end of file