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
_______________________________________________
Mifos-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mifos-users
