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
On Wed, Jul 6, 2011 at 10:56 PM, Van Mittal-Henkle <
[email protected]> wrote:
> Ed,****
>
> ** **
>
> What struck me as I thought about this more is that we really have two
> communities that we are trying to encourage and grow:****
>
> **1) **The community of Mifos users who find that Mifos provides them
> value and helps them to better serve their clients and grow their
> businesses.****
>
> **2) **The community of Mifos contributors including developers,
> translators, documentation writers and others who spend time to make Mifos
> better.****
>
> ** **
>
> Your point #1 sounds great—use whatever tools and processes are most
> effective for gathering end user feedback and requirements with the output
> for contributors being JIRA issues (ideally with a link back to who is
> interested in the feature to get feedback as it is developed). Part of
> engaging the Mifos user community is opening the most effective channels of
> communication so that their needs can be heard and met.****
>
> ** **
>
> For point #2, I like that it includes giving Mifos users a vote in what
> work they would like to see included in the next release.****
>
> ** **
>
> My improvement on it would be the following, rather than attempting to
> choose some set number of features to include in the next release, simply
> keep an ordered list with the features with the most votes at the top.****
>
> ** **
>
> When the time comes to start a release, then contributors who are available
> and interested would be able to use the list as a guide for how they could
> add the most value by choosing a popular request from the list to work on.
> ****
>
> ** **
>
> In order to grow and retain the developer portion of the contributor
> community, I don’t think it will be effective to try assigning issues to
> developers. My view is that for many volunteer developers, choosing what
> they work on is part of the whole attraction to contributing to a project
> like this. ****
>
> ** **
>
> Some developers might choose to work on things that aren’t even on the
> list. As long as the contributions are valuable, move the project forward
> and have an acceptable risk/reward ratio for a given release the project
> would do well to accept them (take some of the recent contributions from
> Michael Vorberger as an examples of things we didn’t ask for but have had a
> big positive impact on the project).****
>
> ** **
>
> --Van****
>
> ** **
>
> 1) Increase ease of capturing requirements. Some users have given feedback
> that JIRA is a bit cumbersome to easily log feature requests or feedback. 2
> options to increase ease of use would be to simplify and hide some of the
> JIRA fields and/or to once again start using a tool like uservoice (http://
> /mifosinitiative.uservoice.com) as a first filter and then we can take
> ideas that gain interest there and add more detail to them as JIRA feature
> requests. ****
>
> ** **
>
> 2) Process for collecting feedback. For each release we have the following
> structured planning process:****
>
> ** **
>
> * Open call for feature requests/suggestions (administered through
> intermediaries, directly in JIRA, virtual user meetings, feedback from
> Specialists, etc.) [2 weeks]****
>
> * Developers "triage" which of these features could potentially be worked
> based on need, product realities and volunteer resources" and narrow down
> requested feature set to a pool of 10-15 features****
>
> * Community Product Roadmap Voting Period. Community can then vote for the
> 5-10 features they would like in the next release (from the pool of 10-15
> features). [1 week] Volunteers would be assigned to projects for these
> selected features. Any features not selected would be up for development in
> next release or (as you stated) MFI could hire a developer/team to build for
> them now.****
>
> ** **
>
> I think this process would be democratic enough in allowing true community
> input and feedback but would allow the core volunteer developer team to
> properly manage expectations and what features could be worked on.****
>
> ** **
>
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mifos-users
