From: Keith W. <kei...@gm...> - 2011-06-21 10:55:35
|
Hi all, At the moment we are wrapping up Maya G (mifos 2.2.x) (see http://mifosforge.jira.com/wiki/display/MIFOS/Maya+G) and its time to plan what to put into next release of mifos. As was mentioned in http://mifos.org/community/news/grameen-foundation-transition-mifos-community-led-effort, mifos is transitioning to 'leaders in the Mifos community'. You the users of the software can help by replying to this email and indicating what you would really like to see done on mifos for the next and following releases. This will probably fall into the following categories: 1) Bug fix: An existing known bug in mifos that annoys or hampers the way you work. e.g. I would really like to see MIFOS-XXXX fixed 2) Improvements: You would like to see an improvement in the way something works on mifos e.g. work flow, ability to edit x, ability to capture some other information currently not tracked on mifos etc 3) New Features: You like to see mifos add support for something it currently does not such as 'micro-insurance', a report that shows x, Maybe you could reply with a prioritised list of whats most important for your organisation. If you have any other comments/suggestions they are also welcome. regards, Keith. |
From: George C. <gc...@gm...> - 2011-06-23 18:07:28
|
Hey Keith it's really heartening to see you stepping up and thinking about Mifos post-Grameen, and helping to drive the conversation forward - thanks for doing this. here are a few things based on what I've seen in the last few weeks in Africa: - there's a mobile revolution underway in sub-Saharan Africa; building both the APIs/hooks for connecting into a variety of mobile systems (from mobile money to mobile interfaces for clients and MFI staff to exchange of info with other systems that are running mobile apps) and also potentially getting a few sample/reference mobile apps running on Mifos (need to vet specific pain points so we don't build something just for the sake of building it) - conversely, there are still a lot of branches etc in MFIs that have either no or unreliable connectivity. it think we should assume connectivity, but also assume that it will occasionally go down - what can we let branches do (limited functionality) in an offline model? - i think there are opportunities for Mifos to expand beyond just financial data eventually for MFIs and other orgs (like Nuru) that do a variety of things for the poor. nothing specific there yet but we should keep eyes open to other domains as well. also for you and the other engineers who have worked on MIfos: in a community model if there's less oversight, is there under-the-covers work that should be prioritized which will help keep Mifos stable and scalable as it goes forward in the community? -g On Jun 21, 2011, at 1:55 PM, Keith Woodlock wrote: > Hi all, > > At the moment we are wrapping up Maya G (mifos 2.2.x) (see > http://mifosforge.jira.com/wiki/display/MIFOS/Maya+G) and its time to > plan what to put into next release of mifos. > > As was mentioned in > http://mifos.org/community/news/grameen-foundation-transition-mifos-community-led-effort, > mifos is transitioning to 'leaders in the Mifos community'. You the > users of the software can help by replying to this email and > indicating what you would really like to see done on mifos for the > next and following releases. This will probably fall into the > following categories: > > 1) Bug fix: An existing known bug in mifos that annoys or hampers the > way you work. e.g. I would really like to see MIFOS-XXXX fixed > > 2) Improvements: You would like to see an improvement in the way > something works on mifos e.g. work flow, ability to edit x, ability to > capture some other information currently not tracked on mifos etc > > 3) New Features: You like to see mifos add support for something it > currently does not such as 'micro-insurance', a report that shows x, > > Maybe you could reply with a prioritised list of whats most important > for your organisation. > > If you have any other comments/suggestions they are also welcome. > > regards, > Keith. > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev |
From: Keith W. <kei...@gm...> - 2011-06-23 18:55:41
|
George, Thanks for your feedback. >> also for you and the other engineers who have worked on MIfos: in a community model if there's less oversight, is there under-the-covers work >> that should be prioritized which will help keep Mifos stable and scalable as it goes forward in the community? With respect to what has to be done to mifos technically and from a developer/development point of view, I have a very clear picture of what needs to be improved. Whats not clear and would be great to hear from existing/potential users of the software is what direction to take mifos as a product that will provide what is needed for todays microfinance sector. Its also clear that if we were to do all the changes we would like to do to get mifos into a state we would believe to be sufficent theres a significant amount investment (the time type) to be made. You highlighted two significant areas for sub-saharan africa 1) integration with mobile money/ branchless banking systems 2) ability to integrate offline capabilities. Both of these require the right services to be 'exposed' to allow easier integration with mifos MIS and can be done. I think whats needed is some organisation who needs this done to give it some direction so we can produce something real and valuable and evolve from there. regards, Keith. On Thu, Jun 23, 2011 at 7:08 PM, George Conard <gc...@gm...> wrote: > Hey Keith > > it's really heartening to see you stepping up and thinking about Mifos post-Grameen, and helping to drive the conversation forward - thanks for doing this. > > here are a few things based on what I've seen in the last few weeks in Africa: > - there's a mobile revolution underway in sub-Saharan Africa; building both the APIs/hooks for connecting into a variety of mobile systems (from mobile money to mobile interfaces for clients and MFI staff to exchange of info with other systems that are running mobile apps) and also potentially getting a few sample/reference mobile apps running on Mifos (need to vet specific pain points so we don't build something just for the sake of building it) > - conversely, there are still a lot of branches etc in MFIs that have either no or unreliable connectivity. it think we should assume connectivity, but also assume that it will occasionally go down - what can we let branches do (limited functionality) in an offline model? > - i think there are opportunities for Mifos to expand beyond just financial data eventually for MFIs and other orgs (like Nuru) that do a variety of things for the poor. nothing specific there yet but we should keep eyes open to other domains as well. > > also for you and the other engineers who have worked on MIfos: in a community model if there's less oversight, is there under-the-covers work that should be prioritized which will help keep Mifos stable and scalable as it goes forward in the community? > > -g > > On Jun 21, 2011, at 1:55 PM, Keith Woodlock wrote: > >> Hi all, >> >> At the moment we are wrapping up Maya G (mifos 2.2.x) (see >> http://mifosforge.jira.com/wiki/display/MIFOS/Maya+G) and its time to >> plan what to put into next release of mifos. >> >> As was mentioned in >> http://mifos.org/community/news/grameen-foundation-transition-mifos-community-led-effort, >> mifos is transitioning to 'leaders in the Mifos community'. You the >> users of the software can help by replying to this email and >> indicating what you would really like to see done on mifos for the >> next and following releases. This will probably fall into the >> following categories: >> >> 1) Bug fix: An existing known bug in mifos that annoys or hampers the >> way you work. e.g. I would really like to see MIFOS-XXXX fixed >> >> 2) Improvements: You would like to see an improvement in the way >> something works on mifos e.g. work flow, ability to edit x, ability to >> capture some other information currently not tracked on mifos etc >> >> 3) New Features: You like to see mifos add support for something it >> currently does not such as 'micro-insurance', a report that shows x, >> >> Maybe you could reply with a prioritised list of whats most important >> for your organisation. >> >> If you have any other comments/suggestions they are also welcome. >> >> regards, >> Keith. >> >> ------------------------------------------------------------------------------ >> EditLive Enterprise is the world's most technically advanced content >> authoring tool. Experience the power of Track Changes, Inline Image >> Editing and ensure content is compliant with Accessibility Checking. >> http://p.sf.net/sfu/ephox-dev2dev > > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Data protection magic? > Nope - It's vRanger. Get your free trial download today. > http://p.sf.net/sfu/quest-sfdev2dev > |
From: George C. <gc...@gm...> - 2011-06-27 09:52:22
|
Hi Keith - > > With respect to what has to be done to mifos technically and from a > developer/development point of view, I have a very clear picture of > what needs to be improved. is this up on mifos.org somewhere? i just looked but couldn't find - admittedly, I may not have looked in the right place. :-) > <snip> > > Its also clear that if we were to do all the changes we would like to > do to get mifos into a state we would believe to be sufficent theres a > significant amount investment (the time type) to be made. You > highlighted two significant areas for sub-saharan africa 1) > integration with mobile money/ branchless banking systems 2) ability > to integrate offline capabilities. Both of these require the right > services to be 'exposed' to allow easier integration with mifos MIS > and can be done. I think whats needed is some organisation who needs > this done to give it some direction so we can produce something real > and valuable and evolve from there. totally agree - need to have specific customers for any/all of the work being done. |
From: Keith W. <kei...@gm...> - 2011-06-27 11:51:22
|
George, >> >> With respect to what has to be done to mifos technically and from a >> developer/development point of view, I have a very clear picture of >> what needs to be improved. > > is this up on mifos.org somewhere? i just looked but couldn't find - admittedly, I may not have looked in the right place. :-) The developer wiki is a mix of old and new content, with some old content being outdated and some still very relevant. In places to try and grasp what has to be done there is the technology planning pages (http://mifosforge.jira.com/wiki/display/MIFOS/Mifos+Technology+Planning) but I guess things have changed recently and I have my own views on what can be done and it what order it should happen. I've documented my thoughts at http://mifosforge.jira.com/wiki/display/MIFOS/Technical+Roadmap+%28Post+Maya+G+and+onwards%29 regards, Keith. On Mon, Jun 27, 2011 at 10:53 AM, George Conard <gc...@gm...> wrote: > Hi Keith - > >> >> With respect to what has to be done to mifos technically and from a >> developer/development point of view, I have a very clear picture of >> what needs to be improved. > > is this up on mifos.org somewhere? i just looked but couldn't find - admittedly, I may not have looked in the right place. :-) > > >> <snip> >> >> Its also clear that if we were to do all the changes we would like to >> do to get mifos into a state we would believe to be sufficent theres a >> significant amount investment (the time type) to be made. You >> highlighted two significant areas for sub-saharan africa 1) >> integration with mobile money/ branchless banking systems 2) ability >> to integrate offline capabilities. Both of these require the right >> services to be 'exposed' to allow easier integration with mifos MIS >> and can be done. I think whats needed is some organisation who needs >> this done to give it some direction so we can produce something real >> and valuable and evolve from there. > > totally agree - need to have specific customers for any/all of the work being done. > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > |
From: George C. <gc...@gm...> - 2011-06-27 10:08:41
|
> We have started using a mobile version of Mifos, with very simple interfaces to upload data from the field. Its NOT mobile money transaction, though. We are also planning to use Mifos as backend for another application in a financial inclusion programme. cool! you're at ASOMI, right? do you have any screen shots of the mobile version of Mifos you're using? is it something that can be contributed back to the community so that others can also use it? |
From: Van Mittal-H. <va...@gr...> - 2011-06-30 05:05:42
|
George, I'm catching up on some of these threads after being out for a few days > - there's a mobile revolution underway in sub-Saharan Africa; building > both the APIs/hooks for connecting into a variety of mobile systems > (from mobile money to mobile interfaces for clients and MFI staff to > exchange of info with other systems that are running mobile apps) and > also potentially getting a few sample/reference mobile apps running on > Mifos (need to vet specific pain points so we don't build something > just for the sake of building it) If Mifos provided Restful or WSDL based APIs it would open up lots of possibilities for building on Mifos for things like this. Having stable APIs for people to build on is one of the things we have been working towards for some time. A lot of KeithW's efforts in particular have been around getting internals to a state where we could start layering an API on them. As mentioned, getting specific customers with specific use cases to drive this is key. > also for you and the other engineers who have worked on MIfos: in a > community model if there's less oversight, is there under-the-covers > work that should be prioritized which will help keep Mifos stable and > scalable as it goes forward in the community? Here's where some big questions come up. One hypothesis is that there are two classes of Mifos users-- Class 1: larger MFIs who have a need for various extensions and customizations of Mifos and who can take on some expense to do that and even host their own infrastructure and Class 2: smaller MFIs who could likely manage with fewer features and less extensibility and who would benefit most from low cost hosted access to Mifos. How to most effectively meet the needs of both users is tricky. We've been challenged by the current code base being difficult and expensive to extend and maintain. We have made progress in improving the code and certain areas of it are much easier to deal with now. However, there is still a large amount of code left that needs improvement. The most cost effective way to deliver a solution that can be effectively hosted at very low cost (supporting multi-tenancy for example) at this point looks like a rewrite that would pull in reusable parts of Mifos but redo the basics from the ground up to get things like multi-tenancy, transaction management, auditing, clean i18n, layered architecture, separation of concerns and manageable tests in place. To keep the cost of doing a rewrite low, it would help for the target release to have fewer features and options than Mifos currently does. On the other hand, supporting larger existing and new MFIs and those requiring the larger feature set currently supported by Mifos would benefit from the current code base being extended and refined. The difficulty here is that the cost to continue maintaining the current code is high as is the cost to refactor and improve it. Keith and I are in agreement on the things that he already laid out here: http://mifosforge.jira.com/wiki/display/MIFOS/Technical+Roadmap+%28Post+ Maya+G+and+onwards%29 This is a good list of how the current code base could be moved forward. Replacing the current Struts/JSP based UI code with Spring/Freemarker is the biggest single enabler for lowering the cost of maintaining and extending Mifos. It leads to: * API creation across the application (by achieving complete separation of business logic from presentation code) * simplified transaction management * simplified i18n * improvement of layered architecture * reduction and simplification of test code --Van |
From: Binny G. <bin...@gm...> - 2011-07-01 04:50:36
|
Are we concentrating too much on technical improvements while not paying adequate attention to new/improved features? Technical improvements without any visible improvement to end-users - may cause users to consider moving away from Mifos. I would like releases to be a mix of new/improved functional features + a bunch of technical improvements. I have had the chance to get a glimpse into some of our competition and very soon our feature set is going to be insufficient, which is heartbreaking .. On technical improvements: - would be good to include testing/handling of larger volumes - I have had a couple of enquiries from large MFI's - one of them has 4+ million members - on i18n, would be good to allow overriding of specific internationalized labels look up from config folders - so that they do not get overwritten by any upgrades. And also handle date formats consistently, especially in reports. Thanks Binny On Thu, Jun 30, 2011 at 10:33 AM, Van Mittal-Henkle < va...@gr...> wrote: > George, > > I'm catching up on some of these threads after being out for a few days > > > - there's a mobile revolution underway in sub-Saharan Africa; building > > both the APIs/hooks for connecting into a variety of mobile systems > > (from mobile money to mobile interfaces for clients and MFI staff to > > exchange of info with other systems that are running mobile apps) and > > also potentially getting a few sample/reference mobile apps running on > > Mifos (need to vet specific pain points so we don't build something > > just for the sake of building it) > > If Mifos provided Restful or WSDL based APIs it would open up lots of > possibilities for building on Mifos for things like this. Having stable > APIs for people to build on is one of the things we have been working > towards for some time. A lot of KeithW's efforts in particular have > been around getting internals to a state where we could start layering > an API on them. As mentioned, getting specific customers with specific > use cases to drive this is key. > > > also for you and the other engineers who have worked on MIfos: in a > > community model if there's less oversight, is there under-the-covers > > work that should be prioritized which will help keep Mifos stable and > > scalable as it goes forward in the community? > > Here's where some big questions come up. > > One hypothesis is that there are two classes of Mifos users-- Class 1: > larger MFIs who have a need for various extensions and customizations of > Mifos and who can take on some expense to do that and even host their > own infrastructure and Class 2: smaller MFIs who could likely manage > with fewer features and less extensibility and who would benefit most > from low cost hosted access to Mifos. > > How to most effectively meet the needs of both users is tricky. > > We've been challenged by the current code base being difficult and > expensive to extend and maintain. We have made progress in improving > the code and certain areas of it are much easier to deal with now. > However, there is still a large amount of code left that needs > improvement. > > The most cost effective way to deliver a solution that can be > effectively hosted at very low cost (supporting multi-tenancy for > example) at this point looks like a rewrite that would pull in reusable > parts of Mifos but redo the basics from the ground up to get things like > multi-tenancy, transaction management, auditing, clean i18n, layered > architecture, separation of concerns and manageable tests in place. To > keep the cost of doing a rewrite low, it would help for the target > release to have fewer features and options than Mifos currently does. > > On the other hand, supporting larger existing and new MFIs and those > requiring the larger feature set currently supported by Mifos would > benefit from the current code base being extended and refined. The > difficulty here is that the cost to continue maintaining the current > code is high as is the cost to refactor and improve it. > > Keith and I are in agreement on the things that he already laid out > here: > http://mifosforge.jira.com/wiki/display/MIFOS/Technical+Roadmap+%28Post+ > Maya+G+and+onwards%29<http://mifosforge.jira.com/wiki/display/MIFOS/Technical+Roadmap+%28Post+%0AMaya+G+and+onwards%29> > > This is a good list of how the current code base could be moved forward. > > > Replacing the current Struts/JSP based UI code with Spring/Freemarker is > the biggest single enabler for lowering the cost of maintaining and > extending Mifos. It leads to: > * API creation across the application (by achieving complete separation > of business logic from presentation code) > * simplified transaction management > * simplified i18n > * improvement of layered architecture > * reduction and simplification of test code > > --Van > > > |
From: Keith W. <kei...@gm...> - 2011-07-01 12:12:05
|
Binny, > Are we concentrating too much on technical improvements while not paying > adequate attention to new/improved features? Yes, this is the whole point of this email chain. I was asking for input/feedback from the users about what to put into mifos after Maya G. So far only george has offered some insight into what might be useful going forward. From a technical point of view we know what we need to do but theres no point in taking on that investment unless customers out there want further features/improvements etc regards, Keith. On Fri, Jul 1, 2011 at 5:50 AM, Binny Gopinath <bin...@gm...> wrote: > > Are we concentrating too much on technical improvements while not paying > adequate attention to new/improved features? > > Technical improvements without any visible improvement to end-users - may > cause users to consider moving away from Mifos. I would like releases to be > a mix of new/improved functional features + a bunch of technical > improvements. I have had the chance to get a glimpse into some of our > competition and very soon our feature set is going to be insufficient, which > is heartbreaking .. > > On technical improvements: > - would be good to include testing/handling of larger volumes - I have had a > couple of enquiries from large MFI's - one of them has 4+ million members > - on i18n, would be good to allow overriding of specific internationalized > labels look up from config folders - so that they do not get overwritten by > any upgrades. And also handle date formats consistently, especially in > reports. > > Thanks > Binny > > > On Thu, Jun 30, 2011 at 10:33 AM, Van Mittal-Henkle > <va...@gr...> wrote: >> >> George, >> >> I'm catching up on some of these threads after being out for a few days >> >> > - there's a mobile revolution underway in sub-Saharan Africa; building >> > both the APIs/hooks for connecting into a variety of mobile systems >> > (from mobile money to mobile interfaces for clients and MFI staff to >> > exchange of info with other systems that are running mobile apps) and >> > also potentially getting a few sample/reference mobile apps running on >> > Mifos (need to vet specific pain points so we don't build something >> > just for the sake of building it) >> >> If Mifos provided Restful or WSDL based APIs it would open up lots of >> possibilities for building on Mifos for things like this. Having stable >> APIs for people to build on is one of the things we have been working >> towards for some time. A lot of KeithW's efforts in particular have >> been around getting internals to a state where we could start layering >> an API on them. As mentioned, getting specific customers with specific >> use cases to drive this is key. >> >> > also for you and the other engineers who have worked on MIfos: in a >> > community model if there's less oversight, is there under-the-covers >> > work that should be prioritized which will help keep Mifos stable and >> > scalable as it goes forward in the community? >> >> Here's where some big questions come up. >> >> One hypothesis is that there are two classes of Mifos users-- Class 1: >> larger MFIs who have a need for various extensions and customizations of >> Mifos and who can take on some expense to do that and even host their >> own infrastructure and Class 2: smaller MFIs who could likely manage >> with fewer features and less extensibility and who would benefit most >> from low cost hosted access to Mifos. >> >> How to most effectively meet the needs of both users is tricky. >> >> We've been challenged by the current code base being difficult and >> expensive to extend and maintain. We have made progress in improving >> the code and certain areas of it are much easier to deal with now. >> However, there is still a large amount of code left that needs >> improvement. >> >> The most cost effective way to deliver a solution that can be >> effectively hosted at very low cost (supporting multi-tenancy for >> example) at this point looks like a rewrite that would pull in reusable >> parts of Mifos but redo the basics from the ground up to get things like >> multi-tenancy, transaction management, auditing, clean i18n, layered >> architecture, separation of concerns and manageable tests in place. To >> keep the cost of doing a rewrite low, it would help for the target >> release to have fewer features and options than Mifos currently does. >> >> On the other hand, supporting larger existing and new MFIs and those >> requiring the larger feature set currently supported by Mifos would >> benefit from the current code base being extended and refined. The >> difficulty here is that the cost to continue maintaining the current >> code is high as is the cost to refactor and improve it. >> >> Keith and I are in agreement on the things that he already laid out >> here: >> http://mifosforge.jira.com/wiki/display/MIFOS/Technical+Roadmap+%28Post+ >> Maya+G+and+onwards%29 >> >> This is a good list of how the current code base could be moved forward. >> >> >> Replacing the current Struts/JSP based UI code with Spring/Freemarker is >> the biggest single enabler for lowering the cost of maintaining and >> extending Mifos. It leads to: >> * API creation across the application (by achieving complete separation >> of business logic from presentation code) >> * simplified transaction management >> * simplified i18n >> * improvement of layered architecture >> * reduction and simplification of test code >> >> --Van >> >> > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Mifos-users mailing list > Mif...@li... > https://lists.sourceforge.net/lists/listinfo/mifos-users > > |
From: George C. <gc...@gm...> - 2011-07-12 22:01:09
|
Hi Van - I missed this when it came through last month. Here are a few thoughts based on what I'm seeing so far in Africa: >> also for you and the other engineers who have worked on MIfos: in a >> community model if there's less oversight, is there under-the-covers >> work that should be prioritized which will help keep Mifos stable and >> scalable as it goes forward in the community? > > Here's where some big questions come up. > > One hypothesis is that there are two classes of Mifos users-- Class 1: > larger MFIs who have a need for various extensions and customizations of > Mifos and who can take on some expense to do that and even host their > own infrastructure and Class 2: smaller MFIs who could likely manage > with fewer features and less extensibility and who would benefit most > from low cost hosted access to Mifos. > How to most effectively meet the needs of both users is tricky. > > We've been challenged by the current code base being difficult and > expensive to extend and maintain. We have made progress in improving > the code and certain areas of it are much easier to deal with now. > However, there is still a large amount of code left that needs > improvement. I agree with that hypothesis and i think you're dead on that it's gonna be hard - especially as the development time/energy on Mifos decreases in the future - to optimize for both/multiple audiences. The surveys/voting on features discussed on other threads is a good start at getting more MFIs engaged on direction setting for Mifos but I think we'll also have to take a decision as a community as to the overall strategic focus for Mifos. With fewer resources, Mifos can't be everything to everyone (it never could in the past either, but it's way more true now). I think the focus we had at Grameen Foundation - small to medium sized, visionary MFIs - was good. Doing the API development you talked about will also make it a lot easier (presumably) to build loosely coupled extensions to Mifos that don't necessarily have to be maintained by the full community, and hopefully would lower the QA/etc burden. > The most cost effective way to deliver a solution that can be > effectively hosted at very low cost (supporting multi-tenancy for > example) at this point looks like a rewrite that would pull in reusable > parts of Mifos but redo the basics from the ground up to get things like > multi-tenancy, transaction management, auditing, clean i18n, layered > architecture, separation of concerns and manageable tests in place. To > keep the cost of doing a rewrite low, it would help for the target > release to have fewer features and options than Mifos currently does. I guess the question there is: do we (the community) have the resources to do a rewrite like that? It sounds good in theory but if it takes 3 years and all of the limited community resources, it may not be as good for MFIs as living with the existing codebase. Does it make sense to have a thread on what has already been rewritten that could be reused, and what would need to be rewritten? We could see how much of the old code functionality could be pared away if we were super focused on a particular class of MFI. I looked at Keith's doc that you linked to - wonder if the thing that's missing is what we could lose without killing Mifos altogether. That said, if you and Keith and others just wanna rewrite the thing over the summer that would solve the whole problem. I'd offer to help, but I suspect my code would be a net liability rather than an asset. :-) > On the other hand, supporting larger existing and new MFIs and those > requiring the larger feature set currently supported by Mifos would > benefit from the current code base being extended and refined. The > difficulty here is that the cost to continue maintaining the current > code is high as is the cost to refactor and improve it. > > Keith and I are in agreement on the things that he already laid out > here: > http://mifosforge.jira.com/wiki/display/MIFOS/Technical+Roadmap+%28Post+ > Maya+G+and+onwards%29 > > This is a good list of how the current code base could be moved forward. > > > Replacing the current Struts/JSP based UI code with Spring/Freemarker is > the biggest single enabler for lowering the cost of maintaining and > extending Mifos. It leads to: > * API creation across the application (by achieving complete separation > of business logic from presentation code) > * simplified transaction management > * simplified i18n > * improvement of layered architecture > * reduction and simplification of test code interesting, that sounds like a good place to start - especially in the "Projects" model that Ed was talking about. I won't likely be hiring engineers in Africa until September at the earliest, but this is super helpful in thinking about where we might focus efforts when/if the business/org I'm scoping out comes online. Cheers, -george George Conard US: +1 206 778 7429 Kenya: +254 (0) 705 038 704 Ghana: +233 (0) 54 975 4222 www.georgeconard.com gc...@gm... @GeorgeConard |
From: Ed C. <ed...@gm...> - 2011-07-01 14:30:53
|
Keith, I think thread may have gotten a bit too technical in discussion and some users didn't realize original intent of thread. Do you want to start up another individual thread on mifos-users regarding functional improvements users would like to see? I'm certain built-in or integrated accounting, automatic fees, support for photos or file attachments, business rules between loan and savings accounts would be some of the requests. I think we're overdue for a community-wide user meeting then can narrow down some of the functional improvements community would like to see as we start a process for identifying, proposing, and then prioritizing community driven processes. Ed On Jul 1, 2011 5:13 AM, "Keith Woodlock" <kei...@gm...> wrote: > Binny, > >> Are we concentrating too much on technical improvements while not paying >> adequate attention to new/improved features? > > Yes, this is the whole point of this email chain. I was asking for > input/feedback from the users about what to put into mifos after Maya > G. So far only george has offered some insight into what might be > useful going forward. From a technical point of view we know what we > need to do but theres no point in taking on that investment unless > customers out there want further features/improvements etc > > regards, > Keith. > > On Fri, Jul 1, 2011 at 5:50 AM, Binny Gopinath <bin...@gm...> wrote: >> >> Are we concentrating too much on technical improvements while not paying >> adequate attention to new/improved features? >> >> Technical improvements without any visible improvement to end-users - may >> cause users to consider moving away from Mifos. I would like releases to be >> a mix of new/improved functional features + a bunch of technical >> improvements. I have had the chance to get a glimpse into some of our >> competition and very soon our feature set is going to be insufficient, which >> is heartbreaking .. >> >> On technical improvements: >> - would be good to include testing/handling of larger volumes - I have had a >> couple of enquiries from large MFI's - one of them has 4+ million members >> - on i18n, would be good to allow overriding of specific internationalized >> labels look up from config folders - so that they do not get overwritten by >> any upgrades. And also handle date formats consistently, especially in >> reports. >> >> Thanks >> Binny >> >> >> On Thu, Jun 30, 2011 at 10:33 AM, Van Mittal-Henkle >> <va...@gr...> wrote: >>> >>> George, >>> >>> I'm catching up on some of these threads after being out for a few days >>> >>> > - there's a mobile revolution underway in sub-Saharan Africa; building >>> > both the APIs/hooks for connecting into a variety of mobile systems >>> > (from mobile money to mobile interfaces for clients and MFI staff to >>> > exchange of info with other systems that are running mobile apps) and >>> > also potentially getting a few sample/reference mobile apps running on >>> > Mifos (need to vet specific pain points so we don't build something >>> > just for the sake of building it) >>> >>> If Mifos provided Restful or WSDL based APIs it would open up lots of >>> possibilities for building on Mifos for things like this. Having stable >>> APIs for people to build on is one of the things we have been working >>> towards for some time. A lot of KeithW's efforts in particular have >>> been around getting internals to a state where we could start layering >>> an API on them. As mentioned, getting specific customers with specific >>> use cases to drive this is key. >>> >>> > also for you and the other engineers who have worked on MIfos: in a >>> > community model if there's less oversight, is there under-the-covers >>> > work that should be prioritized which will help keep Mifos stable and >>> > scalable as it goes forward in the community? >>> >>> Here's where some big questions come up. >>> >>> One hypothesis is that there are two classes of Mifos users-- Class 1: >>> larger MFIs who have a need for various extensions and customizations of >>> Mifos and who can take on some expense to do that and even host their >>> own infrastructure and Class 2: smaller MFIs who could likely manage >>> with fewer features and less extensibility and who would benefit most >>> from low cost hosted access to Mifos. >>> >>> How to most effectively meet the needs of both users is tricky. >>> >>> We've been challenged by the current code base being difficult and >>> expensive to extend and maintain. We have made progress in improving >>> the code and certain areas of it are much easier to deal with now. >>> However, there is still a large amount of code left that needs >>> improvement. >>> >>> The most cost effective way to deliver a solution that can be >>> effectively hosted at very low cost (supporting multi-tenancy for >>> example) at this point looks like a rewrite that would pull in reusable >>> parts of Mifos but redo the basics from the ground up to get things like >>> multi-tenancy, transaction management, auditing, clean i18n, layered >>> architecture, separation of concerns and manageable tests in place. To >>> keep the cost of doing a rewrite low, it would help for the target >>> release to have fewer features and options than Mifos currently does. >>> >>> On the other hand, supporting larger existing and new MFIs and those >>> requiring the larger feature set currently supported by Mifos would >>> benefit from the current code base being extended and refined. The >>> difficulty here is that the cost to continue maintaining the current >>> code is high as is the cost to refactor and improve it. >>> >>> Keith and I are in agreement on the things that he already laid out >>> here: >>> http://mifosforge.jira.com/wiki/display/MIFOS/Technical+Roadmap+%28Post+ >>> Maya+G+and+onwards%29 >>> >>> This is a good list of how the current code base could be moved forward. >>> >>> >>> Replacing the current Struts/JSP based UI code with Spring/Freemarker is >>> the biggest single enabler for lowering the cost of maintaining and >>> extending Mifos. It leads to: >>> * API creation across the application (by achieving complete separation >>> of business logic from presentation code) >>> * simplified transaction management >>> * simplified i18n >>> * improvement of layered architecture >>> * reduction and simplification of test code >>> >>> --Van >>> >>> >> >> ------------------------------------------------------------------------------ >> All of the data generated in your IT infrastructure is seriously valuable. >> Why? It contains a definitive record of application performance, security >> threats, fraudulent activity, and more. Splunk takes this data and makes >> sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-d2d-c2 >> _______________________________________________ >> Mifos-users mailing list >> Mif...@li... >> https://lists.sourceforge.net/lists/listinfo/mifos-users >> >> > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Mifos-users mailing list > Mif...@li... > https://lists.sourceforge.net/lists/listinfo/mifos-users |
From: Keith W. <kei...@gm...> - 2011-07-01 14:40:10
|
Ed, your probably right. I think its a good thing to get the users/MFIs together in any medium possible to flesh out what is critical from a product point of view. regards, Keith. On Fri, Jul 1, 2011 at 3:30 PM, Ed Cable <ed...@gm...> wrote: > Keith, > > I think thread may have gotten a bit too technical in discussion and some > users didn't realize original intent of thread. > > Do you want to start up another individual thread on mifos-users regarding > functional improvements users would like to see? I'm certain built-in or > integrated accounting, automatic fees, support for photos or file > attachments, business rules between loan and savings accounts would be some > of the requests. > > I think we're overdue for a community-wide user meeting then can narrow down > some of the functional improvements community would like to see as we start > a process for identifying, proposing, and then prioritizing community driven > processes. > > Ed > > On Jul 1, 2011 5:13 AM, "Keith Woodlock" <kei...@gm...> wrote: >> Binny, >> >>> Are we concentrating too much on technical improvements while not paying >>> adequate attention to new/improved features? >> >> Yes, this is the whole point of this email chain. I was asking for >> input/feedback from the users about what to put into mifos after Maya >> G. So far only george has offered some insight into what might be >> useful going forward. From a technical point of view we know what we >> need to do but theres no point in taking on that investment unless >> customers out there want further features/improvements etc >> >> regards, >> Keith. >> >> On Fri, Jul 1, 2011 at 5:50 AM, Binny Gopinath <bin...@gm...> >> wrote: >>> >>> Are we concentrating too much on technical improvements while not paying >>> adequate attention to new/improved features? >>> >>> Technical improvements without any visible improvement to end-users - may >>> cause users to consider moving away from Mifos. I would like releases to >>> be >>> a mix of new/improved functional features + a bunch of technical >>> improvements. I have had the chance to get a glimpse into some of our >>> competition and very soon our feature set is going to be insufficient, >>> which >>> is heartbreaking .. >>> >>> On technical improvements: >>> - would be good to include testing/handling of larger volumes - I have >>> had a >>> couple of enquiries from large MFI's - one of them has 4+ million members >>> - on i18n, would be good to allow overriding of specific >>> internationalized >>> labels look up from config folders - so that they do not get overwritten >>> by >>> any upgrades. And also handle date formats consistently, especially in >>> reports. >>> >>> Thanks >>> Binny >>> >>> >>> On Thu, Jun 30, 2011 at 10:33 AM, Van Mittal-Henkle >>> <va...@gr...> wrote: >>>> >>>> George, >>>> >>>> I'm catching up on some of these threads after being out for a few days >>>> >>>> > - there's a mobile revolution underway in sub-Saharan Africa; building >>>> > both the APIs/hooks for connecting into a variety of mobile systems >>>> > (from mobile money to mobile interfaces for clients and MFI staff to >>>> > exchange of info with other systems that are running mobile apps) and >>>> > also potentially getting a few sample/reference mobile apps running on >>>> > Mifos (need to vet specific pain points so we don't build something >>>> > just for the sake of building it) >>>> >>>> If Mifos provided Restful or WSDL based APIs it would open up lots of >>>> possibilities for building on Mifos for things like this. Having stable >>>> APIs for people to build on is one of the things we have been working >>>> towards for some time. A lot of KeithW's efforts in particular have >>>> been around getting internals to a state where we could start layering >>>> an API on them. As mentioned, getting specific customers with specific >>>> use cases to drive this is key. >>>> >>>> > also for you and the other engineers who have worked on MIfos: in a >>>> > community model if there's less oversight, is there under-the-covers >>>> > work that should be prioritized which will help keep Mifos stable and >>>> > scalable as it goes forward in the community? >>>> >>>> Here's where some big questions come up. >>>> >>>> One hypothesis is that there are two classes of Mifos users-- Class 1: >>>> larger MFIs who have a need for various extensions and customizations of >>>> Mifos and who can take on some expense to do that and even host their >>>> own infrastructure and Class 2: smaller MFIs who could likely manage >>>> with fewer features and less extensibility and who would benefit most >>>> from low cost hosted access to Mifos. >>>> >>>> How to most effectively meet the needs of both users is tricky. >>>> >>>> We've been challenged by the current code base being difficult and >>>> expensive to extend and maintain. We have made progress in improving >>>> the code and certain areas of it are much easier to deal with now. >>>> However, there is still a large amount of code left that needs >>>> improvement. >>>> >>>> The most cost effective way to deliver a solution that can be >>>> effectively hosted at very low cost (supporting multi-tenancy for >>>> example) at this point looks like a rewrite that would pull in reusable >>>> parts of Mifos but redo the basics from the ground up to get things like >>>> multi-tenancy, transaction management, auditing, clean i18n, layered >>>> architecture, separation of concerns and manageable tests in place. To >>>> keep the cost of doing a rewrite low, it would help for the target >>>> release to have fewer features and options than Mifos currently does. >>>> >>>> On the other hand, supporting larger existing and new MFIs and those >>>> requiring the larger feature set currently supported by Mifos would >>>> benefit from the current code base being extended and refined. The >>>> difficulty here is that the cost to continue maintaining the current >>>> code is high as is the cost to refactor and improve it. >>>> >>>> Keith and I are in agreement on the things that he already laid out >>>> here: >>>> http://mifosforge.jira.com/wiki/display/MIFOS/Technical+Roadmap+%28Post+ >>>> Maya+G+and+onwards%29 >>>> >>>> This is a good list of how the current code base could be moved forward. >>>> >>>> >>>> Replacing the current Struts/JSP based UI code with Spring/Freemarker is >>>> the biggest single enabler for lowering the cost of maintaining and >>>> extending Mifos. It leads to: >>>> * API creation across the application (by achieving complete separation >>>> of business logic from presentation code) >>>> * simplified transaction management >>>> * simplified i18n >>>> * improvement of layered architecture >>>> * reduction and simplification of test code >>>> >>>> --Van >>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> All of the data generated in your IT infrastructure is seriously >>> valuable. >>> Why? It contains a definitive record of application performance, security >>> threats, fraudulent activity, and more. Splunk takes this data and makes >>> sense of it. IT sense. And common sense. >>> http://p.sf.net/sfu/splunk-d2d-c2 >>> _______________________________________________ >>> Mifos-users mailing list >>> Mif...@li... >>> https://lists.sourceforge.net/lists/listinfo/mifos-users >>> >>> >> >> >> ------------------------------------------------------------------------------ >> All of the data generated in your IT infrastructure is seriously valuable. >> Why? It contains a definitive record of application performance, security >> threats, fraudulent activity, and more. Splunk takes this data and makes >> sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-d2d-c2 >> _______________________________________________ >> Mifos-users mailing list >> Mif...@li... >> https://lists.sourceforge.net/lists/listinfo/mifos-users > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Mifos-users mailing list > Mif...@li... > https://lists.sourceforge.net/lists/listinfo/mifos-users > > |
From: Binny G. <bin...@gm...> - 2011-07-01 16:14:41
|
Keith, Here are the high-lelvel points I have gathered during my interactions with Mifos users: Priority 1: *Reporting and Dashboards* - we have made good progress on this. But there is still some work here to get a few more key reports created or fixed. And also sort out some of the ETL related issues, make the ETL job quicker, reduce installation complexity, integrate reporting UI with Mifos etc. .. *Flexibile loan scheduling* - with facility for individual lending - Maya G's allowing a member to have loans with differing frequencies takes care of this partially. However, navigating to such individual loans (members may not belong to groups) still will have some challenges in Maya G *Accounting* - there are 2 approaches that MFI's have been requesting in India: a) Integrated accounting module - specifically for branch level accounting Also we need to re-look into accrual accounting and a cash book maintenance/cash management module b) Better integration with an existing accounting software like Tally *Disbursement date flexibility* - ability to specify a loan disbursement date in the future and not just the meeting period immediately following the current date *Data migration toolkit* - facility for easily and cleanly getting past member/group/loan data into Mifos - SunGard guys have developed a tool for this. They did give me a demo of this. We should just test and adopt this. Priority 2: *Mobile devices* and handheld device integration *Offline data entry* - important if Mifos has to be adopted by larger MFIs/SHGs who have better reach in rural areas (where internet connectivity is poor and electricity is available only for 1 or 2 hours on some days) *Adequate Support for Self Help Groups* - where more details of each groups linkage with their banks accounts can be managed, managing linkage between savings and loans etc. *Support for large MFIs* (> 1 million customers) - batch jobs and upgrades and reporting becomes a challenge with some tables have millions of rows Priority 3: HR integration - attendance, user security etc. Customer acquisition process - to schedule and manage the client pre-enrollment process (Group trainings and group tests) Customization of look and feel (logo, colors etc.) per installation - move internationalization resource bundles to the configuration folder so that it can be customized and deployed without being overwritten by each upgrade Integration with Credit Bureau / Identity verification systems Thanks Binny On Fri, Jul 1, 2011 at 5:41 PM, Keith Woodlock <kei...@gm...>wrote: > Binny, > > > Are we concentrating too much on technical improvements while not paying > > adequate attention to new/improved features? > > Yes, this is the whole point of this email chain. I was asking for > input/feedback from the users about what to put into mifos after Maya > G. So far only george has offered some insight into what might be > useful going forward. From a technical point of view we know what we > need to do but theres no point in taking on that investment unless > customers out there want further features/improvements etc > > regards, > Keith. > > On Fri, Jul 1, 2011 at 5:50 AM, Binny Gopinath <bin...@gm...> > wrote: > > > > Are we concentrating too much on technical improvements while not paying > > adequate attention to new/improved features? > > > > Technical improvements without any visible improvement to end-users - may > > cause users to consider moving away from Mifos. I would like releases to > be > > a mix of new/improved functional features + a bunch of technical > > improvements. I have had the chance to get a glimpse into some of our > > competition and very soon our feature set is going to be insufficient, > which > > is heartbreaking .. > > > > On technical improvements: > > - would be good to include testing/handling of larger volumes - I have > had a > > couple of enquiries from large MFI's - one of them has 4+ million members > > - on i18n, would be good to allow overriding of specific > internationalized > > labels look up from config folders - so that they do not get overwritten > by > > any upgrades. And also handle date formats consistently, especially in > > reports. > > > > Thanks > > Binny > > > > > > On Thu, Jun 30, 2011 at 10:33 AM, Van Mittal-Henkle > > <va...@gr...> wrote: > >> > >> George, > >> > >> I'm catching up on some of these threads after being out for a few days > >> > >> > - there's a mobile revolution underway in sub-Saharan Africa; building > >> > both the APIs/hooks for connecting into a variety of mobile systems > >> > (from mobile money to mobile interfaces for clients and MFI staff to > >> > exchange of info with other systems that are running mobile apps) and > >> > also potentially getting a few sample/reference mobile apps running on > >> > Mifos (need to vet specific pain points so we don't build something > >> > just for the sake of building it) > >> > >> If Mifos provided Restful or WSDL based APIs it would open up lots of > >> possibilities for building on Mifos for things like this. Having stable > >> APIs for people to build on is one of the things we have been working > >> towards for some time. A lot of KeithW's efforts in particular have > >> been around getting internals to a state where we could start layering > >> an API on them. As mentioned, getting specific customers with specific > >> use cases to drive this is key. > >> > >> > also for you and the other engineers who have worked on MIfos: in a > >> > community model if there's less oversight, is there under-the-covers > >> > work that should be prioritized which will help keep Mifos stable and > >> > scalable as it goes forward in the community? > >> > >> Here's where some big questions come up. > >> > >> One hypothesis is that there are two classes of Mifos users-- Class 1: > >> larger MFIs who have a need for various extensions and customizations of > >> Mifos and who can take on some expense to do that and even host their > >> own infrastructure and Class 2: smaller MFIs who could likely manage > >> with fewer features and less extensibility and who would benefit most > >> from low cost hosted access to Mifos. > >> > >> How to most effectively meet the needs of both users is tricky. > >> > >> We've been challenged by the current code base being difficult and > >> expensive to extend and maintain. We have made progress in improving > >> the code and certain areas of it are much easier to deal with now. > >> However, there is still a large amount of code left that needs > >> improvement. > >> > >> The most cost effective way to deliver a solution that can be > >> effectively hosted at very low cost (supporting multi-tenancy for > >> example) at this point looks like a rewrite that would pull in reusable > >> parts of Mifos but redo the basics from the ground up to get things like > >> multi-tenancy, transaction management, auditing, clean i18n, layered > >> architecture, separation of concerns and manageable tests in place. To > >> keep the cost of doing a rewrite low, it would help for the target > >> release to have fewer features and options than Mifos currently does. > >> > >> On the other hand, supporting larger existing and new MFIs and those > >> requiring the larger feature set currently supported by Mifos would > >> benefit from the current code base being extended and refined. The > >> difficulty here is that the cost to continue maintaining the current > >> code is high as is the cost to refactor and improve it. > >> > >> Keith and I are in agreement on the things that he already laid out > >> here: > >> > http://mifosforge.jira.com/wiki/display/MIFOS/Technical+Roadmap+%28Post+ > >> Maya+G+and+onwards%29 > >> > >> This is a good list of how the current code base could be moved forward. > >> > >> > >> Replacing the current Struts/JSP based UI code with Spring/Freemarker is > >> the biggest single enabler for lowering the cost of maintaining and > >> extending Mifos. It leads to: > >> * API creation across the application (by achieving complete separation > >> of business logic from presentation code) > >> * simplified transaction management > >> * simplified i18n > >> * improvement of layered architecture > >> * reduction and simplification of test code > >> > >> --Van > >> > >> > > > > > ------------------------------------------------------------------------------ > > All of the data generated in your IT infrastructure is seriously > valuable. > > Why? It contains a definitive record of application performance, security > > threats, fraudulent activity, and more. Splunk takes this data and makes > > sense of it. IT sense. And common sense. > > http://p.sf.net/sfu/splunk-d2d-c2 > > _______________________________________________ > > Mifos-users mailing list > > Mif...@li... > > https://lists.sourceforge.net/lists/listinfo/mifos-users > > > > > > |
From: Kay C. <kc...@gr...> - 2011-07-01 17:12:50
|
Binny, this is great. I think it'd be great if we can use Jira to continue to capture and prioritize these effectively. We should be better about using the "Feature" issues and logging all of them so that we can effectively figure out what features to build. Also, here is a somewhat outdated feature train that we used to use to look at priorities - https://spreadsheets.google.com/a/grameenfoundation.org/spreadsheet/ccc? key=0AhPZtOMhomEZcFZ4RXB3YUM4SkVBbU9qNmFvSWYwVHc&hl=en_US#gid=0 Kay From: Binny Gopinath [mailto:bin...@gm...] Sent: Friday, July 01, 2011 9:15 AM To: A good place to start for users or folks new to Mifos. Cc: George Conard Subject: Re: [Mifos-users] [Mifos-developer] Whats after Maya G? Keith, Here are the high-lelvel points I have gathered during my interactions with Mifos users: Priority 1: Reporting and Dashboards - we have made good progress on this. But there is still some work here to get a few more key reports created or fixed. And also sort out some of the ETL related issues, make the ETL job quicker, reduce installation complexity, integrate reporting UI with Mifos etc. .. Flexibile loan scheduling - with facility for individual lending - Maya G's allowing a member to have loans with differing frequencies takes care of this partially. However, navigating to such individual loans (members may not belong to groups) still will have some challenges in Maya G Accounting - there are 2 approaches that MFI's have been requesting in India: a) Integrated accounting module - specifically for branch level accounting Also we need to re-look into accrual accounting and a cash book maintenance/cash management module b) Better integration with an existing accounting software like Tally Disbursement date flexibility - ability to specify a loan disbursement date in the future and not just the meeting period immediately following the current date Data migration toolkit - facility for easily and cleanly getting past member/group/loan data into Mifos - SunGard guys have developed a tool for this. They did give me a demo of this. We should just test and adopt this. Priority 2: Mobile devices and handheld device integration Offline data entry - important if Mifos has to be adopted by larger MFIs/SHGs who have better reach in rural areas (where internet connectivity is poor and electricity is available only for 1 or 2 hours on some days) Adequate Support for Self Help Groups - where more details of each groups linkage with their banks accounts can be managed, managing linkage between savings and loans etc. Support for large MFIs (> 1 million customers) - batch jobs and upgrades and reporting becomes a challenge with some tables have millions of rows Priority 3: HR integration - attendance, user security etc. Customer acquisition process - to schedule and manage the client pre-enrollment process (Group trainings and group tests) Customization of look and feel (logo, colors etc.) per installation - move internationalization resource bundles to the configuration folder so that it can be customized and deployed without being overwritten by each upgrade Integration with Credit Bureau / Identity verification systems Thanks Binny On Fri, Jul 1, 2011 at 5:41 PM, Keith Woodlock <kei...@gm...> wrote: Binny, > Are we concentrating too much on technical improvements while not paying > adequate attention to new/improved features? Yes, this is the whole point of this email chain. I was asking for input/feedback from the users about what to put into mifos after Maya G. So far only george has offered some insight into what might be useful going forward. From a technical point of view we know what we need to do but theres no point in taking on that investment unless customers out there want further features/improvements etc regards, Keith. On Fri, Jul 1, 2011 at 5:50 AM, Binny Gopinath <bin...@gm...> wrote: > > Are we concentrating too much on technical improvements while not paying > adequate attention to new/improved features? > > Technical improvements without any visible improvement to end-users - may > cause users to consider moving away from Mifos. I would like releases to be > a mix of new/improved functional features + a bunch of technical > improvements. I have had the chance to get a glimpse into some of our > competition and very soon our feature set is going to be insufficient, which > is heartbreaking .. > > On technical improvements: > - would be good to include testing/handling of larger volumes - I have had a > couple of enquiries from large MFI's - one of them has 4+ million members > - on i18n, would be good to allow overriding of specific internationalized > labels look up from config folders - so that they do not get overwritten by > any upgrades. And also handle date formats consistently, especially in > reports. > > Thanks > Binny > > > On Thu, Jun 30, 2011 at 10:33 AM, Van Mittal-Henkle > <va...@gr...> wrote: >> >> George, >> >> I'm catching up on some of these threads after being out for a few days >> >> > - there's a mobile revolution underway in sub-Saharan Africa; building >> > both the APIs/hooks for connecting into a variety of mobile systems >> > (from mobile money to mobile interfaces for clients and MFI staff to >> > exchange of info with other systems that are running mobile apps) and >> > also potentially getting a few sample/reference mobile apps running on >> > Mifos (need to vet specific pain points so we don't build something >> > just for the sake of building it) >> >> If Mifos provided Restful or WSDL based APIs it would open up lots of >> possibilities for building on Mifos for things like this. Having stable >> APIs for people to build on is one of the things we have been working >> towards for some time. A lot of KeithW's efforts in particular have >> been around getting internals to a state where we could start layering >> an API on them. As mentioned, getting specific customers with specific >> use cases to drive this is key. >> >> > also for you and the other engineers who have worked on MIfos: in a >> > community model if there's less oversight, is there under-the-covers >> > work that should be prioritized which will help keep Mifos stable and >> > scalable as it goes forward in the community? >> >> Here's where some big questions come up. >> >> One hypothesis is that there are two classes of Mifos users-- Class 1: >> larger MFIs who have a need for various extensions and customizations of >> Mifos and who can take on some expense to do that and even host their >> own infrastructure and Class 2: smaller MFIs who could likely manage >> with fewer features and less extensibility and who would benefit most >> from low cost hosted access to Mifos. >> >> How to most effectively meet the needs of both users is tricky. >> >> We've been challenged by the current code base being difficult and >> expensive to extend and maintain. We have made progress in improving >> the code and certain areas of it are much easier to deal with now. >> However, there is still a large amount of code left that needs >> improvement. >> >> The most cost effective way to deliver a solution that can be >> effectively hosted at very low cost (supporting multi-tenancy for >> example) at this point looks like a rewrite that would pull in reusable >> parts of Mifos but redo the basics from the ground up to get things like >> multi-tenancy, transaction management, auditing, clean i18n, layered >> architecture, separation of concerns and manageable tests in place. To >> keep the cost of doing a rewrite low, it would help for the target >> release to have fewer features and options than Mifos currently does. >> >> On the other hand, supporting larger existing and new MFIs and those >> requiring the larger feature set currently supported by Mifos would >> benefit from the current code base being extended and refined. The >> difficulty here is that the cost to continue maintaining the current >> code is high as is the cost to refactor and improve it. >> >> Keith and I are in agreement on the things that he already laid out >> here: >> http://mifosforge.jira.com/wiki/display/MIFOS/Technical+Roadmap+%28Post+ >> Maya+G+and+onwards%29 >> >> This is a good list of how the current code base could be moved forward. >> >> >> Replacing the current Struts/JSP based UI code with Spring/Freemarker is >> the biggest single enabler for lowering the cost of maintaining and >> extending Mifos. It leads to: >> * API creation across the application (by achieving complete separation >> of business logic from presentation code) >> * simplified transaction management >> * simplified i18n >> * improvement of layered architecture >> * reduction and simplification of test code >> >> --Van >> >> > > ------------------------------------------------------------------------ ------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Mifos-users mailing list > Mif...@li... > https://lists.sourceforge.net/lists/listinfo/mifos-users > > |
From: Van Mittal-H. <va...@gr...> - 2011-07-01 17:15:24
|
This is great information! Can we connect these requests to who wants it? It seems like one of the missing pieces for making things work well in a community driven model is a more direct connection between particular MFIs who want something and the work that is done to deliver it. So far it doesn't seem like many MFIs have directly participated on the Mifos lists (like this one). Perhaps a better model is to have an intermediary like Binny, Ed or others who are in direct contact with MFIs to be their voice on the list. As Keith has mentioned, somehow we need to get a tighter feedback loop going between what MFIs want and the work that is done. The more directly an MFI can express their Mifos needs and desires the better! One of the things we need to do is develop a system for determining what features will go into each upcoming release. Here's a sketch of how that might work: * An MFI (or the MFI's "voice" on the list) creates an issue in Jira for the feature the MFI wants and associates it with the MFI. * Other MFIs express their interest in the issue by associating their names to the issue. * As work begins on a release, issues with the most interest are highlighted as good candidates for volunteer developers to work on. * If volunteer developers don't end up working on an issue that is of interest to an MFI or MFIs, the MFIs with interest could choose to hire a developer (or team) to implement it. --Van From: Binny Gopinath [mailto:bin...@gm...] Sent: Friday, July 01, 2011 9:15 AM To: A good place to start for users or folks new to Mifos. Cc: George Conard Subject: Re: [Mifos-users] [Mifos-developer] Whats after Maya G? Keith, Here are the high-lelvel points I have gathered during my interactions with Mifos users: Priority 1: Reporting and Dashboards - we have made good progress on this. But there is still some work here to get a few more key reports created or fixed. And also sort out some of the ETL related issues, make the ETL job quicker, reduce installation complexity, integrate reporting UI with Mifos etc. .. Flexibile loan scheduling - with facility for individual lending - Maya G's allowing a member to have loans with differing frequencies takes care of this partially. However, navigating to such individual loans (members may not belong to groups) still will have some challenges in Maya G Accounting - there are 2 approaches that MFI's have been requesting in India: a) Integrated accounting module - specifically for branch level accounting Also we need to re-look into accrual accounting and a cash book maintenance/cash management module b) Better integration with an existing accounting software like Tally Disbursement date flexibility - ability to specify a loan disbursement date in the future and not just the meeting period immediately following the current date Data migration toolkit - facility for easily and cleanly getting past member/group/loan data into Mifos - SunGard guys have developed a tool for this. They did give me a demo of this. We should just test and adopt this. Priority 2: Mobile devices and handheld device integration Offline data entry - important if Mifos has to be adopted by larger MFIs/SHGs who have better reach in rural areas (where internet connectivity is poor and electricity is available only for 1 or 2 hours on some days) Adequate Support for Self Help Groups - where more details of each groups linkage with their banks accounts can be managed, managing linkage between savings and loans etc. Support for large MFIs (> 1 million customers) - batch jobs and upgrades and reporting becomes a challenge with some tables have millions of rows Priority 3: HR integration - attendance, user security etc. Customer acquisition process - to schedule and manage the client pre-enrollment process (Group trainings and group tests) Customization of look and feel (logo, colors etc.) per installation - move internationalization resource bundles to the configuration folder so that it can be customized and deployed without being overwritten by each upgrade Integration with Credit Bureau / Identity verification systems Thanks Binny On Fri, Jul 1, 2011 at 5:41 PM, Keith Woodlock <kei...@gm...> wrote: Binny, > Are we concentrating too much on technical improvements while not paying > adequate attention to new/improved features? Yes, this is the whole point of this email chain. I was asking for input/feedback from the users about what to put into mifos after Maya G. So far only george has offered some insight into what might be useful going forward. From a technical point of view we know what we need to do but theres no point in taking on that investment unless customers out there want further features/improvements etc regards, Keith. On Fri, Jul 1, 2011 at 5:50 AM, Binny Gopinath <bin...@gm...> wrote: > > Are we concentrating too much on technical improvements while not paying > adequate attention to new/improved features? > > Technical improvements without any visible improvement to end-users - may > cause users to consider moving away from Mifos. I would like releases to be > a mix of new/improved functional features + a bunch of technical > improvements. I have had the chance to get a glimpse into some of our > competition and very soon our feature set is going to be insufficient, which > is heartbreaking .. > > On technical improvements: > - would be good to include testing/handling of larger volumes - I have had a > couple of enquiries from large MFI's - one of them has 4+ million members > - on i18n, would be good to allow overriding of specific internationalized > labels look up from config folders - so that they do not get overwritten by > any upgrades. And also handle date formats consistently, especially in > reports. > > Thanks > Binny > > > On Thu, Jun 30, 2011 at 10:33 AM, Van Mittal-Henkle > <va...@gr...> wrote: >> >> George, >> >> I'm catching up on some of these threads after being out for a few days >> >> > - there's a mobile revolution underway in sub-Saharan Africa; building >> > both the APIs/hooks for connecting into a variety of mobile systems >> > (from mobile money to mobile interfaces for clients and MFI staff to >> > exchange of info with other systems that are running mobile apps) and >> > also potentially getting a few sample/reference mobile apps running on >> > Mifos (need to vet specific pain points so we don't build something >> > just for the sake of building it) >> >> If Mifos provided Restful or WSDL based APIs it would open up lots of >> possibilities for building on Mifos for things like this. Having stable >> APIs for people to build on is one of the things we have been working >> towards for some time. A lot of KeithW's efforts in particular have >> been around getting internals to a state where we could start layering >> an API on them. As mentioned, getting specific customers with specific >> use cases to drive this is key. >> >> > also for you and the other engineers who have worked on MIfos: in a >> > community model if there's less oversight, is there under-the-covers >> > work that should be prioritized which will help keep Mifos stable and >> > scalable as it goes forward in the community? >> >> Here's where some big questions come up. >> >> One hypothesis is that there are two classes of Mifos users-- Class 1: >> larger MFIs who have a need for various extensions and customizations of >> Mifos and who can take on some expense to do that and even host their >> own infrastructure and Class 2: smaller MFIs who could likely manage >> with fewer features and less extensibility and who would benefit most >> from low cost hosted access to Mifos. >> >> How to most effectively meet the needs of both users is tricky. >> >> We've been challenged by the current code base being difficult and >> expensive to extend and maintain. We have made progress in improving >> the code and certain areas of it are much easier to deal with now. >> However, there is still a large amount of code left that needs >> improvement. >> >> The most cost effective way to deliver a solution that can be >> effectively hosted at very low cost (supporting multi-tenancy for >> example) at this point looks like a rewrite that would pull in reusable >> parts of Mifos but redo the basics from the ground up to get things like >> multi-tenancy, transaction management, auditing, clean i18n, layered >> architecture, separation of concerns and manageable tests in place. To >> keep the cost of doing a rewrite low, it would help for the target >> release to have fewer features and options than Mifos currently does. >> >> On the other hand, supporting larger existing and new MFIs and those >> requiring the larger feature set currently supported by Mifos would >> benefit from the current code base being extended and refined. The >> difficulty here is that the cost to continue maintaining the current >> code is high as is the cost to refactor and improve it. >> >> Keith and I are in agreement on the things that he already laid out >> here: >> http://mifosforge.jira.com/wiki/display/MIFOS/Technical+Roadmap+%28Post+ >> Maya+G+and+onwards%29 >> >> This is a good list of how the current code base could be moved forward. >> >> >> Replacing the current Struts/JSP based UI code with Spring/Freemarker is >> the biggest single enabler for lowering the cost of maintaining and >> extending Mifos. It leads to: >> * API creation across the application (by achieving complete separation >> of business logic from presentation code) >> * simplified transaction management >> * simplified i18n >> * improvement of layered architecture >> * reduction and simplification of test code >> >> --Van >> >> > > ------------------------------------------------------------------------ ------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Mifos-users mailing list > Mif...@li... > https://lists.sourceforge.net/lists/listinfo/mifos-users > > |
From: Keith W. <kei...@gm...> - 2011-07-02 10:12:35
|
Van, > Can we connect these requests to who wants it? It seems like one of the > missing pieces for making things work well in a community driven model is a > more direct connection between particular MFIs who want something and the > work that is done to deliver it. good point. we do need to break down any barriers between the MFI (customer) and those who deliver the features. Binny has given a good list of things that need to be improved/added to mifos to make it a more suitable MIS for MFIs. As you say it would be great and really helps us if we can associate these things that need to be done against praticular MFIs and somehow understand which one is most important to work on now. Keith. On Fri, Jul 1, 2011 at 6:13 PM, Van Mittal-Henkle <va...@gr...> wrote: > This is great information! > > > > Can we connect these requests to who wants it? It seems like one of the > missing pieces for making things work well in a community driven model is a > more direct connection between particular MFIs who want something and the > work that is done to deliver it. > > > > So far it doesn’t seem like many MFIs have directly participated on the > Mifos lists (like this one). Perhaps a better model is to have an > intermediary like Binny, Ed or others who are in direct contact with MFIs to > be their voice on the list. As Keith has mentioned, somehow we need to get > a tighter feedback loop going between what MFIs want and the work that is > done. > > > > The more directly an MFI can express their Mifos needs and desires the > better! > > > > One of the things we need to do is develop a system for determining what > features will go into each upcoming release. > > > > Here’s a sketch of how that might work: > > · An MFI (or the MFI’s “voice” on the list) creates an issue in Jira > for the feature the MFI wants and associates it with the MFI. > > · Other MFIs express their interest in the issue by associating > their names to the issue. > > · As work begins on a release, issues with the most interest are > highlighted as good candidates for volunteer developers to work on. > > · If volunteer developers don’t end up working on an issue that is > of interest to an MFI or MFIs, the MFIs with interest could choose to hire a > developer (or team) to implement it. > > > > --Van > > > > From: Binny Gopinath [mailto:bin...@gm...] > Sent: Friday, July 01, 2011 9:15 AM > To: A good place to start for users or folks new to Mifos. > Cc: George Conard > Subject: Re: [Mifos-users] [Mifos-developer] Whats after Maya G? > > > > Keith, > > Here are the high-lelvel points I have gathered during my interactions with > Mifos users: > > Priority 1: > > Reporting and Dashboards - we have made good progress on this. But there is > still some work here to get a few more key reports created or fixed. And > also sort out some of the ETL related issues, make the ETL job quicker, > reduce installation complexity, integrate reporting UI with Mifos etc. .. > Flexibile loan scheduling - with facility for individual lending - Maya G's > allowing a member to have loans with differing frequencies takes care of > this partially. However, navigating to such individual loans (members may > not belong to groups) still will have some challenges in Maya G > Accounting - there are 2 approaches that MFI's have been requesting in > India: > a) Integrated accounting module - specifically for branch level > accounting > Also we need to re-look into accrual accounting and a cash book > maintenance/cash management module > b) Better integration with an existing accounting software like > Tally > Disbursement date flexibility - ability to specify a loan disbursement date > in the future and not just the meeting period immediately following the > current date > Data migration toolkit - facility for easily and cleanly getting past > member/group/loan data into Mifos - SunGard guys have developed a tool for > this. They did give me a demo of this. We should just test and adopt this. > > Priority 2: > > Mobile devices and handheld device integration > Offline data entry - important if Mifos has to be adopted by larger > MFIs/SHGs who have better reach in rural areas (where internet connectivity > is poor and electricity is available only for 1 or 2 hours on some days) > Adequate Support for Self Help Groups - where more details of each groups > linkage with their banks accounts can be managed, managing linkage between > savings and loans etc. > Support for large MFIs (> 1 million customers) - batch jobs and upgrades and > reporting becomes a challenge with some tables have millions of rows > > Priority 3: > > HR integration - attendance, user security etc. > Customer acquisition process - to schedule and manage the client > pre-enrollment process (Group trainings and group tests) > Customization of look and feel (logo, colors etc.) per installation - move > internationalization resource bundles to the configuration folder so that it > can be customized and deployed without being overwritten by each upgrade > Integration with Credit Bureau / Identity verification systems > > Thanks > Binny > > > On Fri, Jul 1, 2011 at 5:41 PM, Keith Woodlock <kei...@gm...> > wrote: > > Binny, > >> Are we concentrating too much on technical improvements while not paying >> adequate attention to new/improved features? > > Yes, this is the whole point of this email chain. I was asking for > input/feedback from the users about what to put into mifos after Maya > G. So far only george has offered some insight into what might be > useful going forward. From a technical point of view we know what we > need to do but theres no point in taking on that investment unless > customers out there want further features/improvements etc > > regards, > Keith. > > On Fri, Jul 1, 2011 at 5:50 AM, Binny Gopinath <bin...@gm...> > wrote: >> >> Are we concentrating too much on technical improvements while not paying >> adequate attention to new/improved features? >> >> Technical improvements without any visible improvement to end-users - may >> cause users to consider moving away from Mifos. I would like releases to >> be >> a mix of new/improved functional features + a bunch of technical >> improvements. I have had the chance to get a glimpse into some of our >> competition and very soon our feature set is going to be insufficient, >> which >> is heartbreaking .. >> >> On technical improvements: >> - would be good to include testing/handling of larger volumes - I have had >> a >> couple of enquiries from large MFI's - one of them has 4+ million members >> - on i18n, would be good to allow overriding of specific internationalized >> labels look up from config folders - so that they do not get overwritten >> by >> any upgrades. And also handle date formats consistently, especially in >> reports. >> >> Thanks >> Binny >> >> >> On Thu, Jun 30, 2011 at 10:33 AM, Van Mittal-Henkle >> <va...@gr...> wrote: >>> >>> George, >>> >>> I'm catching up on some of these threads after being out for a few days >>> >>> > - there's a mobile revolution underway in sub-Saharan Africa; building >>> > both the APIs/hooks for connecting into a variety of mobile systems >>> > (from mobile money to mobile interfaces for clients and MFI staff to >>> > exchange of info with other systems that are running mobile apps) and >>> > also potentially getting a few sample/reference mobile apps running on >>> > Mifos (need to vet specific pain points so we don't build something >>> > just for the sake of building it) >>> >>> If Mifos provided Restful or WSDL based APIs it would open up lots of >>> possibilities for building on Mifos for things like this. Having stable >>> APIs for people to build on is one of the things we have been working >>> towards for some time. A lot of KeithW's efforts in particular have >>> been around getting internals to a state where we could start layering >>> an API on them. As mentioned, getting specific customers with specific >>> use cases to drive this is key. >>> >>> > also for you and the other engineers who have worked on MIfos: in a >>> > community model if there's less oversight, is there under-the-covers >>> > work that should be prioritized which will help keep Mifos stable and >>> > scalable as it goes forward in the community? >>> >>> Here's where some big questions come up. >>> >>> One hypothesis is that there are two classes of Mifos users-- Class 1: >>> larger MFIs who have a need for various extensions and customizations of >>> Mifos and who can take on some expense to do that and even host their >>> own infrastructure and Class 2: smaller MFIs who could likely manage >>> with fewer features and less extensibility and who would benefit most >>> from low cost hosted access to Mifos. >>> >>> How to most effectively meet the needs of both users is tricky. >>> >>> We've been challenged by the current code base being difficult and >>> expensive to extend and maintain. We have made progress in improving >>> the code and certain areas of it are much easier to deal with now. >>> However, there is still a large amount of code left that needs >>> improvement. >>> >>> The most cost effective way to deliver a solution that can be >>> effectively hosted at very low cost (supporting multi-tenancy for >>> example) at this point looks like a rewrite that would pull in reusable >>> parts of Mifos but redo the basics from the ground up to get things like >>> multi-tenancy, transaction management, auditing, clean i18n, layered >>> architecture, separation of concerns and manageable tests in place. To >>> keep the cost of doing a rewrite low, it would help for the target >>> release to have fewer features and options than Mifos currently does. >>> >>> On the other hand, supporting larger existing and new MFIs and those >>> requiring the larger feature set currently supported by Mifos would >>> benefit from the current code base being extended and refined. The >>> difficulty here is that the cost to continue maintaining the current >>> code is high as is the cost to refactor and improve it. >>> >>> Keith and I are in agreement on the things that he already laid out >>> here: >>> http://mifosforge.jira.com/wiki/display/MIFOS/Technical+Roadmap+%28Post+ >>> Maya+G+and+onwards%29 >>> >>> This is a good list of how the current code base could be moved forward. >>> >>> >>> Replacing the current Struts/JSP based UI code with Spring/Freemarker is >>> the biggest single enabler for lowering the cost of maintaining and >>> extending Mifos. It leads to: >>> * API creation across the application (by achieving complete separation >>> of business logic from presentation code) >>> * simplified transaction management >>> * simplified i18n >>> * improvement of layered architecture >>> * reduction and simplification of test code >>> >>> --Van >>> >>> >> > >> >> ------------------------------------------------------------------------------ >> All of the data generated in your IT infrastructure is seriously valuable. >> Why? It contains a definitive record of application performance, security >> threats, fraudulent activity, and more. Splunk takes this data and makes >> sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-d2d-c2 >> _______________________________________________ >> Mifos-users mailing list >> Mif...@li... >> https://lists.sourceforge.net/lists/listinfo/mifos-users >> >> > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Mifos-users mailing list > Mif...@li... > https://lists.sourceforge.net/lists/listinfo/mifos-users > > |
From: Keith W. <kei...@gm...> - 2011-07-12 08:34:58
Attachments:
logged_in_view.gif
|
Gayl, http://mifosforge.jira.com/wiki/display/MIFOS/Feature+Request+List is a Wiki page so its quiet possible you are being automatically logged in but you also maybe just 'viewing' it as well with no rights to edit/update. When your logged in you can clearly see your username in the top right and you should also then be able to see some icons on the right side of the page, one of which allows you to Edit the page. I've attached a gif of what it looks like for me. > I was wondering what is the status of the enhancements already logged but > not implemented yet? Will they be added to this list or do they need to be > re-entered on this list? It should be good enough just to mention the mifos issue number, e.g. MIFOS-XXXX and indicate which is the most important one to do first from the list if you have more than one issue you really want done.r regards, Keith. On Tue, Jul 12, 2011 at 9:00 AM, Gayl Kennedy <gay...@gm...> wrote: > Hi Van, I took a look at the page and I don't see where you would sign-in or > how you would edit it so it may be good to add a few sentences of > instructions? I have an account so it may have signed me in automatically > but did not see an option to log out or in.. > > I was wondering what is the status of the enhancements already logged but > not implemented yet? Will they be added to this list or do they need to be > re-entered on this list? > > Regards > Gayl > > On 11 July 2011 20:11, Van Mittal-Henkle <va...@gr...> > wrote: >> >> I’ve taken a first step on this and created the page: >> >> >> >> http://mifosforge.jira.com/wiki/display/MIFOS/Feature+Request+List >> >> >> >> based off of Binny’s email. >> >> >> >> There is probably some work to do to refine the format of this, but just >> wanted to get the basic information down as a start. There may already be >> some issues in Jira related to some of the features. If so, we can start >> linking those. >> >> >> >> For some of the suggestions we still need more detail to better understand >> what is wanted. >> >> >> >> Binny, Ed (and others)- feel free to add detail to items on the list. >> >> >> >> We’ll need to come up with a process for assigning priorities to features >> on the list. For now there is a place to put new features at the top. >> >> >> >> This is a place where anyone in the Mifos community can write down what >> feature they would like in Mifos. >> >> >> >> If you have an idea for a feature just sign up for an account on >> mifosforge, log in, and edit the page linked above. >> >> >> >> If you have an idea for a feature but you don’t know how to edit the page, >> you can send an idea to the Mifos users mailing list and someone should be >> able to take your idea and put it on the page. Try including the words >> “Feature Request” in the title of your email message and it will be easier >> to know that you are asking for a new feature. >> >> >> >> As Ed has mentioned, we will try to make it as easy as possible to ask for >> new features. >> >> >> >> Improvements to the page and its organization are welcome! >> >> >> >> --Van >> >> >> >> >> >> >> >> From: Ed Cable [mailto:ed...@gm...] >> Sent: Thursday, July 07, 2011 4:27 PM >> To: Mifos software development >> Cc: A good place to start for users or folks new to Mifos. >> >> Subject: Re: [Mifos-users] [Mifos-developer] Whats after Maya G? >> >> >> >> Van, >> >> >> >> Let me know when you've got that page up on the wiki. Once it's up we can >> start a separate thread for open feedback/feature requests and then guide >> people to document it there on the wiki and as you said put it in some more >> formal tool over time. >> >> >> >> A lot of the users and implementers I interact with have a feedback >> requests and I will direct it through these channels. >> >> Ed >> >> On Thu, Jul 7, 2011 at 4:17 PM, Van Mittal-Henkle >> <va...@gr...> wrote: >> >> Ed, >> >> >> >> All sounds good to me. >> >> >> >> The project oriented approach is one I’ve thought about too. It seems >> like a good thing to try getting multiple people working together in the >> same area of the app. It should allow for taking on bigger projects and >> increase the chances of completion even if the time folks have available is >> variable. (should be more fun too J ) >> >> >> >> The priority list that Binny emailed seems like a good starting point for >> a Mifos user requested feature list. I hope to get this list up on the wiki >> (if the wiki would cooperate) so that areas that need to be fleshed out can >> be added to. From there detailed information could flow into Jira as issues >> and summary information could flow to mifos.org, uservoice or a form that >> gives the Mifos community an easy way to express their interest and vote. >> >> >> >> --Van >> >> >> >> From: Ed Cable [mailto:ed...@gm...] >> Sent: Thursday, July 07, 2011 7:41 AM >> To: Mifos software development >> Cc: mif...@go...; A good place to start for users or folks >> new to Mifos. >> >> Subject: Re: [Mifos-users] [Mifos-developer] Whats after Maya G? >> >> >> >> Van, >> >> >> >> In that first bucket of users in the community, that is actually >> implementers (including both our MFI user and our Specialist ecosystem). >> Our Specialist ecosystem ideally over time will blur the line between both >> communities both implementing and supporting Mifos users, capturing feedback >> and requirements for the product and ultimately contributing to development >> themselves as well. We already have a number of Specialists that want to >> begin to work more on development or have created modules/new functionality >> that could be incorporated or shared more openly. >> >> >> >> I completely agree with what you're saying about letting developers choose >> what they work on. My wording in previous email was wrong as I was trying >> to be realistic about only being able to get work done that we had >> volunteers for - not necessarily assigning volunteers certain places. >> >> >> >> I would like us to move towards more of a project-based model like OpenMRS >> does - we can come up with a stronger set of projects and then openly >> advertise these so potential contributors know they have a well-defined >> project in which they can add meaningful value. Given the transition, we >> can move towards more comprehensive projects but will have to spend the >> effort to divide up into workable tasks, etc. >> >> >> >> Ed >> >> >> >> >> ------------------------------------------------------------------------------ >> All of the data generated in your IT infrastructure is seriously valuable. >> Why? It contains a definitive record of application performance, security >> threats, fraudulent activity, and more. Splunk takes this data and makes >> sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-d2d-c2 >> >> >> >> >> ------------------------------------------------------------------------------ >> All of the data generated in your IT infrastructure is seriously valuable. >> Why? It contains a definitive record of application performance, security >> threats, fraudulent activity, and more. Splunk takes this data and makes >> sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-d2d-c2 >> _______________________________________________ >> Mifos-users mailing list >> Mif...@li... >> https://lists.sourceforge.net/lists/listinfo/mifos-users >> > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Mifos-users mailing list > Mif...@li... > https://lists.sourceforge.net/lists/listinfo/mifos-users > > |
From: Michael V. <mi...@vo...> - 2011-07-12 15:03:36
|
Google Moderator <http://www.google.com/moderator/> could be used for capturing "ideas" and "votes" on them? On Tue, Jul 12, 2011 at 2:04 PM, Keith Woodlock <kei...@gm...> wrote: > Gayl, > > http://mifosforge.jira.com/wiki/display/MIFOS/Feature+Request+List is > a Wiki page so its quiet possible you are being automatically logged > in but you also maybe just 'viewing' it as well with no rights to > edit/update. > > When your logged in you can clearly see your username in the top right > and you should also then be able to see some icons on the right side > of the page, one of which allows you to Edit the page. > > I've attached a gif of what it looks like for me. > >> I was wondering what is the status of the enhancements already logged but >> not implemented yet? Will they be added to this list or do they need to be >> re-entered on this list? > > It should be good enough just to mention the mifos issue number, e.g. > MIFOS-XXXX and indicate which is the most important one to do first > from the list if you have more than one issue you really want done.r > > regards, > Keith. > > On Tue, Jul 12, 2011 at 9:00 AM, Gayl Kennedy <gay...@gm...> wrote: >> Hi Van, I took a look at the page and I don't see where you would sign-in or >> how you would edit it so it may be good to add a few sentences of >> instructions? I have an account so it may have signed me in automatically >> but did not see an option to log out or in.. >> >> I was wondering what is the status of the enhancements already logged but >> not implemented yet? Will they be added to this list or do they need to be >> re-entered on this list? >> >> Regards >> Gayl >> >> On 11 July 2011 20:11, Van Mittal-Henkle <va...@gr...> >> wrote: >>> >>> I’ve taken a first step on this and created the page: >>> >>> >>> >>> http://mifosforge.jira.com/wiki/display/MIFOS/Feature+Request+List >>> >>> >>> >>> based off of Binny’s email. >>> >>> >>> >>> There is probably some work to do to refine the format of this, but just >>> wanted to get the basic information down as a start. There may already be >>> some issues in Jira related to some of the features. If so, we can start >>> linking those. >>> >>> >>> >>> For some of the suggestions we still need more detail to better understand >>> what is wanted. >>> >>> >>> >>> Binny, Ed (and others)- feel free to add detail to items on the list. >>> >>> >>> >>> We’ll need to come up with a process for assigning priorities to features >>> on the list. For now there is a place to put new features at the top. >>> >>> >>> >>> This is a place where anyone in the Mifos community can write down what >>> feature they would like in Mifos. >>> >>> >>> >>> If you have an idea for a feature just sign up for an account on >>> mifosforge, log in, and edit the page linked above. >>> >>> >>> >>> If you have an idea for a feature but you don’t know how to edit the page, >>> you can send an idea to the Mifos users mailing list and someone should be >>> able to take your idea and put it on the page. Try including the words >>> “Feature Request” in the title of your email message and it will be easier >>> to know that you are asking for a new feature. >>> >>> >>> >>> As Ed has mentioned, we will try to make it as easy as possible to ask for >>> new features. >>> >>> >>> >>> Improvements to the page and its organization are welcome! >>> >>> >>> >>> --Van >>> >>> >>> >>> >>> >>> >>> >>> From: Ed Cable [mailto:ed...@gm...] >>> Sent: Thursday, July 07, 2011 4:27 PM >>> To: Mifos software development >>> Cc: A good place to start for users or folks new to Mifos. >>> >>> Subject: Re: [Mifos-users] [Mifos-developer] Whats after Maya G? >>> >>> >>> >>> Van, >>> >>> >>> >>> Let me know when you've got that page up on the wiki. Once it's up we can >>> start a separate thread for open feedback/feature requests and then guide >>> people to document it there on the wiki and as you said put it in some more >>> formal tool over time. >>> >>> >>> >>> A lot of the users and implementers I interact with have a feedback >>> requests and I will direct it through these channels. >>> >>> Ed >>> >>> On Thu, Jul 7, 2011 at 4:17 PM, Van Mittal-Henkle >>> <va...@gr...> wrote: >>> >>> Ed, >>> >>> >>> >>> All sounds good to me. >>> >>> >>> >>> The project oriented approach is one I’ve thought about too. It seems >>> like a good thing to try getting multiple people working together in the >>> same area of the app. It should allow for taking on bigger projects and >>> increase the chances of completion even if the time folks have available is >>> variable. (should be more fun too J ) >>> >>> >>> >>> The priority list that Binny emailed seems like a good starting point for >>> a Mifos user requested feature list. I hope to get this list up on the wiki >>> (if the wiki would cooperate) so that areas that need to be fleshed out can >>> be added to. From there detailed information could flow into Jira as issues >>> and summary information could flow to mifos.org, uservoice or a form that >>> gives the Mifos community an easy way to express their interest and vote. >>> >>> >>> >>> --Van >>> >>> >>> >>> From: Ed Cable [mailto:ed...@gm...] >>> Sent: Thursday, July 07, 2011 7:41 AM >>> To: Mifos software development >>> Cc: mif...@go...; A good place to start for users or folks >>> new to Mifos. >>> >>> Subject: Re: [Mifos-users] [Mifos-developer] Whats after Maya G? >>> >>> >>> >>> Van, >>> >>> >>> >>> In that first bucket of users in the community, that is actually >>> implementers (including both our MFI user and our Specialist ecosystem). >>> Our Specialist ecosystem ideally over time will blur the line between both >>> communities both implementing and supporting Mifos users, capturing feedback >>> and requirements for the product and ultimately contributing to development >>> themselves as well. We already have a number of Specialists that want to >>> begin to work more on development or have created modules/new functionality >>> that could be incorporated or shared more openly. >>> >>> >>> >>> I completely agree with what you're saying about letting developers choose >>> what they work on. My wording in previous email was wrong as I was trying >>> to be realistic about only being able to get work done that we had >>> volunteers for - not necessarily assigning volunteers certain places. >>> >>> >>> >>> I would like us to move towards more of a project-based model like OpenMRS >>> does - we can come up with a stronger set of projects and then openly >>> advertise these so potential contributors know they have a well-defined >>> project in which they can add meaningful value. Given the transition, we >>> can move towards more comprehensive projects but will have to spend the >>> effort to divide up into workable tasks, etc. >>> >>> >>> >>> Ed >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> All of the data generated in your IT infrastructure is seriously valuable. >>> Why? It contains a definitive record of application performance, security >>> threats, fraudulent activity, and more. Splunk takes this data and makes >>> sense of it. IT sense. And common sense. >>> http://p.sf.net/sfu/splunk-d2d-c2 >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> All of the data generated in your IT infrastructure is seriously valuable. >>> Why? It contains a definitive record of application performance, security >>> threats, fraudulent activity, and more. Splunk takes this data and makes >>> sense of it. IT sense. And common sense. >>> http://p.sf.net/sfu/splunk-d2d-c2 >>> _______________________________________________ >>> Mifos-users mailing list >>> Mif...@li... >>> https://lists.sourceforge.net/lists/listinfo/mifos-users >>> >> >> >> ------------------------------------------------------------------------------ >> All of the data generated in your IT infrastructure is seriously valuable. >> Why? It contains a definitive record of application performance, security >> threats, fraudulent activity, and more. Splunk takes this data and makes >> sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-d2d-c2 >> _______________________________________________ >> Mifos-users mailing list >> Mif...@li... >> https://lists.sourceforge.net/lists/listinfo/mifos-users >> >> > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Mifos-users mailing list > Mif...@li... > https://lists.sourceforge.net/lists/listinfo/mifos-users > > |
From: Ed C. <ed...@gm...> - 2011-07-12 17:15:12
|
Michael, We also currently have UserVoice implemented for capturing ideas - http://mifosinitiative.uservoice.com Another option that is available to us as a hosted app on SourceForge is IdeaTorrent. I'll be sending an email out later this week with more details on the Product Feedback process that we're pulling together and will have tool for idea collection/voting as one of the options to provide feedback on. Ed On Tue, Jul 12, 2011 at 8:03 AM, Michael Vorburger <mi...@vo...>wrote: > Google Moderator <http://www.google.com/moderator/> could be used for > capturing "ideas" and "votes" on them? > > > On Tue, Jul 12, 2011 at 2:04 PM, Keith Woodlock <kei...@gm...> > wrote: > > Gayl, > > > > http://mifosforge.jira.com/wiki/display/MIFOS/Feature+Request+List is > > a Wiki page so its quiet possible you are being automatically logged > > in but you also maybe just 'viewing' it as well with no rights to > > edit/update. > > > > When your logged in you can clearly see your username in the top right > > and you should also then be able to see some icons on the right side > > of the page, one of which allows you to Edit the page. > > > > I've attached a gif of what it looks like for me. > > > >> I was wondering what is the status of the enhancements already logged > but > >> not implemented yet? Will they be added to this list or do they need to > be > >> re-entered on this list? > > > > It should be good enough just to mention the mifos issue number, e.g. > > MIFOS-XXXX and indicate which is the most important one to do first > > from the list if you have more than one issue you really want done.r > > > > regards, > > Keith. > > > > On Tue, Jul 12, 2011 at 9:00 AM, Gayl Kennedy <gay...@gm...> > wrote: > >> Hi Van, I took a look at the page and I don't see where you would > sign-in or > >> how you would edit it so it may be good to add a few sentences of > >> instructions? I have an account so it may have signed me in > automatically > >> but did not see an option to log out or in.. > >> > >> I was wondering what is the status of the enhancements already logged > but > >> not implemented yet? Will they be added to this list or do they need to > be > >> re-entered on this list? > >> > >> Regards > >> Gayl > >> > >> On 11 July 2011 20:11, Van Mittal-Henkle <va...@gr...> > >> wrote: > >>> > >>> I’ve taken a first step on this and created the page: > >>> > >>> > >>> > >>> http://mifosforge.jira.com/wiki/display/MIFOS/Feature+Request+List > >>> > >>> > >>> > >>> based off of Binny’s email. > >>> > >>> > >>> > >>> There is probably some work to do to refine the format of this, but > just > >>> wanted to get the basic information down as a start. There may already > be > >>> some issues in Jira related to some of the features. If so, we can > start > >>> linking those. > >>> > >>> > >>> > >>> For some of the suggestions we still need more detail to better > understand > >>> what is wanted. > >>> > >>> > >>> > >>> Binny, Ed (and others)- feel free to add detail to items on the list. > >>> > >>> > >>> > >>> We’ll need to come up with a process for assigning priorities to > features > >>> on the list. For now there is a place to put new features at the top. > >>> > >>> > >>> > >>> This is a place where anyone in the Mifos community can write down what > >>> feature they would like in Mifos. > >>> > >>> > >>> > >>> If you have an idea for a feature just sign up for an account on > >>> mifosforge, log in, and edit the page linked above. > >>> > >>> > >>> > >>> If you have an idea for a feature but you don’t know how to edit the > page, > >>> you can send an idea to the Mifos users mailing list and someone should > be > >>> able to take your idea and put it on the page. Try including the > words > >>> “Feature Request” in the title of your email message and it will be > easier > >>> to know that you are asking for a new feature. > >>> > >>> > >>> > >>> As Ed has mentioned, we will try to make it as easy as possible to ask > for > >>> new features. > >>> > >>> > >>> > >>> Improvements to the page and its organization are welcome! > >>> > >>> > >>> > >>> --Van > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> From: Ed Cable [mailto:ed...@gm...] > >>> Sent: Thursday, July 07, 2011 4:27 PM > >>> To: Mifos software development > >>> Cc: A good place to start for users or folks new to Mifos. > >>> > >>> Subject: Re: [Mifos-users] [Mifos-developer] Whats after Maya G? > >>> > >>> > >>> > >>> Van, > >>> > >>> > >>> > >>> Let me know when you've got that page up on the wiki. Once it's up we > can > >>> start a separate thread for open feedback/feature requests and then > guide > >>> people to document it there on the wiki and as you said put it in some > more > >>> formal tool over time. > >>> > >>> > >>> > >>> A lot of the users and implementers I interact with have a feedback > >>> requests and I will direct it through these channels. > >>> > >>> Ed > >>> > >>> On Thu, Jul 7, 2011 at 4:17 PM, Van Mittal-Henkle > >>> <va...@gr...> wrote: > >>> > >>> Ed, > >>> > >>> > >>> > >>> All sounds good to me. > >>> > >>> > >>> > >>> The project oriented approach is one I’ve thought about too. It seems > >>> like a good thing to try getting multiple people working together in > the > >>> same area of the app. It should allow for taking on bigger projects > and > >>> increase the chances of completion even if the time folks have > available is > >>> variable. (should be more fun too J ) > >>> > >>> > >>> > >>> The priority list that Binny emailed seems like a good starting point > for > >>> a Mifos user requested feature list. I hope to get this list up on the > wiki > >>> (if the wiki would cooperate) so that areas that need to be fleshed out > can > >>> be added to. From there detailed information could flow into Jira as > issues > >>> and summary information could flow to mifos.org, uservoice or a form > that > >>> gives the Mifos community an easy way to express their interest and > vote. > >>> > >>> > >>> > >>> --Van > >>> > >>> > >>> > >>> From: Ed Cable [mailto:ed...@gm...] > >>> Sent: Thursday, July 07, 2011 7:41 AM > >>> To: Mifos software development > >>> Cc: mif...@go...; A good place to start for users or > folks > >>> new to Mifos. > >>> > >>> Subject: Re: [Mifos-users] [Mifos-developer] Whats after Maya G? > >>> > >>> > >>> > >>> Van, > >>> > >>> > >>> > >>> In that first bucket of users in the community, that is actually > >>> implementers (including both our MFI user and our Specialist > ecosystem). > >>> Our Specialist ecosystem ideally over time will blur the line between > both > >>> communities both implementing and supporting Mifos users, capturing > feedback > >>> and requirements for the product and ultimately contributing to > development > >>> themselves as well. We already have a number of Specialists that want > to > >>> begin to work more on development or have created modules/new > functionality > >>> that could be incorporated or shared more openly. > >>> > >>> > >>> > >>> I completely agree with what you're saying about letting developers > choose > >>> what they work on. My wording in previous email was wrong as I was > trying > >>> to be realistic about only being able to get work done that we had > >>> volunteers for - not necessarily assigning volunteers certain places. > >>> > >>> > >>> > >>> I would like us to move towards more of a project-based model like > OpenMRS > >>> does - we can come up with a stronger set of projects and then openly > >>> advertise these so potential contributors know they have a well-defined > >>> project in which they can add meaningful value. Given the transition, > we > >>> can move towards more comprehensive projects but will have to spend the > >>> effort to divide up into workable tasks, etc. > >>> > >>> > >>> > >>> Ed > >>> > >>> > >>> > >>> > >>> > ------------------------------------------------------------------------------ > >>> All of the data generated in your IT infrastructure is seriously > valuable. > >>> Why? It contains a definitive record of application performance, > security > >>> threats, fraudulent activity, and more. Splunk takes this data and > makes > >>> sense of it. IT sense. And common sense. > >>> http://p.sf.net/sfu/splunk-d2d-c2 > >>> > >>> > >>> > >>> > >>> > ------------------------------------------------------------------------------ > >>> All of the data generated in your IT infrastructure is seriously > valuable. > >>> Why? It contains a definitive record of application performance, > security > >>> threats, fraudulent activity, and more. Splunk takes this data and > makes > >>> sense of it. IT sense. And common sense. > >>> http://p.sf.net/sfu/splunk-d2d-c2 > >>> _______________________________________________ > >>> Mifos-users mailing list > >>> Mif...@li... > >>> https://lists.sourceforge.net/lists/listinfo/mifos-users > >>> > >> > >> > >> > ------------------------------------------------------------------------------ > >> All of the data generated in your IT infrastructure is seriously > valuable. > >> Why? It contains a definitive record of application performance, > security > >> threats, fraudulent activity, and more. Splunk takes this data and makes > >> sense of it. IT sense. And common sense. > >> http://p.sf.net/sfu/splunk-d2d-c2 > >> _______________________________________________ > >> Mifos-users mailing list > >> Mif...@li... > >> https://lists.sourceforge.net/lists/listinfo/mifos-users > >> > >> > > > > > ------------------------------------------------------------------------------ > > All of the data generated in your IT infrastructure is seriously > valuable. > > Why? It contains a definitive record of application performance, security > > threats, fraudulent activity, and more. Splunk takes this data and makes > > sense of it. IT sense. And common sense. > > http://p.sf.net/sfu/splunk-d2d-c2 > > _______________________________________________ > > Mifos-users mailing list > > Mif...@li... > > https://lists.sourceforge.net/lists/listinfo/mifos-users > > > > > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Mifos-users mailing list > Mif...@li... > https://lists.sourceforge.net/lists/listinfo/mifos-users > |
From: AMIT J. <ami...@gm...> - 2011-07-01 17:26:16
|
Hello to all, MAYA G is very close to us and we would not like to a part of a history. Now, yes *Binny* you understood all the major requirements of an MFI.I would love to share my views for developing the same.We just require for keeping the thought of several Modules just like a different parts assemble at one place to made a powerful car. The theme of Mifos is good no one software having such wonderful UI. I appeal to the community please save the "Titanic" because we have a tools for it. I am ready to give my eligible support in any form. *THINK AGAIN* ** Hope for a positive reply. Regards AMIT *DIGAMBER* | *FINANCE * On Fri, Jul 1, 2011 at 9:44 PM, Binny Gopinath <bin...@gm...>wrote: > Keith, > > Here are the high-lelvel points I have gathered during my interactions with > Mifos users: > > Priority 1: > > *Reporting and Dashboards* - we have made good progress on this. But there > is still some work here to get a few more key reports created or fixed. And > also sort out some of the ETL related issues, make the ETL job quicker, > reduce installation complexity, integrate reporting UI with Mifos etc. .. > *Flexibile loan scheduling* - with facility for individual lending - Maya > G's allowing a member to have loans with differing frequencies takes care of > this partially. However, navigating to such individual loans (members may > not belong to groups) still will have some challenges in Maya G > *Accounting* - there are 2 approaches that MFI's have been requesting in > India: > a) Integrated accounting module - specifically for branch level > accounting > Also we need to re-look into accrual accounting and a cash book > maintenance/cash management module > b) Better integration with an existing accounting software like > Tally > *Disbursement date flexibility* - ability to specify a loan disbursement > date in the future and not just the meeting period immediately following the > current date > *Data migration toolkit* - facility for easily and cleanly getting past > member/group/loan data into Mifos - SunGard guys have developed a tool for > this. They did give me a demo of this. We should just test and adopt this. > > Priority 2: > > *Mobile devices* and handheld device integration > *Offline data entry* - important if Mifos has to be adopted by larger > MFIs/SHGs who have better reach in rural areas (where internet connectivity > is poor and electricity is available only for 1 or 2 hours on some days) > *Adequate Support for Self Help Groups* - where more details of each > groups linkage with their banks accounts can be managed, managing linkage > between savings and loans etc. > *Support for large MFIs* (> 1 million customers) - batch jobs and upgrades > and reporting becomes a challenge with some tables have millions of rows > > Priority 3: > > HR integration - attendance, user security etc. > Customer acquisition process - to schedule and manage the client > pre-enrollment process (Group trainings and group tests) > Customization of look and feel (logo, colors etc.) per installation - move > internationalization resource bundles to the configuration folder so that it > can be customized and deployed without being overwritten by each upgrade > Integration with Credit Bureau / Identity verification systems > > Thanks > Binny > > > > > On Fri, Jul 1, 2011 at 5:41 PM, Keith Woodlock <kei...@gm...>wrote: > >> Binny, >> >> > Are we concentrating too much on technical improvements while not paying >> > adequate attention to new/improved features? >> >> Yes, this is the whole point of this email chain. I was asking for >> input/feedback from the users about what to put into mifos after Maya >> G. So far only george has offered some insight into what might be >> useful going forward. From a technical point of view we know what we >> need to do but theres no point in taking on that investment unless >> customers out there want further features/improvements etc >> >> regards, >> Keith. >> >> On Fri, Jul 1, 2011 at 5:50 AM, Binny Gopinath <bin...@gm...> >> wrote: >> > >> > Are we concentrating too much on technical improvements while not paying >> > adequate attention to new/improved features? >> > >> > Technical improvements without any visible improvement to end-users - >> may >> > cause users to consider moving away from Mifos. I would like releases to >> be >> > a mix of new/improved functional features + a bunch of technical >> > improvements. I have had the chance to get a glimpse into some of our >> > competition and very soon our feature set is going to be insufficient, >> which >> > is heartbreaking .. >> > >> > On technical improvements: >> > - would be good to include testing/handling of larger volumes - I have >> had a >> > couple of enquiries from large MFI's - one of them has 4+ million >> members >> > - on i18n, would be good to allow overriding of specific >> internationalized >> > labels look up from config folders - so that they do not get overwritten >> by >> > any upgrades. And also handle date formats consistently, especially in >> > reports. >> > >> > Thanks >> > Binny >> > >> > >> > On Thu, Jun 30, 2011 at 10:33 AM, Van Mittal-Henkle >> > <va...@gr...> wrote: >> >> >> >> George, >> >> >> >> I'm catching up on some of these threads after being out for a few days >> >> >> >> > - there's a mobile revolution underway in sub-Saharan Africa; >> building >> >> > both the APIs/hooks for connecting into a variety of mobile systems >> >> > (from mobile money to mobile interfaces for clients and MFI staff to >> >> > exchange of info with other systems that are running mobile apps) and >> >> > also potentially getting a few sample/reference mobile apps running >> on >> >> > Mifos (need to vet specific pain points so we don't build something >> >> > just for the sake of building it) >> >> >> >> If Mifos provided Restful or WSDL based APIs it would open up lots of >> >> possibilities for building on Mifos for things like this. Having >> stable >> >> APIs for people to build on is one of the things we have been working >> >> towards for some time. A lot of KeithW's efforts in particular have >> >> been around getting internals to a state where we could start layering >> >> an API on them. As mentioned, getting specific customers with specific >> >> use cases to drive this is key. >> >> >> >> > also for you and the other engineers who have worked on MIfos: in a >> >> > community model if there's less oversight, is there under-the-covers >> >> > work that should be prioritized which will help keep Mifos stable and >> >> > scalable as it goes forward in the community? >> >> >> >> Here's where some big questions come up. >> >> >> >> One hypothesis is that there are two classes of Mifos users-- Class 1: >> >> larger MFIs who have a need for various extensions and customizations >> of >> >> Mifos and who can take on some expense to do that and even host their >> >> own infrastructure and Class 2: smaller MFIs who could likely manage >> >> with fewer features and less extensibility and who would benefit most >> >> from low cost hosted access to Mifos. >> >> >> >> How to most effectively meet the needs of both users is tricky. >> >> >> >> We've been challenged by the current code base being difficult and >> >> expensive to extend and maintain. We have made progress in improving >> >> the code and certain areas of it are much easier to deal with now. >> >> However, there is still a large amount of code left that needs >> >> improvement. >> >> >> >> The most cost effective way to deliver a solution that can be >> >> effectively hosted at very low cost (supporting multi-tenancy for >> >> example) at this point looks like a rewrite that would pull in reusable >> >> parts of Mifos but redo the basics from the ground up to get things >> like >> >> multi-tenancy, transaction management, auditing, clean i18n, layered >> >> architecture, separation of concerns and manageable tests in place. To >> >> keep the cost of doing a rewrite low, it would help for the target >> >> release to have fewer features and options than Mifos currently does. >> >> >> >> On the other hand, supporting larger existing and new MFIs and those >> >> requiring the larger feature set currently supported by Mifos would >> >> benefit from the current code base being extended and refined. The >> >> difficulty here is that the cost to continue maintaining the current >> >> code is high as is the cost to refactor and improve it. >> >> >> >> Keith and I are in agreement on the things that he already laid out >> >> here: >> >> >> http://mifosforge.jira.com/wiki/display/MIFOS/Technical+Roadmap+%28Post+ >> >> Maya+G+and+onwards%29 >> >> >> >> This is a good list of how the current code base could be moved >> forward. >> >> >> >> >> >> Replacing the current Struts/JSP based UI code with Spring/Freemarker >> is >> >> the biggest single enabler for lowering the cost of maintaining and >> >> extending Mifos. It leads to: >> >> * API creation across the application (by achieving complete separation >> >> of business logic from presentation code) >> >> * simplified transaction management >> >> * simplified i18n >> >> * improvement of layered architecture >> >> * reduction and simplification of test code >> >> >> >> --Van >> >> >> >> >> > >> > >> ------------------------------------------------------------------------------ >> > All of the data generated in your IT infrastructure is seriously >> valuable. >> > Why? It contains a definitive record of application performance, >> security >> > threats, fraudulent activity, and more. Splunk takes this data and makes >> > sense of it. IT sense. And common sense. >> > http://p.sf.net/sfu/splunk-d2d-c2 >> > _______________________________________________ >> > Mifos-users mailing list >> > Mif...@li... >> > https://lists.sourceforge.net/lists/listinfo/mifos-users >> > >> > >> >> > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Mifos-users mailing list > Mif...@li... > https://lists.sourceforge.net/lists/listinfo/mifos-users > > -- AMIT JAIN | E.D | Digamber Finance (Chota Loan Bade Sapne) | +919414041821 | |
From: Keith W. <kei...@gm...> - 2011-07-02 10:16:30
|
Hi Amit, > .I would > love to share my views for developing the same.We just require for keeping > the thought of several Modules just like a different parts assemble at one > place to made a powerful car. Yes splitting things into components/modules is where we want to head to and are moving in that direction with respect to the code base. > I am ready to give my eligible support in any form. Amit, could you answer the following on behalf on Digamber? 1) what is the biggest challenge facing your MFI and what can we add/improve on mifos to help with this? regards, Keith. On Fri, Jul 1, 2011 at 6:26 PM, AMIT JAIN <ami...@gm...> wrote: > Hello to all, > > MAYA G is very close to us and we would not like to a part of a history. > > Now, yes Binny you understood all the major requirements of an MFI.I would > love to share my views for developing the same.We just require for keeping > the thought of several Modules just like a different parts assemble at one > place to made a powerful car. > > The theme of Mifos is good no one software having such wonderful UI. > > I appeal to the community please save the "Titanic" because we have a tools > for it. > > I am ready to give my eligible support in any form. > > THINK AGAIN > > Hope for a positive reply. > > Regards > > AMIT > DIGAMBER | FINANCE > On Fri, Jul 1, 2011 at 9:44 PM, Binny Gopinath <bin...@gm...> > wrote: >> >> Keith, >> >> Here are the high-lelvel points I have gathered during my interactions >> with Mifos users: >> >> Priority 1: >> >> Reporting and Dashboards - we have made good progress on this. But there >> is still some work here to get a few more key reports created or fixed. And >> also sort out some of the ETL related issues, make the ETL job quicker, >> reduce installation complexity, integrate reporting UI with Mifos etc. .. >> Flexibile loan scheduling - with facility for individual lending - Maya >> G's allowing a member to have loans with differing frequencies takes care of >> this partially. However, navigating to such individual loans (members may >> not belong to groups) still will have some challenges in Maya G >> Accounting - there are 2 approaches that MFI's have been requesting in >> India: >> a) Integrated accounting module - specifically for branch level >> accounting >> Also we need to re-look into accrual accounting and a cash book >> maintenance/cash management module >> b) Better integration with an existing accounting software like >> Tally >> Disbursement date flexibility - ability to specify a loan disbursement >> date in the future and not just the meeting period immediately following the >> current date >> Data migration toolkit - facility for easily and cleanly getting past >> member/group/loan data into Mifos - SunGard guys have developed a tool for >> this. They did give me a demo of this. We should just test and adopt this. >> >> Priority 2: >> >> Mobile devices and handheld device integration >> Offline data entry - important if Mifos has to be adopted by larger >> MFIs/SHGs who have better reach in rural areas (where internet connectivity >> is poor and electricity is available only for 1 or 2 hours on some days) >> Adequate Support for Self Help Groups - where more details of each groups >> linkage with their banks accounts can be managed, managing linkage between >> savings and loans etc. >> Support for large MFIs (> 1 million customers) - batch jobs and upgrades >> and reporting becomes a challenge with some tables have millions of rows >> >> Priority 3: >> >> HR integration - attendance, user security etc. >> Customer acquisition process - to schedule and manage the client >> pre-enrollment process (Group trainings and group tests) >> Customization of look and feel (logo, colors etc.) per installation - move >> internationalization resource bundles to the configuration folder so that it >> can be customized and deployed without being overwritten by each upgrade >> Integration with Credit Bureau / Identity verification systems >> >> Thanks >> Binny >> >> >> >> On Fri, Jul 1, 2011 at 5:41 PM, Keith Woodlock <kei...@gm...> >> wrote: >>> >>> Binny, >>> >>> > Are we concentrating too much on technical improvements while not >>> > paying >>> > adequate attention to new/improved features? >>> >>> Yes, this is the whole point of this email chain. I was asking for >>> input/feedback from the users about what to put into mifos after Maya >>> G. So far only george has offered some insight into what might be >>> useful going forward. From a technical point of view we know what we >>> need to do but theres no point in taking on that investment unless >>> customers out there want further features/improvements etc >>> >>> regards, >>> Keith. >>> >>> On Fri, Jul 1, 2011 at 5:50 AM, Binny Gopinath <bin...@gm...> >>> wrote: >>> > >>> > Are we concentrating too much on technical improvements while not >>> > paying >>> > adequate attention to new/improved features? >>> > >>> > Technical improvements without any visible improvement to end-users - >>> > may >>> > cause users to consider moving away from Mifos. I would like releases >>> > to be >>> > a mix of new/improved functional features + a bunch of technical >>> > improvements. I have had the chance to get a glimpse into some of our >>> > competition and very soon our feature set is going to be insufficient, >>> > which >>> > is heartbreaking .. >>> > >>> > On technical improvements: >>> > - would be good to include testing/handling of larger volumes - I have >>> > had a >>> > couple of enquiries from large MFI's - one of them has 4+ million >>> > members >>> > - on i18n, would be good to allow overriding of specific >>> > internationalized >>> > labels look up from config folders - so that they do not get >>> > overwritten by >>> > any upgrades. And also handle date formats consistently, especially in >>> > reports. >>> > >>> > Thanks >>> > Binny >>> > >>> > >>> > On Thu, Jun 30, 2011 at 10:33 AM, Van Mittal-Henkle >>> > <va...@gr...> wrote: >>> >> >>> >> George, >>> >> >>> >> I'm catching up on some of these threads after being out for a few >>> >> days >>> >> >>> >> > - there's a mobile revolution underway in sub-Saharan Africa; >>> >> > building >>> >> > both the APIs/hooks for connecting into a variety of mobile systems >>> >> > (from mobile money to mobile interfaces for clients and MFI staff to >>> >> > exchange of info with other systems that are running mobile apps) >>> >> > and >>> >> > also potentially getting a few sample/reference mobile apps running >>> >> > on >>> >> > Mifos (need to vet specific pain points so we don't build something >>> >> > just for the sake of building it) >>> >> >>> >> If Mifos provided Restful or WSDL based APIs it would open up lots of >>> >> possibilities for building on Mifos for things like this. Having >>> >> stable >>> >> APIs for people to build on is one of the things we have been working >>> >> towards for some time. A lot of KeithW's efforts in particular have >>> >> been around getting internals to a state where we could start layering >>> >> an API on them. As mentioned, getting specific customers with >>> >> specific >>> >> use cases to drive this is key. >>> >> >>> >> > also for you and the other engineers who have worked on MIfos: in a >>> >> > community model if there's less oversight, is there under-the-covers >>> >> > work that should be prioritized which will help keep Mifos stable >>> >> > and >>> >> > scalable as it goes forward in the community? >>> >> >>> >> Here's where some big questions come up. >>> >> >>> >> One hypothesis is that there are two classes of Mifos users-- Class 1: >>> >> larger MFIs who have a need for various extensions and customizations >>> >> of >>> >> Mifos and who can take on some expense to do that and even host their >>> >> own infrastructure and Class 2: smaller MFIs who could likely manage >>> >> with fewer features and less extensibility and who would benefit most >>> >> from low cost hosted access to Mifos. >>> >> >>> >> How to most effectively meet the needs of both users is tricky. >>> >> >>> >> We've been challenged by the current code base being difficult and >>> >> expensive to extend and maintain. We have made progress in improving >>> >> the code and certain areas of it are much easier to deal with now. >>> >> However, there is still a large amount of code left that needs >>> >> improvement. >>> >> >>> >> The most cost effective way to deliver a solution that can be >>> >> effectively hosted at very low cost (supporting multi-tenancy for >>> >> example) at this point looks like a rewrite that would pull in >>> >> reusable >>> >> parts of Mifos but redo the basics from the ground up to get things >>> >> like >>> >> multi-tenancy, transaction management, auditing, clean i18n, layered >>> >> architecture, separation of concerns and manageable tests in place. >>> >> To >>> >> keep the cost of doing a rewrite low, it would help for the target >>> >> release to have fewer features and options than Mifos currently does. >>> >> >>> >> On the other hand, supporting larger existing and new MFIs and those >>> >> requiring the larger feature set currently supported by Mifos would >>> >> benefit from the current code base being extended and refined. The >>> >> difficulty here is that the cost to continue maintaining the current >>> >> code is high as is the cost to refactor and improve it. >>> >> >>> >> Keith and I are in agreement on the things that he already laid out >>> >> here: >>> >> >>> >> http://mifosforge.jira.com/wiki/display/MIFOS/Technical+Roadmap+%28Post+ >>> >> Maya+G+and+onwards%29 >>> >> >>> >> This is a good list of how the current code base could be moved >>> >> forward. >>> >> >>> >> >>> >> Replacing the current Struts/JSP based UI code with Spring/Freemarker >>> >> is >>> >> the biggest single enabler for lowering the cost of maintaining and >>> >> extending Mifos. It leads to: >>> >> * API creation across the application (by achieving complete >>> >> separation >>> >> of business logic from presentation code) >>> >> * simplified transaction management >>> >> * simplified i18n >>> >> * improvement of layered architecture >>> >> * reduction and simplification of test code >>> >> >>> >> --Van >>> >> >>> >> >>> > >>> > >>> > ------------------------------------------------------------------------------ >>> > All of the data generated in your IT infrastructure is seriously >>> > valuable. >>> > Why? It contains a definitive record of application performance, >>> > security >>> > threats, fraudulent activity, and more. Splunk takes this data and >>> > makes >>> > sense of it. IT sense. And common sense. >>> > http://p.sf.net/sfu/splunk-d2d-c2 >>> > _______________________________________________ >>> > Mifos-users mailing list >>> > Mif...@li... >>> > https://lists.sourceforge.net/lists/listinfo/mifos-users >>> > >>> > >>> >> >> >> ------------------------------------------------------------------------------ >> All of the data generated in your IT infrastructure is seriously valuable. >> Why? It contains a definitive record of application performance, security >> threats, fraudulent activity, and more. Splunk takes this data and makes >> sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-d2d-c2 >> _______________________________________________ >> Mifos-users mailing list >> Mif...@li... >> https://lists.sourceforge.net/lists/listinfo/mifos-users >> > > > > -- > AMIT JAIN | E.D | Digamber Finance (Chota Loan Bade Sapne) | +919414041821 | > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Mifos-users mailing list > Mif...@li... > https://lists.sourceforge.net/lists/listinfo/mifos-users > > |
From: AMIT J. <ami...@gm...> - 2011-07-02 16:43:37
|
Hello Keith. > > > > I am ready to give my eligible support in any form. > > Amit, could you answer the following on behalf on Digamber? > > Yes, help in terms of funds from Digamber and myself will be available for generating new ideas and thoughts for solution to developing the Mifos as most effective application worldwide > 1) what is the biggest challenge facing your MFI and what can we > add/improve on mifos to help with this? > > As all the points has been discussed by Binny but my priorities are different as following Immediate:Some changes in client capture and loan disbursement required (Please discuss with Binny) then Mobile integration, Accounting inbuilt Preparation for HR and In continuation upgrades in reports. Thanks for give attention Regards AMIT JAIN > regards, > Keith. > > On Fri, Jul 1, 2011 at 6:26 PM, AMIT JAIN <ami...@gm...> wrote: > > Hello to all, > > > > MAYA G is very close to us and we would not like to a part of a history. > > > > Now, yes Binny you understood all the major requirements of an MFI.I > would > > love to share my views for developing the same.We just require for > keeping > > the thought of several Modules just like a different parts assemble at > one > > place to made a powerful car. > > > > The theme of Mifos is good no one software having such wonderful UI. > > > > I appeal to the community please save the "Titanic" because we have a > tools > > for it. > > > > I am ready to give my eligible support in any form. > > > > THINK AGAIN > > > > Hope for a positive reply. > > > > Regards > > > > AMIT > > DIGAMBER | FINANCE > > On Fri, Jul 1, 2011 at 9:44 PM, Binny Gopinath <bin...@gm... > > > > wrote: > >> > >> Keith, > >> > >> Here are the high-lelvel points I have gathered during my interactions > >> with Mifos users: > >> > >> Priority 1: > >> > >> Reporting and Dashboards - we have made good progress on this. But there > >> is still some work here to get a few more key reports created or fixed. > And > >> also sort out some of the ETL related issues, make the ETL job quicker, > >> reduce installation complexity, integrate reporting UI with Mifos etc. > .. > >> Flexibile loan scheduling - with facility for individual lending - Maya > >> G's allowing a member to have loans with differing frequencies takes > care of > >> this partially. However, navigating to such individual loans (members > may > >> not belong to groups) still will have some challenges in Maya G > >> Accounting - there are 2 approaches that MFI's have been requesting in > >> India: > >> a) Integrated accounting module - specifically for branch > level > >> accounting > >> Also we need to re-look into accrual accounting and a cash > book > >> maintenance/cash management module > >> b) Better integration with an existing accounting software > like > >> Tally > >> Disbursement date flexibility - ability to specify a loan disbursement > >> date in the future and not just the meeting period immediately following > the > >> current date > >> Data migration toolkit - facility for easily and cleanly getting past > >> member/group/loan data into Mifos - SunGard guys have developed a tool > for > >> this. They did give me a demo of this. We should just test and adopt > this. > >> > >> Priority 2: > >> > >> Mobile devices and handheld device integration > >> Offline data entry - important if Mifos has to be adopted by larger > >> MFIs/SHGs who have better reach in rural areas (where internet > connectivity > >> is poor and electricity is available only for 1 or 2 hours on some days) > >> Adequate Support for Self Help Groups - where more details of each > groups > >> linkage with their banks accounts can be managed, managing linkage > between > >> savings and loans etc. > >> Support for large MFIs (> 1 million customers) - batch jobs and upgrades > >> and reporting becomes a challenge with some tables have millions of rows > >> > >> Priority 3: > >> > >> HR integration - attendance, user security etc. > >> Customer acquisition process - to schedule and manage the client > >> pre-enrollment process (Group trainings and group tests) > >> Customization of look and feel (logo, colors etc.) per installation - > move > >> internationalization resource bundles to the configuration folder so > that it > >> can be customized and deployed without being overwritten by each upgrade > >> Integration with Credit Bureau / Identity verification systems > >> > >> Thanks > >> Binny > >> > >> > >> > >> On Fri, Jul 1, 2011 at 5:41 PM, Keith Woodlock <kei...@gm... > > > >> wrote: > >>> > >>> Binny, > >>> > >>> > Are we concentrating too much on technical improvements while not > >>> > paying > >>> > adequate attention to new/improved features? > >>> > >>> Yes, this is the whole point of this email chain. I was asking for > >>> input/feedback from the users about what to put into mifos after Maya > >>> G. So far only george has offered some insight into what might be > >>> useful going forward. From a technical point of view we know what we > >>> need to do but theres no point in taking on that investment unless > >>> customers out there want further features/improvements etc > >>> > >>> regards, > >>> Keith. > >>> > >>> On Fri, Jul 1, 2011 at 5:50 AM, Binny Gopinath < > bin...@gm...> > >>> wrote: > >>> > > >>> > Are we concentrating too much on technical improvements while not > >>> > paying > >>> > adequate attention to new/improved features? > >>> > > >>> > Technical improvements without any visible improvement to end-users - > >>> > may > >>> > cause users to consider moving away from Mifos. I would like releases > >>> > to be > >>> > a mix of new/improved functional features + a bunch of technical > >>> > improvements. I have had the chance to get a glimpse into some of our > >>> > competition and very soon our feature set is going to be > insufficient, > >>> > which > >>> > is heartbreaking .. > >>> > > >>> > On technical improvements: > >>> > - would be good to include testing/handling of larger volumes - I > have > >>> > had a > >>> > couple of enquiries from large MFI's - one of them has 4+ million > >>> > members > >>> > - on i18n, would be good to allow overriding of specific > >>> > internationalized > >>> > labels look up from config folders - so that they do not get > >>> > overwritten by > >>> > any upgrades. And also handle date formats consistently, especially > in > >>> > reports. > >>> > > >>> > Thanks > >>> > Binny > >>> > > >>> > > >>> > On Thu, Jun 30, 2011 at 10:33 AM, Van Mittal-Henkle > >>> > <va...@gr...> wrote: > >>> >> > >>> >> George, > >>> >> > >>> >> I'm catching up on some of these threads after being out for a few > >>> >> days > >>> >> > >>> >> > - there's a mobile revolution underway in sub-Saharan Africa; > >>> >> > building > >>> >> > both the APIs/hooks for connecting into a variety of mobile > systems > >>> >> > (from mobile money to mobile interfaces for clients and MFI staff > to > >>> >> > exchange of info with other systems that are running mobile apps) > >>> >> > and > >>> >> > also potentially getting a few sample/reference mobile apps > running > >>> >> > on > >>> >> > Mifos (need to vet specific pain points so we don't build > something > >>> >> > just for the sake of building it) > >>> >> > >>> >> If Mifos provided Restful or WSDL based APIs it would open up lots > of > >>> >> possibilities for building on Mifos for things like this. Having > >>> >> stable > >>> >> APIs for people to build on is one of the things we have been > working > >>> >> towards for some time. A lot of KeithW's efforts in particular have > >>> >> been around getting internals to a state where we could start > layering > >>> >> an API on them. As mentioned, getting specific customers with > >>> >> specific > >>> >> use cases to drive this is key. > >>> >> > >>> >> > also for you and the other engineers who have worked on MIfos: in > a > >>> >> > community model if there's less oversight, is there > under-the-covers > >>> >> > work that should be prioritized which will help keep Mifos stable > >>> >> > and > >>> >> > scalable as it goes forward in the community? > >>> >> > >>> >> Here's where some big questions come up. > >>> >> > >>> >> One hypothesis is that there are two classes of Mifos users-- Class > 1: > >>> >> larger MFIs who have a need for various extensions and > customizations > >>> >> of > >>> >> Mifos and who can take on some expense to do that and even host > their > >>> >> own infrastructure and Class 2: smaller MFIs who could likely manage > >>> >> with fewer features and less extensibility and who would benefit > most > >>> >> from low cost hosted access to Mifos. > >>> >> > >>> >> How to most effectively meet the needs of both users is tricky. > >>> >> > >>> >> We've been challenged by the current code base being difficult and > >>> >> expensive to extend and maintain. We have made progress in > improving > >>> >> the code and certain areas of it are much easier to deal with now. > >>> >> However, there is still a large amount of code left that needs > >>> >> improvement. > >>> >> > >>> >> The most cost effective way to deliver a solution that can be > >>> >> effectively hosted at very low cost (supporting multi-tenancy for > >>> >> example) at this point looks like a rewrite that would pull in > >>> >> reusable > >>> >> parts of Mifos but redo the basics from the ground up to get things > >>> >> like > >>> >> multi-tenancy, transaction management, auditing, clean i18n, layered > >>> >> architecture, separation of concerns and manageable tests in place. > >>> >> To > >>> >> keep the cost of doing a rewrite low, it would help for the target > >>> >> release to have fewer features and options than Mifos currently > does. > >>> >> > >>> >> On the other hand, supporting larger existing and new MFIs and > those > >>> >> requiring the larger feature set currently supported by Mifos would > >>> >> benefit from the current code base being extended and refined. The > >>> >> difficulty here is that the cost to continue maintaining the current > >>> >> code is high as is the cost to refactor and improve it. > >>> >> > >>> >> Keith and I are in agreement on the things that he already laid out > >>> >> here: > >>> >> > >>> >> > http://mifosforge.jira.com/wiki/display/MIFOS/Technical+Roadmap+%28Post+ > >>> >> Maya+G+and+onwards%29 > >>> >> > >>> >> This is a good list of how the current code base could be moved > >>> >> forward. > >>> >> > >>> >> > >>> >> Replacing the current Struts/JSP based UI code with > Spring/Freemarker > >>> >> is > >>> >> the biggest single enabler for lowering the cost of maintaining and > >>> >> extending Mifos. It leads to: > >>> >> * API creation across the application (by achieving complete > >>> >> separation > >>> >> of business logic from presentation code) > >>> >> * simplified transaction management > >>> >> * simplified i18n > >>> >> * improvement of layered architecture > >>> >> * reduction and simplification of test code > >>> >> > >>> >> --Van > >>> >> > >>> >> > >>> > > >>> > > >>> > > ------------------------------------------------------------------------------ > >>> > All of the data generated in your IT infrastructure is seriously > >>> > valuable. > >>> > Why? It contains a definitive record of application performance, > >>> > security > >>> > threats, fraudulent activity, and more. Splunk takes this data and > >>> > makes > >>> > sense of it. IT sense. And common sense. > >>> > http://p.sf.net/sfu/splunk-d2d-c2 > >>> > _______________________________________________ > >>> > Mifos-users mailing list > >>> > Mif...@li... > >>> > https://lists.sourceforge.net/lists/listinfo/mifos-users > >>> > > >>> > > >>> > >> > >> > >> > ------------------------------------------------------------------------------ > >> All of the data generated in your IT infrastructure is seriously > valuable. > >> Why? It contains a definitive record of application performance, > security > >> threats, fraudulent activity, and more. Splunk takes this data and makes > >> sense of it. IT sense. And common sense. > >> http://p.sf.net/sfu/splunk-d2d-c2 > >> _______________________________________________ > >> Mifos-users mailing list > >> Mif...@li... > >> https://lists.sourceforge.net/lists/listinfo/mifos-users > >> > > > > > > > > -- > > AMIT JAIN | E.D | Digamber Finance (Chota Loan Bade Sapne) | > +919414041821 | > > > > > ------------------------------------------------------------------------------ > > All of the data generated in your IT infrastructure is seriously > valuable. > > Why? It contains a definitive record of application performance, security > > threats, fraudulent activity, and more. Splunk takes this data and makes > > sense of it. IT sense. And common sense. > > http://p.sf.net/sfu/splunk-d2d-c2 > > _______________________________________________ > > Mifos-users mailing list > > Mif...@li... > > https://lists.sourceforge.net/lists/listinfo/mifos-users > > > > > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Mifos-users mailing list > Mif...@li... > https://lists.sourceforge.net/lists/listinfo/mifos-users > -- AMIT JAIN | E.D | Digamber Finance (Chota Loan Bade Sapne) | +919414041821 | |
From: Thomas (Uganda) <nd...@gm...> - 2011-07-14 05:57:39
|
Hi Keith, Just a few suggestions to have a Stable Mifos Version - Having Basic Standard reports ( i.e Client details report, Client Loan details rpt, Loan Payment details rpt etc) running as part of the mifos and not a separate solution for reporting - A Fix for Java out of Memory exception - Enabling use of Client Photo on creating a Client - Having basic accounting reporting enforced from with in mifos by creating standard reports for say Total Loan Portfolio rpt, Total Profit rpt, Total Exependiture rpt etc - Inclusion of Shares Module like the loan and saving modules - A way to Import existing Client Data for a new Microfinace deployment I believe with a much stable version Mifos will be the only way to go. On Jun 21, 1:55 pm, Keith Woodlock <keithwoodl...@gmail.com> wrote: > Hi all, > > At the moment we are wrapping up Maya G (mifos 2.2.x) (seehttp://mifosforge.jira.com/wiki/display/MIFOS/Maya+G) and its time to > plan what to put into next release of mifos. > > As was mentioned inhttp://mifos.org/community/news/grameen-foundation-transition-mifos-c..., > mifos is transitioning to 'leaders in the Mifos community'. You the > users of the software can help by replying to this email and > indicating what you would really like to see done on mifos for the > next and following releases. This will probably fall into the > following categories: > > 1) Bug fix: An existing known bug in mifos that annoys or hampers the > way you work. e.g. I would really like to see MIFOS-XXXX fixed > > 2) Improvements: You would like to see an improvement in the way > something works on mifos e.g. work flow, ability to edit x, ability to > capture some other information currently not tracked on mifos etc > > 3) New Features: You like to see mifos add support for something it > currently does not such as 'micro-insurance', a report that shows x, > > Maybe you could reply with a prioritised list of whats most important > for your organisation. > > If you have any other comments/suggestions they are also welcome. > > regards, > Keith. > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking.http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Mifos-users mailing list > Mifos-us...@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/mifos-users |
From: Keith W. <kei...@gm...> - 2011-07-14 20:19:12
|
Thomas, Thanks for your comments and feedback. I will add these points to http://mifosforge.jira.com/wiki/display/MIFOS/Feature+Request+List > - A Fix for Java out of Memory exception On this could you be more specific? I wasnt aware of an out of memory problem with mifos? > - Inclusion of Shares Module like the loan and saving modules Could you provide more details on this. I dont have much knowledge of what is meant by 'Shares' in relation to microfinance sector. We can then add this detail to a project page to help guide development. Also, could you state what MFI/NGO you are working with and possibly even a short description of the products and services your provide (maybe ed cable has this information already though?) regards, Keith On Thu, Jul 14, 2011 at 6:57 AM, Thomas (Uganda) <nd...@gm...> wrote: > Hi Keith, > Just a few suggestions to have a Stable Mifos Version > > - Having Basic Standard reports ( i.e Client details report, Client > Loan details rpt, Loan Payment details rpt etc) running as part of the > mifos and not a separate solution for reporting > - A Fix for Java out of Memory exception > - Enabling use of Client Photo on creating a Client > - Having basic accounting reporting enforced from with in mifos by > creating standard reports for say Total Loan Portfolio rpt, Total > Profit rpt, Total Exependiture rpt etc > - Inclusion of Shares Module like the loan and saving modules > - A way to Import existing Client Data for a new Microfinace > deployment > > I believe with a much stable version Mifos will be the only way to go. > > > On Jun 21, 1:55 pm, Keith Woodlock <keithwoodl...@gmail.com> wrote: >> Hi all, >> >> At the moment we are wrapping up Maya G (mifos 2.2.x) (seehttp://mifosforge.jira.com/wiki/display/MIFOS/Maya+G) and its time to >> plan what to put into next release of mifos. >> >> As was mentioned inhttp://mifos.org/community/news/grameen-foundation-transition-mifos-c..., >> mifos is transitioning to 'leaders in the Mifos community'. You the >> users of the software can help by replying to this email and >> indicating what you would really like to see done on mifos for the >> next and following releases. This will probably fall into the >> following categories: >> >> 1) Bug fix: An existing known bug in mifos that annoys or hampers the >> way you work. e.g. I would really like to see MIFOS-XXXX fixed >> >> 2) Improvements: You would like to see an improvement in the way >> something works on mifos e.g. work flow, ability to edit x, ability to >> capture some other information currently not tracked on mifos etc >> >> 3) New Features: You like to see mifos add support for something it >> currently does not such as 'micro-insurance', a report that shows x, >> >> Maybe you could reply with a prioritised list of whats most important >> for your organisation. >> >> If you have any other comments/suggestions they are also welcome. >> >> regards, >> Keith. >> >> ------------------------------------------------------------------------------ >> EditLive Enterprise is the world's most technically advanced content >> authoring tool. Experience the power of Track Changes, Inline Image >> Editing and ensure content is compliant with Accessibility Checking.http://p.sf.net/sfu/ephox-dev2dev >> _______________________________________________ >> Mifos-users mailing list >> Mifos-us...@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/mifos-users > > ------------------------------------------------------------------------------ > AppSumo Presents a FREE Video for the SourceForge Community by Eric > Ries, the creator of the Lean Startup Methodology on "Lean Startup > Secrets Revealed." This video shows you how to validate your ideas, > optimize your ideas and identify your business strategy. > http://p.sf.net/sfu/appsumosfdev2dev > _______________________________________________ > Mifos-users mailing list > Mif...@li... > https://lists.sourceforge.net/lists/listinfo/mifos-users > |
From: Ed C. <ed...@gm...> - 2011-07-14 21:46:58
|
> > > > - Inclusion of Shares Module like the loan and saving modules > > Could you provide more details on this. I dont have much knowledge of > what is meant by 'Shares' in relation to microfinance sector. We can > then add this detail to a project page to help guide development. > Keith, in the SACCO (Savings and Credit Cooperative) model, shares are akin to shares of ownership a member of a credit union would have. In the past some MFIs have used savings to address there needs to track shares at a limited level. A couple pages on the wiki tracking some of the requirement gathering we did on support for a shares module: http://mifosforge.jira.com/wiki/display/MIFOS/Shares+Module http://mifosforge.jira.com/wiki/display/MIFOS/Shares+Module+Work+In+Progress I'm certain our African users could add more details on Shares in the context of the SACCO, ROSCA, ASCA models, More on SACCOs: http://www.saccol.org.za/what_is_sacco.php > > Also, could you state what MFI/NGO you are working with and possibly > even a short description of the products and services your provide > (maybe ed cable has this information already though?) > Keith, Thomas is Systems Analyst with VasTech, an ICT service provider in Uganda. I have updated their Specialist profile in the Mifos Community Directory - http://mifos.org/node/1960. They've currently deployed Mifos at Friends Capital Finance and have additional implementations underway. Ed > > On Thu, Jul 14, 2011 at 6:57 AM, Thomas (Uganda) <nd...@gm...> > wrote: > > Hi Keith, > > Just a few suggestions to have a Stable Mifos Version > > > > - Having Basic Standard reports ( i.e Client details report, Client > > Loan details rpt, Loan Payment details rpt etc) running as part of the > > mifos and not a separate solution for reporting > > - A Fix for Java out of Memory exception > > - Enabling use of Client Photo on creating a Client > > - Having basic accounting reporting enforced from with in mifos by > > creating standard reports for say Total Loan Portfolio rpt, Total > > Profit rpt, Total Exependiture rpt etc > > - Inclusion of Shares Module like the loan and saving modules > > - A way to Import existing Client Data for a new Microfinace > > deployment > > > > I believe with a much stable version Mifos will be the only way to go. > > > > > > On Jun 21, 1:55 pm, Keith Woodlock <keithwoodl...@gmail.com> wrote: > >> Hi all, > >> > >> At the moment we are wrapping up Maya G (mifos 2.2.x) (seehttp:// > mifosforge.jira.com/wiki/display/MIFOS/Maya+G) and its time to > >> plan what to put into next release of mifos. > >> > >> As was mentioned inhttp:// > mifos.org/community/news/grameen-foundation-transition-mifos-c..., > >> mifos is transitioning to 'leaders in the Mifos community'. You the > >> users of the software can help by replying to this email and > >> indicating what you would really like to see done on mifos for the > >> next and following releases. This will probably fall into the > >> following categories: > >> > >> 1) Bug fix: An existing known bug in mifos that annoys or hampers the > >> way you work. e.g. I would really like to see MIFOS-XXXX fixed > >> > >> 2) Improvements: You would like to see an improvement in the way > >> something works on mifos e.g. work flow, ability to edit x, ability to > >> capture some other information currently not tracked on mifos etc > >> > >> 3) New Features: You like to see mifos add support for something it > >> currently does not such as 'micro-insurance', a report that shows x, > >> > >> Maybe you could reply with a prioritised list of whats most important > >> for your organisation. > >> > >> If you have any other comments/suggestions they are also welcome. > >> > >> regards, > >> Keith. > >> > >> > ------------------------------------------------------------------------------ > >> EditLive Enterprise is the world's most technically advanced content > >> authoring tool. Experience the power of Track Changes, Inline Image > >> Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > >> _______________________________________________ > >> Mifos-users mailing list > >> Mifos-us...@lists.sourceforge.nethttps:// > lists.sourceforge.net/lists/listinfo/mifos-users > > > > > ------------------------------------------------------------------------------ > > AppSumo Presents a FREE Video for the SourceForge Community by Eric > > Ries, the creator of the Lean Startup Methodology on "Lean Startup > > Secrets Revealed." This video shows you how to validate your ideas, > > optimize your ideas and identify your business strategy. > > http://p.sf.net/sfu/appsumosfdev2dev > > _______________________________________________ > > Mifos-users mailing list > > Mif...@li... > > https://lists.sourceforge.net/lists/listinfo/mifos-users > > > > > ------------------------------------------------------------------------------ > AppSumo Presents a FREE Video for the SourceForge Community by Eric > Ries, the creator of the Lean Startup Methodology on "Lean Startup > Secrets Revealed." This video shows you how to validate your ideas, > optimize your ideas and identify your business strategy. > http://p.sf.net/sfu/appsumosfdev2dev > _______________________________________________ > Mifos-users mailing list > Mif...@li... > https://lists.sourceforge.net/lists/listinfo/mifos-users > |