Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
A lot of OS projects I know (I am PHP developer) uses versions as milestones, but is this the best way?
Should milestones mean something in process of project iterations (meaningfull names)?
Are there any rules? Or maybe its totally subjective?
Like the old adage goes, "The wonderful thing about standards are that there are so many to choose from." I can't tell you how I would do it for a PHP project, but I can tell you the approach that we use for our shop - which is a .NET shop.
We use a fairly traditional four-part versioning system, with each part of the version representing something different. For example:
Major.Minor.Revision.Build
Obviously, each of those would be a number. These four parts are, for us, preordained by Microsoft. Let me walk you backwards through the stack, as to how we justify each:
Build - Automatically incremented in our shop. This indicator is like a unique identifier for a build, as it is provided by the compiler.
Revision - We reserve this for a release that will not break compatibility. Exposed interfaces are preserved and third party implementations will presumably run intact without modifications.
Minor - This is a release that generally introduces new functionality, changes existing functionality, and runs a higher risk of breaking compatibility.
Major - Large scale changes that involve large rewrites, large new feature sets, and fundamentally deviate from the previous codebase.
Where do Milestones come in to play? They are project goals for us. Milestones are determined prior to project kickoff and represent points where an expected progress level should be met. It is largely used to introduce business users to functionality before a release and to monitor the overall delivery schedule of the release. We additionally apply a label in our version control for each milestone to help to easily identify the milestone if it needs to be manually built for any reason.
In our shop, the content of the milestone is more important than what it is called. Why? Complex milestones cannot be easily named in a way to convey meaning when there are multiple reasons that it is a milestone. We put milestones on the calendar and wiki with a description of what is expected to be achieved in it.
Like I mentioned earlier, I am sure that you will get some other "standards", as well. The goal is to find the process that works for you and your team, and to stick to it.
In our development process, versions and milestones are something different.
One of our standard milestones is the release. That has, of course, a version.
But to me, a milestone is somthing in the future, something that I have to plan for. A version is coupled to a release, so it is something that is in the past.
Our standard milestone scheme is based on a company wide project management standard. We have
S-Gate: Specified
A-Gate: Available
V-Gate: Verified
R-gate: Released
For iterative development, we basically repeat this cycle.
From A to V gate is the alpha phase, from V to R is beta phase. For bigger projects we add milestones that relate to specific feature sets being completed.
The reason we use it is mainly that all projects are reported according to this scheme, and it is always good practice to present information to the managament in a way they are familiar with ;-)
Well yes it means that you have completed enough work in the iterations to release something useful. A milestone generally means that you have acheived something of more significance than just the end of an iteration. I would use meaningful names yes.
You're talking about at least two unrelated things. There are source code control and project milestones. They're related, but they aren't the same thing. Plus, there's also software development work itself, which is related to source code and project milestones, but it's also different.
Here's an approach based on Scrum. It has three unrelated things which could be numbered or named.
First, there's the software development work.
We have sprints to build stuff. These can be numbered, but they usually have names. Names like "Bulk Loading Part 1", or "Refactor workbook library" or "Add Sales Demo Data Fixture" or things like that.
We have releases to release stuff. These could be numbered (based on the SVN revision, or based on our internal "compatibility version", but they usually have names. "First Release for Customer X", or "Bug Fix For This" or "Upgrade to That" or something meaningful.
Second, there's source code control. For this, we have some internal version/revision tracking that has little to do with sprints and releases.
SVN has repository version numbers. This increments with each checkin. Some weeks, there's a checkin every day. Some weeks, there's only a few "big" checkins.
We have a major.minor version number that we update manually to show compatibility. Some applications move from 1.1 to 1.2 because something small changed, but the database and the API's are the same. Other applications move from 2.3 to 3.1 because either the database or the API (or both) changed in some incompatible way and we need to do schema migration and possibly notify customer of changes to the REST client interface.
Third, there's project planning.
Our project planning milestones include our release schedule. However, the project milestones have include other things which have little to do with software. Milestones include things like "Signing the new hosting agreement", for example, or "Get Customer X Test Data". These aren't versions or releases or sprints or anything.
"Are there any rules?" Yes. Read up on Scrum for a good set of rules.
This is not a single thing. It's two (or three) things.
Version numbers are convenient because you can instantly take any two versions and see which one is the newer of the two. It is always going to be subjective to a degree, because who is to say what feature(s) or bug fix(es) constitutes a milestone?
The scheme I like is x.y.z where x is the major release number, y is the minor release number, and z is the build number. Major release would mean either a rewrite, overhaul, or major new functionality is introduced. Minor release would mean a significant bug fix, or number of small feature improvements or bug fixes. Build number would be precisely that - the number of builds.
Related
These are more high level questions, but our team is new to developing with APEX. We are currently a team of 3. We are using APEX 19.2, but are planning to upgrade up to 21.1
How do others handle the development flow, versioning, and releases of their projects when working in APEX?
We put majority of the business logic (validations, source sql, and process handling) in packages. So I feel it is pretty easy to version those files as they are outside of the APEX UI and can version in Git accordingly, but how do others version control all the APEX UI changes (pages, regions, items, DAs, etc...)?
I've searched and haven't really stumbled upon best practices of how teams, that use APEX, conduct their development process. One thing I'm nervous about is branching changes inside APEX UI. Sometimes we are given a requirement (say A) and we are asked to hold that release, but start working on requirement B. We may even release B before A gets final approval.
Are there any best practices, to ensure that developers working in the same workspace do not collide with others work? Luckily most of our project tasks do not overlap, but curious how others handle this
Any links or tips to this would be appreciated as we are new to APEX and trying to work these things out up front.
I'm probably not the right person to answer as my Apex team consists of 1 (one) member - me.
However:
We put majority of the business logic (validations, source sql, and process handling) in packages.
Me too, I found that to be the best option. Keep as little code on pages themselves as possible.
As of team development, did you read Managing the Application Life Cycle with Team Development?
Tracking Features might be particularly interesting for you. For example, it contains
Approval status of the feature. Indicates if the feature is to be implemented and the current progress.
which sounds like what you asked for.
I hope that someone - who really works in a team - will see your question and answer; I'd be interested in reading about their experiences and suggestions as well.
When we export application as zip , we can see there is folder structure. So in git we have to follow the same directory structure so it is easy to review and for versioning.
Thanks,
Nagaraju P
Let's say you have a bunch of code and let's assume that you have a first working version. This is version 1.0. You go to your git repository and tag the version. Then in that exact moment you have your first tag or release. Then you have in your code version number 1.0 and in your repository tag number 1.0.
My question is, when exactly do you change the version number in the code to version 1.1 (let's assume we don't care about 1.0.1):
A) do you change it right away after the tag 1.0 is done? Therefore all your code from this moment on belongs to version 1.1. This version "ends" when you create a new tag 1.1, which is the stable version 1.1 and change to version 1.2 in the code.
B) do you change it after you have done several code changes and publish your second tag (tag 1.1)? In that case you have a tag version 1.0 of the stable code and you are making improvements in the code. All new changes you do belong to version 1.0. Then when you are finished making changes, you change the code number to 1.1 and the tag number to 1.1
Nerdy question right ;-)
This is somewhat subjective but I would strongly suggest A. Branch out at a the time of release and start working in a new branch.
It's because your users are then in sync with where you left off in v1. If you introduce a number of features for the working v1.1 branch and possibly some design changes which kind of strongly branch away from v1, you can always come back to what the users are seeing by updating to the v1 branch.
Branching in this way based on release is useful as "checkpoints" based on what the users actually have, not based on what you intend to deliver. This way when a user reports something, you can easily know which version of the code they're actually using and quickly flick to it.
This also leaves some breathing room to do easy "service patches", like a v1.01. I know you wrote that you don't care about that, but if your users report an issue in v1 that you've already kind of solved in v1.1 or the v1.1 design has changed in a way to make it no longer valid, but you want to sneak some patch in between there, you can update to your v1 branch, make a minor tweak, and release a v1.01 service patch kind of thing. There's a bit more wiggle room there for that kind of thing.
As a hypothetical, imagine a user reports a glitch in v1. You can't reproduce it in your latest development branch. Now does the fact that you can't reproduce it in your current changeset mean it's fixed, or that you simply can't reproduce it? The easiest way to know for sure is to be able to quickly switch and use the same version you released to the user. That's where branching off and kind of freezing the branch at the time of release is useful.
Of course you could do that without branching or tagging at all if you just comment your changesets in a way such that you know which one is which. But then there's little point to tagging/branching in the context of a release. If you do it as an organizational means and a way of isolating changesets to one place, I'd suggest doing it in a way that keeps those branches in sync with what the users actually have.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
SHORT QUESTION
If you want to skip the details below, here's the short question:
I want to know if you keep your app's specifications similarly, in a bugtracker + a wiki and how do you split the information for good management. I look for a simple solution or just a point to start.
DETAILS
I need to keep track of the features for a web app that I want to build. So, I've used MediaWiki to gather a list of features.
For each feature, I have a wiki page where I include functional specs, technical specs and various related brainstormings in FreeMind format or plain text. Also, I include a series of open-questions related to it as TODOs and lots of images for various use cases. I found the wiki to be an excellent place where to keep all these.
I have a page in the wiki with all features transcluded manually so I can see them all in one page, in a specific format.
I also have a page in the wiki where I state what's the goal for v1.0, and a manually transcluded list of features for this version.
In the bug tracker(I use ClockingIT), I want to keep track of the tasks, bugs, etc. in order to build version 1.0 of the product.
ISSUE
Since I keep all features(well, the major features at least) in the wiki, I now feel the need to duplicate them in the bug tracker. Also, after brainstorming on V1.0, I realized there are many smaller features(that are too small to include in the wiki) that I'll need to keep track of in the bug tracker.
The problem is that I end up with 2 systems that will keep and manage the set of features and lots of duplicates will appear, like:
which features get in V1.0 -> this exists in the wiki as a page and the bugtracker keeps a milestone for this; moving a feature from v1.0 to another version, will mean to update both the bugtracker and the wiki
in the bugtracker I add comments as logs for what I do while working on the feature, so the wiki will get deprecated because some part of the brainstorming moves into the bugtracker
the wiki will tend to contain the major features while the bugtracker will contain minor features(like add a button to show/hide a section or something)...but the limit between major and minor features is very subjective and will tend to get messy so I'll have a hard time searching for a feature - I'll have to search in both wiki and bugtracker or I'll have to remember if it was a major or a minor feature
QUESTION
Since I need to keep the features in the wiki because it is an excellent tool for brainstorming, information keeping, etc. what should I include in the bugtracker? How can I efficiently separate these two tools' functionality so they integrate well with each-other and I don't get to duplicate any(or small amount of) data?
Thank you!
I use something mixed. On the wiki, there is a requirements page (among other pages), which describes the features and delivery data. Some features has separated topics where design/implementation details are explained. The requirements topic includes links to bugs with a short description of the bug/feature. Not all features are reflected as bugs. All bugs are listed in the current release section, if they are planned to be fixed in that release. A separated link goes to bug-tracking system to show all the bugs for the product (there are many products in the bug tracker). So:
all features, bug fixes are listed on the requirements page under a particular release;
bug tracking system contains bugs found during testing;
there is no exact definition which requests go to the bug tracker and which don't. An external reviewer may report feature requests as tickets in the bug tracker.
the key point is to keep all the requirements together and organized per release.
Maybe there are better ways to organize things, but this one is the simplest to me, and doesn't require lots of time.
You will need to customize for your needs but have you seen trac : http://trac.edgewall.org/.
This will serve many of your purpose. It combines bug tracker with wiki and other aspects.
Trac is an enhanced wiki and issue tracking system for software development projects. It provides an interface to Subversion (or other version control systems), an integrated Wiki and convenient reporting facilities.
I use Trac to track my bugs related to my php web application. Tough, mainly I register feature request/tasks in trac. Do you find it a good practice, btw?
It's very handy, becouse I can track my tasks via Eclipse/mylyn, comment and fix them. I like trac very much, but I'm afraid of a lot of loosley coupuled tasks, that almost looks like bugs.
Is there a way (or other tracker system) to store my tasks hierarchically? I mean:
Store module (feature)
Add product (feature)
List product (feature)
Delete product (feature)
Unable to delete no name product (Bug)
Other Module.. etc.
Edit: Is there any other good practice where and how to store tasks hierarchically?
Fogbugz has tasks & subtasks, I haven't worked with this feature enough to see if it would help though. You could play around with the hosted eval version, though. (For my taste, the web interface feels to sluggish for me to use it - but I have that problem with lots of things.)
I recognize your problem as one of my own, however I'd prefer to use separate lists/hierarchies.
[update]
At the moment, I am using the starring and heavy search/filtering, and for "keeping my head on" with quickly incoming tasks or larger refactors, I use pen&paper for temporaries (A5 ringbound booklet) and ToDoList for semi-permanents.
JIRA also has this functionality + it's almost free ($10 for 10 users).
See here, and here.
And yes... I think this is good practice, just don't over exploit it.
And this is how it looks like:
You could stick with Trac and look for desired functionality in http://trac-hacks.org/
That looks like what you want (there might be others I just did a fast search):
http://trac-hacks.org/wiki/MasterTicketsPlugin
http://trac-hacks.org/wiki/TracTicketDepgraphPlugin
We are using a couple of plugins from http://trac-hacks.org/ with 0.11 and they work great.
Have a look at the Roundup Issue Tracker.
Years ago, before Trac came out, I wrote several user support and development trackers with it. It's very, very easy to customize the database schema and create new html page templates.
To manage hierarchic tasks, you basically define an IssueClass-based task class that way:
task = IssueClass(db, "task",
dependson=Multilink("task"), # here, you link tasks to other tasks
assignedto=Link("user"),
keyword=Multilink("keyword"),
priority=Link("priority"),
status=Link("status"))
There's a recipe in the Roundup documentation that shows you how to create "blockers" issues, meaning that you can't close an issue if one of its linked issues is not closed:
http://www.roundup-tracker.org/docs/customizing.html#blocking-issues-that-depend-on-other-issues
TargetProcess supports the hierachical structure you want. It's an agile Software Project Management Software, however it features highly customizable development processes and can therefore be used for Waterfall or Kanban/Lean processes also. The deepest hierachical structure you can have goes like this:
Program
Project
Release
Feature
User Story
Task
There is a free community edition which you can use for up to 5 users. TP has a lot more than just task tracking, it features Bug Tracking, Q&A, Help Desk, Time Tracking...
You mind look at GoPlan: http://goplanapp.com/.
It is fully functional project management web application, which provides to create a hierarchy of tasks. There is a free plan, so You can check it easily. You can have task tree with any depth.
Difference between this tool and Trac is that GoPlan is not directed to maintain source code, but a project itself, so You cannot close Your tickets from Eclipse. Unfortunately tasks do not have resolutions (tickets have, but they cannot be arranged in hierarchy), but I think it is not a kind of disadvantage that discourages from using this application.
You've probably already thought of this, but I'll put this in just in case. In Trac, I oftentimes organized tickets as sub-tasks, at least through convention by simply placing links to those tickets in the description of the master ticket. What's nice about this is that closed tickets are shown as crossed out, so you can get an idea of the status of the sub-tickets at a glance. OK, so it's not setting up a hierarchy, but it's a flexible system that also allows you to set up other relationships; for example you can also reference another ticket as a dependency or related issue.
Some of the requirement management tools out there support hierachies, e.g. CaliberRM from Borland. However, these are heavyweight and commercial. This only makes sense if you have some significant amount of information to handle.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
What tips and "standards" do you use in your Redmine project management process?
Do you have a standard wiki insert template you could share or a standard way to work a project using bugs features tasks and support issues?
Do you let issues and updates get emailed into Redmine?
Do you use the forums?
Do you use SVN repository?
Do you use Mylyn in eclipse to work the task lists?
I'm trying to drag our dept. into some web based PM instead of emailed Word docs of vague requirements followed by Word docs explaining how to QA and Deploy that all get lost in a pile of competing updates and projects so that by the time I have to fix something, no one can find any documentation on how it works.
I develop and maintain internal applications for a family of manufacturing companies. As of the time of this comment, I'm the only developer/analyst on the IT team. During the worst of the recession my project demands exploded. As such my project AND issue backlog is quite unwieldy. We are currently in the process of restructuring to expand the team.
Here's how I use Redmine to keep my head straight (to the extent that is possible), my users at bay, and hopefully prevent too much hand-holding of new staff in the future.
I use Subversion for source control, with TortoiseSVN and the aptly named Tortoise-Redmine plugin. Refreshing the Repository on the Redmine project after a commit links the issue, which shows the revision on the issue, and updates my stakeholders via email notification.
I treat the project description as a means of communicating the project's purpose, scope, and lifecycle stage to those who are not involved. That way my users know what I've got on my plate, and what's still on the buffet that I'm eyeballing from a distance.
I use specific role names for my permission sets that indicate more than a set of permissions -- again, as a means of documentation. My roles include the following: Project Manager, Project Team Member, Owner, Primary User, Secondary User, Observer, Overlord (for my bosses...both fun and undeniably correct).
I use the Wiki and Documents for documentation, depending on which I feel is appropriate.
Versions are pretty much useless to me, so instead of using that for planned releases, I use it to group related issues into sprints.
I use Eric Davis's fabulous Stuff-To-Do plugin to organize/re-organize the aforementioned sprints before mass-editing the Target Versions on my issues. This also lets my stakeholders know what I'm working on and how I've prioritized their interests (for better or worse).
To encourage user interaction, I added links to the Redmine project into my applications' Help menus. The "About" box also contains a link to the Redmine project.
Future Plans
I hope at some point to finish my Visual Studio extension for Redmine integration.
Build a code library to loosely couple my application with its Redmine project: automate bug submission, alert subscribing stakeholders from system tray, reusable interactive Help menu driven by Redmine's REST API, etc. (Maybe automate portions of documentation with the Wiki?)
I'm a freelance Ruby and Redmine web developer who runs a development business of one (me). So my Redmine is setup to be pretty lightweight and customer focused. My Redmine also serves double duty for hosting my Open Source projects.
I do allow new issues and updates to be emailed and it works great for email connected users (or those who are always on their iPhones).
I've been using the repository view with git repositories and it's working great. With every checkin I reference the issue with #nnn so the actual issue page will show all the commits to implement the feature.
I found the forums are underused. I think if there was some email integration, they would be more useful.
We have found useful the following practices:
1) Hide "Issue" and "Support" tracker, and file everything as a bug:
time-saver for developers, testers, management;
if some activities are to be billed as "extra" or "new feature" or anything else, quick meetings are arranged to assess them.
2) milestones & versions
I love this, you can easily track down the status of each release and at any time you can download an older package, i.e. to test a bug filed by client.
3) "save" function on "issues" tab: another big time-saver, I have different queries saved for many day-to-day reporting tasks and that's all I need.
4) versioning integration, i.e. using "#123" in comments creates a link to corresponding issue: simply clever!
We use Redmine extensively on our system. We have even set up a "Sales" project for our sales team to use as a CRM. We have a heap of custom fields in this project, and it replaces SugarCRM which we were using before.
Within our system, we have projects for Server and Client software. Server project is broken up into submodules, based on how I have structured the system and sub-repositories, since Redmine likes a seperate repo per project.
We use, as others note, #nnn codes in commit messages to reference tickets. What is cool is that it needn't be a ticket in the same project. Thus, a sales ticket can be blocked by a bug issue, or a support request.
We have just started using Documents for agenda/minutes of meetings. We use Versions to group into releases, on both client and server.
To try to use Redmine Time Tracker plugin to track time, but I always forget to click start or end. We get daily emails about issues that haven't been touched in a while (Redmine Whining, I think), and that have due dates in the past or near future (Advanced Reminder).
Support emails go directly into our Support project, and if the email importing was a bit more robust (sometimes it doesn't create new tickets properly if the Project: line is included in the email), we would have website inquiries automatically generate Sales tickets. As it is, we just have to monitor Support tickets, and move them to Sales if applicable.
Things I would like to be able to do:
Have relationships between our system and redmine, so that tickets can be associated with a user or company in our system. Also, so that we can generate a new company from a Sales ticket at the relevant point. This just requires me to do some work.
Have a relationship between our error tracking software (sentry) and redmine, so that server errors generate a redmine ticket. Again, solvable with current technology.
Have a desktop client to redmine. The server is within our LAN, but being able to have a more flexible way to access the data other than the web page would be great. It's not that there is anything I can't really do in the redmine web interface, but something like Things.app is so much nicer to work in.
Have our support documentation all within redmine, and then generated out onto a public-facing server. That way, our support staff can maintain the documentation, edit in a nice way, and deploy changes out to doc-server.
Redmine has been fantastic for us so far. We use it as a multi-tenant ticketing/agile prioritization queue, and have tied it to SVN as well. In particular:
Installing/maintaining via SVN has been a breeze (I've migrated us from 1.1 to 1.2 to 1.3 to 1.4 via the use of svn switch https//.../branches/1.3-stable . commands followed by the rake migrate commands with only occasional gem installations needed in between).
Backups of the database and stored files is a one-line script execution
We love the Time Tracker and Spent Time plugins. I would kill for a Mac OS X time tracking fat client for some of our office users, but that's beside the point :)
We don't use the Forums much, but heavily use Activity and Roadmap. Tying issues to specific versions is a godsend.
We also have Client/Server distinctions, but use the target version to tie the tickets to specify which goes where (and have open ended NEXT CLIENT RELEASE/NEXT SERVER RELEASE) so as to distinguish between while being worked on.
We mix metaphors for statuses - we use our lists first grouped by these ("Immediate", "Rejected", "Blocked", "Working", "On Deck" "The List", "Waiting For Build", "Released To Test", "Verified", "Released to Production", "Closed", "Cancelled).
Then, within each group above, we have this sorted list of Priorities: ("Immediate", "Prioritize Me", "Design And Size Me", "P1"…"P5", "P-Watch List"). This plus the above allow for easy workflow all from the issues area.
For the basic issues list, we do sort by "Priority", "Parent Task", then "Updated Date" - need that middle one so that Redmine indents nicely should there be a child task in the same grouping.
We use checkin commits to tie commits to issues (i.e., svn ci -m "This fixes #1733 #2.5, holy smoke what a weird foo bug. It is now bacon and unicorns.") - and have it move that issue to "Waiting For Build" (That used to be "Resolved", but I got tired of explaining that "Resolved" did not mean someone can expect to see it released yet).
I think I will have to go investigate the Redmine-stuff-to-do plugin though. +1 Question.
My company works with software and hardware developers of international origin. Before I joined the company, email was used with MS Word documents to relay our issues and bugs with software or hardware to request a fix. This process was impossible to track and maintain any kind of process. I implemented RedMine as a means to track the software and hardware bugs and it's been working very well since. There is a major language barrier with my situation. Thankfully RedMine can display in Sipmlified Chinese language and feedback has shown that this is OK so far from my developers.
Status
- When I find a software or hardware issue, Status is "New"
- When my software/hardware developers have seen this issue and they are working on it, they change status to "In Progress." They can use the % done if they wish from 0 - 50. I have them set % Done to 50 when they feel they have resolved the issue.
- I determine if the issue is fixed, and I change Status to "Resolved" and % done to 100%. This allows me to filter out issues < or equal to 50% to find issues that are still open.
Priority
- Low, Normal, High, Urgent, Immediate all translates well into Chinese.
Due Date
- I use this to tell me when the fix was originally uploaded by my software developers. It may take me 4-6 days to test something and close the issue. I like my Gannt chart to reflect the responsiveness of my software team, not how long it took me to approve the fix.
Category
- This always reflects the version of software or hardware where I found the issue. I use this to see which version of software had the most amount of bugs, and to make sure newer versions of software do not suffer from regression.
I have everyone included on the RedMine watchers list for all bugs. The email comes across as (New), (Resolved), or (In Progress) so my supervisors, and the supervisors and head engineers of the teams involved can all see the email and quickly read what progress is currently being made. Most of the other people involved never login to RedMine, I'm typically the only one. The emails serve perfectly to give instant updates to everyone whose only concern is whether or not progress is being made.
As you mentioned sending Word documents back and forward with your QA - I know this feeling, been there, done that.
The main issue for me was: QA people don't like to add issues in any bug tracker, they note them down in an editor next to them during testing.
We are using Redmine now with a nice addon - Usersnap (Disclaimer: We built the tool to solve this problem for ourselves.
Usersnap is great for web developers - add it to your web project and you will get screenshots directly attached to Redmine tickets - including meta information about the used browser, operating system and so on.
Our QAs/customers can enter bugs now directly in the web application and the devs get easier to reproduce bug reports into Redmine.
We are using the Roadmap section as a clear way to display:
bugs
features (that would be references to your word document, or link to html requirement pages)
reconciliations (differences between production values and test values)
and so on...
That is the main point of consolidation for us. The rest is used in relation with that (for instance, the 'announce' section is used to define the main milestone/release dates used in the roadmap)
In addition to the other comments I recommend the use of the "Stuff To Do"-Plugin (written by Eric Davis I think :)
Using that plugin allows you to drag-and-drop sort the order of issues across multiple projects.
https://projects.littlestreamsoftware.com/projects/show/redmine-stuff-to-do
We use Versions as a way to define sprints, so each Version is a sprint with the Roadmap view giving a clear illustration of progress. Issues in sprints are marked as 'ready for review' when completed and then closed when QA has verified.
We use a Version as a backlog for any issues that fall out of scope or lose their priority etc.
We have been using Redmine for about a year now and it has evolved on its own in many ways. We use versions to group issues together for a release, and categories to group issues by discipline.
Each issue goes through a workflow of new > in progress > resolved. Then the tester will close the issue when happy.
We would love to update the way we use Redmine, there seems to be so many great plugins, but we find so many of them are broken or won't install.
We use the wiki comprehensively for developer documentation.