I do wonder though if it would be useful to have a sticky post or a wiki page describing some of the more popular feature requests, with links to or excerpts from the most relevant forum threads. Alternatively, we could write summaries on the current status of each feature request, and the main issues that have to be overcome for implementation (and the level of difficulty). This could be similar to a Google Summer of Code project list (see e.g. http://developer.pidgin.im/wiki/FutureSOCProjects or http://www.abisource.com/wiki/Google_Summer_of_Code_2010#Project_Ideas), and might help in attracting some outside developers. (the only thing that I'm aware of that is somewhat related to this are the "help wanted"-tickets in the Trac issue tracker, which are rather out of sight)
Several things - 1. I think the fact that user requests are awkward and take some time to research isn't necessarily bad. I'd argue that in most cases an informed request requires insights in what exactly is possible, what has been discussed and possibly rejected already already etc. There are much more requests than resources - the economist in my nick says that increasing the "price" of requests is the correct market solution ;-).
2.
But somehow I seem to read here that the developers will go in the direction that they think the greatest and/or that is best for satisfying grant requirements, largely ignoring user opinion.
Along with bdarcus I think that's not quite right. Users input isn't ignored - and there are in fact many examples of user input leading to new features or changes - but for the reasons bdarcus states, some notion of (perceived) user democracy - votes, +1s, most comments etc. - isn't used to determine dev priorities. Also, as noksagt points out above and your comment about duplicates confirms, a company like Mendeley with a more elaborate feature request system, more money and more staff struggles to meet those demands, too. And note that developers here refers to the paid folks at GMU - there is always the option for outside developers and there are a whole bunch of examples of that type of involvement with fruitful results - from mrronko's quick look plugin to the new CSL to the improved translator dev documentation etc.
3.
I do wonder though if it would be useful to have a sticky post or a wiki page describing some of the more popular feature requests, with links to or excerpts from the most relevant forum threads.
agree with that - within the current technical framework we could just set up wiki pages for that, but I wonder if it wouldn't be possible to integrate that more tightly with the forum. Maybe fcheslak could chime in?
within the current technical framework we could just set up wiki pages for that, but I wonder if it wouldn't be possible to integrate that more tightly with the forum.
Would a static sticky in the Feature Requests forum pointing to the wiki page (where everybody has access) work? E.g. something like "Many ideas for new features have already been discussed on these forums. For a quick overview of the most common feature requests and the status of their implementation, see [...]."
The fact is, grants do currently primarily fund Zotero development.
This being the case, I'd also like to see a listing of these grants on the Zotero wiki (assuming that that information is publicly available). That might enlighten people (including me) somewhat with regard to some of the goals and plans for Zotero.
Seconded. I have a vague idea of some of the running grants (e.g. Zotero Commons) and some of them have been published on the blog, but it would certainly help to have an overview, also to point people to.
Upgrade Storage
1. I think the fact that user requests are awkward and take some time to research isn't necessarily bad. I'd argue that in most cases an informed request requires insights in what exactly is possible, what has been discussed and possibly rejected already already etc. There are much more requests than resources - the economist in my nick says that increasing the "price" of requests is the correct market solution ;-).
2. Along with bdarcus I think that's not quite right. Users input isn't ignored - and there are in fact many examples of user input leading to new features or changes - but for the reasons bdarcus states, some notion of (perceived) user democracy - votes, +1s, most comments etc. - isn't used to determine dev priorities. Also, as noksagt points out above and your comment about duplicates confirms, a company like Mendeley with a more elaborate feature request system, more money and more staff struggles to meet those demands, too.
And note that developers here refers to the paid folks at GMU - there is always the option for outside developers and there are a whole bunch of examples of that type of involvement with fruitful results - from mrronko's quick look plugin to the new CSL to the improved translator dev documentation etc.
3. agree with that - within the current technical framework we could just set up wiki pages for that, but I wonder if it wouldn't be possible to integrate that more tightly with the forum. Maybe fcheslak could chime in?