|
1 | | -## Contribution Guidelines |
| 1 | +# Contribute to the Papers Repository |
2 | 2 |
|
3 | | -Please note that this project is released with a [Contributor Code of Conduct](CODE_OF_CONDUCT.md). By participating in this project you agree to abide by its terms. |
| 3 | +We appreciate your interest in contributing to the `papers-codechef` repository! Please follow these guidelines to ensure a smooth and effective contribution process. |
4 | 4 |
|
5 | | -## How to contribute |
6 | 5 |
|
7 | | -- Decide which repository to contribute |
8 | | -- Decide what to contribute |
9 | | -- Fork the repo then clone it locally |
10 | | -- Commit your work (You should create a new branch when you're doing development work that is somewhat experimental in nature.) |
11 | | -- Create a **Pull Request** |
12 | | -- Congrats 🎉 you have just contributed towards open source! |
| 6 | +## Getting started |
13 | 7 |
|
14 | | -## What to contribute |
| 8 | +- If you're looking for ideas about what to work on, check out our [issues](https://github.com/CodeChefVIT/papers-codechef/issues) |
| 9 | +- If you have a bugfix to report ensure that you are on the latest pkull and no similar issue exists. You can then [create an bug report](https://github.com/CodeChefVIT/papers-codechef/issues/new?template=bug_report.md) |
| 10 | +- You can also propose a [feature request](https://github.com/CodeChefVIT/papers-codechef/issues/new?template=feature_request.md). Begin by filling out the template, write a brief problem statement that clearly explains the issue you want to address, without tying it to any specific solution. It doesn’t need to be long or formal; just provide enough context to clearly understand the problem before discussing possible solutions. |
15 | 11 |
|
16 | | -- Find an open issue to tackle |
17 | | -- Ask if you can help write a new feature |
18 | | -- Add / Improve Unit Testing |
19 | | -- Write tutorials for how a project can be used and add to the readme |
20 | | -- Review code on other people’s submissions and help improving / finding vulnerabilities |
| 12 | +## Setting up |
| 13 | +- **Fork** the repository. All the PRs would be made from this fork. |
| 14 | +- **Clone** the repository. |
21 | 15 |
|
22 | | -## Making a PR |
23 | | -- Provide all the appropriate details asked in PR template |
24 | | -- A pull request doesn’t have to represent finished work. It’s usually better to open a pull request early on, so others can watch or give feedback on your progress. Just mark it as a “WIP” (Work in Progress) in the subject line. You can always add more commits later. |
| 16 | +To get the project running, you need to set up your local environment: |
25 | 17 |
|
26 | | -## Opening an Issue |
27 | | -- Make use of an appropriate Issue Template |
28 | | -- We welcome Feature request, Bug Report, Documentation fix and others |
29 | | -- Do not open critical security issues here, report them directly at [our email](mailto:contact@codechefvit.com). |
| 18 | +- **Create a `.env` file:** Create a new file named `.env` and use the .env.example file to create your own .env file and put in your your own environment variables to make the project functional. |
| 19 | +- **Install dependencies:** Run `pnpm i` in your terminal to install all necessary dependencies. |
| 20 | +- **Checkout staging branch**: Run `git checkout staging` to switch branches. |
| 21 | +- **Run the project:** Run `pnpm dev` to start the project. |
30 | 22 |
|
31 | | -## Communicating effectively |
32 | | -**Give context.** Help others get quickly up to speed. If you’re running into an error, explain what you’re trying to do and how to reproduce it. If you’re suggesting a new idea, explain why you think it’d be useful to the project (not just to you!). |
| 23 | +## How to Contribute |
33 | 24 |
|
34 | | -``` |
35 | | -✔️ “X doesn’t happen when I do Y” |
36 | | -❌ “X is broken! Please fix it.” |
37 | | -``` |
| 25 | +Once your environment is set up, you're ready to start coding. |
38 | 26 |
|
39 | | -**Do your homework beforehand.** It’s OK not to know things, but show that you tried. Before asking for help, be sure to check a project’s README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate when you demonstrate that you’re trying to learn. |
| 27 | +- **Create a new branch:** Use the command `git checkout -b yourName/featureName` to create a new branch for your work. |
| 28 | +- **Make your changes:** Write the code to address the issue you were assigned. |
| 29 | +- **Add changed files:** After making your changes, use `git add .` to add the modified files to Git tracking. |
| 30 | +- **Commit your changes:** Please follow standard conventional commit guidelines as outlined here: https://www.conventionalcommits.org/en/v1.0.0/ |
| 31 | +- **Push your changes:** Push your commits to your forked repository using `git push`. |
40 | 32 |
|
41 | | -``` |
42 | | -✔️ ““I’m not sure how to implement X. I checked the help docs and didn’t find any mentions.”” |
43 | | -❌ “How do I X?” |
44 | | -``` |
| 33 | +## Submit a Pull Request |
45 | 34 |
|
46 | | -**Keep requests short and direct.** |
| 35 | +- **[Submit your pull request](https://github.com/CodeChefVIT/papers-codechef/compare):** Please, fill in the Pull Request template - it will help us better understand the PR and increase the chances of it getting merged quickly. |
47 | 36 |
|
48 | | -``` |
49 | | -✔️ “I’d like to write an API tutorial.” |
50 | | -❌ “I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you…“ |
51 | | -``` |
| 37 | +An organization member will review the PR and discuss changes you might have to make before merging it. Any new changes you push to your branch will be automatically attached to the PR. |
52 | 38 |
|
53 | | -**It’s okay to ask questions (but be patient!).** |
| 39 | +--- |
54 | 40 |
|
55 | | -``` |
56 | | -✔️ “Thanks for looking into this error. I followed your suggestions. Here’s the output.” |
57 | | -❌ “Why can’t you fix my problem? Isn’t this your project?” |
58 | | -``` |
| 41 | +### Mandatory PR contents |
59 | 42 |
|
60 | | -**Respect community decisions.** |
| 43 | +Please ensure that any Pull Request you make contains these things - |
61 | 44 |
|
62 | | -``` |
63 | | -✔️ “I’m disappointed you can’t support my use case, but as you’ve explained it only affects a minor portion of users, I understand why. Thanks for listening.” |
64 | | -❌ “Why won’t you support my use case? This is unacceptable!” |
65 | | -``` |
| 45 | +- Purpose and issue which the PR is made for. |
| 46 | +- Before & after screenshots if your changes involve any visual adjustments (e.g. UI changes, layout tweaks). |
| 47 | +- List of the major changes made in this PR. |
| 48 | +- Mention of any bug fixes, known issues or follow-ups needed. |
66 | 49 |
|
67 | | -## Misc |
68 | | -- You are welcome to Propose a new feature by creating an **Issue**. |
69 | | -- You may Discuss a high-level topic or idea (for example, community, vision or policies) by writing to us at our [Email](mailto:contact@codechefvit.com). |
| 50 | +**Important:** Ensure no merge conflicts exist before making a PR and run `pnpm build` to check for build errors. |
70 | 51 |
|
71 | | -## Attribution |
72 | | -- [Open Source Guide](https://opensource.guide/how-to-contribute/) |
| 52 | + |
| 53 | +### Tips to improve the chances of your PR getting reviewed and merged |
| 54 | + |
| 55 | +- Small, focused & incremental pull requests are much easier to review. |
| 56 | +- Spend time explaining your changes in the pull request body. |
| 57 | +- Low effort PRs, such as those that just re-arrange syntax, won't be merged without a compelling justification. |
0 commit comments