5 ms·

if someone from github is looking at this, can u please include Gitlab's "Scoped Labels" in this - https://docs.gitlab.com/ee/user/project/labels.html#scoped-la

if someone from github is looking at this, can u please include Gitlab's "Scoped Labels" in this - https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels https://docs.gitlab.com/ee/user/project/labels.html#scoped-l... it seems that the new issues are going to operate on the basis of labels (as it should). Scoped/Nested labels are a godsend. For example, I can tag an issue with a label "UI::App::Android" and i should be able to filter on the basis of "UI::App" and get all issues. One of the things i still notice about the boards is that it is created on the basis of status. Gitlab's boards are created on milestones/status...or LABELS. https://docs.gitlab.com/ee/user/project/issue_board.html#organization-of-topics https://docs.gitlab.com/ee/user/project/issue_board.html#org... Most importantly, dragging tickets across boards will change the labels. This is far more powerful than just hardcoding them on statuses.

bostonsre 5y ago
Why not just tag it with separate labels? For that example, tag it with ui, app, and android. Then search with ui and app labels?
- coffeemug 5y ago
  For the same reason you ever need hierarchies-- without scoped labels you end up with a confusing soup of labels that's very difficult to make sense of. And the more labels you get, the harder everything becomes.
  - bostonsre 5y ago
    hrm.. I guess I could see that being useful in some cases. It might make discovery a little harder for someone that doesn't know the hierarchy, but I could see that being useful for people that know the hierarchy in an org that has a massive amount of stuff to label. I guess I just like key/value tags better than labels to organize and filter through data. They seem a little more self explanatory and I think they obviate the need of a hierarchy in the tag key naming.
  - jayd16 5y ago
    "UI::App::Android" seems kind of odd to me, or at least its a poor example. Does this mean you can't search for "Android" and get all Android issues? Maybe I'm not understanding how it works? It seems like it would make sense as a way of name spacing. "Web::UI" and "Android::UI" would ensure an Android dev doesn't need to sort through all UI issues and all UI issues without a platform tag would also show up in a different search. Having the platform last seems strange to me, though.
    - sandGorgon 5y ago
      my apologies. Its the hardest thing in computer science - "Naming Things"
    - kungito 5y ago
      Yeah, often I get into a problem where I wanted to have a hierarchical tree to organize my things and then later I wanted to somehow connect nodes from different branches in some way. I guess you could always have `ui::app::android ui app android` if needed
isbadawi 5y ago
This seems to be covered by the new ability to extend issues with custom fields.
- sandGorgon 5y ago
  not really - u can have multiple labels for an issue. but one value for a custom field. that's why the scoped/hierarchical stuff start becoming powerful for issues. Gitlab had the right insight here.
  - deleted 5y ago
    [deleted]
Lorin 5y ago
Scoped labels are the primary thing keeping me on GitLab
swozey 5y ago
Wild, I just went through the pain of automating all my org labels today and it was a huge bummer to not have scoping. I'm doing "Type: $var" etc but I know it'll look terrible compared to scoping. Going from Gitlab to gh has been interesting. For anyone unfamiliar, example; https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issu...
neilv 5y ago
The custom scoped labels in GitLab are very nice, and I found great uses for them. I threw away all the default labels for now, and juggle just two custom sets of scoped labels: `urgency` and `kanban` (which column on the board). All `urgency` labels are color-coded (red, orange, green, blue), and also ordered (for when viewing in the Issues List, rather than on the Board). I was using only the `urgency` labels before I added the Board and `kanban`. `kanban` labels are all gray, and tie in with the Closed property of an Issue: non-Closed `kanban` labels can be `backlog`, `waiting`, `doing` (each of which have a Board column); Closed can be `done`, `abandoned`, `duplicate` (all of which are in the Closed column of the Board). I'm mostly liking this, though still missing Gantt models and views sometimes, even in very dynamic/agile/responsive/reactive tasking. For example, even just yesterday, a few Blocked-by relationships are not obvious on the Board, as they're piling up in the `kanban::waiting` column. (And finishing those tasks was an extra relief, so the Board was back to intelligible.)

bostonsre 5y ago

Why not just tag it with separate labels? For that example, tag it with ui, app, and android. Then search with ui and app labels?

coffeemug 5y ago
For the same reason you ever need hierarchies-- without scoped labels you end up with a confusing soup of labels that's very difficult to make sense of. And the more labels you get, the harder everything becomes.
- bostonsre 5y ago
  hrm.. I guess I could see that being useful in some cases. It might make discovery a little harder for someone that doesn't know the hierarchy, but I could see that being useful for people that know the hierarchy in an org that has a massive amount of stuff to label. I guess I just like key/value tags better than labels to organize and filter through data. They seem a little more self explanatory and I think they obviate the need of a hierarchy in the tag key naming.
- jayd16 5y ago
  "UI::App::Android" seems kind of odd to me, or at least its a poor example. Does this mean you can't search for "Android" and get all Android issues? Maybe I'm not understanding how it works? It seems like it would make sense as a way of name spacing. "Web::UI" and "Android::UI" would ensure an Android dev doesn't need to sort through all UI issues and all UI issues without a platform tag would also show up in a different search. Having the platform last seems strange to me, though.
  - sandGorgon 5y ago
    my apologies. Its the hardest thing in computer science - "Naming Things"
  - kungito 5y ago
    Yeah, often I get into a problem where I wanted to have a hierarchical tree to organize my things and then later I wanted to somehow connect nodes from different branches in some way. I guess you could always have `ui::app::android ui app android` if needed

isbadawi 5y ago

This seems to be covered by the new ability to extend issues with custom fields.

sandGorgon 5y ago
not really - u can have multiple labels for an issue. but one value for a custom field. that's why the scoped/hierarchical stuff start becoming powerful for issues. Gitlab had the right insight here.
- deleted 5y ago
  [deleted]

Lorin 5y ago

Scoped labels are the primary thing keeping me on GitLab

swozey 5y ago

Wild, I just went through the pain of automating all my org labels today and it was a huge bummer to not have scoping. I'm doing "Type: $var" etc but I know it'll look terrible compared to scoping. Going from Gitlab to gh has been interesting. For anyone unfamiliar, example; https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issu...

neilv 5y ago

The custom scoped labels in GitLab are very nice, and I found great uses for them. I threw away all the default labels for now, and juggle just two custom sets of scoped labels: `urgency` and `kanban` (which column on the board). All `urgency` labels are color-coded (red, orange, green, blue), and also ordered (for when viewing in the Issues List, rather than on the Board). I was using only the `urgency` labels before I added the Board and `kanban`. `kanban` labels are all gray, and tie in with the Closed property of an Issue: non-Closed `kanban` labels can be `backlog`, `waiting`, `doing` (each of which have a Board column); Closed can be `done`, `abandoned`, `duplicate` (all of which are in the Closed column of the Board). I'm mostly liking this, though still missing Gantt models and views sometimes, even in very dynamic/agile/responsive/reactive tasking. For example, even just yesterday, a few Blocked-by relationships are not obvious on the Board, as they're piling up in the `kanban::waiting` column. (And finishing those tasks was an extra relief, so the Board was back to intelligible.)