@rmehta I shared a possible mechanism to sort and address feature requests -
Agree with @James_Robertson about prioritizing Accounting and HR (Hourly Attendances!)
1 Like
It’d be really helpful if you can tel more about whats the kind of data you use revolving around construction. How does the data flow from one task to another…
@Zlash65 @salman_dawood : you may like to incorporate ‘Batch Billing’ functionality, which is the critical challange of road construction and residential construction players.
@akurungadam from earthians, I believe is working on it - Collaboration could help making construction domain more comprehensive.
Regards,
Liyakat
Awesome we have more than one projects going on in Construction, lets nail this one too!
Specially for new (entry-level) devs its better to get them started on something new rather than build on existing functionality. This is because fixing existing functionality is mostly pretty hard which needs at least 6-8 months of development experience.
@almeidapaulopt @dufani1 Good to hear from you guys. I think we should start a dedicated thread for construction management and discuss over there. Construction Management
1 Like
I read the post from Rushabh on the fact that a new functionality is easier for a new resource to develop than enhancing an existing functionality.
That maybe the case, but I think we are all better off if the Foundation Resources struggle with enhancing existing functionality, rather than build new ones.
So, I would like to propose the following:
We only focus on ERPNext, Schools and Healthcare Module. The community can pick up the Not for Profit Module, the Construction Module and the AgriTech Module and develop that further using their own resources, or if they want the Foundation Resource to continue working on those functionalities, they pay for the resource for the duration that it will take the resource to develop these modules. Rushabh can indicate how much that will entail per month.
If the community is not willing to fund it, we park these development at the logical point and redeploy these resources.
I hear @LifeP’s approach and it is a great approach, but I think that for the next 6 months we are better off focusing on the following four areas:
- Bug fixing
- Better Deliver existing functionality
- Enhancements to deliver normal expectations of existing functionality
- Localize existing functionality to countries we (Foundation) chooses to invest in (US, Canada, South Africa, UK, Ireland, Australia, New Zealand, Singapore, Hong Kong, UAE, Saudi Arabia, Oman - not that I have anything against other countries, but I’m choosing countries where the business language is English and has huge potential. If I’ve missed out any country, please let me know and I will add on those countries too).
I suggest that we have one resource dedicated to bug fixing. But because bug fixing is a drag and developers would much rather work on sexy enhancements, I suggest that each Foundation Resource focus on Bug Fixing and Bug Fixing only for 1 out of every 4 weeks. I understand that Tunde is the king of bug fixing, but he can help bring the other resources up to speed on bug fixing.
Each of the four Foundation Resources are allocated projects that they work on 3 out of every 4 weeks. The other one week, they are working on bug fixing.
Here are the projects that I think we need to get going on ASAP:
Manufacturing Module
Subcontracting Process
HR Module
Accounting Module
CRM Module
Fee Module and Integration with Accounting for ERPNext Schools
Please add your passion
We assign one Foundation Resource for each activity and two Foundation Members to drive the development on that module.
Tunde is an obvious choice for the Accounting related development.
If there are other important development of existing functionality that we need to address, please add to this list.
Once we come up with the final list of initiatives, we assign developers and Foundation Members and we get going.
After getting inputs on this thread, I suggest we post this as a separate thread, get the inputs of the Foundation Members and then the Community and we execute.
Your inputs please!
Thanks
Jay
4 Likes
What we really need is a person to define work for the devs and help them with specs and feedback. Hence my earlier post for a full time analyst for the foundation.
6 Likes
I agree that improving existing features and bugfix should be the major point for foundation developers. That said, @rmehta is right : you need more experience to work on complex existing features and on bugfixes than when you create new ones.
So one question is : who can supervise new foundation developers ? Only Frappé ? Maybe foundation members employees ?
It could also be an idea to ask current foundations developers to systematically take time to document things they learn (docstrings, maybe doctests, developer documentation…) to help at the same time new community developers and new foundations developers.
Bugfixing, testing and documenting from the foundation can help Frappé team to have more time to made R&D.
3 Likes
My view:
Let them work what they like to do.
I am sure lots of more developer willing to contribute more features in ERPNext and Frappe. They just need some guidance and documentation.
After developer training video the contributions are increased. Foundation need some working plan for increasing community involvement.
I think we are concentring more on ERPNext Product rather than community. We need to build ecosystem which mentioned in following blogpost.
2 Likes
As a developer we also face same issue when we make new feature OR making any generic design from customer specific requirement.
Developer might be good in Coding, but thats not mean every good developer understand business logic and able to design system.
2 Likes
I disagree with this. It’s good to work within your comfort zone. but, foundation as an organization needs to make their resource work on things they like and related areas based on ERPNext-community priorities.
I also feel this is a challenge. Many want to contribute, but the process of pull request & related docs is too much for someone to motivate - Maybe the solution could be 2-3 contributors collaborate and work on one aspect/feature than everyone building their own ship.
Why do you say so? I thought ERPNext itself is the central part of ERPNext community eco-system. Please elaborate on what I might be missing while reading your comments.
Precisely for this reason, we kept debating on the definition of ‘Contribution’ in ERPNext conference 2017. Maybe functional people are not kept in the loop while development is happening OR the programmers are working in silos, trying to build their own ships than making part of a bigger ship.
We are happy to collaborate with any programmer on accounting, compliance, & finance related subject.
Goals of Foundation from Foundation website https://erpnext.org/about
The goal of the ERPNext Foundation is to provide a platform for the ERPNext Community to come together, join hands and build assets to help build and enhance ERPNext around the world. ERPNext Foundation aims to be a community driven organization and run in a transparent.
I feel instead of 4 developer building features and fixing bug, it will be more helpful if they help other 10 community member to contribute there features in core product.
So I have posted above comment.
1 Like
You are correct in stating that. At current stage we have only 4, maybe that will scale and become bigger to contribute and work along with non-foundation programmer and enhance ERPNext. But, someone has to resolve the bug in the current system, which I believe should be top priority over building new features, else we might lose credibility of a stable solution.
_Liyakat
1 Like
I only have a question …no one will be working on Frappè framework? All foundation devs are allocated to work on ERPNext.
Seems Frappe framework development is left in charge to Frappe team only. 
I’d rather shift 1/2 foundation dev to help core team to improve framework and fix possible bugs.
The better will become Frappe …better will be ERPNext …IMHO 
4 Likes
Good point. But we need to relook at the scope of ERPNext foundation. Is it only the product ERPNext or in includes the framework as well.
@JayRam: your comment please.
_Liyakat
Agreed
I’m sorry, but is there any significant annoyances and irritations on the Frappe Framework?
If yes, and we can define the scope of what we are trying to achieve and we are able to break it down into milestones and we have a person from the community to help the developer, we sure can dedicate a Foundation Resource for this.
Apologies if it appears that I’m setting higher yardsticks for the Frappe Framework, but its just that I don’t understand the interplay between Frappe Framework and ERPNext. Frappe Framework is too esoteric for me and I understand ERPNext enough to be dangerous. Plus it is easy to meet all those requirements for ERPNext (milestones, deliverables, domain expertise) and maybe that’s why it appears so.
If @JoEz: you have enough expertise in this area, may I please suggest that you take the lead on this and help us (Foundation & Frappe) evolve the roadmap for the Framework?
Thanks
Jay
@JayRam IMHO framework and “product” aka ERPNext are strictly correlated so, working on ERPNext feature bug fix an stuff directly involves working on Frappe Framework.
As an non exhaustive example on actual PRs: Barcode Control, Map Control, Grid Report View etc
I think the Frappe Roadmap is, let’s say a “false” problem; that could be surely driven by Frappe core team, but as Foundation IMHO, we should give some help in terms of developers to them not only defining a roadmap.
BTW, i’ve experience, probably not enough, but i’d be happy and i’ve few ideas to share with core team and help in this area.
3 Likes