mirror of
https://github.com/frappe/erpnext.git
synced 2026-02-12 17:23:38 +00:00
Updated Contribution Guidelines (markdown)
@@ -20,8 +20,8 @@ We will strive for a "Zero Pull Request Pending" policy, inspired by "Zero Inbox
|
||||
1. **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.
|
||||
1. **Demo:** Remember to update the demo script so that data related your feature is included in the demo.
|
||||
1. **Failing Tests:** This is simple, you must make sure all automated tests are passing.
|
||||
1. **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.
|
||||
1. **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.
|
||||
1. **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 in most cases try and keep your pull-request to **30 lines of code** excluding tests and config files.
|
||||
1. **Incomplete Contributions must be hidden:** If the contribution is WIP or incomplete - which will most likely be the case, you can send small PRs as long as the user is not exposed to unfinished functionality. This will ensure that your code does not have build or other collateral issues. But these features must remain completely hidden to the user.
|
||||
1. **Incorrect Patches:** If your design involves schema change and you must include patches that update the data as per your new schema.
|
||||
1. **Incorrect Naming:** The naming of variables, models, fields etc must be consistent as per the existing design and semantics used in the system.
|
||||
1. **Translated Strings:** All user facing strings / text must be wrapped in the `__("")` function in javascript and `_("")` function in Python, so that it is shown as translated to the user.
|
||||
|
||||
Reference in New Issue
Block a user