The project module is designed for software project management, but this issue tracking module could have more general audience.

The project module has a few fields that will just confuse general usage (like shortname). If this issue tracking module wants to gain more usage, then we need to remove the dependency to the Project module. (I have no idea how the two are linked at the moment, so this could be a big change.)

Comments

dww’s picture

dww
we/he/they
commented
Title: Decouple this module from Project module » Make the default project + project_issue install easy to use for non-software project management

I wholeheartedly support the goal of making project_issue more accessible to a wider audience. However, at some level, you're just perpetuating a stereotype that's not true. Yes, Project* was originally designed (and continues to be suitable) for software project management, but it's fully functional and suitable for general task tracking and project management, too.

Machine name could be generated automatically based on the human-readable name, but even regular task trackers need something like that (e.g. for sane URLs for your issue queue listings and searches).

I think a more appropriate feature request would either be:

A) Make the default project.module installation really easy to use for non-software project management

or:

B) Build an install profile that makes it all slick for you (e.g. make Project install more full-featured and useful)

But at this point, especially with the D7 re-write, I think project.module is still a useful thing, even for non-software project management, and I don't believe there's much more "decoupling" that's worth doing.

What do you think?

Thanks for the interest and suggestion!
-Derek

skyredwang’s picture

skyredwang
Location Shanghai
commented

For the "Project" Content Type created by the Project Module; we probably only need the "Enable issue tracker" option as default. All other presets: machine name, Components, Project type and Maintainers (project_release disabled) are "too much" for the default.

Here is an hypothetical example:

Office task management: They don't need the machine name, they need the components, they need hierarchical types (probably taxonomy, so they don't need the default Project type), and they don't need maintainers tab either. So, they probably want their own Content Type for the Project.

In conclusion, the current Project module has a lot of assumptions. Yes, I can make it work perfectly for a team of engineers, but not a team of mothers. Therefore, I suggest either make the Project do LESS, or decouple the Project issue tracking module from Project module; so at least the tracking module can become more general purpose orientated.