Join the community

• Chat: We have an active community chat on Gitter. You can register for free their with your Github identity.
• Tweet: Janssen is on Twitter too. Follow us there to stay up to date on release announcements and news around Janssen.
• Email: We have an active mailing list also.
• Google group : You can subscribe to the Janssen Google Group and post messages there.

Contribute

Please go through Janssen contribution guidelines so it’ll be easy for you to make successful contributions.

In case you are first-time contributor, then you can start with Janssen good first issues list These are issues where you can easily contribute and community members will guide and support your contribution as always.

Janssen workspace setup guide will help you setup your workspace where you can build and test your code changes.

There are many ways of contributing to Janssen. And it is not just limited to fixing issues and raising pull requests. Janssen welcomes you to raise issues, respond to queries, suggest new features, tell us your experience with Janssen, be it good or bad. All these are contributions towards making Janssen better.

Contribution guidelines

We are really glad you are reading this, because we need volunteer developers to help this project come to fruition.

• Code of Conduct
• Community
• Issues
  • Triaging
    • More about labels
• Pull Requests
  • Commit convention
    • Rule type
• Coding Guidelines
• Developer Certificate Of Origin

Code of Conduct

Janssen project has a Code of Conduct to which all contributors must adhere, please read it before interacting with the repository or the community in any way.

Community

We have setup a community chat on Gitter. Please raise discussion and support requests here first.

Join the google group mailing list for news, announcements, and a Google calendar invite for our community open source meetings.

We also run monthly community calls which are open calls to discuss Janssen projects from an user perspective. In case you want to discuss a topic during those calls you can simply propose it opening an issue in the community repository and join the call!

Issues

There are different kinds of issues you can open:

• Bug report:

  You believe you found a problem in a project and you want to discuss and get it fixed, creating an issue this type is the best way to do so.

• Development item:

  This type of issue provides tracking mechanism for development effort. It should be opened by developers who want to contribute code to Janssen. It has checklist driven approach that helps developers make high-quality contributions.

• Feature request:

  Any kind of new feature need to be discussed. do you want a new rule or a new feature? This is the kind of issue you want to open. Be very good at explaining your intent, it’s always important that others can understand what you mean in order to discuss, be open and collaborative in letting others help you getting this done!

• Failing tests:

  You noticed a flaky test or a problem with a build? This is the kind of issue to triage that!

• Report a security vulnerability:

  If you find a security vulnerability, please share it with Janssen team by following steps as mentioned in Janssen security policy.

The best way to get involved is through issues. Here you can help in many ways:

• Issues triaging: participating in the discussion and adding details to open issues is always a good thing, sometimes issues need to be verified, you could be the one writing a test case to fix a bug!
• Helping to resolve the issue: you can help in getting it fixed in many ways, more often by opening a pull request. In case you are first-time contributor, then you can start with our good first issues list These are issues where you can easily contribute and community members will guide and support your contribution as always.

Triaging

We need help in categorizing issues. Thus any help is welcome!

When you triage an issue, you:

• assess whether it has merit or not

• quickly close it by correctly answering a question

• point the reporter to a resource or documentation answering the issue

• tag it via labels, projects, or milestones

• take ownership submitting a PR for it, in case you want 😇

More about labels

These guidelines are not set in stone and are subject to change.

Anyway a kind/* label for any issue is mandatory.

This is the current label set we have.

You can use commands - eg., /label <some-label> to add (or remove) labels or manually do it.

The commands available are the following ones:

/[remove-](area|kind|priority|triage|label)

Some examples:

• /area rules
• /remove-area rules
• /kind kernel-module
• /label good-first-issue
• /triage duplicate
• /triage unresolved
• /triage not-reproducible
• /triage support
• …

Pull Requests

Thanks for taking time to make a pull request (hereafter PR).

In the PR body, feel free to add an area label if appropriate by typing /area <AREA>, PRs will also need a kind, make sure to specify the appropriate one by typing /kind <KIND>.

The PR template is there to guide you through the process of opening it.

Also feel free to suggest a reviewer with /cc @theirname, or to assign an assignee using /assign @nickname.

Once your reviewer is happy, they will say /lgtm which will apply the lgtm label, and will apply the approved label if they are an owner for the project.

Your PR will be automatically merged once it has the lgtm and approved labels, does not have any do-not-merge/* labels, and all status checks (eg., rebase, tests, DCO) are positive.

Commit convention

As commit convention, we adopt Conventional Commits v1.0.0, we have an history of commits that do not adopt the convention but any new commit must follow it to be eligible for merge.

Rule type

Besides the classic types, we adopt a type for rules, rule(<scope>):. Example:

rule(Write below monitored dir): make sure monitored dirs are monitored.

Each rule change must be on its own commit, if a change to a macro is done while changing a rule they can go together but only one rule per commit must happen.

If you are changing only a macro, the commit will look like this:

rule(macro user_known_write_monitored_dir_conditions): make sure conditions are great

Coding Guidelines

Developer Certificate Of Origin

The Developer Certificate of Origin (DCO) is a lightweight way for contributors to certify that they wrote or otherwise have the right to submit the code they are contributing to the project.

Contributors to the Janssen project sign-off that they adhere to these requirements by adding a Signed-off-by line to commit messages.

This is a commit message

Signed-off-by: Foo Bar <foobar@spam.org>

Git even has a -s command line option to append this automatically to your commit message:

$ git commit -s -m 'This is my commit message'