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.
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.
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.
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.
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.
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.
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 sentry.io), 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?**
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.
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.
Yeah, I think we all are.