-
Notifications
You must be signed in to change notification settings - Fork 7.5k
Contribution Guidelines
Thank you for your interesting in contributing to an open source project! Our world works on people taking initiative to contribute to the "commons" and contributing to open source means you are contributing to make things better for not only yourself, but everyone else too! So thank you for taking this initiative.
Great projects also work because of great quality. Open source or not, the user really cares that things should work as they are advertised, and consistently. New features should follow the same pattern and so that users don't have to learn things again and again.
Developers who maintain open source also expect that you follow certain guidelines. These guidelines ensure that developers are able quickly give feedback on your contribution and how to make it better. Most probably you might have to go back and change a few things, but it will be in th interest of making this process better for everyone. So do be prepared for some back and forth.
Happy contributing!
We will strive for a "Zero Pull Request Pending" policy, inspired by "Zero Inbox". This means, that if the pull request is good, it will be merged within a day and if it does not meet the requirements, it will be closed.
- Test Cases: Important to add test cases, even if its a very simple one that just calls the function. For UI, till we don't have Selenium testing setup, we need to see a screenshot / animated GIF.
- UX: If your change involves user experience, add a screenshot / narration / animated GIF.
- Documentation: Test Case must involve updating necessary documentation
- Explanation: Include explanation if there is a design change, explain the use case and why this suggested change is better. If you are including a new library or replacing one, please give sufficient reference of why the suggested library is better.
- Demo: Remember to update the demo script so that data related your feature is included in the demo.
- Failing Tests: This is simple, you must make sure all automated tests are passing.
- Very Large Contribution: It is very hard to accept and merge very large contributions, because there are too many lines of code to check and its implications can be large and unexpected. They way to contribute big features is to build them part by part. We can understand there are exceptions, but if it is possible to break it, please break your contribution into parts. If you happen to build a completely new feature, like a workflows for a new domain, then be sure to include test cases, documentation, screenshots and screencasts.
- Incomplete Contributions: If the contribution is WIP or incomplete, it cannot be accepted. If the contribution is a part of a big plan, make sure each part is end-to-end complete with at least one workflow and test case.
- Incorrect Patches: If your design involves schema change and you must include patches that update the data as per your new schema.
- Incorrect Naming: The naming of variables, models, fields etc must be consistent as per the existing design and semantics used in the system.
-
Deprecated API: The API used in the pull request must be the latest recommended methods and usage of globals like
cur_frm
must be avoided. - Whitespace and indentation: The ERPNext and Frappe Project uses tabs (I know and we are sorry, but its too much effort to change it now and we don't want to lose the history). The indentation must be consistent whether you are writing Javascript or Python. Multi-line strings or expressions must also be consistently indented, not hanging like a bee hive at the end of the line. We just think the code looks a lot more stable that way.
Don't worry, fix the problem and re-open it!
This is because ERPNext is at a stage where it is being used by thousands of companies and introducing breaking changes can be harmful for everyone. Also we do not want to stop the speed of contributions and the best way to encourage contributors is to give fast feedback.