Project

General

Profile

Actions

Feature #3068

open

Generic task management (not issues)

Added by Matthew Dixon almost 15 years ago. Updated almost 2 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Translations
Target version:
-
Start date:
2009-03-28
Due date:
% Done:

0%

Estimated time:
Resolution:

Description

I'd like to suggest an addition which would make this excellent app useable in a much broader set of situations.

Issues -> Tasks.

There should be a per-project setting, what to actually call "issue" in that project. And, as a corollary, add a related option that tells what to call "tracker" there, too. (E.g. "task type", if "issue" is renamed to "task".)

If left empty, the generic names are used by default, as before. Otherwise, throughout the whole UI (including emails sent & documents generated for human reading), they are replaced with the terms given in the project settings. Ideally, corresponding system-wide settings could also be added, a) to optionally enable these project-level settings, and b) to set the defaults for every new project.

By allowing these more generic descriptions (and other types of trackers), suddenly the same project logic is understandable by people other than developers!

Although there are plenty of RoR task management applications (e.g. Tracks) none of them is a fully featured project manager like this (with features like file management, gantt charts, wiki etc).

And although there are project management apps on other platforms (e.g. ProjectFork on joomla) it would be great to have something on RoR.

Regards,
Matthew
(Updated as suggested by Szabolcs Szász)


Files

en-tasks.yml (27.4 KB) en-tasks.yml Matthew Dixon, 2009-03-29 14:08

Related issues

Related to Redmine - Feature #2082: Rename Issue as Ticket (or ...) in GUINew2008-10-24

Actions
Related to Redmine - Feature #4636: System-wide Object Label Settings and the general Open Pario MalaiseNew2010-01-22

Actions
Has duplicate Redmine - Feature #4568: Replace "Issue" for "Task"Closed2010-01-13

Actions
Has duplicate Redmine - Feature #4908: Change Issue for TaskClosed2010-02-23

Actions
Has duplicate Redmine - Feature #25561: Issues are not tasks: please split themReopened

Actions
Actions #1

Updated by Matthew Dixon almost 15 years ago

Hi,

I realised there's a very simple way to do this via the language file. I'm uploading a new English language file which I search and replaced so that it simply calls issues tasks.

Combine that with custom trackers and workflows, and the suggested feature is >90% done.

I'm not really anything on this project (apart from a fussy tester) so if someone thinks it's useful, please feel free to post it where where people can access it.

All the best,

Matt

Actions #2

Updated by Dipan Mehta almost 11 years ago

While this is possible through the locale file changes - it might still be not convenient for some organization where the admins do not prefer you to mess with the 'packaged' software.

It might be more desirable to have Application setting such as 'Label used for Issue'.

Actions #3

Updated by Dipan Mehta almost 11 years ago

Add related (duplicate) #4568, #4908

Actions #4

Updated by Daniel Felix almost 11 years ago

  • Category set to Translations

Added relation to #4568 (which duplicates this) and #4908 (also a duplicate).

Actions #5

Updated by Toshi MARUYAMA almost 11 years ago

Is this issue category Translation?

Japanese: チケット = ticket
source:tags/2.3.0/config/locales/ja.yml#L486
Traditional Chinese: 問題 = problem
source:tags/2.3.0/config/locales/zh-TW.yml#L575
Simplified Chinese: 问题 = problem
source:tags/2.3.0/config/locales/zh.yml#L450

Actions #6

Updated by Szabolcs Szasz almost 10 years ago

Excellent point!

NOTE: the actually used semantic content of the nicely generic term "issue" varies by project!

Thus, changing it globally on the system-level cannot be a real solution. Also, changing this in the translation layer is even more of a hack to workaround the missing option.

Also:

Please edit the issue description so as to also request an option for changing "Tracker", too! That term resonates with even less people than "issue" (not even developers in general). And changing it globally (to e.g. "Issue type") would be equally wrong, as the term "issue" and "tracker" would usually need to be changed together, in tandem.

Thanks, cheers!

Actions #7

Updated by Toshi MARUYAMA almost 10 years ago

Szabolcs Szasz wrote:

Please edit the issue description so as to also request an option for changing "Tracker", too!

Please post what should be added.

Actions #8

Updated by Szabolcs Szasz almost 10 years ago

Toshi MARUYAMA wrote:

Szabolcs Szasz wrote:

Please edit the issue description so as to also request an option for changing "Tracker", too!

Please post what should be added.

Thanks for watching, Toshi!

The original issue description says (among other things):

"There could even be a per project toggle setting, whether to call them issues or tasks!"

1. As (I figure) that is the main point, that should stand on a separate paragraph.

2. It should read: "There should be a per-project setting, what to actually call "issues" in that project."

3. And, to cover "Trackers", another sentence should be added, right next to it: "And, as a corollary, add a related option that tells what to call "tracker" in that project."

4. You might also add: "If empty, the current names are used by default. Otherwise, throughout the whole UI (including emails sent and documents generated for human reading), they are replaced with the terms given in the project settings. Ideally, corresponding system-wide settings could also be added, a) to optionally enable these project-level settings, and b) to set the defaults for every new project."

5. Break the rest of the text (from "By allowing this more generic description...") to a new paragraph.

(If you wish, I could also post a new issue, setting this as related -- but that would feel duplicating it, and may risk closing it by others.)

Thanks!
Sz.

Actions #9

Updated by Toshi MARUYAMA almost 10 years ago

Please post full description to replace for cut and paste.

Actions #10

Updated by Szabolcs Szasz almost 10 years ago

BTW, actually, it's an interesting question, how it relates/interferes with the translation layer.

1. This, in fact, appears to be a localization problem. However, not belonging to a given language (translation) or country locale, but to the "locale" of a problem domain.

2. Problem domains exist independently of languages, so this change must also be orthogonal to language translations. It should apply on a different level, being subject to language translations itself.

3. After all, this is actually subclassing: subclassing the generic Redmine tool to apply better to a specific problem domain.

4. As the issue (tracker) data models can already be customized ("subclassed") manually to fit a target domain, it is only natural to make it complete by allowing proper names to reflect those narrowed-down (customized) "issue" concepts better for the participants of that target problem domain.

Actions #11

Updated by Szabolcs Szasz almost 10 years ago

(Deleted by note-13 request)

Actions #12

Updated by Szabolcs Szasz almost 10 years ago

Toshi MARUYAMA wrote:

Please post full description to replace for cut and paste.

OK, here it goes (with further slight modifications):

----
I'd like to suggest an addition which would make this excellent app useable in a much broader set of situations.

Issues -> Tasks.

There should be a per-project setting, what to actually call "issue" in that project. And, as a corollary, add a related option that tells what to call "tracker" there, too. (E.g. "task type", if "issue" is renamed to "task".)

If left empty, the generic names are used by default, as before. Otherwise, throughout the whole UI (including emails sent & documents generated for human reading), they are replaced with the terms given in the project settings. Ideally, corresponding system-wide settings could also be added, a) to optionally enable these project-level settings, and b) to set the defaults for every new project.

By allowing these more generic descriptions (and other types of trackers), suddenly the same project logic is understandable by people other than developers!

Although there are plenty of RoR task management applications (e.g. Tracks) none of them is a fully featured project manager like this (with features like file management, gantt charts, wiki etc).

And although there are project management apps on other platforms (e.g. ProjectFork on joomla) it would be great to have something on RoR.

Regards,
Matthew
(Updated as suggested by Szabolcs Szász)

Actions #13

Updated by Szabolcs Szasz almost 10 years ago

(Please delete update 11! I thought I was editing it but accidentally posted a new one, sorry!)

Actions #14

Updated by Toshi MARUYAMA almost 10 years ago

Szabolcs Szasz wrote:

(Please delete update 11! I thought I was editing it but accidentally posted a new one, sorry!)

Done.

Actions #15

Updated by Toshi MARUYAMA almost 10 years ago

  • Description updated (diff)

Original description:


I'd like to suggest an addition which would make this excellent app useable in a much broader set of situations.

Issues -> Tasks.

There could even be a per project toggle setting, whether to call them issues or tasks! By allowing this more generic description (and other types of trackers), suddenly the same project logic is understandable by people other than developers!

Although there are plenty of RoR task management applications (e.g. Tracks) none of them is a fully featured project manager like this (with features like file management, gantt charts, wiki etc).

And although there are project management apps on other platforms (e.g. ProjectFork on joomla) it would be great to have something on RoR.

Regards,
Matthew

Actions #16

Updated by Toshi MARUYAMA almost 7 years ago

  • Has duplicate Feature #25561: Issues are not tasks: please split them added
Actions #17

Updated by cyril Thibout almost 7 years ago

Hi

I don't understand where is the actual status of this issue that has been published 8 years ago.

I'm in favor of renaming the current issues module as tasks module since it is connected to the Gantt which has nothing to do with issues / tickets. Even if we think differently we do need to separate issues that are mainly submitted by the end user , from tasks that are generally submitted by the internal staff.

This issues / task confusion is the source of most rebukes from our customers.

thanks a lot

cyril

Actions #18

Updated by Aleksandar Pavic over 3 years ago

+1

For native English speaking users (USA, Canada, and UK),
word issue carries bad meaning, usually connected towards personality problems.

So they immediately have bad attitude towards Redmine.

Preferably Issues should be renamed to tasks which carry meaning
that something should be done.

Thanks!

P.S.

Here is quick sed command to replace it on systems
where sed is available...

Just rename en.new.yml to en.yml after this command)...

sed -r 's/(^.*)\: Issue/\1\: Task/g' en.yml > en.new.yml

Or:
sed -i "s/\<issue\>/task/g" en.yml

sed -i "s/\<Issue\>/Task/g" en.yml

Actions #19

Updated by Aleksandar Pavic almost 2 years ago

Any news on this? Voting maybe?

Actions

Also available in: Atom PDF