Give this a try for user feedback: zotero.uservoice.com
Having seen multiple threads and messages over the last few years related to improving the way Zotero development and user feedback influence each other, and having seen Mendeley's fabulous implementation of UserVoice, I decided to go ahead and set up a proof of concept.
Find it here: https://zotero.uservoice.com/
I set it up as a free UserVoice account. This is just a proof of concept and may be deleted. I hope Zotero can spare a few bucks a month to set up something like this and to have additional features like user moderation and different categories, if needed. UserVoice is incredibly slick at providing domain name aliasing and JSON single site login, so perfect integration would be possible. However, even this free account allows a fair amount of possibilities.
Needless to say, as a loyal Zotero user, I would be more than willing to hand over this particular subdomain to staff if needed. On the other hand, I can easily imagine something like this being maintained by committed users — by way of a service to the developers which may help them gauge the priorities in the usersbase more effectively. That is to say it needn't cost valuable developer time, it might actually improve the development cycle by being a more efficient alternative for the current feature request system.
Small selection of earlier threads/comments by users related to the feedback process: Migugg; Rintze, Adam Smith and me; and Scot.
Find it here: https://zotero.uservoice.com/
I set it up as a free UserVoice account. This is just a proof of concept and may be deleted. I hope Zotero can spare a few bucks a month to set up something like this and to have additional features like user moderation and different categories, if needed. UserVoice is incredibly slick at providing domain name aliasing and JSON single site login, so perfect integration would be possible. However, even this free account allows a fair amount of possibilities.
Needless to say, as a loyal Zotero user, I would be more than willing to hand over this particular subdomain to staff if needed. On the other hand, I can easily imagine something like this being maintained by committed users — by way of a service to the developers which may help them gauge the priorities in the usersbase more effectively. That is to say it needn't cost valuable developer time, it might actually improve the development cycle by being a more efficient alternative for the current feature request system.
Small selection of earlier threads/comments by users related to the feedback process: Migugg; Rintze, Adam Smith and me; and Scot.
Yes, trac tickets are created sometimes and devs reference these tickets sometimes in the original thread, but in the current setup there is often a great disconnect between the user feedback and what is done with it — witness the threads referenced above.
Before we throw yet-another-tech (that happens to be used by a few other projects that have larger development teams), we should answer these questions:
What are the top communication issues that need to be addressed and is this tool actually help to address them? Who will be the uservoice wrangler when there is not really a trac wrangler?
Currently, users have a single point of communication with zotero (these forums) to address bug reports, feature requests, and support requests. These "brainstorm" webapps only really address feature requests. And the single thing they are able to do best is to see what popular opinion says are the most important issues. Developer priority is (and both should and must be) different than user priorities. Can one not already accomplish a similar thing by glancing at popular forum threads? Is the problem that this softwar solves even a real need for Zotero?
Migugg seems to most want a system to keep track of the next steps of program development. I don't know whether I agree to the importance of this (it seems more important that the scarce resource of developer time is spent improving Zotero). But I also don't think brainstorm software actually addresses issue tracking.
Mendeley's system actually demonstrates some of this disconnect: the second most popular request, over a year old, is for them to release their code under an open source license. The status is still listed as 'under review,' and the Mendeley developers only responded to it in the past few months to say "no, we can't do this."
As I believe I've said before, I think a more productive shift would be to have more issue tracking and bug fixing take place via Trac -- the more problematic disconnect, I think, is between zotero-dev and Trac, and between patch submission and patch landing.
If there's a tech-of-the-month that I'd like to see applied to Zotero, it's a bug bounty site, which could also be non-official. A good number of the long-time feature requests are things that could probably be done by a sufficiently motivated outside programmer in only a day or two (or an hour or two), and money can sometimes be a good motivator.
I haven't fully made up my mind, but I think I tend towards noksagt and ajlyon. Gathering and organizing feature requests doesn't seem a priority to me. And Dan has suggested that developers often don't feel they can make realistic predictions on issues, so respsonses might not be particularly useful.
Like miggug (and somewhat contra noksagt) I would place more value on issue tracking - I guess the tracker could work for this in theory, but does not in practice.
Personally, I'd be happy with something very simple - like a "to do" list of the core developers for the larger issues by order of priority - it wouldn't even have to include ETAs, but just knowing the next couple of things they are planning to do - and updating that maybe once every 3 months - wouldn't seem like a big use of developer resources and would already help - so basically a little more detailed roadmap than the one we currently have and I for my part would be content.
But I'm also perfectly happy to be convinced that a uservoice type forum can be useful.
As for the above, it's not lack of awareness of user priorities that prevents things from getting done—it's lack of developer time, and our having other priorities for a variety of reasons (including, most notably, grant requirements) that have nothing to do with how many users vote for a feature.
If there were a system that would indicate to me if my request is a) heard and b) shared by others and c) taken care of (or, for good reasons not) that would help a lot.
noksagt's example of mendeley's feature of going open source is unfair. It is very obvious why they do not adress it, and noksagt just play's the obvious "bad commercial mendeley" card here. Apart from this issue, as far as I can judge, mendeley's system works perfectly fine and makes sense.
That said, I think there is a place in the feedback ecosystem for a voting forum. Sometimes we as users just want to chip in our two bits' worth and move on, and it serves that purpose well. A voting forum shouldn't drive development, for sure, and the peripheral role of such a tool in forward planning could and should be made clear and explicit. But don't think the value of such a forum derives from any sense that users somehow control the development process. People who participate in digg-like systems are communicating with one another, as much as with dev central. To that extent, it can release some of the pressure to be recognized, and that can save time for everyone in the long run.
One possible use for a voting forum might be to float ideas for third-party plugins. It's easy to come up with armchair visions for such things, but the necessary attention (for development, or for writing the grant applications necessary for development) can be galvanized by evidence of widespread demand.
Anyway, mark has set up the account, let's see how it goes. Perhaps there is a positive stance to be found toward such an enterprise that lies somewhere between benevolent dictatorship and the democracy of the Borg. :)
Agree with fbennett that we should cultivate a more diverse set of information tools around the zotero project. Forums are good for some things but here far too broadly used, for purposes where other tools would work better.
Also agree that there are big issues with trac. That's a key part of the problkem here. (Dan, see follow-up post on Redmine.)
Finally, I don't think you can talk about these questions without talking about the definition of zotero's core mission, and medium-to-long-term project planning. To what degree are users involved, and how? Project planning and management is integral because, having a mission, that's how you "make it so."
The "open" part of "open source" is flexibly vague. Open source ... information ... planning ... process? Every project is different, and the range runs from individual fiefdoms to large-scale participatory chaos. Every project needs to work out its definition.
Some background about me - now I'm working on a PhD in architectural history but I worked for years in software (no formal education though). I've defined and set up development infrastructures numerous times. I'm a big partisan of open-source software, and that has to do with how I think about human interaction, at all scales, and even the nature of knowledge, as much as more pragmatic aspects.
I'm currently using Redmine for my (bill-paying) job. I love it. It's the perfect balance of features you want without bloat. Running about 9 months with zero problems. A few admin and UI quirks but nothing major. I set it up primarily for my own use but colleagues liked it so much they've defined their own projects and are using it - actually more for project planning and task management, not specifically software development.
Contact me offline (see my profile) if you have questions or would like to hear more (I can give you an account on my system if you like). I myself installed and configured it and the database back-end. I'd be happy to help you guys out if I can.
* I remember the first time I looked at zotero-dev. I said, "this is a joke, obviously not where the real communication is taking place."
* The norm for open-source projects is that anybody can sign up and use the bug database.
I do agree with noksagt and others, including Dan Stillman, that perhaps this is not the greatest hurdle in Zotero's development cycle. Yet it is a palpable problem that quite a number of users have called attention to over the years. If Dan says, "As for the above, it's not lack of awareness of user priorities that prevents things from getting done", we are ready to believe him. Dan is taking the developers' point of view; fair enough. But from the users' point of view, there is an opacity-of-mind problem that can be quite annoying — a disconnect between what the devs are aware of and how the users can get to know what the devs are aware of. An ideas forum (where the status of ideas can be simply and clearly marked as "planned", "under review", "declined", with a brief explanation) helps solve this problem and in the end saves lots of valuable time.
I appreciate fbennet's insightful comments on the value of an ideas forum. Also, his point about the use of such a voting forum to developers of third party plugins is an important one: In short, I'm glad some of you agree with the possible usefulness of an ideas forum like this. We'll have to see whether it flies or not. I'm waiting a bit to see if there's more input.
But I'd say ANY other issue request there shows my point too. Their number one feature request is, similar to a popular Zotero request, duplicate detection and handling. That thread is also over a year old & has been marked "started." But what does that mean? When will it be implemented? What works in their (private) development builds right now? That is one of the threads that is most commented on by the Mendeley developers, but it still doesn't provide anymore information than we have about Zotero's duplicate detection (which is: there is code that can be enabled by a hidden preference to find dups already, there isn't currently heavy development on that feature, but there are plans to improve this).
A well-used issue tracker seems far superior to handle the kinds of problems you say you want solved. If there are other issues (of the kind that Frank Bennett notes) that this would address, then fine. But let's not fool ourselves!
Most people in this thread have ticket-creation privileges in Trac already. I suspect they don't create tickets currently for the same reason we don't—i.e., it takes forever.
In the meantime, though, I'm happy to give translator commit access to a few more of the usual contributors. We still need to push them to clients ourselves, but that's a bit easier once they're already committed.
For other patches, I would say it's not really any different from how you get a patch to land in most projects: try to get other people to test it, be persistent, and be patient.
This is not just about Trac. The problem is that these forums are a particularly bad place, interface-wise, to solve the disconnect I've observed above, because (1) there are no clear ways for users to quickly find what the devs have said about some topic; and as an immediate consequence, (2) many users just start a new thread if they can't find this information soon enough, wasting valuable time of many people including devs. The resulting duplicate threads make problem 1 only worse, reinforcing problem 2.
My perception of this is obviously different than the developers' perspective. I don't think Zotero is doing as good a job in communicating to the userbase as it could. Although the devs are confident they got the main priorities covered, the opacity-of-mind problem remains and this leads to a lot of time wasted in the forums. My intent was to suggest an improved interface that would help take away some of these problems. If this is not a priority right now, so be it. I look forward to the improvements that a better alternative for Trac will bring. I remain skeptical that the forums will become a much more enlightening place through it though.
would that still work if the core developers really don't go there? - I'm happy to check out pretty frequently and together with the dozen or so other power users here we probably know everything that a developer has ever written on a topic.
But how would requests feed back to developers?
Also, I think there is still the problem of forking - many feature requests are, as Dan points out, not feature requests but help requests - how should those be dealt with?
I really like the fact that it essentially forces you to search before you can put in a feature request, I've often wished the forum did that.
Another advantage is that this could (and probably should) be moderated much more aggressively, especially in terms of merging threads/requests.
The voting would, in that case, be more useful in pushing common requests to the tops and less important as a signal to developers - I think Dan has made it clear that their future priorities are not going to be determined mostly by user votes.
The main thing that's not clear to me is how another system (which, no, I probably wouldn't participate in) wouldn't become just as messy as the forums. It might seem cleaner initially when there's simply less content, but that would change if it were actually used. We're pretty aggressive about merging and closing threads here.
And the inability to properly deal with the inevitable support requests seems like a pretty serious problem to me, since one of the main points of these forums is that the developers can step in if need be. Given that we wouldn't be saying anything at all on a separate system, I'm not sure how well it would help with that, unless other moderators were willing to do a whole lot of quoting or linking. But then you're mostly just fragmenting discussion into a forum where developers participate and one where they don't.
Also it would help, if somewhere on the entrance to the forums a note says: "if you want to push the development of a feature, simply add an entry with "+1"". Then, sorting according to "most contributions" would return the most wanted features. That would be a low tech alternative to Marks initiative.
Further, but probably this is technically not possible, a summary of the discussion on top of a discussion would help. It is quite annoying to find a discussion and then to discover somewhere in contribution 22 that a it is fix or a fix is planned or it can't be fixed.
The other thing we've considered adding is a feature that gives some indication of the status of people posting, since being able to quickly tell who's a developer or power-contributor would probably be helpful to newcomers.
Dan, pile-on threads may be 'distracting' from a developer's point of view, but I do think that you can see why from a user's point of view it can be important to have a way to say "this is my issue too!" Basically, you're never going to avoid it as long as Zotero has users and forums, so why not try and streamline the process? As migugg and various others have pointed out, users would not just vote to drive development; it's also, and perhaps more importantly, to 'release some of the pressure to be recognized' (fbennett) and to get common requests pushed to the top where users that are likely to be looking for them can find them easily.
Sorry to warp the thread, but do I read you correctly that there is a hidden preference to enable (some alpha version of) duplicate detection? Could you please give me a link to more information on that?
https://zotero.uservoice.com/forums/60719-general/suggestions/807201-duplicate-detection?ref=comments
I am fully committed, which also means fully dependent on the functioning of Zotero.
If it went away, I'd be dead... So please keep up the great work :) !
That said, from my personal user experience, the forums leave a lot to be desired.
It can take hours to read the multiple and highly repetitive tracks that usually exist for popular topics. The forums are far too fractured - do not know where to go. If there is some useful information at all, it is often buried somewhere in the middle of a thread. Way too time consuming, and this time is to be multiplied with the number of users reading... No wonder many users avoid the search and open yet another thread.
Something like a summary, and more guidance/pruning would be highly welcome.
Feature requests are awkward. A search will lead to several threads, which may be on topic or not, have to be read completely, may have been answered or not, and the status and prospects often remain unclear.
And it is completely non-obvious what requests are popular to what extend.
Final aspect: Of course the developer point of view has to be different than that of the user. 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. Huh ??? Zotero is great, because it is so useful - to the user, of course... - and wouldn't that also the ultimate goal of a grant ?
One point in case is the lack of duplicate detection. Four years old in the forums, a "show stopper" to several people who commented, and by far the most popular request on Mendeley. A very simple detection on import would be enough for many people, as has been commented often - and still there is nothing. Why ?
Almost inevitably, my sense is that these issues come down limited labor, and a long list of competing priorities. Priorities attached to funding don't necessarily conflict with "user" priorities.
If you have a comment on the duplicates issue, post it on the relevant thread.