Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dependencies UI / Terminology #6947

Open
bobemoe opened this issue May 14, 2019 · 2 comments
Open

Dependencies UI / Terminology #6947

bobemoe opened this issue May 14, 2019 · 2 comments
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first.

Comments

@bobemoe
Copy link
Contributor

bobemoe commented May 14, 2019

Great work over at #2531 seems to be functioning well, I've just got a few ideas for UI/Workflow tweaks. Although I completely understand the concept of the blocks/depends on relation, I find the UI, or terminology, confuses this for me a little. I'm often creating the relation the wrong way around.

Personally I would probably find the terminology parent/child less confusing, but I can see why we may prefer something more descriptive.

From within an issue, I can add a dependency. This sets the issue I'm in as the parent (blocker) and the issue I selected as the child (dependency). The issue then comes under the heading "depends on" on the parent issue, and the parent is shown under "blocks" on the child issue.

If I'm creating a child issue, I have to create the issue, then go to the parent, then add the dependency. When we have a big issue that needs to be split up this is not that convenient.

What also may be adding to the confusion is when you add/remove a dependency between issues a comment is added to both issues stating "user added/removed a dependency" however there is no difference between the message so it is impossible to tell which way the dependency is/was from the message alone.

Am I just missing something here? Or could we choose better terminology?

Suggestions:

  1. Consider consistent terminology. Not sure which to pick though!! :/
    Dependent / Depends / Depending / Dependency
    Blocks / Blocking / Blocker
    Parent / Child

  2. A "create sub issue" button on every issue that creates new issue with the parent already set.

  3. The ability to choose the direction of the dependency when its added, so it can be set from the issue, without having to first browse to the parent. This choice would then give a better indication of the direction through the terminology being side by side.

@bobemoe bobemoe changed the title Dependancies UI Dependencies UI / Terminology May 14, 2019
@lunny lunny added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label May 17, 2019
@funkyfuture
Copy link

that clear terminology must be found for all localizations. eg. the german translations uses "blockiert" which can be used both in active and passive sentences.

with regards to proposal 2. and the parent / child terms: i don't think they fit well for m:n relations.

maybe a tooltip that elaborates in a sentence on a relationship widget would be helpful too.

@wohenbushuang
Copy link

What also may be adding to the confusion is when you add/remove a dependency between issues a comment is added to both issues stating "user added/removed a dependency" however there is no difference between the message so it is impossible to tell which way the dependency is/was from the message alone.

Same problem to me, which with the same expression and icon, both in English and in Chinese. It made me suspect that this function is not working well for the first time, until I saw the side toolbar.

that clear terminology must be found for all localizations. eg. the german translations uses "blockiert" which can be used both in active and passive sentences.

I guess that just use the similar expressions in the side toolbar would be fine. @lunny

image

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Development

No branches or pull requests

4 participants