Nirjas welcomes any form of contribution or suggestions. We believe that open source is all about collaborative working to make the project and community stronger than ever. Whether you are a beginner or an experienced developer, each and every contribution counts.
You can contribute to Nirjas by:
- Opening a valid issue: visit https://github.com/fossology/nirjas/issues
- Help us in closing an existing issue
- Open a Pull Request
- Suggest us some new agent for license scanning
- Want to discuss something else: Reach out to us @ Slack
-
venv (for Python 3) allow you to manage separate package installations for different projects.
-
To create a virtual environment, go to your project’s directory and run venv.
-
On macOS and Linux:
python3 -m venv env
-
On Windows:
py -m venv env
The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it env.
-
On macOS and Linux:
source env/bin/activate
-
On Windows:
.\env\Scripts\activate
-
Leaving the virtual environment If you want to switch projects or otherwise leave your virtual environment, simply run:
deactivate
Nirjas uses GitHub's issue tracker. All bugs and enhancements should be listed so that we don't lose track of them, can prioritize and assign them to the relevant developer or maintainer.
Consider the following recommended best practice for writing issues, which are (Recommended but not limited to):
- More detailed description rather than one-liners
- Screenshots
- Providing example files and error logs
- How to reproduce it
- Details of your local system or environment that you're using
Please follow the Coding Style (PEP8)
Not Familiar with Git?
Invest a few minutes on our Git Tutorial
We are using the Feature Branch Workflow (also known as GitHub Flow), and prefer delivery as pull requests.
The cardinal rule for creating good commits is to ensure there is only one "logical change" per commit. Why is this an important rule?
-
The smaller the amount of code being changed, the quicker & easier it is to review & identify potential flaws.
-
If a change is found to be flawed later, it may be necessary to revert the broken commit. This is much easier to do if there are not other unrelated code changes entangled with the original commit.
-
When troubleshooting problems using Git's bisect capability, small well defined changes will aid in isolating exactly where the code problem was introduced.
-
When browsing history using Git annotate/blame, small well defined changes also aid in isolating exactly where & why a piece of code came from.
Things to avoid when creating commits
- Mixing whitespace changes with functional code changes.
- Mixing two unrelated functional changes.
- Sending large new features in a single giant commit.
We use git commit as per Conventional Changelog:
<type>(<scope>): <subject>
Example:
feat(CosineSim): Implemented similarity score to approximately match headers
Allowed types:
- feat: A new feature
- fix: A bug fix
- docs: Documentation only changes
- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, newline, line endings, etc)
- refactor: A code change that neither fixes a bug or adds a feature
- perf: A code change that improves performance
- test: Adding missing tests
- chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
Pull requests with patches, improvements and new features are a great help.
# Clone your fork of the repo into the current directory
git clone https://github.com/<USERNAME>/Nirjas.git
# Navigate to the cloned directory
cd Nirjas
# Assign the original repo to a remote called "upstream"
git remote add upstream [email protected]:fossology/Nirjas.git
git checkout master
git pull upstream master
git checkout -b <topic-branch-name>
git add <path/to/modified/file/>
git commit -m "write a commit message"
Examine the status of your working tree at each step to see if everything is clean
git status
Push your topic branch up to your fork:
git push origin <topic-branch-name>
A maintainer/developer will review and might suggest some changes before merging them into the repository.
Success!! 🎉 Well done! 🙇♂️
Thank you for reading through and we look forward to your valuable contribution! :smiley:
We appreciate the hard work and time of our contributors who have built and maintained the project! 🙌
You are Awesome! 🌟 🤩