You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+16-19Lines changed: 16 additions & 19 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,19 +8,19 @@ We appreciate your interest in contributing to the `papers-codechef` repository!
8
8
9
9
If you're looking for ideas about what to work on, check out:
10
10
11
-
- Our [issues](https://github.com/CodeChefVIT/papers-codechef/issues) based on votes by the community.
11
+
- Our [issues](https://github.com/CodeChefVIT/papers-codechef/issues) based on votes by the community
12
12
13
-
The best way to propose a change is to start a discussion on our CodeChefVIT GitHub repository. Begin by writing 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 make sure it provides enough context to understand the problem before discussing possible solutions.
13
+
The best way to propose a change is to start a discussion 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.
14
14
15
15
---
16
16
17
17
### Set Up Your Local Environment
18
18
19
-
To get the project running, you'll need to set up your local environment.
19
+
To get the project running, you need to set up your local environment:
20
20
21
21
-**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.
22
22
-**Install dependencies:** Run `pnpm i` in your terminal to install all necessary dependencies.
23
-
-**Do git checkout staging** if you want to contribute during a major revamp that is going on.
23
+
-**Checkout staging branch**: Run `git checkout staging`to switch branches.
24
24
-**Run the project:** Run `pnpm dev` to start the project.
25
25
26
26
---
@@ -31,7 +31,7 @@ Once your environment is set up, you're ready to start coding.
31
31
32
32
-**Create a new branch:** Use the command `git checkout -b yourName/featureName` to create a new branch for your work.
33
33
-**Make your changes:** Write the code to address the issue you were assigned.
34
-
-**Add changed files:** After making your changes, use `git add` to add the modified files to Git tracking.
34
+
-**Add changed files:** After making your changes, use `git add .` to add the modified files to Git tracking.
35
35
-**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:
36
36
-`feat:` A new feature.
37
37
-`fix:` A bug fix.
@@ -50,31 +50,28 @@ Once your environment is set up, you're ready to start coding.
50
50
51
51
### Submit a Pull Request
52
52
53
-
-**Open a Pull Request:** On your GitHub page for the forked repository, you will see a button to "Open pull request" since your branch is ahead of the upstream. Click this to begin the process.
54
-
55
-
-**Target the `staging` branch:** When creating the pull request, make sure you set the **base branch** to `staging`.
56
-
57
-
-**Request a review:** After creating the pull request, wait for a organization member to review your PR. Any new changes you push to your branch will be automatically attached to the pull request.
53
+
-**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.
54
+
-**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.
58
55
59
56
---
60
57
61
58
## Mandatory PR contents
62
59
63
-
Please ensure that any PR you make contains these things -
60
+
Please ensure that any Pull Request you make contains these things -
64
61
65
-
- Purpose and issue which the PR is made regarding.
62
+
- Purpose and issue which the PR is made for.
66
63
- Before & after screenshots if your changes involve any visual adjustments (e.g. UI changes, layout tweaks).
67
-
- List the major changes made in this PR.
68
-
- Mention any bug fixes, known issues, or follow-ups needed.
64
+
- List of the major changes made in this PR.
65
+
- Mention of any bug fixes, known issues or follow-ups needed.
69
66
70
-
**Important:**Make sure there are no merge conflicts with the branch while making a PR otherwise it will not be merged, run `pnpm build`before making a PR to ensure there are no build errors while merging as well.
67
+
**Important:**Ensure no merge conflicts exist before making a PR and run `pnpm build` to check for build errors.
71
68
72
-
**AI Disclosure:**Disclosure of any AI assistance used while working on the PR. Clearly state the extent of AI involvement (for example, “used AI for documentation only” or “used AI to generate initial code”). If the PR descriptions or responses are generated by AI, that must also be disclosed.
69
+
**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
70
74
71
**Note:** Trivial tab-completion (like single keywords or short phrases) does not need to be disclosed.
75
72
76
73
## Tips to improve the chances of your PR getting reviewed and merged
77
74
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
75
+
- Small, focused & incremental pull requests are much easier to review.
76
+
- Spend time explaining your changes in the pull request body.
77
+
- Low effort PRs, such as those that just re-arrange syntax, won't be merged without a compelling justification.
0 commit comments