How to improve user involvement in development of ERPNext

Business users need easy playground for testing daily development.
How to solve this problem?

This is the process currently (2021-05-19) followed.

  • Pull requests have the features that are proposed to be added in ERPNext.
  • Develop branch is where the features that are accepted get merged.
  • Developers can decide to backport the feature to older versions if the change is minor
  • Whatever needs to be in next v12 release will have to be added/backported to version-12-hotfix
  • Whatever needs to be in next v13 release will have to be added/backported to version-13-hotfix
  • Whenever release is published, the version-*-hotfix is merged into version-* branch

I think for that to be a testing playground, there would have to be a simple way to spin up the server for them to experiment on. Currently installing a development environment is just as frustrating as trying to get a production system up.

So maybe a docker system that creates a complete test system so that he business users can easily and reliably test the features and make comments.

Anything that requires complex installation processes will simply be out of their reach most of the time. I cannot think of anything that might be easier unless there was a perpetual live server but that costs money. creating the docker images is probably the fastest way to get feedback even if it is somewhat a chore on the developer side of the equation to create the image.

Your thoughts?


I was thinking of having multiple live servers with multiple user groups from different domains.

Writing the thoughts is difficult when many people want to say many things.

1 Like

While I would be happy to continue this philosophical discussion elsewhere, I believe that @revant_one intended this thread to be the solution to problems and not the further discussion of philosophy.


Doesn’t that A) cost money to support and B) further dilute the responses you might receive?

If you have multiple servers then you are attempting to support multiple discussion threads simultaneously. That seems a bit of a stretch for anyone looking to make any progress.

The only way that might work is if there were developers assigned to focus on only one server one discussion at a time.

The same could be accomplished using the docker method. The difference is that instead of getting ANY user that happens to be passing by the thread, you will only really be hearing from those that took the time to spin up the docker image and do the testing.

I think it it smart to make the users that want to participate in the improvement be active beyond just talk. The act of having to spin up a server image is probably just the right amount of work to them want to pay attention to their input.

Your thoughts?


I thought this is where we were asked to continue that discussion, but if I misunderstood I am of course happy to oblige.

What improvements would be necessary to the official docker images to make this a reality? I’ve literally never used docker before, but I had that up and running in 15min from repo instructions. It was a breeze to use, thanks to @revant_one’s hard work.

This is not true in my experience. Frappe / ERPNext is one of the fastest and easiest way to setup both development and production.

If you have two machines (VPS), you setup a development mode in one, and production mode in the other. Inside those two machines you can have multiple sites. multiple apps, multiple everything.

For every bench init, you keep similar business concerns (one bench init for real estate business, another bench init for schools, another bench init for hospitals, another bench init for swine farms.

Once you set up one Frappe / ERPNext, you can bench init / binch new-app / bench get-app everything.

Setting up ssl certificates is simple. I mean, the Frappe team had made everything easy. Add into the mix Revant’s work on containerizatin…

When you are sure that your app changes are okay on the development side, you just commit to github, and bench update on the production side and you are done.


Things are going too fast, I’m just dumping thoughts!

Group of Domain Experts get a live server

  • Retail
  • Manufacturing
  • Healthcare
  • Distribution

Multiple groups okay. Retail-UAE, Retail-FMCG

Need a process to create “Domain Experts Group” and their “live server”

User group decides which PR needs they need to test on their live server.

Chosen PR will be deployed on their live server

Users test things with their domain data and approve, reject, propose improvements.

1 Like

We need process first. We can do whatever it takes in code.

This is likely true for “some” people, but the intent is to get the input of those that struggle with the install process (which makes up almost 20% of the forum posts).

Regular business users will not fight that battle. But if you have a very reliable thing like the docker image, then you might be better at getting their interest and their real input.

The down side is that the developer would need to generate a docker image of a system containing their improvements. Then put it out there to be tested.

The testing and responses you get then would be controlled because there are not several changes happening at the same time in the same code. it is a snapshot of what the developer is actually trying to get feedback on without any other development cycles interfering with the testing experience.


1 Like

:laughing: Yeah, I think we all are.

The concept you propose is good. The implementation can be worked out.

It is setting up the user groups and finding them representation in the developer community that is the real hurdle.


I totally agree that ERPNext will benefit if the domains were separated. I see some very popular paid manufacturing software that ERPNext could beat in features alone. But because ERPNext is mixed up (I don’t mean messed up, but more like a treasure box with many many different jewels), the value is actually decreased.

In marketing these days, DIFFERENTIATION is very important. You must be able to say who you are or what your software is in 10 seconds. Therefore, mixing up everything devalues.

1 Like

That is probably the first identifiable task that needs to be addressed.


That is where organized user groups focused on only one domain could have an impact. Then the individual domains begin to have their own life. That is how you get outside attention. When any one given domain begins to make waves, the world pays attention and possibly sees the other things the package can do as well.



Groups can be multiple. Half of them may fail. They are not elected bodies, they are just volunteer testers.

Groups should be small enough to take quick decisions.

I’ll start thinking about the “pipeline”

1 Like

Guys, can we do an whiteboard exercise?

There’s some levels of problems

  • Level 0
    • Install Bugs (they can affect everyone)
    • Migration Bugs ( they affect some users, depending on how they setup ERPNext)
  • Level 1
    • Module Bugs (they affect some users, that may have started use a module)
  • Level 2
    • They are business process challenges or integration between features in ERPNext
      • Examples (Scrap in Manufacturing, Sub-Contracting in Manufacturing)
    • There’s an upcoming feature, how understand
      • The boundaries of the feature
        • What is the problem this feature can resolve?
        • There’s problems out of the scope of the feature?
      • Available ways to contribute with the extension of the boundaries of the feature
        • Knowledge
        • Monetary
        • Work
  • Level 3
    • You are developing things around ERPNext
      • How contribute it back into a realistict time
      • How get support from the community to do that?
  • Level 4
    • Deprecations
      • How what’s being deprecated affect others?

If you face a problem in any level, how get support?

  • Disquss
    • If Discuss doesn’t resolve then, open an issue
    • How many time, to someone understand and address this?
    • What’s the impact for this bug
      • for the user who identify the bug
      • for the project
      • for the community
    • What’s the ETA time to get this resolved?
      • for the user who identify the bug
      • for the project visibility
      • for the community feelings
    • What’s the desirable time to get this resolved?
      • for the user who identify the bug
      • for the project visibility
      • for the community feelings

If we can monitor problems level 0 and 1 (with, probably we can apply pareto’s law, to resolve 80% of the problems, with 20% of effort.

What’s the implication, of active monitory bugs in someone-else server? Like mozilla and chrome does with crash reports?

Problems of Level 2, 3 and 4, come from the daily user experience with ERPNext, this most of the time, is because

  • Some feature is incomplete (there’s no clear boundary definition)
  • Some functionality have been disabled from one version to another (intentionally or accidentally)
  • There’s some feature available, but it’s not documented (Ex: Transfer Warehouse in Packed Item)
  • Users are already using the system in ways developers never thought

Can these problems addressed if we:
*** Have a system of PE (Proposal Enhancements), where :**
** * community can vote at level 1**
** * community can comment for what passed to level 2 (due traction policy)**
** * community can define scope boundaries at level 3**
** * work (can the community sponsor this)**
** * Who in the community can take the leadership to coordinate work here?**


True. Experience and study does eventually bring results.

I think the Frappe / ERPNext team is arranged into domain “owners”.

It would be nice if the domain owners listened to this advice. This would make Frappe / ERPNext agile. Many coders in this community would be able to contribute more significantly.

Team needs to be cross-functional.

Docker or no-docker we need 1 person who can do basic sysadmin things to test PR and collaborate with user group

The key to making this work, is to keep the time frames on deliverables and review very short (within days). This would make the groups and their results agile. You do not need to make a perfect waterfall. It is better to do small increments and immediate feedback multiple times. This way, if you make a wrong turn, you do not have to turn back again when you are already far down the wrong road.

1 Like