Over the years that WebPA has developed, at Loughborough University, the users have always requested new features to be added. This developed into a long list of academic wishes, but it has so far not been evaluated to show if the whole user community requires the features listed. Now, seems an appropriate time as the project are looking to update the road map.
The road map document lets the projects community members see where the project is intending to go for the next phase of work. WebPA tries to update the road map every six months of the projects current funding period. I hope that in this phase the community needs for WebPA will be more clearly reflected in the development to take place.
In order to ensure that the community needs are reflected the current wish list was sent to all active users at Loughborough University. The community where sent a list of requirements that had previously be gathered and asked to select their top three. If their most important requirements where not on the list the community was asked to feed back what they needed. From all the emails sent there has been a 23% response rate. While this is not wonderful it is sufficient, well we aren't going to statistically analyse the information. From this I have identified a list of requirements to take the development of WebPA forward while ensuring the users needs are met. These requirements may not be pedagogically sound in most cases, but as an open source project I think that we can be forgiven this if we are meeting user need.
I do think that it will be interesting to re do this task as the project community grows. But in that growth I feel that more work will be needed to ensure that the community of users are aware of the WebPA sourceforge area, and how features can be requested.
Subscribe to:
Post Comments (Atom)
webpa
4 comments:
The link to your feature tracker is not correct it should be http://sourceforge.net/tracker/?group_id=194016&atid=947740
(just thought I'd post it here, but you might want to change it in the main text)
I've done the things of circulating lists of feature requests in the past. The problem with suggesting new features to users is that they typically want them all.
I wonder if you had the same problem?
What I do now is I encourage users to visit the tracker and search for their most commonly requested features. Unfortunately the sourceforge tracker does not have a feature vote facility, but people can add their support in a comment.
There are two main advantages to this:
a) new users can see that they too can express their "vote"
b) new users who don't find their required feature realise they can add it and, since they are already at the feature page often do so
Having said that, 23% repsonse rate is excellent, you may feel it is low, but I think that is pretty high. Well done!
To try and prevent the respondents from selecting all of the wishlist items circulated, I asked them to rank their top three. As usual I had one or two responses where the list extended to all, but ranked. However, on the whole most individuals where fairly restrained. Once I collated all of the responses, the requirements where quite clear. I did also state that if there was something missing from the list that they thought was needed to email this back.
I would have loved to just get everyone to do the selection through the source forge tracker. However, I don't think I would have had the same response rate. Also I am trying to introduce the current users to the concept and methods to working in the open source arena. I hope by the end of the project they would be more comfortable contributing in a more open fashion.
Thanks for the additional information.
I appreciate the concerns about response rates if you'd asked people to go to the tracker. I'm pretty sure you are right, you would have got lower response rates.
Many people take a very hard line view of leading by example in projects.
Karl Fogel (in "Producing OSS") says:
"Stability in a project does not come from formal policies, but from a shared, hard-to-pin-down collective wisdom that develops over time. ... Consider how children's songs survive the centuries. There are children today singing roughly the same rhymes as children did hundreds of years ago, even though there are no children alive now who were alive then. Younger children hear the songs sung by older ones, and when they are older, they in turn will sing them in front of other younger ones. ... The goal of setting precedents early is to make those "in-group" behaviors be ones that are useful to the project; for once established, they will be largely self-perpetuating."
Fogel is not suggesting you have to start out with the activities as where you intend to take them. He is merely saying that self-perpetuating behaviours can be difficult to change.
Getting the right balance between encouraging *some* activity and encouraging the *desired* activity is a thorny problem for open source projects.
I think I'll bring this topic up on the Community Development list to see if there is any common wisdom. The results may make an interesting follow up post here.
Post a Comment