29 replies

1. Jan Lehnardt 4 min later

   @zachleat labels/tags never click for people, they want ontologies. Technically: no difference

   1. Zach Leatherman 8 min later

      @janl ugh. feels like complexity for complexity’s sake tbh

      1. Jesper Karsrud 2 days later

         @zachleat @janl I feel like this fits right into their direction lately. Replace things that work with something new that either doesn’t or has no now value 🫢

2. Zach Leatherman 5 min later

   At first I was excited that this might be a nice replacement for the closed issue needs-votes “Enhancement queue” we use in Eleventy (https://github.com/11ty/eleventy/issues?q=label%3Aneeds-votes+sort%3Areactions-%2B1-desc+label%3Aenhancement) but alas, it doesn’t seem like it

   1. Zach Leatherman 21 min later

      What I really want are issues to not be Open nor Closed but a third quantum physics style super-positioned state: Limbo

      1. Eric A. Meyer 22 min later

         @zachleat Open, Closed, and It’s Complicated

         1. Zach Leatherman 23 min later

            @Meyerweb exactly, yes.

      2. Max Fenton 32 min later

         @zachleat Icebox

         1. Zach Leatherman 45 min later

            @maxfenton 10 minute penalty, unnecessary roughness

      3. David O'Brien 42 min later

         Open / Closed / It depends ...

         @zachleat

   2. meduz' 21 min later

      @zachleat I don’t have a strong opinion on this, but it looks like one of GitHub move towards being perceived on the long run as a project management software for non-fev folks.

      1. Zach Leatherman 26 min later

         @meduz Makes sense. I think how they shipped this feature leaves a lot to be desired for existing orgs

3. Adam Stoddard 6 min later

   @zachleat key line: "shared and consistent language across all repositories in an organization"

   Means they can reliably build much more tailored reporting features that cut across repositories.

   1. Zach Leatherman 9 min later

      @aaadaaam but there are already controls for org-level labels — or do you mean this is a feature for GitHub at large (given they provided 3 defaults)

      1. Adam Stoddard 18 min later

         @zachleat the latter. Basically lets GitHub design and build more job-specific tools and interfaces. Labels are just too unreliable for that kind of stuff.

         1. Zach Leatherman 23 min later

            @aaadaaam I see, yeah — makes sense.

4. Jason Garber 7 min later

   @zachleat what if tags but categories

   1. Zach Leatherman 10 min later

      @jgarber same problem in 11ty versus wordpress 😅

5. Amelia Bellamy-Royds 1 hr later

   @zachleat There's certainly a benefit of a consistent labelling scheme across repos, so someone looking at a new-to-them issue list doesn't need to first learn a labelling taxonomy.

   Pulling the bug vs feature issue type to the front of the description also helps replace people's custom schemes of using an emoji to start an issue name.

   But I suspect the driving factor for GitHub may have been easier integration into their more complex project management features (milestones, versions, etc).

   1. Zach Leatherman 1 hr later

      @AmeliaBR I think you’re right! It’s hard (for me) to get on board with the feature for only those reasons though

      1. Litherum 2 hr later

         @zachleat @AmeliaBR

         There is value in custom labeling taxonomies, though. The standard names might not fit for a particular project.

         IMO I don’t think mixing two separate labeling systems - one standard and one custom - is necessarily a good thing

         1. Zach Leatherman 2 hr later

            @litherum @AmeliaBR for the record you can delete the default types or rename them to something else so in that regard I might classify both systems as more custom than standard?

            two of the three default types are also represented as default labels for new repos too 🤷‍♂️

            1. Amelia Bellamy-Royds 9 hr later

               @zachleat @litherum Huh. So they really are just super-labels, aren't they? 🤷🏻‍♀️

               1. Litherum 9 hr later

                  @AmeliaBR @zachleat

                  Having two independent customizable label systems seems worse to me than having one standard one and one custom one

                  1. Zach Leatherman 21 hr later

                     @litherum @AmeliaBR opinions are souring!! 😅

6. Anthony 23 hr later

   @zachleat My understanding is that they are defined at the organisation level while labels aren’t. So I’m remembering them as “organisation labels” and think that they are only useful for organisation managers.

   1. Zach Leatherman 23 hr later

      @anthony ah yeah — that’s not accurate! I’ve done that with the 11ty org: https://docs.github.com/en/organizations/managing-organization-settings/managing-default-labels-for-repositories-in-your-organization

      edit: though the word “new” is doing a lot of work in that doc so I think I see your point!

      1. Anthony 23 hr later

         @zachleat As a repo manager, I’m free to edit the list of labels that can be used. The org can provide a default list for new projects.

         But as a repo manager, I cannot edit the list of issue types.

         I think.

         1. Zach Leatherman 23 hr later

            @anthony yeah, that is a subtle but important difference!