Skip to content

Latest commit

 

History

History
39 lines (29 loc) · 3.16 KB

CONTRIBUTING.md

File metadata and controls

39 lines (29 loc) · 3.16 KB
Raw

Contributions

There are certain DOs and DON'Ts that must be followed for a proper and meaningful contribution that would actually add to the mission of making the repository a standard medium of learning.
Please take heed to the suggestions below very carefully because no additions would be entertained in any other case.

DONTs

  • Make PRs to non-existent Issues.
  • Make PRs to unassigned Issues.
  • Make PRs/ Issues with respect to adding any Hackerrank/ Leetcode/ competitive programming problems. That shall be dealt with later.
  • Make PRs/ Issues that deal with topics of Spring, Hibernate, JDBC, etc. That shall be dealt with later.
  • Make PRs adding Recommended Resources in the README file. Suggestions to that are certainly welcome and would undergo thorough scrutiny.
  • Make PRs with respect to starting off a new topic/ sub-topic (such as Bucket Sort, Radix Sort, etc. that has not been done but will be done later). Issues regarding that are welcome but such PRs won't be accepted at all.
  • Make PRs/ Issues with respect to new design patterns that haven't been covered. The existing ones, albeit scanty, may be improved with more examples or documentations, if needed.
  • Make PRs already if the tests written do not pass. Tests should, moreoever, cover edge-cases that are possible (we need not test a function against alphanumeric inputs if the method itself only ever accepts numeric inputs via a Scanner in the main method at all times). Tests should be extensive but not unnecessary.
  • Change pre-written code by swapping larger variable names for shorter and more convenient-to-type ones.
  • Expect PRs to be merged when they do not pass the workflow checks.

DOs

  • Request to be assigned to an Issue to make a PR to solve the problem.
  • While coding, use verbose and clear variable names no matter how long it is.
  • Learn to take feedback and contribute in ways that the maintainer wants the work to be.
  • Have patience to open an Issue, be assigned before beginning work on a PR.
  • Make suggestions to parts of the documentations under the README files.
  • Make Issues with respect to tools (like Jenkins) that are made with Java and supply documentations having exhaustive explanation to those. Make the documentation modular like it is with Maven or Jenkins in this repository.
  • Use Grammarly or any such tool to have proper control over English (if needed) while writing the README documentations.

General Guidelines for Hacktoberfest

  • Be polite to all and don't clash over Issues to solve.
  • Only work towards the resolution of the issues that are labelled with hacktoberfest. Others won't be awarded with the hacktoberfest-accepted badge upon resolution.
  • Issues would get assigned on the basis of first-come-first-serve, despite the assignees level of knowledge. Only if the assignee is unable to solve the issue will it be reassigned to the next person in queue who may ave requested.
  • Please have patience as to the process of merging of branches.
  • An in-depth discussion over a certain issue will always be welcome! That said, civility is the key to that.
  • Issues asking for clarification of certain parts of code (source or tests) are always welcome in the community.