The following is a set of guidelines for contributing to "cheapBuy" and its packages, which are hosted in the cheapBuy on GitHub. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.
- Pass all the test cases that we have mentioned in the test.py.
- Update the README.md with the changes you have made.
- Add all the unnecessary build files have to the .gitignore file.
- Mention any new installatiuon dependencies in the requirements.txt file.
- You need to start an issue on the project kanban board.
- You need to move this issue from to_do to in progress.
- Create a new branch and clone the repository.
- Change the branch of the code using git checkout.
- Make the required changes and commit everything to the newly created branch.
- Create a new pull request.
-
.github workflows all github workflow yaml files
-
docs proj1rubrics.md
-
.gitignore
-
.travis.yml
-
CITATION.md
-
CODE_OF_CONDUCT.md
-
CONTRIBUTING.md
-
LICENSE
-
README.md
-
requirements.txt
-
setup.py
-
code init.py
-
data README.md
-
test README.md test.py
This project and everyone participating in it is governed by the Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to [email protected].
This section gives detailed information on how to report bugs. Reporting a bug will help the community and maintainers of the repository.
Before reporting any bug, make sure it is correct and you have all the details with you. Fot creating any bug report, please fill out the required template. This template will give us necessary information to help solve a bug faster.
The following is a list of items you need to check before submitting a bug report.
debugging guide. Check out this debugging guide, which helps you to find the cause of the problem and you may fix it by yourself manually.
cursory search A cursory search is necessary to check if the reported bug is already mentioned before or not. You can add to the existing bug report if the issue is still open.
GitHub issues You can track the bugs from this. For the repository that has bug, create an issue and fill out the template to give details of the bug.
- To identify the problem, give the issue a clear and informative term.
- Describe in as much detail as possible to duplicate the problem. Explain the problem and explain about the exact command sused in the terminal which caus ethe bug to occur.
- To demonstrate the steps, give specific examples. Include links to files or GitHub projects, or copy/pasteable snippets, which you use in those examples. If you're providing snippets in the issue, use Markdown code blocks.
- Specify what is the problem beavior and what you expected to see and why
- If possible, include screenshots and animated GIFs that clearly demonstrate the problem. this tool- to record GIFs on macOS and Windows, and this tool or this tool on Linux.
- To include a crash report, add a stack trace from the operating system. For macOS,
Console.app
under "Diagnostic and usage information" > "User diagnostic reports" has crash report. Include the crash report in the issue in a code block, a file attachment, or put it in a gist and provide link to that gist. - For performance or memory issues, include a CPU profile capture with your report.
Provide more context by answering these questions:
- If the problem started happening recently then try downloading the old version of the packages and the code.
- Include details about your configuration and environment.
- What is the name and version of the OS you're using?
- Are you running the project in a virtual environment?
- Which packages have installed in your system? You can get a list of packages installed by running 'apm list --installed'
Any suggesting enhancements like adding new features or imporving existing functionalities, etc can done by following the below guidelines. They help maintainers understand your improvement.
the template- this template is to be filled to add suggestions. These can include the steps that you imagine you would take if the feature you're requesting existed.
debugging guide. Check out this debugging guide, which helps you to find the cause of the problem and you may fix it by yourself manually.
cursory search A cursory search is necessary to check if the reported bug is already mentioned before or not. You can add to the existing bug report if the issue is still open.
GitHub issues You can track the bugs from this. For the repository that has bug, create an issue and fill out the template to give details of the bug.
- To identify the problem, give the issue a clear and informative term.
- Describe in as much detail as possible to duplicate the problem. Explain the problem and explain about the exact command sused in the terminal which caus ethe bug to occur.
- To demonstrate the steps, give specific examples. Include links to files or GitHub projects, or copy/pasteable snippets, which you use in those examples. If you're providing snippets in the issue, use Markdown code blocks.
- Specify what is the problem beavior and what you expected to see and why
- If possible, include screenshots and animated GIFs that clearly demonstrate the problem. this tool- to record GIFs on macOS and Windows, and this tool or this tool on Linux.
- To include a crash report, add a stack trace from the operating system. For macOS,
Console.app
under "Diagnostic and usage information" > "User diagnostic reports" has crash report. Include the crash report in the issue in a code block, a file attachment, or put it in a gist and provide link to that gist. - For performance or memory issues, include a CPU profile capture with your report.
beginner
and help-wanted
issues can help you getting started to contribute your first contribution:
- [Beginner issues][beginner] - issues which should only require a few lines of code, and a test or two.
- [Help wanted issues][help-wanted] - issues which should be a bit more involved than
beginner
issues.
For developing the project, each section is done locally.
The goals to be considered are:
- Focus of problems that are more valuable to users of the platform
- Engage the community in working toward the best possible solution
- To review contributions, enable a sustainable system for the maintainers
Please follow these steps to have your contribution considered by the maintainers:
- Follow the styleguides
- Verify that all status checks are passing once the pull request is submitted.
What if the status checks are failing?
If a status check is failing, and you believe that the failure is unrelated to your change, please leave a comment on the pull request explaining why you believe the failure is unrelated. A maintainer will re-run the status check for you. If we conclude that the failure was a false positive, then we will open an issue to track that problem with our status check suite.
While the prerequisites above must be satisfied prior to having your pull request reviewed, the reviewer(s) may ask you to complete additional design work, tests, or other changes before your pull request can be ultimately accepted.
-
Use the present tense ("Add feature" not "Added feature")
-
Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
-
Limit the first line to 72 characters or less
-
Reference issues and pull requests liberally after the first line
-
When only changing documentation, include
[ci skip]
in the commit title -
Consider starting the commit message with an applicable emoji:
- 🎨
:art:
when improving the format/structure of the code - 🐎
:racehorse:
when improving performance - 🚱
:non-potable_water:
when plugging memory leaks - 📝
:memo:
when writing docs - 🐧
:penguin:
when fixing something on Linux - 🍎
:apple:
when fixing something on macOS - 🏁
:checkered_flag:
when fixing something on Windows - 🐛
:bug:
when fixing a bug - 🔥
:fire:
when removing code or files - 💚
:green_heart:
when fixing the CI build - ✅
:white_check_mark:
when adding tests - 🔒
:lock:
when dealing with security - ⬆️
:arrow_up:
when upgrading dependencies - ⬇️
:arrow_down:
when downgrading dependencies - 👕
:shirt:
when removing linter warnings
#### CoffeeScript Styleguide
- 🎨
-
Set parameter defaults without spaces around the equal sign
clear = (count=1) ->
instead ofclear = (count = 1) ->
-
Use spaces around operators
count + 1
instead ofcount+1
-
Use spaces after commas (unless separated by newlines)
-
Use parentheses if it improves code clarity.
-
Prefer alphabetic keywords to symbolic keywords:
a is b
instead ofa == b
-
Avoid spaces inside the curly-braces of hash literals:
{a: 1, b: 2}
instead of{ a: 1, b: 2 }
-
Include a single line of whitespace between methods.
-
Capitalize initialisms and acronyms in names, except for the first word, which should be lower-case:
getURI
instead ofgetUri
uriToOpen
instead ofURIToOpen
-
Use
slice()
to copy an array -
Add an explicit
return
when your function ends with afor
/while
loop and you don't want it to return a collected array. -
Use
this
instead of a standalone@
return this
instead ofreturn @
-
Place requires in the following order:
- Built in Node Modules (such as
path
) - Local Modules (using relative paths)
- Built in Node Modules (such as
-
Place class properties in the following order:
- Class methods and properties (methods starting with a
@
) - Instance methods and properties
- Class methods and properties (methods starting with a
- Use Markdown.
- Reference methods and classes in markdown with the custom
{}
notation:- Reference classes with
{ClassName}
- Reference instance methods with
{ClassName::methodName}
- Reference class methods with
{ClassName.methodName}
- Reference classes with
Code of Conduct was adapted from [Contributor Covenant][homepage], version 2.0, available at https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.