Skip to content

Latest commit

 

History

History
138 lines (91 loc) · 8.68 KB

CONTRIBUTING.md

File metadata and controls

138 lines (91 loc) · 8.68 KB
Raw

LinksHub contributing guidelines

Thank you for taking the time to contribute to our project. Please take a moment to read the following guidelines before contributing:

⚠️IMPORTANT Note

Pull Requests having no issue associated with them will not be accepted. Firstly get an issue assigned, whether it's already opened or raised by you, and then create a Pull Request.

An automated process has been implemented to ensure timely management of Pull Requests (PRs) on this platform. PRs that have been open for a duration exceeding 45 days will be automatically closed, so please plan accordingly.

Prerequisites

  • Open Source Etiquette: If you've never contributed to an open source project before, have a read of Basic etiquette for open source projects.

  • Basic familiarity with Git and GitHub: If you are also new to these tools, visit GitHub for complete beginners for a comprehensive introduction to them

  • Node.js is installed.

How to Contribute 🤔

  • Look at the existing Issues or create a new issue!
  • Fork the Repo. Then, create a branch for any issue that you are working on. Finally, commit your work.
  • Create a Pull Request (PR), which will be promptly reviewed and given suggestions for improvements by the community.
  • Add screenshots or screen captures to your Pull Request to help us understand the effects of the changes proposed in your PR.

Appending new Categories 🔗

✨ You can also create issue(s) for inserting your categories and someone else will take care of them.

🌟Follow these steps to add your Category/Subcategory to the Hub

  • To add a newly created category or subcategory, include them in the data.ts & index.ts files located in the database folder.

  • Each category has its own folder with its name

  • Ensure that every subcategory is placed in its respective category folder.

    For example, if images is a subcategory, it should be inside the frontend folder, which is a category.

  • To add a new category, create a folder with its name.

    For example, create a folder named Resources

  • If you want to add a new subcategory, add it in data.ts under the correct category, and provide the appropriate url. You can refer to the examples in the file.

  • Make sure to export the newly created JSON file in the index file.

Appending new Links 🔗

✨ You can also create issue(s) to suggest new links, and someone else will take care of them.

🌟Follow these steps to add your links to the Hub

  • Choose the category and subcategory under which you want to add the resource.

  • Locate the appropriate structure: database/category_name/subcategory_name.json

For example, to add a resource in the fonts subcategory under the frontend category, navigate to database/frontend/fonts.json.

  • The values in the JSON file should follow this pattern for the subcategory object:

      name:'', 
  description:'',
  url:'',
  category:'', 
  subcategory:''

    Details

    • name: Name of the site

    • description: A brief description of what the site does

    • url: Add a valid URL of the site

    • category: Choose an existing category or create a new one following the instructions mentioned above.

    • subcategory: Choose an existing subcategory or create a new one following the instructions mentioned above.

    • language: This field is included for some of the resources, such as React resources or YouTube channel links. If multiple languages are involved, prioritize English if available. Otherwise, choose a language that you deem necessary.

  • You can use JSONLint to check the correctness of the JSON to avoid failing tests during pull requests.

NOTE When adding YouTube channel link, please specify language of the channel they are using to teach in for example English, Hindi, Spanish etc. In cases where the language is NOT specified, then just remove the language property.

⚠️Important

  • Do not make duplicate entries. Always confirm that an entry does not exist by searching through the JSON file.
  • Ensure that your entries are error-free by double-checking before staging your changes.
  • Your entries should follow the above structure.

Issues

  • Select an issue template from issues tab. Otherwise, choose Other if it doesn't match what you're looking for.

  • When creating an issue, make sure you fill up all the fields properly.

  • Make sure that you are NOT raising a duplicate issue.

  • If you want to work on the issue, please click on the I am willing to work on this issue checkmark.

  • Note: If you are apart of GSSoC'23, please check the I am a GSSoC'23 contributor check mark as shown in the image below:
    issue checkmark for gssoc'23

  • Do not create the PR until you have confirmed with the maintainers that you are participating in this program

  • If you aren't the owner of the issue, please comment that you're willing to work on the issue and wait for maintainers to assign you the issue. Also, don't work on the issue if you're NOT assigned.

  • Please do not start working on the issue if you aren't yet assigned.

  • Work on only ONE issue at a time.

Closing the issue

  • If you decide to close the issue, please leave a brief comment describing why(e.g., I'm busy with other obligations.) before you do.
  • Note: If the Pull Request associated with the issue gets merged and the issue still remains open, it's your responsibility to close the issue.

Commits

  • Please keep your commit messages short and clear.
  • Use type: subject format for writing your commit messages. type could be one the followings:
    • feat: use this if you're adding any new feature
    • fix: use this if you're fixing anything in the codebase
    • chore: use this when you're adding new links/resources AND when making any small changes (ex. chore: add resource_name in subcategory_name category_name ) If you need more tips, check out Conventional Commits

Making Pull Requests

  1. When you submit a pull request, several tests are automatically run as GitHub Actions. If any of these tests fail, it is your responsibility to try and resolve the underlying issue(s). If you don't know how to resolve the underlying issue(s), you can ask for help.

  2. If your pull request has merge conflicts with the main branch (GitHub checks for this automatically and notifies you), you are responsible for resolving them. You can do this by merging the main branch into your branch (git pull upstream main), and then pushing the updated branch to your fork (git push).

  3. Each pull request should contain a single logical change or related set of changes that make sense to submit together. If a pull request becomes too large or contains too many unrelated changes, it becomes too difficult to review. In such cases, the reviewer has the right to close your pull request and ask that you submit a separate pull request for each logical set of changes that belong together.

  4. Link the issue you have resolved in the Pull Request Template (e.g Closes/Fixes #99).

  5. Use Conventional commit messages for your changes.

  6. Do not re-open a pull request that a reviewer has closed.

    • Make sure to tick the "Allow edits from maintainers" box. This allows us to directly make minor edits / refactors and saves a lot of time.

Remarks ✅