Prioritizing Features

The forums we observed either provided no explicit inbuilt prioritization mechanisms or else provided a simple voting button that enabled users to register their support for a feature request. The virtual world game provided a feature that allowed stakeholders to assign priorities to feature requests. In all of the forums we observed that users attempted to prioritize certain features through adding comments. For examples, in several cases users included comments such as “let my comment serve as a vote for this

feature,” or started their posts with the words “Feature Request” in order to attract attention. Although

we could not substantiate this through responses to our survey, our informal discussions with forum users also suggested that one reason people created new threads for each feature request, was because in some forums this meant their feature request would be placed at the top of the list, which would make it more visible than if it had been entered as a response to an existing post.

It was clear that users wanted project managers to listen to them and to build features that were important to them. Several forums included queries from users who were obviously perplexed or annoyed that feature requests that were important to them were apparently ignored by the vendors. In one case a vendor responded to the question of “Who decides which new feature requests to implement in a given

release?” with the comment that “We have some polls on our website that might influence decisions,”

thereby highlighting the fact that for that particular project user opinion only marginally influenced development decisions.

Chapter 4. Open Source Software Projects Data Analysis 40

Another more subtle problem was observed in the virtual world forum which provided both prioritization and voting functions. The initial contributor was allowed to prioritize the requirements, while other users were simply allowed to vote for it. This introduced an ambiguity as to whether users were voting for the feature, or agreeing to its prioritization level. For example, if a contributor had created a new feature request and assigned it a low priority, then subsequent users were unable to change its priority level, although they could cast their votes for it. In general, the forums we observed did not provide sophisticated support for the requirements prioritization process.

The three administrators who responded to our survey indicated that they were only partially satisfied with the requirements prioritization process. User responses to the question “How satisfied are you that your feature requests for new functionality are addressed by this process?” are reported in Figure 4.3, and showed that users were most dissatisfied were ERP and Java application server, which interestingly represented two of the projects with no separate feature request module. There was also a significant degree of dissatisfaction in the password manager and virtual world projects. The possible reasons for this are found in users responses to the question “Which of the following methods do you think your OSSP uses to prioritize feature requests?” The users’ responses, which are reported in Figure 4.4, indicate that in most cases prioritization decisions are made by administrators who do take users’ requests into consideration. It was interesting that in the groupware project, the users’ perception was that prioritization decisions were largely based on user input. This project notably had no users that reported being dissatisfied or somewhat dissatisfied with the prioritization method. It should be noted that the level of dissatisfaction by users of the Java application server, might be correlated to the fact that 28% of the surveyed users did not know how project administrators prioritized feature requests.

Figure 4.4. Methods for Prioritizing Feature Requests.

Users’ responses from the virtual world project also provided some indication as to why they were so dissatisfied with the requirements prioritization process. Two respondents who checked the “other” option commented that features were prioritized by “dart game, random selection”, while another user said that “On rare occasions, there are discussions either in the blog or in the newly-active area in the

forums; however, (the administrators) seem to disregard these for the most part although they are the ones who have openly solicited comments.” Despite this perception of random prioritization, the virtual

world forum does in fact provide a webpage describing how feature requests are processed. The page includes advice that “Features are more likely to get implemented if the description of the feature is clear.

For a complicated feature, a link to a specification on the wiki is a great way to help flesh out the idea.”

Nevertheless, the level of dissatisfaction in the process suggests that users do not believe their feature requests are handled in a satisfactory way despite the appearance of due process.

In CRM’s very active discussion forum one of the project managers created a new discussion thread and asked users “what would you like us to build next?” In one sense, this demonstrated willingness to engage the user base in the prioritization process, but in another sense it demonstrated that the existing forum failed to explicitly capture this information and to create a prioritized ranking of feature requests, despite the active engagement of the user community. This problem illustrates one of the main challenges of gathering requirements in a forum, where large amounts of data must be processed in order to extract useful information. It seems that despite the active discussions in many of the forums, administrators are still not easily able to understand the users’ real needs.

Chapter 4. Open Source Software Projects Data Analysis 42