[HN Gopher] GitHub introduces sub-issues, issue types and advanc...
___________________________________________________________________
GitHub introduces sub-issues, issue types and advanced search
Author : julius-fx
Score : 305 points
Date : 2025-01-16 14:34 UTC (3 days ago)
(HTM) web link (github.blog)
(TXT) w3m dump (github.blog)
| grajaganDev wrote:
| Nice additions - Buganizer has had these for years.
|
| Good that issue types can be user defined.
| kkaatii wrote:
| The sub-issue structure seems much better than Jira's approach
| where everything has to fit into a hierarchy. Then it becomes
| hard to align on the definition of a certain level in the
| hierarchy.
|
| This create-a-subissue-when-needed way is more sensible.
| WorldMaker wrote:
| It's also not that different from what people have been using
| Task Lists for today: https://docs.github.com/en/get-
| started/writing-on-github/wor...
|
| I think that's maybe my biggest question is what the interop
| looks like between Task Lists and Sub-Issues. Is there a "one-
| click upgrade" yet? What if I want to copy a list of Sub-Issues
| as Markdown Task List to copy into a Discussion or a Wiki
| somewhere?
| trallnag wrote:
| You can use a single type of issue in Jira and just rely on
| linking them together
| kkaatii wrote:
| Wow i didn't know that.
| IshKebab wrote:
| Yeah we ended up doing this. You should basically never use
| Epics or Subtasks in Jira because they have weird unnecessary
| restrictions that don't apply to normal tasks, especially
| around putting them in sprints.
| Wicher wrote:
| Great, but I would've been happier if I'd had some dead simple
| dependency tracking 10 years ago. Just enough to create metabug
| functionality with. Like Bugzilla, Trac, Mantis etc have sported
| for at least two deades. I've always wondered why Github didn't
| have such basic functionality. (No, just the ability to reference
| other issues is not enough; I want to get an email for the
| metabug when all blocking issues are resolved).
| tw12312831 wrote:
| GitHub was better before MSFT took over. MSFT introduces
| bureaucratic fluff, hierarchies and loads of unnecessary
| complexities. How about adding a registry?
| shamiln wrote:
| What type of registry? GitHub packages?
| yallpendantools wrote:
| I would hazard a guess, more in the vein of the much-maligned
| "Windows Registry".
|
| https://en.wikipedia.org/wiki/Windows_Registry
| vivzkestrel wrote:
| also let people sort repositories by the ratio of open requests
| to closed requests, average amount of time to respond on an issue
| Calzifer wrote:
| Great, a few more decades and it might become a usable
| bugtracker.
|
| What's next on the list? Maybe priority/severity or
| status/resolution?
|
| I helped on a quite large open source project for some time and
| loved working with Bugzilla. The announced switch to Github for
| that project was one reason I lost interest. I even prefer to
| work with a well administrated(!) Jira over Github issues.
| StableAlkyne wrote:
| > Maybe priority/severity or status/resolution?
|
| That's already possible with the tag system. At least, that's
| the most common use I see for repos that decide to use tags.
|
| How do you envision this differing?
| akoboldfrying wrote:
| Are you thinking of labels?
|
| I only know GitHub "tags" to be the raw git branch-that-
| never-moves kind.
| ffsm8 wrote:
| Totally off topic, but Tags can be moved too. ;) It's
| mostly a convention that we use annotated tags (a tag that
| also creates a commit) and don't move them
| smarx007 wrote:
| Sorting by priority?
| chrisandchris wrote:
| Transitioned from Jira to Gitlab. Jira has workflows/resolution
| states. Gitlab only has tags.
|
| It's a different mindset and a different way to work. I'm not
| sure I'm happy with only-tags because it puts the work to the
| end-user (i regularly need to add tags because someone forgot
| to add it - could not happen with workflows and proper
| transitions).
| IshKebab wrote:
| > well administrated Jira
|
| Based on my experience that doesn't exist.
|
| Hell even if it did, Jira is sooooo unbelievably slow I would
| still take literally anything else. Maybe even Savannah.
|
| A colleague joked that we need a "waiting for Jira" Jira task.
| marginalia_nu wrote:
| I think 99% of the problems with Jira stem from trying to use
| it for too many things at the same time.
|
| If it's used for tracking issues, it's great.
|
| If a team just uses it for keeping track of its ongoing work,
| it ok.
|
| If the team also uses it to plan work, it works less well.
|
| If management also uses it to keep track of what the team is
| doing, it works even less well, because now the team needs to
| put on a show for management with the tool it needs to track
| and plan its work. Now issues need to be phrased in a way so
| that they aren't causing outsiders to worry. Maybe don't say
| "problem" or "bug" so often. Use an euphemism. Can't we word
| it in a less concerning way?
|
| If upper management has a dashboard of all departments'
| boards, you get nested Potemkin villages where the jira tasks
| are performative for both middle management, who in turn try
| to dress things up even more for upper management. At this
| point, the team (which still needs to track its issues and
| ongoing work) likely has a secret second issue tracker via
| post-it notes on a door somewhere.
| rplnt wrote:
| I believe Apple silicon has Jira coprocessor. It really
| became usable on M1 and beyond. Even the horrid UX got
| somehow better in the last few years (like not having 3+
| different text inputs, each with different formatting
| behavior). My guess is since the hardware caught up with them
| they can now finally use it and iterate.
| jonpurdy wrote:
| You jest, but I tested this and it turns out that it was
| JavaScript, not slow networking, that made Jira so slow for
| me. (I was trying to figure out how to locally cache assets
| to speed it up.)
|
| The M-series single-core speeds were so much faster than
| Intel at the time that it was noticeably faster.
| aklemm wrote:
| "Apple silicon has Jira coprocessor" time to retire to the
| country and raise chickens.
| hadrien01 wrote:
| A well administered JIRA can be really fast. There's a reason
| Atlassian themselves don't use JIRA Cloud:
| https://jira.atlassian.com/browse
| originalvichy wrote:
| My guess is that self-hosted versions have an infinitely
| simpler user experience when it comes to accounts and
| visibility. Jira Cloud is definitely angled towards always
| being behind some sort of an account system, which used a
| real, costly backend, but the self-hosted one can get by
| with the local hosted IdP or an LDAP server.
| IshKebab wrote:
| Huh that is much faster than Jira Cloud. How come though?
| Do they just hate their customers or something?
| tetha wrote:
| I don't have practical experience with JIRA Cloud
| Operations, or JIRA on-prem operations, but if I compare
| on-prem vs SaaS of our own solutions, the answer is scale
| and focus.
|
| If I combine our three internal ticketing systems, we end
| up with something like 200k - 300k tickets, with maybe up
| to 5M comments on those in JIRA-Terms. If you throw a
| small-ish, decently configured postgres with 8GB - 16GB
| of memory at it, it'll keep most to all of that in memory
| at all times, indexes will be analyzed and fine-tuned to
| your specific dataset. It will answer queries very, very
| fast. Any cache in the application servers will also be
| primed with your data 24/7, speeding it up even further.
|
| JIRA Cloud is most likely not an in-memory problem as a
| whole at a database layer, so it is at quite the
| disadvantage performance wise for a small customer.
|
| (In case this turns into a SaaS-Hate-Thread: Yes our
| customers could have a faster system if they were on-
| prem. If they had the same experience and expertise
| running postgres as well as all the other necessary
| middlewares. And then we're not talking about non-
| functional operational requirements such as availability,
| emergency scalability or backups yet)
| dotancohen wrote:
| Take a look at Redmine. It's a self-hosted Ruby project
| manager and I love it, especially for issue dependencies.
| IshKebab wrote:
| Nobody who uses Jira is really in a position to pick
| anything else.
| lukeforehand wrote:
| Even years ago Jira was too complicated, to the point that we
| joked about replacing it with a physical notebook.
|
| https://thedailywtf.com/images/200802/manualJira.jpg
| badgersnake wrote:
| Indeed, see https://ifuckinghatejira.com/
| treyd wrote:
| Yeah I have no confidences in GH to become viable for issue
| management for large commercial projects.
|
| It works fine if you're a group of highly competent and aligned
| FOSS developers that need it more as a communication tool than
| a work management tool. But if you get to breaking work down to
| the level of a few story points it becomes completely
| unmanageable. The table view turns into a slog if you have more
| than like 70 tickets.
| rbetts wrote:
| Using Github issues as a manager of multiple teams using
| multiple repos in GitHub has so many gaps, I often wonder if
| I'm just doing it wrong. The multi-repo issues feature a few
| years back was a huge step forward but also is very incomplete,
| still. Multi-repo labels and milestones, for example, are an
| obvious missing feature.
| lmeyerov wrote:
| Exactly this, they are so close!
| sangeeth96 wrote:
| I really feel like GH needs to spin out Projects into a more
| dedicated, funded team while still maintaining a close sync in
| order for it to become more viable/interesting. Besides
| allowing it to grow faster and better, that should also allow
| for non-dev seat pricing.
| bastardoperator wrote:
| They're called issue labels, go read up because your complaint
| isn't valid.
| bnewman85 wrote:
| Let us comment on the commit messages and create a better UI for
| editing messages for teams that take git history seriously,
| please. Are there no linux kernel devs at msft who can make this
| happen?
| atq2119 wrote:
| In the same vein, better reviewability of series of commits.
| It's absolutely baffling to me that GitHub still doesn't
| support the original workflow for Git.
| decide1000 wrote:
| I am not sure if I am going to like this feature. I miss the
| simplicity. Guess those times re over.
| captn3m0 wrote:
| I'm remembering the Redmine slide from Zach Holman's talk,
| where he makes fun of the overly complicated Redmine issue
| creation screen, compared to what the GitHub screen looked like
| (back in 2011).
|
| Slides 56 and 57 at https://speakerdeck.com/holman/how-github-
| uses-github-to-bui...
| dacryn wrote:
| same here.
|
| I guess it's Microsoft slowly making it cater to their
| enterprise clients
| foepys wrote:
| Microsoft is getting ready to replace Azure DevOps with
| GitHub.
| alternatex wrote:
| This is fiction considering Microsoft is extensively using
| Azure DevOps internally and is still developing it. Moving
| projects away from it and to GitHub is impossible because
| they're incredibly far from having feature parity.
| ciberado wrote:
| Feature parity is probably not required as long as the
| different teams are able to adapt their workflow to
| GitHub's approach. Anecdotally, every employee from
| Microsoft I've talk to about this point during the last
| two years keep telling me that ADO is over.
| stackskipton wrote:
| Feature parity is absolutely required. We are ADO
| customer because A) Inertia and B) GH Actions is nowhere
| close to features of ADO Pipelines.
|
| Every conversation we have with Microsoft about our ADO
| -> GH migration is either get GH to feature party or if
| you force us to migrate, we will evaluate ALL our
| options.
| zo1 wrote:
| People have been saying this for half a decade, and
| fearmongering everyone into moving elsewhere (sadly my team
| fell for it).
|
| Azure Devops is such an underrated tool, it's a shame that
| it's being ignored by Microsoft. Not only that, but they're
| enshittifying it by turning into Github. I kid you not, it
| actually went backwards in terms of features. E.g. Instead
| of nifty UIs that was implemented for their pipelines, we
| now instead have to write shitty yaml files with absolutely
| no validation and guidance. This is the same company that
| (re)wrote Word, Excel and Powerpoint in the browser! The
| mental whiplash from witnessing this is very jarring.
| Gigachad wrote:
| I can handle these 3 changes but if they take it any further
| it's going the way of jira..
| globular-toast wrote:
| That's not how it works. It _is_ going the way of Jira. What
| you mean is if it keeps going that way it will _be_ Jira.
|
| Until we get to the point we can decide things are finished
| and move on to other problems, everything will turn into Jira
| eventually. It's like entropy. We have the power to stop it,
| but it wouldn't guarantee those sweet, sweet growth targets.
| voidfunc wrote:
| The problem is Microsoft has two products in this space but
| everyone hates Azure DevOps which is supposed to be a JIRA
| competitor and GitHub is where all the momentum is. They'd
| love to ditch having to maintain ADO and GitHub long term
| but that means crapifying GitHub so they can migrate their
| ADO customers. At the same time they're hoping to pull
| Atlassian customers that use JIRA and GitHub to ditch the
| latter and just entirely be on GitHub.
|
| What well end up with is a service that sucks to use for
| all cases.
| SSLy wrote:
| ditch the former?
| ronnier wrote:
| I really dislike the use of former and latter. It's
| confusing, people get it wrong, and it can be interpreted
| at least two different ways to make it ambiguous.
| layer8 wrote:
| I agree that it tends to add cognitive overhead that
| could be avoided, but I don't see the ambiguity.
| cratermoon wrote:
| ADO almost made me want to use Jira instead. Turned out
| that, while the product it not great, the pain I
| experienced using it had more to do with corporate
| processes than the software itself.
| xpe wrote:
| Lots of ideas above, rather speculative.
|
| Overall, the claim above, as written, is a rather
| generalized prediction, not an inevitability.
|
| Enterprise buying power and expectations create various
| pressures, sure. But there are other pressures and factors
| that need to be accounted for such as demands from other
| types of customers and the company's expertise with what
| has worked well so far (simpler is better, compared to
| Jira).
|
| Entropy is a law of physics, sure, but the ways and degrees
| to which it manifests in software is far from obvious or
| inevitable.
|
| We live in a world of possible future scenarios, not of
| narrative-based certainties.
|
| I predict GitHub Issues will remain considerably simpler
| than Jira for the next five years at least. As code
| analysis tools improve (traditional static analysis as well
| as LLM-based), I think we will see a lot of experimentation
| in this space.
| jonpurdy wrote:
| It is less simple, but nowhere Jira-level, and yet still more
| useful (for my team and I).
|
| We've been using GH Projects at my current org and program for
| two years. The one feature I wish it had was nested issues.
|
| In Jira, you had Epic > Task > Sub-task and that's it. With GH,
| you can just have issue > issue > issue (insert "it's
| turtles/issues all the day down meme"). So it's more powerful,
| but can be ignored by folks who don't want to do this.
| renegade-otter wrote:
| GitHub is free for most people, so they are only beholden to
| large organizations and their feature requests. This is how it
| seems now - a feature creep by committee. It's getting more and
| more bloated and unwieldy, sort of like what happened to AWS.
| whataguy wrote:
| They also changed the design of issue comments, but seemingly
| reverted it back to the old design in production? (If you check
| the first video on the blog you can see e.g. the profile picture
| inside of the comment, while the old and current version has it
| on the outside.)
| eviks wrote:
| > This means there are no new UI patterns to slow you down,
|
| Sure there are, it's a common UI design mistake - you can't do
| advanced without breaking the basics: previously you could filter
| your issues with a drop-down filter in 2 clicks. The PR tab still
| has this (inconsistency) while the new issue requires a worse and
| longer path that uses a typed field, bringing up you phone
| keyboard as a downside
| maeil wrote:
| Longer paths, especially ones like these that require keyboard
| input, are especially painful from an accessibility
| perspective, where for most cases such typed fields make things
| take exponentially longer than if it can be achieved by just
| clicks/tabs/arrows.
| prymitive wrote:
| There is a huge wall of placeholder being replaced with issues
| when the issues tab loads, which is pretty annoying when you got
| used to the old UI. But it's nice to see M$ can still deliver
| features without Autocomplete Integration forced in it.
| Springtime wrote:
| It's neat there are more options for filtering though ime the new
| issues UI is less responsive, showing placeholder skeletons more
| frequently than I'd like. Perhaps less noticeable when a fast
| connection is always available but even just showing the total
| Open/Closed ticket counters can take a few seconds when it used
| to be instant.
| stock_toaster wrote:
| From Copilot integration that you can't disable if you
| accidentally clicked something once (you can only now as of a few
| days ago hide the UI, but you are still not able to disable it in
| settings), to this issues UI aglomeration.
|
| The Microsoftization/enshittification of Github continues apace.
| paradox460 wrote:
| Not bad, but I still have to say that zenhub does it better
|
| Used that at an old job and it was the only project management
| software I didn't grow to hate. Fast, "built into" GitHub, and
| adds other value across the site, I miss it now at my current
| jira gig
| hamandcheese wrote:
| Big +1, I used zenhub at one of my first jobs and I miss it to
| this day.
| politelemon wrote:
| The issue types are similar to labels. I wonder why they didn't
| build on that.
| isodev wrote:
| In other words, GitHub introduces "endless discussions if we're
| going to use subtasks or sub-issues in our WoW"
| Nuzzerino wrote:
| That's a leadership issue
| Y-bar wrote:
| And even then it affects us all and distracts us from the
| work we actually want to do.
| polycaster wrote:
| I've been waiting so long for this. Finally, we can have Epics
| that are not a pain in the ass!
| shiomiru wrote:
| So that's why they broke loading issue comments without JS. As if
| the (post-M$) UI hadn't been sluggish enough before...
| weinzierl wrote:
| I, for my part, would be happy if they could make basic search
| work for a start. Will the advanced search finally allow us to
| find the most basic things reliably?
| edflsafoiewq wrote:
| What doesn't work?
| weinzierl wrote:
| If you search code for a string you know is there it is
| completely git or miss if it is found. Always has been like
| that.
|
| Also see https://news.ycombinator.com/item?id=35144250
| edflsafoiewq wrote:
| I assumed you were talking about issue search, since that's
| what the thread is about.
| idunnoman1222 wrote:
| Oh yeah, where on the Internet does this work
| reliably?please don't say gitlab
| maeil wrote:
| Sourcegraph.
| trollbridge wrote:
| grep -rli search_this some-repo # (or use rg if you
| prefer)
| idunnoman1222 wrote:
| Holy shit what a good idea why doesn't GitHub just let
| you use ripgrep?!?!?
| edflsafoiewq wrote:
| Too expensive I assume.
| zb3 wrote:
| Sorting code search results by date.
| hamandcheese wrote:
| A GitHub feature I think would be really handy is suggesting
| duplicate issues when writing up a new issues. Many projects ask
| that you search for already reported tickets, but GitHub's
| current search isn't great if you aren't sure what you are
| looking for.
| hnlmorg wrote:
| Completely agree with this suggestion.
|
| Ive often wondered why GitHub hasn't introduced this feature
| because it feels like a really obvious thing to introduce and
| something that would add an immense amount of value to a lot of
| projects.
| sethops1 wrote:
| Cynical answer: because having users writeup duplicate issues
| and then having maintainers close them is more engagement
| than warding off unnecessary toil. Gotta keep those metrics
| going up and to the right.
| rafram wrote:
| GitHub doesn't have ads and makes its money off of
| enterprise subscriptions (and Copilot), so I don't think
| "engagement" is a very important metric for them.
| ysavir wrote:
| To the company, no. But to people trying to get a
| promotion/bigger budgets by proving the features they
| work on are getting a lot of usage, plausible.
| drdaeman wrote:
| > To the company, no.
|
| Why not? Companies love to boast about MAUs and similar
| metrics (even if completely bogus), it has good effect on
| stock prices.
| that_guy_iain wrote:
| I suspect it's more to do with issue management isn't their
| core product so doesn't get the same attention an issue
| management system would give it.
| mort96 wrote:
| Wait if it's not their core product, what _is_? GitHub
| is, at its core, a file /history browser + issue
| management system + merge request system built around
| Git. There's not that much to it _other than_ issue
| management.
| that_guy_iain wrote:
| It's core product is git hosting, you use it to host your
| git repositories. You use features such as Pull Requests
| to power how you merge within your git repositories. If
| the issue system isn't working it's not a big deal, but
| if we can't use git it's a massive deal. It's all in the
| name GIThub
|
| Most companies don't use GitHub's issue management system
| they use issue management tools such as JIRA, Trello,
| etc. Issue management, project management, CI/Actions,
| wiki, discussions, etc are all nice to haves and are
| probably more aimed at the open source projects that are
| used as a marketing tool.
| alexpovel wrote:
| Agree!
|
| For fun, I had put together a GitHub bot for this purpose a
| while ago. It indexes all existing issues in a repo, creates
| embeddings and stores them in a vector DB. When a new issue is
| created, the bot comments with the 3 most similar, existing
| issues, from vector similarity.
|
| In theory, that empowers users to close their own issues
| without maintainer intervention, provided an existing & solved
| issue covers their use case. In practice, the project never
| made it past PoC.
|
| The mechanism works okay, but I've found available (cheap)
| embedding models to not be powerful enough. For GitHub,
| technology-wise, it should be easy to implement though.
|
| https://github.com/alexpovel/issuedigger
| Sytten wrote:
| We made a similar thing too for our community discord where
| you can add an Emoji on a message and it will look for
| similar issues with a simple RAG. That saves us so much time
| when a user asks if a feature is planned or not. We also ask
| them to go upvote the issue or create one in the response.
|
| Not open source right now but if people are interested I
| could clean up the code.
| smarx007 wrote:
| Microsoft seems to use a similar bot themselves, not sure how
| it is called or whether it is OSS:
| https://github.com/microsoft/winget-
| cli/issues/4765#issuecom...
| alexpovel wrote:
| Oh yeah, that looks super similar. I remember the
| similarity score being tricky to get useful signal out of,
| for the underlying model I had used back then. Similar and
| dissimilar issues all hovered around the 0.80 mark. But
| surely not hard to improve on, with larger models and
| possibly higher-dimension vectors.
| mort96 wrote:
| If only Microsoft was interested in finding actual useful
| use-cases for their machine learning tech instead of
| constantly selling everyone on their chat bot...
| Sytten wrote:
| Ideally there should even be an API for it so we can use it in
| other systems like slack/discord bots when people suggest
| improvements.
| grajaganDev wrote:
| Meta and Google have this in their internal systems.
| rukshn wrote:
| I was also having some frustration in navigating GitHub issues.
|
| So I wrote a simple app for fun to navigate and search GitHub
| issues like emails and even reply
|
| Screen recoding
| https://x.com/justruky/status/1878507719520387347
| anon7000 wrote:
| It definitely had something like this at least in beta within
| the last couple years, or maybe just based on the title.
|
| But you're completely right, GH search is truly bad
| ruraljuror wrote:
| Good suggestion! Sounds similar to what stack overflow does
| when asking a question.
| tommoor wrote:
| Linear (linear.app) does this FWIW build on vector search,
| we're actively working on making it more accurate too
| joshSzep wrote:
| this happens after I've moved everything to height. downside is
| it was a lot of work. upside is height is amazing and I'm pleased
| with the choice. anyone else using it?
| mg74 wrote:
| what is height?
| matt_kantor wrote:
| Maybe this? https://height.app/
| quesera wrote:
| > _anyone else using it?_
|
| We're looking for a new home, with Pivotal Tracker shutting
| down on April 30th (101 days left!). I had not heard of Height
| before.
|
| On first glance, it looks like a genuinely modern project
| management service -- which is both interesting and unsettling.
| joshSzep wrote:
| We are loving it and we aren't even using it fully to its
| ability. For example we do almost no communication in the
| 'chat' that exists for each issue (in place of comments)
| since we are a very small team and still are talking mostly
| in slack about the issues, but I predict as we grow this will
| become a useful feature for us.
|
| In the meantime we are loving the 'every issue can have sub-
| issues' and have customized the fields to our liking.
|
| This is a tool with a lot of power. I can see a well-
| intentioned PM going crazy with it, but for our needs I was
| startled with how great it is.
| zb3 wrote:
| Bring back sorting code search results by date!
|
| https://github.com/orgs/community/discussions/52932
| shpx wrote:
| Instead of these features I want them to stop spam issues on my
| repos. All the issues I've gotten in the last year on my project
| are completely nonsensical. It's not even spam it's just like
| random URLs or complete nonsense from freshly created accounts
| that aren't trying to sell anything or just the issue template.
| And every time it costs me 2 clicks to click on "report" then I
| have to type "spam", click the spam category, then I have to type
| "it's spammmmmmmmmmmmmmmmmmmmmm" to hit the 15 character report
| description requirement, then I have to solve a captcha. All this
| despite the fact that I've had a GitHub account for like a decade
| and I've filed like 30+ spam reports, none of which were
| frivolous.
|
| I opened GitHub after typing this comment and there it was, a
| notification from an obvious bot account opening an issues that's
| just 5 meaningless Korean letters with no description.
| bsmth wrote:
| It might be worth trying the moderation tools that prevent
| interactions from accounts less than 24 hours old. Docs here
| https://docs.github.com/en/communities/moderating-comments-a...
|
| I share your frustration with this, and in my experience a lot
| of noise comes from these types of accounts.
| javier2 wrote:
| I would like it if Github could fix all the bugs with back button
| (broken browser history) first
| riidom wrote:
| Ah this really feels like they could have tackled
| https://github.com/orgs/community/discussions/4993 too, what a
| missed opportunity, I'd love to be notified about some
| repositories again, which I had to unwatch now because of daily
| autobuild spam.
| akimbostrawman wrote:
| >This means there are no new UI patterns to slow you down,
|
| requiring JS to simply view issues begs to differ....
| donatj wrote:
| This seems... unneeded bloat? I guess there are some obsessive
| organizers out there, but a markdown checklist of steps -
| potentially with _links to other tickets_ seems like all you
| need.
|
| If you're going to improve something improve code review! Let me
| comment on and suggest diffs to lines the author did not touch.
| Like half the time I am reviewing code it is "Hey, you refactored
| this but you missed a usage in this other file" and right now I
| have to manually give them file and line number manually and hope
| for the best.
| replete wrote:
| A lot of this will seem trivial if you haven't used Github for
| an organization's management of issues. This also lets you
| start off with a markdown checklist, and convert items to sub-
| issues.
| paulryanrogers wrote:
| > This also lets you start off with a markdown checklist, and
| convert items to sub-issues.
|
| Wasn't that already possible with Tasklists? We did it using
| "- [ ] description", then clicking the covert-to-issue hover
| option.
| donatj wrote:
| See, but I do. For almost a decade, we have used it as-is for
| tickets and bug tracking, and it's never been a problem. I
| just don't see the use case for sub issues.
| mikeocool wrote:
| Maybe they'll add "Closed - won't fix" and "Closed - stale"
| statuses next!
| edflsafoiewq wrote:
| They already have "Closed as not planned (won't fix, can't
| repro, stale)". You can use labels for finer granularity if you
| want.
| paulryanrogers wrote:
| There is already close as unplanned, which can serve both if
| you're flexible
| jerrygoyal wrote:
| I've almost stopped using GitHub as I switched over to vscode
| Github Pull Request Extension.
| ttoinou wrote:
| Looks very good. I might switch from Gitlab Issues if I find a
| tool to convert issues
| jxi wrote:
| Strange that issue types is only available if your repository is
| part of an organization. Why is this not configurable at the
| repository level?
| paulryanrogers wrote:
| To upsell? To maintain consistency among repos? To facilitate
| use among GH Projects?
| sangeeth96 wrote:
| I'm curious if there are folks here who work at for-profit orgs
| who use GitHub projects as their sole issue tracker for the
| entire org. How do you do it and what are the common pain points?
| Do you couple it with other issue trackers/project management
| tools like Jira? If so--why?
|
| I still feel GH Projects is solely aimed at OSS or dev-centric or
| dev-only orgs and doesn't cater to teams with non-devs, which is
| how I think most orgs function. I'm not sure if it'll ever try to
| be something more than that but I really wish it did.
| jjayj wrote:
| It would be a tough sell for my org to triple our license spend
| on GHEC just so we can teach a bunch of folks new software.
| sangeeth96 wrote:
| Absolutely. They definitely can't expect to sell this to
| teams/orgs with non-devs without introducing separate pricing
| for folks who just want to read/write to projects but maybe
| read-only for some aspects of a repo.
| eclipticplane wrote:
| A FOSS plugin to mimic Service Desk on top of Github issues
| would be great.
|
| You'd miss the infinite complexity of Jira workflow
| configuration, but that might be a good thing.
| jt_b wrote:
| Not FOSS, but this is kind of what Zenhub was/is, right?
| acjohnson55 wrote:
| We did at my previous employer (https://www.ourbranch.com/) in
| our data org. I can't totally remember, I'm pretty sure the
| engineering org did, too. It definitely is lacking in some of
| the advanced features you get with a Jira, but it was fine. I
| was surprised by how powerful GitHub Projects is. We also built
| out extra reporting for it in our data warehouse, using
| Fivetran for ELT.
| sangeeth96 wrote:
| Oh cool! I have some questions:
|
| 1. Does the data org work in isolation from other orgs? I'm
| guessing not.
|
| 2. Does the data org consist of non-engineers? If yes, are
| they also onboarded into GitHub with their own GH accounts?
|
| 3. If (1) is no, what tool is used to track cross-org work?
| Does the company also use Jira or some other tool and is GH
| projects integrated with them or something? I'm really
| curious about this workflow if it is relevant to how you
| folks work.
| yakshaving_jgt wrote:
| We ditched Jira to go all-in on GH. It's nice having the
| project management in the same place as where the actual work
| happens. It's not perfect, but it's better than GH + Jira.
|
| Probably the benefit I'm most happy with are that people are
| writing more, and in greater detail. I don't know why that is.
| For some reason, the GH experience just encourages writing,
| whereas the Jira experience seems hostile to it.
| sangeeth96 wrote:
| Interesting. Are you an all-dev org or did you also onboard
| non-devs into GH Projects?
|
| > the GH experience just encourages writing, whereas the Jira
| experience seems hostile to it.
|
| Huh, that's interesting to hear. I didn't personally find it
| harder to add detailed descriptions in Jira back when I used
| it couple of years back. Wonder if there's anything specific
| about the experience you can describe that makes you feel GH
| projects is more friendly for writing.
| yakshaving_jgt wrote:
| Roughly half the company are programmers, so we have non-
| devs working with GH Projects and collaborating on issues.
|
| Colleagues who aren't developers have become more engaged
| in the process of writing bug reports or giving feedback on
| product development (or at least, the parts of it that
| concern them). Some of the non-programmers have admitted
| that they are surprised by how much they enjoy using
| GitHub.
| sangeeth96 wrote:
| That's really nice to hear. I'm glad things worked out
| for your org.
|
| GitHub marketing folks probably should reach out to you
| :)
| landsman wrote:
| Nice job!
| portaouflop wrote:
| We tried (dev-centric org) but the non-technical users weren't
| able to use it well / didn't like it - so now we don't have
| issue tracking at all for non technical stuff -.-
| sangeeth96 wrote:
| Oh my! That doesn't sound like a good place to be in. I hope
| y'all figure something out to get them onboard or migrate
| out.
| portaouflop wrote:
| We mostly use notion and google workspace for the non-
| technical stuff now and as far as I can tell both are
| pretty good.
| saxonww wrote:
| We were interested in Issues and Projects, but the number of
| people at an organization who need access to those but not to
| code or CI is pretty large. GitHub does not have a different
| license option for BA/CX/PM types. We ended up going with Jira
| for tasking, which was substantially cheaper.
|
| I was sad about this because issues/projects had all the stuff
| I personally cared about, and there was no need to work to set
| up integrations. I think there was some anxiety by the PMO that
| it wasn't mature enough for what they wanted, but I don't
| remember any specifics. Probably something about reporting.
| sangeeth96 wrote:
| That's how I feel as feel. It's costly given the things non-
| devs types won't need and it's not fleshed out enough to
| attract those types of folks to make the switch. GitHub is
| probably missing the boat tbh. Even the marketing page
| (https://github.com/features/issues) is targeted at
| developers.
| madeofpalk wrote:
| We do at Grafana - it's mostly all public so you can go look at
| the mess of trying to run jira boards for however many teams
| out of one repo https://github.com/orgs/grafana/projects. It's
| a mixed bag, but Github's been building out Issues and Projects
| a lot in the last few years that's really improved things.
| drcongo wrote:
| We do. We're an agency so there's probably 60 odd repos on
| GitHub each with a project attached, a lot of non-tech people
| (even clients) using the issues and boards. Nobody has
| complained, though every now and then I've looked around for
| something else, but for me the number one priority is that the
| code and issues are in perfect sync with each other - much
| harder with a 3rd party tracker.
| the_duke wrote:
| Slowly inching towards something usable for companies / large
| projects...
|
| One big thing missing is resolution status for issues, like
| "cancelled", "complete", ...
| paulryanrogers wrote:
| You can close as complete (default) or unplanned today. It's
| called the 'reason'.
| landsman wrote:
| I am looking forward to project management without Jira!
| cloverich wrote:
| I was excited to see this feature pop up in beta, specifically
| sub issues. VS code organizes their work with parent sprint
| issues ("iteration plan", see [1]). I started using this pattern
| on my own project and once i adapted, now prefer it. Now rather
| than using markdown bullet points, i can use first class sub
| issues which are slightly less awkward. Ultimately a minor
| feature addition, but if it pushes more people to use then
| pattern, i think it would be nice. Lighter weight than proper
| tools, and imho all you need for moderately complex projects if
| the suits dont have too many needs / influence.
|
| [1]: https://github.com/microsoft/vscode/issues/237297
| localghost3000 wrote:
| A few jobs back I got "promoted" (honestly I didn't want it but I
| digress) to an EM. First thing I did was ditch Jira for GH
| issues. I was hailed as a hero for it. Unfortunately it ended up
| being a disaster and we had to switch back a year or so later.
| These were some of the missing features so pretty exciting.
| aklemm wrote:
| You should write Cliff's notes for the Odyssey. What an epic
| summary.
| JensRantil wrote:
| Jens's law: Every ticketing system will eventually become Jira.
|
| This is also what is happening with GH issues.
| dmd wrote:
| It's worse than that. Every ticketing system will eventually
| become ServiceNow.
|
| Compared to SN, Jira is a breath of fresh air.
| redserk wrote:
| One more field will solve it!
| maxcruer wrote:
| Behold: GitHub is becoming Jira!
| nmstoker wrote:
| I wish they would build features to defend against those near-
| spam type comments where someone is lazy and appends their
| clearly unrelated issue onto an existing one that maybe shares a
| few keywords but nothing substantive.
|
| It's not quite spam: there's often a real person behind it with a
| real issue but they need a (metaphorical) slap before they muddy
| the waters and disturb countless people already in the
| conversation.
| nmstoker wrote:
| This would be worthwhile for the individuals too - you often
| find a recurring pattern with all / most of their raised issues
| and with basic guidance they might up their game (or give up)
| andy_ppp wrote:
| When you have issues in different repos but in the same board it
| seems very confusing that you can create them and then have to
| assign them to a repo for them to move out of being a Draft issue
| (well maybe it is not an issue yet rather a task). Maybe I'm
| using it wrong but I found this pretty strange. Most projects
| will have a backend and frontend repo certainly when building an
| app so I think not being able to manage issues against both
| projects made things a bit strange. Maybe I should use a
| different blank mono repo just for issues but then I imaging the
| integration with PRs and commit messages breaks.
|
| Additionally I want to be able to have #PROJ-0002 style IDs for
| tasks, so for example I can add messages for tasks that affect
| both repos (e.g. "Imported types from GraphQL API into app
| (#BACKEND-1234, #FRONTEND-1234)") just having numbers is very
| limited and slightly confusing.
| antics wrote:
| I think of GitHub as a sad story. There are probably going to be
| at least 3 public companies that should have "just" been GitHub
| features: GitLab (GitHub Enterprise), Sourcegraph (search), and
| Linear (GitHub Issues). There are dozens of upstarts "unbundling"
| features of GitHub that are genuinely useful, but which are
| under-loved and under-invested in, and surely some of those will
| become successful too. It feels like GitHub continuously invents
| the future, and then waits for someone else to make it truly
| great.
|
| It is so painful to watch because I love GitHub so much. I
| graduated college in 2013, which means I started programming
| right when they got started. I read their dev blog every single
| day, eagerly waiting for new features (which were released every
| couple days). I watched their team page grow, I looked carefully
| at what they did to deserve a spot at such a cool company. I
| scoured the projects they contributed back to for hints about
| what good code looked like (my favorite was Vicent Marti's
| contributions to libgit2). I eagerly taught my friends how to use
| git because university taught subversion. I wrote my own Rails
| tutorials as a way to learn the magic.
|
| But it's been years now, and it's not an easy love. It's work!
| It's _so painful_ to watch it get continuously lapped by
| upstarts. I always just thought the core offerings (Pull Requests
| and Issues) would get better eventually. And now, 14 years later,
| they finally are. But very slowly. I really want to believe, but
| after 16 years, it is starting to sink in that GitHub might just
| be a place to store files.
|
| The magic is still in there. I think there are lots of people
| like me, who want to believe. But it will take real agency to do
| it, and that's really hard to muster at this stage in a company's
| life.
| SOLAR_FIELDS wrote:
| FWIW, this specific feature - what they are now calling _sub-
| issues_ - is actually better described as a framework for
| modeling proper parent-child relationships in their system,
| which is something quite hard to get right, mainly because it
| has to work somehow with the existing issues feature set.
| People building this feature from scratch (e.g. Linear) have it
| trivial to solve, because they didn 't have any backwards
| compatibility issue to worry about. This is, of course,
| absolutely Github's fault for not designing it to accomodate
| such a thing easily in the first place, but the people who
| built this feature are probably not the same people who made
| that original decision.
|
| They've been working on some version of this feature for
| several years now in various iterations. I believe this is
| either their third or fourth attempt to get it right - I was
| trialing a beta of some previous iteration of it a few years
| ago and it was incomplete/not fully well thought out which must
| be why they dropped it. I'd trust the feature here at least to
| be decent now, because of how many attempts they've had at it.
|
| But yeah if I was a company like Zenhub I would be probably a
| bit worried at this announcement since it is almost inevitable
| that this specific feature is going to be enough for people to
| no longer need third party management of issues. I know in a
| previous company I worked for that specific feature (proper
| parent-child relationships) was the reason they used Zenhub,
| and same for my current company using Linear.
| antics wrote:
| Sorry, the goal here is not to trivialize GitHub, or suggest
| they suck at engineering, or even to say this is easy. I am
| just saying my own perspective, which is that I wish the core
| properties (pull requests, issues) had improved a long time
| ago. I have been a maintainer of a top 0.01% project, and I
| have seen it get in the way where other tools would have been
| tolerable. It hasn't always been easy to be a fan.
| btown wrote:
| I like GitHub precisely _because_ it didn 't try to capture the
| entire market of issue trackers and code search too
| aggressively.
|
| If GitHub sub-issues had existed even in an inferior form back
| in 2019, developer-targeted trackers like Linear and Shortcut
| would have had a hard time existing, and all of their ideas
| (some of which have advised the UX of today's GitHub sub-issues
| release!) would have been lost to time.
|
| Now, perhaps this was not value-maximizing to Microsoft, or
| value-maximizing to companies who now need an extra license for
| Linear - but I would argue that for actual developer
| experience, GitHub fostering a spirit of innovation through its
| own stagnation has created a vibrant ecosystem better than
| anything any company could do themselves.
| antics wrote:
| Yes this is one of the reasons this discussion is so tricky.
| I just believe that if I maintain a popular project on GitHub
| I should not be automatically consigned to worst-in-class
| experiences for Issues and code review. I understand this is
| mildly controversial but I have had maintainer status on a
| few top 0.01% GitHub repositories and I have seen tools that
| do not suck, and so my opinion is that a better world is
| possible.
|
| Again, I say all of this entirely with love. I love GitHub. I
| have used GitHub since I started programming. I want them to
| win.
| habosa wrote:
| > automatically consigned to worst-in-class experiences
|
| You said it perfectly. This is why there are a lot of
| people willing to create better experiences on top of
| GitHub's API.
|
| I created CodeApprove (https://codeapprove.com) to improve
| GitHub's code review and there's also Graphite, CodePeer,
| Reviewable, and others doing a great job.
| TeMPOraL wrote:
| Any of them support dependencies between issues? Without
| it, it's still all worst-in-class experience for the
| purpose of managing work. Yes, this is distinct from
| _issue tracking_ , which is an _input_ , and usually
| external, but people seem to have this weird habit of
| trying to _manage software projects_ using GitHub or
| GitLab issues.
| motorest wrote:
| > There are probably going to be at least 3 public companies
| that should have "just" been GitHub features: GitLab (GitHub
| Enterprise), Sourcegraph (search), and Linear (GitHub Issues).
|
| I don't agree, and I cannot understand what train of thought
| would lead to conclude that each individual feature that's a
| crucial part of any developer's workflow should be broken down
| to external companies without any good reason at all.
|
| Any developer's workflow consists of a) ticketing, b) revision
| control, c) auditing code and change history, d) CICD.
| Obviously a) b) and c) are tightly coupled and you cannot have
| one without the other, whereas d) invariably leads to a) b) and
| c) in any incident response scenario. There is no argument that
| justifies any alternative to a unified developer experience.
| cratermoon wrote:
| I feel like ticketing is something that has been pasted on
| for corporate reasons. Keeping track of the work to be done
| doesn't require a ticketing system, anyone remember using
| Story Cards? A whiteboard?
| ImPostingOnHN wrote:
| I hate bureaucracy and will actively question the necessity
| of any imposition of bureaucracy, and resist its imposition
| if it doesn't seem justified.
|
| Nonetheless, there is use to more than just sticky notes.
| It tends to come with scale, and trying to coordinate and
| align teams of teams of teams of teams, etc.
|
| Additionally, sticky notes are impractical for remote teams
| (would there be some always-on webcam pointed at them?)
| TeMPOraL wrote:
| Well, if they wanted to implement _keeping track of work to
| be done_ , they'd have long ago implemented subissues,
| _sub-subissues, and sub^n-issues_ , because _obviously_
| work does _not_ break down into a list, or a one-level-deep
| tree - the natural data structure for breaking down work is
| a _directed graph_ (and if you really must do an 80 /20 on
| it, then _a tree_ ).
|
| Sadly, to this day, out of popular software packages used
| in software companies, only _Microsoft Project_ and maybe
| Jira get this right. Unfortunately, they have plethora of
| unrelated issues that are big enough that they drive the
| industry towards silliness of managing work in tools like
| Trello or Github /Gitlab issues.
|
| EDIT: I sometimes wonder how much of how Agile
| implementations look is a consequence of simplistic
| tooling. When your team's work planner is fundamentally
| unable to represent the basic idea that _tasks can depend
| on other tasks_ , you can't really plan ahead much further
| than a sprint. So is the Agile cadence really about
| avoiding the Folly of the Waterfall, or is it just shitty
| tooling that makes it exponentially hard to think ahead for
| more than two weeks? Did we invent "epics" because we can't
| link together multiple tasks on a Kanban board?
|
| And then, how many companies SCRUM the living hell out of
| their developers, while PMs secretly plan the whole thing
| ahead in MS Project to keep the project on track towards
| some goal, and then pray no one on the dev team spots a
| Gantt chart open on their screen?
|
| (Personally, I worked under one once; they begrudgingly
| admitted to managing everything in MS Project once I
| started asking if I can get a license, because _even Emacs
| Org Mode_ sucks at the job if the job is to break down
| month 's worth of work on entire deliverable.)
|
| EDIT2:
|
| > _Keeping track of the work to be done doesn 't require a
| ticketing system, anyone remember using Story Cards? A
| whiteboard?_
|
| Anyone remembers a _project plan_? _Work breakdown
| structure_? I know PERT looks to people like a Borg Cube,
| but then the status quo in software dev looks like Pakled
| technology. "We are devs. We scrum. Trello make us go!"
| antics wrote:
| Sorry if this was not clear, but I am not making a normative
| statement that each feature _should_ be broken out into its
| own tool. I 'm saying that the revenue ramp on each these
| products is, empirically, good enough to be on track to IPO.
| So GitHub is apparently doing a bad enough job in each of
| those areas that three separate companies were able to break
| a feature out into a dedicated product, sell it on its own,
| and ramp revenue fast enough to support a venture class
| business. Absolutely wild stuff.
| habosa wrote:
| Don't forget code review. I created CodeApprove, but there are
| so many other good alternatives that could have been GitHub
| features (Graphite, CodePeer, Reviewable, etc).
| whalesalad wrote:
| GitHub is a hugely successful company. They make a shit load of
| money. Your idea of success is not in congruence with actual
| success.
| ozim wrote:
| Next thing you know they just reimplement JIRA and everyone
| starts writing posts how much they hate it.
| breatheoften wrote:
| I just wish they'd improve the markdown autocomplete for issues
| and pull requests ... I'm not sure why it's so bad but even if i
| know two or three words in the issue title i almost never get the
| right issue to choose in the autocomplete list while typing in a
| markdown comment ...
| liontwist wrote:
| Corporate customers do pay the bills i suppose.
| cratermoon wrote:
| The enjirafication of github continues.
___________________________________________________________________
(page generated 2025-01-19 23:00 UTC)