Hacker News Reader

Comment by sandGorgon | Hacker News Reader

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-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#org...

Most importantly, dragging tickets across boards will change the labels. This is far more powerful than just hardcoding them on statuses.

View on HN

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/-/issu...

Scoped labels are the primary thing keeping me on GitLab

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.)

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?

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.

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.

"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.

my apologies.

Its the hardest thing in computer science - "Naming Things"

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

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

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.

Reply on news.ycombinator.com