Guidelines

Read the Documentation

Always read the documentation, first. Periodically check the README.md and CONTRIBUTING.md files and look for any changes affecting you.

Respect the Project's Scope and Vision

Only propose changes aligned with the project goals and strategy, to streamline your efforts, optimise the use of available resources and drive impactful results. Get support for your new feature concept from the core developers before spending any time coding it, unless you want a very steep and painful learning experience. You can always fork the repository, as a starting point for your own idea...

Be Clear and Concise in Communication

Use simple, professional language anf technical jargon, if necessary. Avoid using any slang unknown to others.

File Issues Responsibly

Include all relevant details for efficient problem resolution.

Align with Feedback

Engage constructively with the core developers. Even when you do not like the feedback, you can reach out politely to the core developer or documentation maintainer who provided the feedback. You must align and be consistent with existing documentation standards.

Be Resilient and Thrive

Having a contribution rejected is part of the open-source process. Use this experience to refine your approach. You must rise above any rejection, rise above your own circunstances (it does not matter how difficult) and become the world class person that you are meant to be. Who does rely on luck at unknown doors??

Focus on Modernization

Rather than proposing radical changes to the code or documentation, unless there is an obvious reason or technological gap, make sure that your contributions are incremental. Focus on improving the documentation's clarity, the code structure or relevance without duplicating content.

Clarity is Crucial

If you do have a proposal for an implementation, make it clear whether the implementation is a simple prototype or is expected to be the final code. This is specially important during any voting process.

Make Thoughtful Pull Requests

Validate and test your code to ensure that your code is ready and aligns with the project's style and objectives.

Be Patient and Grateful

Respect the maintainers’ time and efforts. Sometimes, your feature suggestions will be greeted by an apparent lack of interest. Don't be discouraged. This only means that you need to take a stronger leadership role and also prove your credentials by first working on the existing code base.

Give Back to the OSS Community

Help others with reviews, feedback, translations and documentation.

Avoid Making Demands

OSS development process is an organic process and subject to flexibility, while it is based heavily on users contributing the required features, it also requires an high investment from those same users who want to change things... The core developers of a project often lack the time and resources to fully consider other people's ideas, regardless of their merit. Any new features acceptance is highly pragmatic.

Follow Licensing Rules

Adhere to license terms like AGPLv3 or Apache License 2.0 (among many others) and give proper attribution.

Respect Time Zones and Cultures

Be mindful of global contributors and different cultures.

Engage in Discussions

Provide constructive feedback and decline dismissive behavior. Arrogant people need to project superiority to be deemed credible and worthy. While rejection can feel discouraging to anyone involved (sometimes is very hard to say NO), it can be a valuable learning experience in collaborative OSS projects. Aligning your contributions with the project’s goals is key to having your work accepted and making a meaningful and lasting impact.

Conclusion

By following these guidelines, you can contribute positively to OSS Communities, build relationships and increase the chances of your contributions being well-received by others.