Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Preparing a Contribution Proposal
ERPNext is now being built for over 10 years and has tons of built-in features based on experiences for more than hundreds of businesses. When you start building a new feature, make sure you do your ground work right. It is necessary that you spend at least a few days playing with "using" the system, and understanding how features and workflows are designed in ERPNext.
1. Work with the User
When you start building a new feature, start with a broad discussion with the end user. Understand the need from the end user's point of view. Ask a lot of questions as they will help you clear your thoughts and also help you identify how the feature must be integrated with the rest of the product.
Don't start developing on the same day. Prepare a note and sleep over your thoughts for at least one day.
2. Using Existing Models v/s Making New Models
ERPNext has a lot of workflow tools on top of the models that may be used to fit your requirement. Generally, extending an existing feature is always better than making new models. But this is not always true. A good way to decide this is on the basis of naming of your model. Is it synonymous to an existing model, or is it completely new?
For example if you are planning to start a new model to track students, you could decide to use the Customer model and add a few fields. But, a Student is not synonymous to Customer, so its best to make a separate model for this. See naming guidelines for more details, but always remember that words are the most important way of communicating with users and the biggest contributor to a good user experience.
Example: #9949 Product Life Management PLM
3. User Experience Consistency
ERPNext also has thousands of users, and all these users are going to discover and use the feature you are going to build. The most important thing for these users is that your new feature must look and behave in a consistent manner to the existing features, so that the user does not have to learn a new way of doing things. This means how things are named, how objects are laid out on the screen etc.
4. Start with a GitHub Issue
Summarize your discussion and start with a GitHub Issue. Also post your design with a tag
[Proposal] on both GitHub and discuss.
In your Issue, make sure to mention
- Feature Goals (Use cases)
- Additional DocTypes and fields (with fieldtype, etc) if any.
- Discovery (how will the user find the feature you are building)
- Screen Mockups with buttons and any custom UI if any
- Business Logic
- Links to existing DocTypes
5. Get Feedback from a Maintainer
Make sure you get at least some feedback from the maintainers before you start building your feature, since this will help the maintainers when they have to merge the issue.
If your contribution is very significant, don't hesitate to @-tag or ask a maintainer for a call. A good way to select who to call is based on who has worked on similar or adjacent features to the one you are proposing.