This post is for Domain Experts and Business Users.
The business process and brainstorming before creating the Pull Request (PR) is not covered in this. It generally happens on forum, github issues and tickets.
Introduction
Business users sleeplessly review the systems. It happens so because of the pain area they have in their system. Developers don’t really know that pain. Developers have different pain areas that keeps them awake.
One thing is certain, both parties need to have fluent conversation using tools each one of them prefer.
How can this be achieved?
Developers send Github Pull Requests (PR) and focus their effort on it. PR thread begins as soon as the PR is created. Other developers and technical users start conversations there.
This is where the domain expert and business users should also participate by commenting, providing screenshots, error logs, design review.
It must be easy for domain expert to review PR without any technical requirement to setup servers.
For business users convenience we’ll not call it Pull Request, we’ll call it “Improvement”, as in proposed improvement.
Business user feedback on each update to Improvement will result in quality code being merged into system. It will also help set expectations for both parties for the related improvement.
Over few weekends of work, we came up with a frappe+kubernetes app that can help generate sites from PRs.
Vision for the feature board app
Things will change as per user and developer conversations and feedback.
“Moderation Request” and types
Request to Initiate site for “Improvement”
Request to Upgrade site for “Improvement”
Request to Delete site for “Improvement”
Request to Add system manger user for “Improvement” site
Improvement Web view (also allowed for Guest users)
show search enabled paginated “Improvement” list
on “Improvement” Form show PR url, deployment status, and site url.
add Web form or popup to initiate a “Moderation Request” referencing Improvement
keep track of “Moderation Request”(s) by user on the form view
Webhooks
Required for automation when github PR is updated and developer fixes code after user review
Webhooks will add “Moderation Request” of type upgrade. (on commits, force-push)
Webhooks will be triggered on open PR and PR with active sites only.
Moderators can:
Respond to “Moderation Request”, “act” on it or “deny/close”
Add system manager user in the sites generated for PR
Trigger builds for PR
Trigger updated after PR is updated
Trigger tear down, if site generation results in Error, or PR is merged.
check error logs and report
Add moderator by validation only.
Mods can add new mods.
Filter Mods by Domain
Access Improvements by domain, so we get picture of set of Improvements under set of mods.
Name “Moderation Request” to something more meaningful.
@BKM, @Pirated have joined the current system as moderators. We more participation for making it successful.
I have functional background in Supply chain modules, highlevel understanding on accounting modules and HR.
PR review starting point is requirement specification, what is the use case, what we want to achieve in business user words.
then it comes solution design how reqt specs will be implemented
then developer start working to implement reqt specs,
once devlopment completed, a request for test should be raised, SME or use case owner notified, he approve or reject solution, and so on
This is where we need to improve, once things are complete, they are merged and business users may or may not be happy with the merge. The time when business users come to know about the feature the developer may have lost the context and may be working on something else. If conversations happen immediately things will not need rework or repair.
Feature should be corrected during development process, before the merge happens. Each PR waits for some review. That is the time when things can be improved.
Suppose I come now without any previous idea on this PR shall I join or leave it?
also who represent business user in the PR?
who wrote use case and reqt specs for developer?
I suggest to use discuss forum only, it will be availabe for community and if anyone perform a search on a key word it will show PR in the result.
if somone interested by PR will update tracking to watching to get email on each update.
Now each new PR will be added in the discussion forum only with all document attached, PR discussion is for developer only.
I believe, in the process that @revant_one and @RohanB have brainstormed, the individual business users will be able to add their voice to the process. In offline discussions, @RohanB had already suggested that all of this take place here on the forum.
To that end goal, we are already working out how to easily identify the forum threads that will be relevant to each of the testing cases. Everything is still in early stages right now and yet we already have 2 test systems available for any user to test and experience the changes for themselves.
We would certainly like to have you join us as a specialist in supply chain and accounting improvements that show up in this new process. It is the experienced business users like yourself that can help bring clarification to this process.
The only thing that may be uncomfortable for them at this time is the lack of official tools of analytics or standardized specifications. While large corporate business users may understand those things, the smaller business users may not have a great deal of exposure to those tools. It would be up to us to help them express what they want in the clearest terms possible so the volunteer developers can understand “at-a-glance” exactly what is needed.
@revant_one This is such a welcome initiative. I wish I could give this post 10x
I firmly believe that there are many domain experts using ERPNext whom now have the mechanism to contribute meaningfully. Thanks so much for bringing this capability to fruition.
Hi,
One important point, PR use case should be assigned an owner who is leading test and merge since we are community based sometimes things get lost in between contributors, for any reason also valid reasons project engagement or what ever.
PR test owner will follow PR till the end or find another owner to do handover.
So our current idea is to create a Discuss post everytime a build succeeds on the server (we’re only doing builds via manual requests right now to save server resources).
The Discuss post will contain some basic information about the Github PR (along with a description if it has one) and also provide a way to access the testing site.
This really sounds like a policy change. Automatically tagging both the requesters and the contributors with users across Github and Discuss is going to be a bigger problem.
The next best thing right now should be the Discuss post I shared above, where anyone can go in and test, and leave their feedback for the contributor(s).
Do let us know what you think, and we’d appreciate feedback on any improvements to be made.
This is a great Initiative and it might help us be part of the development process. An option to contribution (or atleast an opportunity to contribute) is now available at PR level.
PR means Pull Request. If you fix the issue on your own in your frappe / erpnext fork code hosted on your server and it works for you and if you wish to share that with everyone you can send it as a PR. This is where you contribute to core.
In case you just need to solve the problem immediately, the issue seem to be around the “Supplier Quotation Comparison” report. Copy that report in separate custom app, rename it, make changes you need. This is where you create your custom app.
By looking at the closed Issue I feel there is gap between developer’s expectation from the feature and your expectation from the feature. That might take time to resolve. You can choose custom app option to solve your problem immediately.
