Every open-source project has some kind of guidebook, though it might not be called 'documentation' outright. Docs can be anything from super detailed to just the basics. But remember, if you ask a maintainer something that's already covered in the docs, it shows them right away that you didn't bother reading. And that's not the best first impression. So, yeah, check out the docs first!

Open source maintainers are often experienced developers who not only write code and develop projects but also create documentation, develop live sites, handle deployment, track and document issues, conduct code reviews, and assist collaborators within the project's scope. There are cases where maintainers may not directly contribute code, but they still engage in various activities. It's important to verify before assuming their responsibilities. Typically, maintainers are heavily involved in code writing, and you can gain more insights by exploring the repository's analytics.

First of all, acknowledge that the maintainer has likely already considered the proposed solution. Begin with 'Have you considered' to respect their expertise and decision-making process. Then, explore why the solution hasn't been implemented without wasting time. It's possible that the solution isn't applicable to the project's structure or that the maintainer intentionally left it for a collaborator to implement. However, it's highly unlikely that the maintainer is unaware of the solution or lacks the ability to implement it. By framing the discussion in this way, you can facilitate productive dialogue and collaboration within the open-source community.

Consider contributing to the project by automating repetitive tasks that maintainers handle. Automation can help streamline the development process and free up maintainers' time for more critical tasks.

Help enhance the project's test coverage by writing and improving automated tests. Comprehensive test coverage ensures the stability and reliability of the codebase, making it easier for maintainers to manage.

Support the project by ensuring that its documentation remains current and accurate. You can contribute by updating documentation to reflect new features, changes, or improvements, helping maintain a valuable resource for users and contributors.

Participate in keeping the issues organized by identifying and resolving duplicate issues. This contribution helps streamline the development process, making it easier for maintainers to focus on addressing genuine problems and feature requests.

Contribute to the project by submitting well-tested and documented pull requests. By thoroughly testing your changes and providing clear description, you help maintainers review and merge contributions more efficiently.

You don't have to be in love with the tech stack but if you want to join as a contributor you should at least respect the technology and progress already achieved by the project. When contributing, focus on building upon existing features and infrastructure rather than introducing disruptive changes. By working incrementally and collaboratively, you can enhance the project's functionality and maintain its stability.

Don't bug the maintainers with questions they've already answered in the docs. It's like asking for directions when you've got a map right in front of you. Save everyone's time and check the docs first before reaching out.

While maintainers are resources for guidance and support, avoid relying solely on them for every task or decision. Furthermore, maintainers are not your personal mentors and they are not here to: answer Google-able questions; explain basic programming concepts; or cover anything outside the scope of the open-source project. If you have knowledge gaps, you must address them. Take initiative in problem-solving, seek guidance from documentation and community resources, and collaborate with other contributors. Empowering yourself fosters personal growth and contributes to a more self-sustaining community

Avoid assuming that you are the first person to propose a solution. Project maintainers invest significant time and effort into exploring solutions for their projects. If a solution hasn't been implemented, refrain from assuming that the maintainer lacks awareness or competence. Instead, respectfully propose the solution while acknowledging the maintainer's expertise and decision-making process. Ask if they have already considered it, recognizing that they may have intentionally deferred implementation for collaboration or technical reasons. This approach fosters a culture of respect, collaboration, and effective communication within the open-source community

Respect the project's community guidelines and code of conduct when contributing. Behaviors such as spamming, trolling, or engaging in disrespectful communication detract from the collaborative spirit of open source. Adhere to established norms to maintain a positive and inclusive community environment.

Avoid overwhelming maintainers with requests beyond the scope of their responsibilities. While maintainers are there to guide and support contributors, it's essential to respect their time and autonomy. Instead, foster your growth by seeking resources and engaging with the community.

Refrain from offering unsolicited or unconstructive criticism. Instead, focus on providing feedback and suggestions in a respectful and constructive manner. Positive and constructive communication fosters a supportive and collaborative environment within the open-source community.

Avoid assuming that maintainers are always available to address your queries or review your contributions immediately. Understand that maintainers have other commitments and responsibilities beyond the project. Exercise patience and allow them sufficient time to respond or review your contributions.

Refrain from introducing disruptive or destructive changes to the project. Is the contributors responsibility to verify that they are not introducing a destructive change, wether it being due to lack of experience or other reasons. Respect the existing codebase and infrastructure, and avoid making changes that undermine its stability or functionality. Instead, focus on incremental improvements that build upon the project's foundation and align with its goals.

If a maintainer or existing contributor informs you that your pull request is not compliant, avoid arguing or being disrespectful. Refrain from telling them they are wrong. Such behavior can lead to being banned from the project. Instead, approach feedback with humility and a willingness to learn and improve.

Do not attempt to manipulate indentation to create the illusion of having made more changes to the code, or to make the PR appear more substantial. This tactic may be tempting for inexperienced developers, but experienced developers can easily detect it and will be frustrated by such behavior. Such actions will leave a negative impression and undermine trust within the project's community. This is just one example, but avoid engaging in any of those silly cheap tricks, as you are not fooling anyone.