Added contribution guide (#627) (#630)

* Added contribution guide

* Added email id in Code of conduct

CODEOWNERS

@@ -0,0 +1,19 @@
+# This is a comment.
+# Each line is a file pattern followed by one or more owners.
+# More on CODEOWNERS files: https://help.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners
+
+# Entries that are commented out have maintainers that are not in the
+# Be-Secure organization and so cannot be automatically added as reviewers.
+#
+# We retain those as documentation of who agreed to maintain, but they
+# cannot be used automatically by GitHub's pull request workflow and would
+# make GitHub consider this file invalid if not commented.
+
+# For any changes, Unless a later match takes precedence, these maintainer will be requested for review
+*     @sudhirverma @harimohanr
+
+# For docs and other md files
+*.md  @sudhirverma @asa1997 @harimohanr @panickervinod
+
+# For source code changes
+src/* @sudhirverma @asa1997 @harimohanr

CODE_OF_CONDUCT.md

@@ -0,0 +1,132 @@
+
+# Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, caste, color, religion, or sexual
+identity and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery, and sexual attention or advances of
+  any kind
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or email address,
+  without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Community leaders have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, and will communicate reasons for moderation
+decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official e-mail address,
+posting via an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the community leaders responsible for enforcement at
+[email protected].
+All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series of
+actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or permanent
+ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior, harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within the
+community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.1, available at
+[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
+
+Community Impact Guidelines were inspired by
+[Mozilla's code of conduct enforcement ladder][Mozilla CoC].
+
+For answers to common questions about this code of conduct, see the FAQ at
+[https://www.contributor-covenant.org/faq][FAQ]. Translations are available at
+[https://www.contributor-covenant.org/translations][translations].
+
+[homepage]: https://www.contributor-covenant.org
+[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
+[Mozilla CoC]: https://github.com/mozilla/diversity
+[FAQ]: https://www.contributor-covenant.org/faq
+[translations]: https://www.contributor-covenant.org/translations
+

CONTRIBUTING.md

@@ -0,0 +1,144 @@
+# Contributing to BeSLighthouse
+
+Thank you for contributing your time and expertise to the BeSLighthouse project. This document provides guidance on BeSLighthouse contribution recommended practices. It covers what we're looking for in order to help set expectations and help you get the most out of participation in this project.
+
+# Code of Conduct
+
+This project adheres to the Contributor Covenant code of [conduct](https://github.com/Be-Secure/BeSLighthouse/blob/main/CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code.
+
+# Using GitHub Issues
+
+We use GitHub [issues](https://github.com/Be-Secure/BeSLighthouse/issues) to track bugs and enhancements. If you have a general question, you can start a discussion [here](https://github.com/Be-Secure/BeSLighthouse/discussions).
+
+If you are reporting a bug, please help to speed up problem diagnosis by providing as much information as possible. Ideally, that would include a small sample project that reproduces the problem.
+
+# Contributing a Pull Request
+
+If you are a new contributor to BeSLighthouse, or looking to get started committing to the Be-Secure ecosystem, here are a couple of tips to get started.
+
+First, the easiest way to get started is to make fixes or improvements to the documentation. This can be done completely within GitHub, no need to even clone the project!
+
+You can check the documentations in below links to get a feel of what we are doing,
+
+- [Be-Secure ecosystem](https://be-secure.github.io/Be-Secure/).
+- [BeSLighthouse Readme](./README.md).
+
+If you feel like you are stuck somewhere, please start a [discussion](https://github.com/Be-Secure/BeSLighthouse/discussions) and we will reach out to your queries as soon as we can.
+
+# Maintainers
+
+Maintainers are key contributors to our community project.
+
+For code that has a listed maintainer or maintainers in our [CODEOWNERS](./CODEOWNERS) file, the Be-Secure team will highlight them for participation in PRs which relate to the area of code they maintain. The expectation is that a maintainer will review the code and work with the PR contributor before the code is merged by the Be-Secure team.
+
+If an unmaintained area of code interests you and you'd like to become a maintainer, you may simply make a PR against our [CODEOWNERS](./CODEOWNERS) file with your github handle attached to the appropriate area. If there is a maintainer or team of maintainers for that area, please coordinate with them as necessary.
+
+# Proposing a Change
+
+In order to be respectful of the time of community contributors, we aim to discuss potential changes in GitHub issues prior to implementation. That will allow us to give design feedback up front and set expectations about the scope of the change, and, for larger changes, how best to approach the work such that the BeSLighthouse team can review it and merge it along with other concurrent work.
+
+If the bug you wish to fix or enhancement you wish to implement isn't already covered by a GitHub issue that contains feedback from the BeSLighthouse team, please do start a discussion (either in a new GitHub issue or an existing one, as appropriate) before you invest significant development time. If you mention your intent to implement the change described in your issue, the BeSLighthouse team can, as best as possible, prioritize including implementation-related feedback in the subsequent discussion.
+
+# Reporting Security Vulnerabilities
+
+If you think you have found a security vulnerability in our project please DO NOT disclose it publicly until we’ve had a chance to fix it. Please don’t report security vulnerabilities using GitHub issues, instead please reach out to [email protected].
+
+# Pull Request Lifecycle
+
+1. You are welcome to submit a [draft pull request](https://github.blog/2019-02-14-introducing-draft-pull-requests/) for commentary or review before it is fully completed. It's also a good idea to include specific questions or items you'd like feedback on.
+2. Once you believe your pull request is ready to be merged you can create your pull request.
+3. When time permits BeSLighthouse's core team members will look over your contribution and either merge, or provide comments letting you know if there is anything left to do. It may take some time for us to respond. We may also have questions that we need answers about the code, either because something doesn't make sense to us or because we want to understand your thought process. We kindly ask that you do not target specific team members.
+4. If we have requested changes, you can either make those changes or, if you disagree with the suggested changes, we can have a conversation about our reasoning and agree on a path forward. This may be a multi-step process. Our view is that pull requests are a chance to collaborate, and we welcome conversations about how to do things better. It is the contributor's responsibility to address any changes requested. While reviewers are happy to give guidance, it is unsustainable for us to perform the coding work necessary to get a PR into a mergeable state.
+5. In some cases, we might decide that a PR should be closed without merging. We'll make sure to provide clear reasoning when this happens. Following the recommended process above is one of the ways to ensure you don't spend time on a PR we can't or won't merge.
+
+## Getting Your Pull Requests Merged Faster
+
+It is much easier to review pull requests that are:
+
+1. Well-documented: Try to explain in the pull request comments what your change does, why you have made the change, and provide instructions for how to produce the new behavior introduced in the pull request. If you can, provide screen captures to show what the changes look like. This helps the reviewers understand and test the change.
+2. Small: Try to only make one change per pull request. If you found two bugs and want to fix them both, that's awesome, but it's still best to submit the fixes as separate pull requests. This makes it much easier for reviewers to keep in their heads all of the implications of individual code changes, and that means the PR takes less effort and energy to merge. In general, the smaller the pull request, the sooner reviewers will be able to make time to review it.
+3. Passing checks: Based on how much time we have, we may not review pull requests which aren't passing our checks. If you need help figuring out why checks are failing, please feel free to ask, but while we're happy to give guidance it is generally your responsibility to make sure that checks are passing. If your pull request changes an interface or invalidates an assumption that causes a bunch of checks to fail, then you need to fix those checks before we can merge your PR.
+
+If we request changes, try to make those changes in a timely manner. Otherwise, PRs can go stale and be a lot more work for all of us to merge in the future.
+
+Even with everyone making their best effort to be responsive, it can be time-consuming to get a PR merged. It can be frustrating to deal with the back-and-forth as we make sure that we understand the changes fully. Please bear with us, and please know that we appreciate the time and energy you put into the project.
+
+# PR Checks
+
+The following checks run when a PR is opened:
+
+1. Contributor License Agreement (CLA): If this is your first contribution to BeSLighthouse you will be asked to sign the CLA.
+
+# Contributing Steps
+
+- Identify an existing issue you would like to work on, or submit an issue describing your proposed change to the repo in question.
+- The repo owners will respond to your issue promptly.
+- Fork the desired repo, develop and test your code changes.
+- Submit a pull request with a link to the issue.
+
+# Branching and Release Strategy
+
+Here we discuss the branching and release strategy for our projects. It ensures a structured approach to development, testing, and release management, leading to stable and reliable software releases.
+
+## Branches
+
+1. **Main Branch (main)**:
+
+    - The `main` branch represents the stable version of the software.
+    - Only production-ready code is merged into this branch.
+    - Stable releases are tagged from this branch.
+
+2. **Development Branch (develop)**:
+
+    - The `develop` branch serves as the integration branch for ongoing development work.
+    - Automated testing is conducted when the pull request is raised to the `develop` branch.
+    - All feature branches are merged into `develop` via pull requests.
+    - Once changes are validated, an RC (Release Candidate) is prepared for testing.
+
+## Pull request process
+
+1. **Feature Development**:
+
+    - Create a feature branch off `develop` for each new feature or bug fix.
+    - Name the branch descriptively (e.g., `feature/new-feature`).
+    - Implement the changes in the feature branch.
+
+2. **Pull Requests**:
+
+    - Once the feature is ready, open a pull request from the feature branch to `develop`.
+    - Ensure the PR title and description are clear and descriptive.
+    - Various automated checks will be done on the files changed.
+    - Resolve any failing checks promptly.
+    - Reviewers will provide feedback and approve the PR.
+
+3. **Release Candidate (RC)**:
+
+    - When `develop` is stable, prepare an RC from the `develop` branch for testing.
+    - The RC undergoes end-to-end testing to ensure it meets quality standards.
+
+4. **Stable Release**:
+
+   - After successful testing, the changes will be merged from `develop` into `main`.
+   - Merge commit will be tagged as a stable release.
+
+## Other guidelines
+
+1. **Branch Naming**:
+
+    - Use meaningful names for branches (e.g., `feature/issue-123`).
+    - Prefix feature branches with `feature/`, bug fix branches with `bugfix/`, etc.
+
+2. **Pull Requests**:
+
+    - Assign appropriate reviewers to PRs.
+    - Provide a clear description of the changes in the PR.
+    - Link the PR to an existing issue.
+
+3. **Testing**:
+
+    - Test changes locally before opening a PR.
+
+4. **Communication**:
+
+    - Discuss major changes or architectural decisions with the community.
+    - Communicate any delays or blockers promptly.