https://www.zotero.org/trac contains guidelines & the method to request a trac account.

Dan has noted a few times over the last couple of years that the development team (which I am not a member of) doesn't feel that they are able to play triage to all bugs, which is why access isn't more open. The guidelines still seem to reflect this sentiment. As such, I'd be hesitant to submit anything to TRAC that seemed controversial and/or wasn't thought out enough (e.g. having TWO BibTeX exporters) & would save such discussions for these forums or the development list.

Note also that bugs can sit in trac with no comment or progress for months or more, just as forum posts can. Neglect is not a sign that nothing will ever happen or that nobody thinks it is a good idea. Bumping a thread in the forums is certainly less discouraged than filling trac with "bugspam." Perhaps more threads should be turned into tickets, but again: this won't provide you any more timely feedback. Note that you can follow forum threads using RSS, etc.

I have Trac access, though (tests...), no apparent way to create tickets.

But but the Zotero Trac page is pretty specific (seems to me) that it shouldn't be used for the kinds of user proposals I'm talking about, at least not until they've been given developer say-so.

And even if I could physically create new tickets, that doesn't exactly do it, since the issues can still die in the trac as easily as they can die in the forums.

It's partly an issue of how user suggestions and requests are integrated into the development process. It seems to someone outside that Zotero development is pretty centralized at CHNM. I don't mind this, I've seen great projects with a centralized vision-and-decision core, and which are quite good at taking user input into account. But I would suggest that if Zotero works that way, then good user proposals are most helpfully handled centrally, or at least by someone who is integrated enough into the development process that they can speak with authority about how things stand and what can and will get done.

If the development is not to center around CHNM, then that's a different story, but I'm not sure what that would look like.

I also realize, again with regard to Trac acess, that I'm not sure what the Trac's relation to development is. It seems like it's positioned as repository of tasks that are committed to at some level. If that's the case then it doesn't do much good to give me or someone like me Trac access, since I can't do any committing for the project. If it's broader than that, containing projects and issues and bugs that that still remain to be committed to, then it's different. Do they want that? Do we? The number of Help Wanted tickets on the Trac is currently a tiny fraction of the total. And if it were a repository for 'stuff people hope will happen' then some more of the discussion and bumping would need to happen there, otherwise there's no where it can be noticed by those who actually make the decisions.

(edited to clarify what I meant):

A short additon: As an example of a space for community commentary on bugs and features which still has workflow features, see Ubuntu's launchpad.net. This is not a suggestion to change tools, only another model which has some virtues, and which they seem to use well. The Ubuntu team make a pretty good effort to have all issues dealt with (by some means). And that helps them say "No really, this is Open Source, we *want* your bug reports." The Zotero devs also want to (and do) say something like that, but (perhaps) need some way to take those bug reports and feature requests forward so that all of us can benefit from users' mental work on the remaining problems.

And let me add again, that in lots of places the Zotero devs have done this well. Of the posts he answers, Dan S. in particular is quite good at moving each one to the next step, even if that's a 'Sorry, but no.' I appreciate that.

I disagree with both points: merely changing tools will do nothing to improve a situation that is fundamentally limited by manpower.

Yes, but changing tools along with changing focus and priorities a little can address the manpower issue. The bottomline is there need to be more people driving development, because at some point the grant money will dry up. So how to make that happen?

FWIW: I use git-svn for the extension and CSL repositories & there is nothing stopping you from benefiting from the "private" advantages of distributed version control.

Yeah, but I'm more speculating on the social advantages. A distributed approach allows potential code contributors to start contributing without needing commit rights (they can commit to their local repository). That significantly lowers barrier to entry (notwithstanding technical issues with new VC systems). And if CSL issues were handled outside Zotero, that's one less issue for the Zotero team to worry about.

I'm partly thinking about these issues in terms of xbib too; we've got a bunch of different subprojects in the SVN repo, and now forks of some of it on GitHub; seems to me everything but the schema and test suite ought to be spun off. But I'd still like to be able to contribute to those when time permits. Keeping track of them on GitHub or BitBucket is a nice/easy way to do that.

Give 10 or 20 eager users (or less, whatever) the ability the permission and the charge to help turn decent forum problems and suggestions into 'development requests'.

Scot: I don't think what you describe is appreciably different from the current situation. Most of the non-dev folks who would be qualified and inclined to do this sort of triage already have privileges to create tickets in Trac. I've now added you as well. But I don't think we want to fundamentally change how we use Trac.

As an example, a few hours ago Rintze, who has ticket creation privileges, created a ticket for a small bug that noksagt pointed out the other day. I'll probably get around to fixing it soon, or, if someone were inclined, they could follow the link to the ticket from the thread and ask to take it. This is as it should be. In that case, I had agreed on the thread that it should be fixed, but noksagt or Rintze could've easily put it into Trac before then, since it's pretty clearly non-optimal and there's no need for further discussion. If it did need further discussion, though, I think that restricting that discussion to the people who follow Trac would be a mistake.

The real limiting factor, as noksagt has pointed out, is developer time to actually implement things, and putting stuff into Trac isn't really going to help with that. Most of us on the Zotero team read every single post in the forums, and we could probably name off the top of our heads most of the issues that would appear on the sort of in-Trac-but-not-fully-committed-to list that you describe.

Ultimately, people not on the core development team are going to work on things that bother them, and they're going to search the forums for previous discussions and either try to get consensus or just offer up a patch. (Frank Bennett has gone both of these routes, and both have led to accepted patches.) We've marked a few tickets as "helpwanted" to suggest places where people could get involved, but I don't think anyone has ever actually worked on such a ticket. We have some ideas to more actively encourage community involvement in development and other areas, but I don't think it will fundamentally change what motivates people.

I think part of the frustration here is simply because, for most of the last year, the Zotero team has been focused primarily on metadata and file syncing, web features, and related social features (including some that have yet to appear), so we haven't had as much time as we've had in the past to devote to implementing other features suggested on the forums. This will change in the coming months as the sync-and-web-related features stabilize.

I think we've demonstrated that we're more than willing to engage deeply in forum discussions and turn user suggestions into code (even, sometimes, within hours), but we can't carry every discussion forward. I understand that it's frustrating not to receive a response to a post, but a lack of response on our end is usually a sign that we don't have anything of interest to add and are seeing if others chime in. This doesn't mean that we're uninterested in an idea, that we wouldn't join in if the discussion progressed, and/or that we wouldn't ultimately either implement something ourselves or welcome patches, but we simply don't have the time to respond to everything.

Ultimately, as I've said in the past, our limiting the use of Trac is aimed not at closing off the development process but rather at keeping it open and accessible to all users, including the large majority of people who would be intimidated by Trac but who can offer valuable contributions in the forums.

@fbennett: I just signed up for BitBucket, and added the (now empty) citeproc-js repo as first on my "watch" list ;-)

Regarding my comment in the previous post about a development timeline, here's a more concrete example.

I have my own high-priority list of 2 or 3 features, where I now use klugy work-arounds. These are not "deal-breakers" per se, but I would really, really like to know what chance they'll be implemented when I start writing my dissertation. It could affect my workflow now, if I know I probably won't have the feature.

Another angle is that I'm capable of being a developer (although now working in social sciences / humanities). Some of these features I might go ahead and implement myself ... if I ever had time :-/

I have my own high-priority list of 2 or 3 features....I would really, really like to know what chance they'll be implemented

So ask in the forums or the dev list? Trac doesn't provide some magic way that these concerns would be addressed. Unless there were more developer hours, they'll probably be less likely to be implemented if you ask that current developer hours be spent on triage.

Another angle is that I'm capable of being a developer (although now working in social sciences / humanities). Some of these features I might go ahead and implement myself ... if I ever had time :-/

If you have genuine interest, that is great & we'd want to definitely make the threshold to do this low. For minior changes, you can post patches to the dev list & they'd probably be appreciated. If you are concerned that there might be ongoing work or that your patches might be controversial, the dev list is friendly & helpful & would try to help you if you made a query there.

alexuw: But the whole point is that Trac is for developers, not end users. We know the problem exists, which is rather evident because it's displaying a specific message that was obviously written and put in by a developer. We don't need further information on it, and we don't need to search for it. For end users like yourself, you can either search for the text in the forums, as you did, which brings you to a thread where Sean acknowledges we're aware of it, or you can look at the known issues page for 1.5, which also lists it (and, I might add, includes a link to the existing ticket).

We generally do try to include links to Trac tickets from forum threads and vice versa, but that's mostly just to save a few seconds when something is fixed and we want to quickly post a note letting people know.

As noksagt says, that well-meaning individuals like yourself would want to create a Trac ticket for something for which a ticket exists and which is even listed on the known issues page seems like a pretty good indication that reserving Trac for developers and a few select community members is a good idea.

Thanks for your responses.

Dan, I'm in sympathy with the way you want to continue to use Trac, and with your reluctance to add new tools and the associated overhead. Thanks for your work, also and especially the work of keeping your energies from getting dissipated.

I do still suggest that it would help Zotero's users if each user idea which is (or in the course of discussion came to be) intelligently presented, received some kind of "processing on" from those with the authority to do so.

This would help users in two ways (1) Zotero users and potential users have their own commitments, and need to make good decisions about what tools to use as their project deadlines approach. For those that have fairly exacting requirements (and citation requirements do tend to migrate in that direction!), they need to be able to make good decisions about when and to what degree to migrate to Zotero. This includes knowledge about what manual workarounds might be required, and whether such workarounds will be required forever (for less mainstream problems or workflows, some may!). A "requested features" tool would help them see just what can and can't be done at any one point. (2) Quite apart from the development process itself, it is a big help to know that some feature request we came up with (researched, discussed, or wrote out details for) is part of some assembly line, and making its way (however slowly, with whatever setbacks) into the code. Or of course to know that it won't make the cut, or that it needs more discussion, research, or planning. We also have limited time and attention which we need to use effectively.

Noksagt asked " How do you perceive submitting a ticket to be different than making a forum post?"

As I said, I've (now) no problem if these things don't become Trac tickets. But if the question is, "What's wrong with forum posts for presenting feature requests?" I have an answer: 3 month old Trac tickets are still "live." A forum post which was a Good Idea (TM), but which never made it off the forums is dead to all but those who search for it. The users who worked on it have no satisfaction. In truth, the forums work great for *presenting* feature requests, it's just that in their present state, they're not that good for taking the lower-, medium- or long-term-priority items into the development flow.

Whatever the implications of this "forum fade" for development, it is a frustration for users. I'm glad to hear, Dan, that you're still able to read everything that's posted on the forums (it's more than I expected), and I'm sure you "could probably name off the top of your heads" many of the issues of the kind that I'm describing. But your mental horizon is much bigger than mine if you are really able to hold all the full set of decent development directions which emerge from the forums. (see a few small ones below)

I hesitate to give one of my own requests as an example, since this I'd rather the thread didn't get diverted by the (de)merits of one particular request, but I'll include it anyway in the interests of making the above a little more concrete:

One feature I need is the inclusion of a place for abbreviating Series Titles. In my field we need it. (For some reason, we're addicted to named series, and we cite them by abbreviation, except when crossing discipline boundaries, then they get spelled out in full.) Again, I pick this only because I know about it and can describe its lifespan on the forums, which went like this:

1. Sept 2007: Initial Request. (Bruce responds from the CSL side, but no word about the Zotero UI and database).
http://forums.zotero.org/discussion/1305/
2. Jan 2008: Second Request. New Thread.
http://forums.zotero.org/discussion/2047/
3. Jan 2008: Request by another user.
http://forums.zotero.org/discussion/2045/
4. April 2008: SBL style announced, and with it the line that "abbreviations for series titles...should be possible in 1.5" This is the first official word about series abbreviations, and comes from erazlogo.
http://forums.zotero.org/discussion/2655/society-of-biblical-literature-note-style
5. Jun 2008: Another user requests (see JB88's request in mid-thread)
http://forums.zotero.org/discussion/3211/
6. Sept: I request again, having not heard anything as the early 1.5s came out.
http://forums.zotero.org/discussion/3999/series-abbreviations/
7. Dec 2008. I bump thread
8. Feb 2009: Ticket created by erazlogo (same thread)

In the various threads, I had made what I thought was a pretty comprehensive justification for the feature. Again, it is more about the process rather than this particular non-sexy feature, but it was pretty frustrating not hear anything from the Zotero side for a year, and nothing concrete for 18 months. As it was I had to revisit the process repeatedly until finally a ticket was added. I don't think that I "deserve better" or that someone else is responsible for implimenting the features I want, but still.

Could this have been helped by some way to 'promote' (or demote) such a request? The main thing I would have wanted is, once it was established as a Reasonably Good Idea, it were out of my hands. Somewhat playfully, something like the following:

-------------------------------------------------------------
This is an autoresponse from the Zotero dev team. Your request sounds good to us. In fact it's now on This-Linked-List of stuff we know about and plan to get to. No breath holding, OK? But there it is. Discuss further here if you have anything to add. Bookmark this forum thread if you like. We'll post here when it's done.
------------------------------------------------------------

Note that the "Known Bugs" page already does something like this for bugs. Perhaps a minimal solution is just a "Requested Features" page, divided (or tagged) into "definitely planned" and "still in discussion" (and possibly others: "rejected", "an idea for an external utility" "we'd include it if someone else did the work.") This would be much more useful if it had links to relevant forum discussion, and (sez me) it would be most useful if it were made easy on developers. I.e. they could manipulate items between the categories, move things to Trac, link to and from the forums, etc.

Another example of a smaller feature request: Add series number to BibTeX export. I requested this a few weeks ago. Noksagt helpfully replied that it was a good idea. But I didn't really know where it would go from there. I asked her about it as far as it had to do with her, and she gave me a good answer, but that was still a user-to-user answer, which she made clear. It's a tiny thing, but because of that, it's pretty easy for it to slip through the cracks. Could it possibly be on the mental map of anyone besides noksagt and myself?

Link: http://forums.zotero.org/discussion/1302/export-bibtex-webpage-specific-fieldsinformation-missing/

Another example, just to round it out. Someone mentioned that it would be handy to have Zotero automatically run a postprocessor on BibTeX export (there's enough of a mismatch between the kinds and format of the data that Zotero holds and exports and what a native BibTeX database wants that systematic postprocessing is often required.) He uses bibtool for the job. The change is not non-controversial (perhaps), and I wouldn't feel at liberty to just add it to Trac (right?) but I think it's a Fine Idea. (He may have requested it elsewhere on the forums, I didn't check.)

Link: http://forums.zotero.org/discussion/6674/zotero-extra-bibtex-note-how-not-to-show/#Item_2

Can we do anything so that these kinds of things get addressed in a way that makes good use of the energy that users invest in discussing them, and is also helpful for the development process itself?