|
1 | | -## Contribution Guidelines |
| 1 | +<img width="1440" height="122" alt="image" src="https://github.com/user-attachments/assets/b43352aa-df3c-4165-872d-6cbc6fbcf026" /># 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 |
| 5 | +--- |
6 | 6 |
|
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! |
| 7 | +## Contribution ideas |
13 | 8 |
|
14 | | -## What to contribute |
| 9 | +If you're looking for ideas about what to work on, check out: |
15 | 10 |
|
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 |
| 11 | +- Our [issues](https://github.com/CodeChefVIT/papers-codechef/issues) |
21 | 12 |
|
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. |
| 13 | +The best way to propose a change is to start a [discussion] (https://github.com/CodeChefVIT/papers-codechef/discussions) on our CodeChefVIT GitHub repository. Begin by creating a new issue, 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. |
25 | 14 |
|
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). |
| 15 | +--- |
| 16 | +### Cloning the repository |
| 17 | +- **Fork** the repository. |
| 18 | +- **Clone** the repository. All the PRs would be made from this clone. |
30 | 19 |
|
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!). |
| 20 | +### Set Up Your Local Environment |
33 | 21 |
|
34 | | -``` |
35 | | -✔️ “X doesn’t happen when I do Y” |
36 | | -❌ “X is broken! Please fix it.” |
37 | | -``` |
| 22 | +To get the project running, you need to set up your local environment: |
38 | 23 |
|
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. |
| 24 | +- **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. |
| 25 | +- **Install dependencies:** Run `pnpm i` in your terminal to install all necessary dependencies. |
| 26 | +- **Checkout staging branch**: Run `git checkout staging` to switch branches. |
| 27 | +- **Run the project:** Run `pnpm dev` to start the project. |
40 | 28 |
|
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 | | -``` |
| 29 | +--- |
45 | 30 |
|
46 | | -**Keep requests short and direct.** |
| 31 | +## How to Contribute |
47 | 32 |
|
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 | | -``` |
| 33 | +Once your environment is set up, you're ready to start coding. |
52 | 34 |
|
53 | | -**It’s okay to ask questions (but be patient!).** |
| 35 | +- **Create a new branch:** Use the command `git checkout -b yourName/featureName` to create a new branch for your work. |
| 36 | +- **Make your changes:** Write the code to address the issue you were assigned. |
| 37 | +- **Add changed files:** After making your changes, use `git add .` to add the modified files to Git tracking. |
| 38 | +- **Commit your changes:** Use `git commit -m "feat: xyz"` to create a checkpoint for your work. Use a prefix that describes your changes. Common prefixes include: |
| 39 | + - `feat:` A new feature. |
| 40 | + - `fix:` A bug fix. |
| 41 | + - `docs:` Documentation changes. |
| 42 | + - `style:` Formatting or white-space changes that do not affect the code's meaning. |
| 43 | + - `refactor:` A code change that is not a bug fix or a new feature. |
| 44 | + - `perf:` A code change that improves performance. |
| 45 | + - `test:` Adding or correcting tests. |
| 46 | + - `build:` Changes affecting the build system or external dependencies. |
| 47 | + - `ci:` Changes to CI configuration files or scripts. |
| 48 | + - `chore:` Other changes that don't modify source or test files. |
| 49 | + - `revert:` Reverts a previous commit. |
| 50 | +- **Push your changes:** Push your commits to your forked repository using `git push`. |
54 | 51 |
|
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 | | -``` |
| 52 | +--- |
59 | 53 |
|
60 | | -**Respect community decisions.** |
| 54 | +### Submit a Pull Request |
61 | 55 |
|
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 | | -``` |
| 56 | +- **Open a Pull Request:** On the forked repository, open a pull request and set the **base branch** to `staging` to submit your changes for review. |
| 57 | +- **Request a review:** Wait for a organization member to review your PR. Any new changes you push to your branch will be automatically attached to the PR. |
66 | 58 |
|
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). |
| 59 | +--- |
70 | 60 |
|
71 | | -## Attribution |
72 | | -- [Open Source Guide](https://opensource.guide/how-to-contribute/) |
| 61 | +## Mandatory PR contents |
| 62 | + |
| 63 | +Please ensure that any Pull Request you make contains these things - |
| 64 | + |
| 65 | +- Purpose and issue which the PR is made for. |
| 66 | +- Before & after screenshots if your changes involve any visual adjustments (e.g. UI changes, layout tweaks). |
| 67 | +- List of the major changes made in this PR. |
| 68 | +- Mention of any bug fixes, known issues or follow-ups needed. |
| 69 | + |
| 70 | +**Important:** Ensure no merge conflicts exist before making a PR and run `pnpm build` to check for build errors. |
| 71 | + |
| 72 | +**AI Disclosure:** Disclose any AI assistance used while working on the PR. Clearly state the extent of AI involvement (for example, “used AI for documentation only”, “used AI to generate initial code” or "used AI for PR descriptions & responses"). |
| 73 | + |
| 74 | +**Note:** Trivial tab-completion (like single keywords or short phrases) does not need to be disclosed. |
| 75 | + |
| 76 | +## Tips to improve the chances of your PR getting reviewed and merged |
| 77 | + |
| 78 | +- Small, focused & incremental pull requests are much easier to review. |
| 79 | +- Spend time explaining your changes in the pull request body. |
| 80 | +- Low effort PRs, such as those that just re-arrange syntax, won't be merged without a compelling justification. |
0 commit comments