As usual, when you configure a system you need to customise it as much as possible to try and meet your own needs. I personally don't know of any guidelines or recommendations for Redmine per-se, however I can relate what we do here and I hope that will help you! :-)
Features/Bugs/Maintenance are just ways to label your tasks so that you can filter them. These are a specific label known as a "tracker" in Redmine. You can define your own trackers for additional types of task.
Project and Sub-Project are also effectively a way of labelling your tasks, but grouping them under a broader umbrella category. When you create 'projects', you assign the trackers you will need to them. In our case, we create an API, and have distinct trackers to identify bugs, features & modifications with (effectively) duplicated tracker names so that we can identify if the tasks are for desktop or dsp programmers. The sub-projects are used to identify product lines or customisations that our customers require specific support for. We also use version labels to identify specific releases in each subproject so that we can get a nice roadmap view of all of the tasks we are tracking. We have multiple projects in our Redmine system, each configured in a similar manner, with some project tasks linked across projects as "related" issues so that we can identify dependencies.
This is just one way to configure Redmine, but is the simplest we could manage given the complex relationships between some of our projects. It is the second configuration that we have tried and we find it works well. FYI, the first configuration was on a test system to allow us to work out what we needed from the system after migrating from Trac, a couple of years ago. The current configuration has been in use for about 2 years and seems to suit our needs nicely.
As I said earlier, you need to decide what you need from the system, but the simplest approach is to think about how you view a project from the top down, configure your system to match your processes, and not change your processes to match the tool - always the more 'disastrous' option IMHO. I wouldn't recommend tracking bugs and features etc in separate projects, as getting your roadmaps together is usually harder, and it also makes it harder to visualise the total task load for a given project. Even dividing task types into subprojects could be problematic, as it complicates things if you find you need to support multiple product release cycles, adding to your workload in terms of managing your Redmine system.
That's about all I can think of for now. I hope that helps you. :-)
The kind of tasks you mention seems to be what Redmine calls tracker. You can define your own trackers. In my opinion, you shouldn't need a sub-project for each "kind of task", but a tracker.
发布评论
评论（2）
与往常一样，当您配置系统时，您需要尽可能地对其进行自定义，以尝试满足您自己的需求。我个人不知道有关 Redmine 本身的任何指南或建议，但是我可以将我们在这里所做的事情联系起来，希望对您有所帮助！ :-)
功能/错误/维护只是标记任务的方法，以便您可以过滤它们。这些是 Redmine 中称为“跟踪器”的特定标签。您可以为其他类型的任务定义自己的跟踪器。
项目和子项目也是有效地标记任务的一种方式，但将它们分组在更广泛的类别下。创建“项目”时，您可以将所需的跟踪器分配给它们。在我们的例子中，我们创建了一个 API，并有不同的跟踪器来识别错误、功能和功能。使用（有效）重复的跟踪器名称进行修改，以便我们可以确定任务是针对桌面程序员还是针对 DSP 程序员。子项目用于识别客户需要特定支持的产品线或定制。我们还使用版本标签来标识每个子项目中的特定版本，以便我们可以获得我们正在跟踪的所有任务的良好路线图视图。我们的 Redmine 系统中有多个项目，每个项目都以类似的方式配置，其中一些项目任务作为“相关”问题在项目之间链接，以便我们可以识别依赖关系。
这只是配置 Redmine 的一种方法，但考虑到我们的一些项目之间的复杂关系，这是我们可以管理的最简单的方法。这是我们尝试过的第二种配置，我们发现它效果很好。仅供参考，第一个配置是在测试系统上进行的，以便我们能够在几年前从 Trac 迁移后确定系统需要什么。目前的配置已经使用了大约2年，似乎非常适合我们的需求。
正如我之前所说，您需要决定您需要从系统中获得什么，但最简单的方法是考虑如何自上而下地看待项目，配置您的系统以匹配您的流程，而不是更改您的流程以匹配您的流程。工具 - 恕我直言，总是更“灾难性”的选择。我不建议在单独的项目中跟踪错误和功能等，因为将路线图放在一起通常更困难，而且也更难可视化给定项目的总任务负载。即使将任务类型划分为子项目也可能会出现问题，因为如果您发现需要支持多个产品发布周期，这会增加管理 Redmine 系统的工作量，从而使事情变得复杂。
目前我能想到的就这么多了。我希望这对你有帮助。 :-)
As usual, when you configure a system you need to customise it as much as possible to try and meet your own needs. I personally don't know of any guidelines or recommendations for Redmine per-se, however I can relate what we do here and I hope that will help you! :-)
Features/Bugs/Maintenance are just ways to label your tasks so that you can filter them. These are a specific label known as a "tracker" in Redmine. You can define your own trackers for additional types of task.
Project and Sub-Project are also effectively a way of labelling your tasks, but grouping them under a broader umbrella category. When you create 'projects', you assign the trackers you will need to them. In our case, we create an API, and have distinct trackers to identify bugs, features & modifications with (effectively) duplicated tracker names so that we can identify if the tasks are for desktop or dsp programmers. The sub-projects are used to identify product lines or customisations that our customers require specific support for. We also use version labels to identify specific releases in each subproject so that we can get a nice roadmap view of all of the tasks we are tracking. We have multiple projects in our Redmine system, each configured in a similar manner, with some project tasks linked across projects as "related" issues so that we can identify dependencies.
This is just one way to configure Redmine, but is the simplest we could manage given the complex relationships between some of our projects. It is the second configuration that we have tried and we find it works well. FYI, the first configuration was on a test system to allow us to work out what we needed from the system after migrating from Trac, a couple of years ago. The current configuration has been in use for about 2 years and seems to suit our needs nicely.
As I said earlier, you need to decide what you need from the system, but the simplest approach is to think about how you view a project from the top down, configure your system to match your processes, and not change your processes to match the tool - always the more 'disastrous' option IMHO. I wouldn't recommend tracking bugs and features etc in separate projects, as getting your roadmaps together is usually harder, and it also makes it harder to visualise the total task load for a given project. Even dividing task types into subprojects could be problematic, as it complicates things if you find you need to support multiple product release cycles, adding to your workload in terms of managing your Redmine system.
That's about all I can think of for now. I hope that helps you. :-)
你提到的任务类型似乎就是Redmine所说的跟踪器。您可以定义自己的跟踪器。在我看来，您不应该为每种“任务”需要一个子项目，而是需要一个跟踪器。
The kind of tasks you mention seems to be what Redmine calls tracker. You can define your own trackers. In my opinion, you shouldn't need a sub-project for each "kind of task", but a tracker.