We have recently added Backlogs to our Redmine and while for the most part we love it, it has a number of areas that are more intrusive than a plugin should be and have causes us some grief. I would suggest that a plugin should be adding functionality as opposed to removing or retasking existing functionality. In particular, the following:

Sprints using Versions was something of an annoying surprise. We already use versions for a variety of tasks and the sprints taking them over has caused some problems. We have worked around these by creating a shadow "Target XXX Version" for each project where XXX is the project name but this is quite annoying. Especially since we have had to make a variety of custom queries to do what we used to get for free from the "Roadmap" tab.
Tasks being issues with a "Task" tracker. This significantly pollutes our issue queries and displays. We would greatly prefer that tasks not be issues at all but be a separate type of object attached to the issues. Basically we have had to edit most of our custom queries to add an "if not Task" filter.
Issues having their priorities reset to the default priority is a major problem for us. And we haven't yet figured out a suitable workaround. So far the only thing we have managed to come up with is duplicating our issues before we drag them into a sprint hence converting them to stories. And we don't like that option either. Our essential problem is that our issue priorities are something that is set by sales and management, not by the development staff. Our default priority is "Unprioritised" and sales and management set the priorities based primarily on cost and customer input. At present there is significant concern that as soon as we drag an issue into a sprint it reverts to "Unprioritised" messing up a number of our regular reports. As mentioned we have not yet come up with a suitable workaround short of creating yet another shadow field. And if we don't we may be forced to stop using this plugin as there is a significant current investment in our present use of the priority field. This is probably our most significant problem right now. It is certainly the problem that is most visible to management.
Somewhat related to the previous item is that there does not appear to be any way to show the issue priority in the product backlog. This means that we have to keep a separate window open in our sprint planning so that we can find the higher priority items while determining which issues to include in the next sprint.
Another annoyance is that all issues that were sub-issues (i.e. had a parent) automatically became tasks when the parent was brought into the sprint. This struck us as a very poor assumption to make. What was worse was that we could not revert them back to "normal" issues but had to as an admin user delete them and manually re-enter them in order to restore our system. We have a workaround for this - namely we create an additional sub-issue to contain any tasks that would relate to the parent as a whole, and then we drag that sub-issue into the sprint. But this seems like another example of a very intrusive decision being made by this plugin.

Don't get me wrong. We love this plugin and it is the best agile plugin of those that we tested. However we would love to see the above items changes. Personally, if I had been creating an agile plugin I would have made a couple of significant design decisions differently. First I would not turn an issue into a story. And second I would not make a task a tracker. Rather I would have created new objects called stories and tasks and would have related them back to the original issue allow issue management and tracking to work as before but adding agile methodologies on top.

Just my 2 ct:

regarding 1: I totally agree. Since redmine versions are subject to various reports and so on using them as sprints distorts the whole redmine experience. I guess the folks here already do know that since this a point on the roadmap, see also #866. Personally I think the recently introduced release management functionality - which is good from a feature point of view - did make the situation worse, since a release should be what a redmine version is. But instead of modelling sprints as seperate objects, releases are. So the redmine roadmap is not of any use anymore (not to mention that various plugins also assume redmine versions to be what backlog releases are).
regarding 2: For us this does not impose major problems (beside query pollution). Instead this nicely integrates with different plugins and tools. E.g. I did manage development with eclipse mylyn and redmines mylyn plugins where it's handy to treat tasks as issues. That way mylyn just sees "issues" and is able to maintain context information and tracked time per task.
regarding 3: I argue you should promote your agile development method to your management. With scrum story priority is solely determined by the position within the backlog. For this the backlog plugin added another field to stories to allow for ordering. While planning the sprint you should drag tasks from the top of your backlog into the sprint. Maintaining another priority field is something not really compatible with scrum. Nevertheless, I consider the reset of the priority field as a bug on its own, since the backlogs plugin should simply ignore it. Also consider issue #997
regarding 4: see 3, Story priority is maintained via order.
regarding 5: again this is Scrum. There is no middle layer between stories and tasks. If you've got something bigger than a story it might be a so called Epic or Theme. Nevertheless you should participate in #979 for that request.

Regarding this whole issue: I'd prefer you tried finding existing tickets for your feedback instead of creating a new issue with several mainly unrelated suggestions. You should know that this is not the way issue tracking works, instead forums and mailing lists have been designed for discussions like that.

You are correct, I should have placed this into a forum. I will add some additional comments here, then in a short while I will close this issue and replace it with a few specific issues as mentioned at the bottom of this comment.

My main point with the intrusiveness is that agile development methodologies are exactly that - development methodologies and redmine can encompass much more than just the software development phase. In fact software development is only one part of a product's life cycle. In our company we use three different trackers - "Bug", "Feature Request", and "Internal Enhancement" to track the change requests in our software and these are the three trackers that we added as stories in backlogs. But we also use redmine for our project planning phases (trackers "Project Proposal", "Requirement", and "Constraint") and for the customer support phases (trackers "Problem Report", "Change Request", "Question", and "Support Activity"). These all tie into the software development. For example customer support will take the "Problem Report"s from customers and will create "Bug"s and "Feature Request"s based on them, but will leave them unprioritised. Sales and management decides on their importance and assigns them a priority of "Immediate" - implies the fix must be a patch sent to customers in short order which implies an interruption in our current sprint, "Urgent" - implies it should be included in the next project plan, "High" - it should be included in one of the next two project plans, "Normal" - is only included if time allows, and "Low" - will not be done unless other needs change its priority. This is all outside of the actual software development hence has nothing to do with the development methodology. (All the while the new issues raised are either child issues of the "Requirement" or related to issues of the "Problem Report"s allowing sales and management to track the progress of the various items without the details being visible by the customer.) This is what is choosing what is to be included in a release. From the agile point of view this is how development is to choose what will be included in the sprints that make up a release. And the backlog plugin "blew away" the priority field which is an important one in our overall process.

In addition, not every software process is an agile one. Our product includes both software and hardware. And the firmware that is developed for the hardware does not follow an agile process but something much closer to a cleanroom approach. It is important that the backlog plugin not interfere with the processes of that team. That is what I mean by it being intrusive.

In fact whenever I see a comment such as "you should promote your {idea/religion/policy/process} to {someone else}" I have to ask if the person making the comment is perhaps limiting their view to their particular part of the organization. At the very least "promoting" should not imply "forcing". Software development is not the only part of the story. Unless you are willing to work without being paid you also have to deal with cost management, customer requests, and yes, even office politics.

With that said, we have, since I raised this "issue", determined how we can use the plugin without it interfering with our overall product life cycle. We are going to do this in a couple of ways, and I wouldn't mind your comments if you think there are better ways we can do this.

First, our redmine projects follow a hierarchy that separates the project planning, software development, and customer support phases of the lifecycle. As part of this all the software products are sub-projects of a parent project called "Software". By turning on the sprint sharing and making the sprints in the overall "Software" project we can continue to use the "Target Version" field for its intended use - specifying the version that the issue is targeted for inclusion, and the "Roadmap" functionality should still work. The only restriction would be that developers must only drag issues into the "sprints" of the "Software" project and must ignore the "sprints" that backlogs creates for the "Target Versions" of the sub-projects. This also has the advantage that our developers only need to watch one task board that crosses multiple projects. (We still have to determine how we are going to manage separate teams - so far only one team is following this process but we will soon add a second team - and in particular how we will deal with developers who are on both teams. I suspect we will use separate sprints for each team and those (few) developers on both teams will have to monitor two task boards.)

Second, instead of including "Bug", "Feature Request", and "Internal Enhancement" issues as stories we will create a new tracker called "Story". And we will modify our practices so that when a given issue is targeted for a release (i.e. when we set the "Target Version") we will create a child issue of type "Story". Then only the "Story" issues will be included in the backlogs. In this way the backlogs plugin can change the "Priority" and "Target Version" fields to its heart's content without it affecting the original issue. (As an additional bonus this will also handle the case where a "Feature Request" would not fit in a single sprint - we will just create multiple "Story" issues for it.)

That said, it would be nicer if we could include our original issues as stories as most of the time an issue is small enough to fit in a sprint and having to make a shadow issue seems like extra overhead. To that end, I will shortly close this "issue" and add the following ones which would allow us to do that.

866 already deals with the version vs. sprint so I won't repeat it. (Our workaround using sharing will work but won't be necessary once this one has been completed.)

997 would be very nice, especially if any field including custom fields could be chosen for display. This is especially true in our case where an "Immediate" priority does not just mean do it first, but requires an interruption of the current process, and hence cannot be implied strictly by an ordering. For our process (and assuming #866 is completed) we would like to see both the priority and the target version in the backlog list.

My new requests (to be entered soon)...

The backlogs plugin should not change the priority of the overall issue. As you say the "priority" of a story is implied by its ordering in the sprint, hence it should not be wiping out the field, it should just be ignoring it. I would consider the current functionality to be a bug in the plugin.
Allow custom filters to be applied by default to the backlog page. Our "backlog" is huge because it currently shows every outstanding "Bug", "Feature Request", and "Internal Enhancement" in our system. We will work around that by creating the "Story" tracker and only including those in the backlog. But it would be better if we didn't need to do this (which we wouldn't if #866 was completed and if the priority field were not modified). In that case we would like to be able to define the "backlog" as being something along the lines of all the issues that have the target version set to one in a list (our upcoming releases) or have a priority of "High" or greater (even if not targeted). Basically we would like to define the filters that make up the "backlog" at any given point of time. (The default would be to list them all which is what current happens.)
The plugin should not assume that all child issues are Tasks. We use child issues for a number of things and having them changed to Tasks when we dragged the "Feature Request" into a sprint was rather annoying (and came as a surprise) and was quite time consuming to undo. Our plan to create a "Story" tracker will alleviate this but in general the fact that all tasks are child issues should not imply that all child issues are tasks. I would consider the current functionality to be a bug in the plugin.

I totally agree with all points you made. It's obviously up to the specific company how to apply scrum and in particular how to adapt it to fit into existing or otherwise required "conflicting" processes. Don't get me wrong - my company faced that, too. We've been choosing another way to cope with that, but I won't tell anybody this is the way to go.

In the end we agree on that the backlogs plugin should defensively accept as much as default redmine functionality as possible and make as less assumptions as possible about how it gets used.

I'm looking forward to positive discussions regarding the new issues you gonna create.

Looks like my first issue, and the most important one in my view, of the priority not being changed isn't an issue with this plugin at all but is an issue of redmine itself. The priority of a parent task is set to be the highest priority of all of its children. This is already logged as a defect in the redmine project but it looks like they have no current plans to fix it despite the rather large number of people who have commented that this functionality disallows them from using the child issues.

It looks like your original request 2:

Tasks being issues with a "Task" tracker. This significantly pollutes our issue queries and displays. We would greatly prefer that tasks not be issues at all but be a separate type of object attached to the issues. Basically we have had to edit most of our custom queries to add an "if not Task" filter.

And your updated request 3:

The plugin should not assume that all child issues are Tasks. We use child issues for a number of things and having them changed to Tasks when we dragged the "Feature Request" into a sprint was rather annoying (and came as a surprise) and was quite time consuming to undo. Our plan to create a "Story" tracker will alleviate this but in general the fact that all tasks are child issues should not imply that all child issues are tasks. I would consider the current functionality to be a bug in the plugin.

These are each requested in multiple other tickets, but it seems the main one for tracking the feature request is #184.

backlogs / redmine_backlogs

intrusive behaviour of the backlogs plugin #1068

866 already deals with the version vs. sprint so I won't repeat it. (Our workaround using sharing will work but won't be necessary once this one has been completed.)