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
+6-5Lines changed: 6 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,18 +3,18 @@
3
3
files a PR. This is only suitable for really small changes like: spelling fixes, variable name changes or error string
4
4
change etc. For larger commits, following steps are recommended.
5
5
* (Optional) If you want to discuss your implementation with the users of GoFr, use the GitHub discussions of this repo.
6
-
* Configure your editor to use goimport and golangci-lint on file changes. Any code which is not formatted using these
6
+
* Configure your editor to use goimports and golangci-lint on file changes. Any code which is not formatted using these
7
7
tools, will fail on the pipeline.
8
8
* Contributors should begin working on an issue only after it has been assigned to them. To get an issue assigned, please comment on the GitHub thread
9
9
and request assignment from a maintainer. This helps avoid duplicate or conflicting pull requests from multiple contributors.
10
10
* Issues labeled triage are not open for direct contributions. If you're interested in working on a triage issue, please reach out to the maintainers
11
-
to discuss it before proceeding in the Github thread.
11
+
to discuss it before proceeding in the GitHub thread.
12
12
<!-- spellchecker:off "favour" have to be ignored here -->
13
13
* We follow **American English** conventions in this project (e.g., *"favor"* instead of *"favour"*). Please keep this consistent across all code comments, documentation, etc.
14
14
<!-- spellchecker:on -->
15
-
* All code contributions should have associated tests and all new line additions should be covered in those testcases.
15
+
* All code contributions should have associated tests and all new line additions should be covered in those test cases.
16
16
No PR should ever decrease the overall code coverage.
17
-
* Once your code changes are done along with the testcases, submit a PR to development branch. Please note that all PRs
17
+
* Once your code changes are done along with the test cases, submit a PR to development branch. Please note that all PRs
18
18
are merged from feature branches to development first.
19
19
* PR should be raised only when development is complete and the code is ready for review. This approach helps reduce the number of open pull requests and facilitates a more efficient review process for the team.
20
20
* All PRs need to be reviewed by at least 2 GoFr developers. They might reach out to you for any clarification.
0 commit comments