Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
49 lines (33 loc) · 2.96 KB

CONTRIBUTING.md

File metadata and controls

49 lines (33 loc) · 2.96 KB
Raw

Contributing to the Repository

👍🎉 First off, thanks for taking the time to contribute! 🎉👍

Computer Programming can be tough, and everyone agrees on that. This project was made as an atttempt to collect and organize all the necessary problems one can face while programming and which one must know how to solve.

I'm really glad you're reading this, because we need volunteer developers to help this project come to fruition.

The following is a set of guidelines for contributing to the project 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.

Working on Issues

Please take a moment to request the assignment of a issue before you begin working on it. In open source projects, it is occasionally possible that multiple people are working on the same problem without being aware of one another. Assigning someone to an issue is merely a method of keeping track of who is working on what and removing confusion. It saves the contributor's time and resources, as well as the time and resources of the project maintainer.
You can have a look at all the open issues here. You can also open up new issues always!

Testing

Please check that code you create is acceptable and working. Use the testing methods present in the language that you choose to work with.

Submitting changes

Please send a GitHub Pull Request to Banque-De-Questions with a clear list of what you've done (read more about pull requests). When you send a pull request, we will love you forever 🫀. Please follow our coding conventions (below) and make sure all of your commits are atomic (one feature per commit).

Always write a clear log message for your commits. One-line messages are fine for small changes, but bigger changes should look like this:

$ git commit -m "A brief summary of the commit
> 
> A paragraph describing what changed and its impact."

Coding conventions

Start reading our code and you'll get the hang of it. We optimize for readability:

  • We indent using two spaces (soft tabs)
  • We ALWAYS put spaces after list items and method parameters ([1, 2, 3], not [1,2,3]), around operators (x += 1, not x+=1), and around hash arrows.
  • This is open source software. Consider the people who will read your code, and make it look nice for them. It's sort of like driving a car: Perhaps you love doing donuts when you're alone, but with passengers the goal is to make the ride as smooth as possible.
  • Always use image_path or image_tag when referring to images. Never prepend "/images/" when using image_path or image_tag.
  • Always use cwd-relative paths rather than root-relative paths in image URLs in any CSS. So instead of url('/images/blah.gif'), use url('../images/blah.gif').

Thanks,
The Project Maintainer