Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Evolving GitHub Issues

github.blog

Post reply on HN
Print view View original

51–60 of 92 posts

Re: Evolving GitHub Issues

#51

Post by vundercind »

sluongng wrote: post #14

I don't get the negativity. This is a great upgrade for enterprise user persona and is a catch up comparing to Gitlab Issue or Linear. I hope they put more effort into this.

Serving the “enterprise user” (the enterprise project manager and product owner, specifically) personas is why most other solutions are already so unproductive and unhelpful for the people doing the actual work. That’s where the negativity comes from. It’s like a mechanic’s ratchet having all kinds of bullshit attached to it to measure how many turns it makes and which socket’s getting used the most: that’s probably useful info for someone, but now the tool is terrible for the mechanic.

Re: Evolving GitHub Issues

#53

Post by digging »

ProxCoques wrote: post #7

If Issues could be restricted to repo maintainers (with everyone else using Discussions), it would make contributing to F/LOSS projects far easier because you could easily see what the team was "thinking" (PR lists aren't like that). As it is, most Issues are polluted by random support requests, suggestions and open-ended chat which obscures the focus so much that sometimes I just can't tell what they need help with,…

I feel this new version could help with that if unapproved users are restricted in the types of issues they're allowed to create. Something like "external". Or vice versa, they can't create "Internal" issues. But I immediately see a problem which is that types are not tags so the dichotomy of internal/external means that types now can't be used for type-of-work, only channel-of-input. So you'd be back to using tags for the former...

Re: Evolving GitHub Issues

#54

Post by xnorswap »

voidfunc wrote: post #45
vundercind wrote: post #2

Noooooo! I’ve been hoping for years and years to eventually land on a team that uses GH issues so I can not hate our ticket tracker for once, but they’re gonna shit it up like ADO and Jira and Asana before that can happen. They’d already made it borderline too complicated, this will complete the transition from productivity to “legibility”.

This was inevitable. Microsoft probably doesn't want to support both Azure DevOps and GitHub long term. GitHub needs to gain the most important features of ADO that ADO customers care about.

ADO has felt borderline abandoned since MS bought GitHub, and honestly good riddance, it feels terrible to use.

For example having more than 1 user edit anything is almost unsupported, and pages will regularly do things such as telling you that you ought to refresh to see changes, rather than just showing you the changes.

Or on other pages, anyone elsewhere changing anything at all will just trigger your page to refresh so you lose your place. This is particularly noticable on the sprint board, where if you view "all expanded" or "all collapsed", the refresh will often also reset that and throw you to a completely different part of the board.

The code review is even worse, despite some modest attempts at improvements, because you can't stage a batch of comments. Each and every comment is hand-delivered with a notification email to the recipient, so writing out a bunch of comments feels like a disruptive activity.

Overall the experience of ADO is horrible.

Re: Evolving GitHub Issues

#55

Post by madeofpalk »

Our org/team was very heavy users of the never-broadly-released tasklists revamp from a while back, and I was a huge fan of them.

I really liked the organic approach to project management - soft-epics and soft-subtasks, without Github Issues just turning into Jira. It felt like really neat product design (even though it often did have a bunch of sync bugs them them trying to do too much in markdown)

So I was disapointed to see they weren't happy with that and rolled it into an explicit subtasks instead. I haven't used it seriously yet for a project yet though. We'll see how it goes.

Re: Evolving GitHub Issues

#56

Post by nikeee »

mckn1ght wrote: post #47
mikeocool wrote: post #32

Please god add a “closed - duplicate,” “closed - won’t fix,”and maybe “our bot closed this because no one commented on it for 6 weeks” status. Nothing is more frustrating than finding an issue that exactly describes what your are experiencing marked “closed,” scrolling through months of comments only to find that the issue still exists and it’s been closed for one of these reasons.

Labels have been able to do this for years, why are they not a sufficient solution? And even if they elevated these to first class items, nothing is stopping maintainers from still closing them or letting them be closed without the issue having been actually fixed.

Because a label does not contain a reference to the issue that was duplicated. You still have to scroll through the issue's timeline to find it.

Re: Evolving GitHub Issues

#57

Post by mdaniel »

RicoElectrico wrote: post #3

What about merging duplicates?

Out of curiosity, what would you expect any such UI to look like in that case? Merging the comments? Even right now one can comment "closing as it is a dupe of #666" and GH will cheerfully create bidirectional links, the link in the comment and the other issue will get a "mention" comment

Re: Evolving GitHub Issues

#58

Post by sluongng »

vundercind wrote: post #51
sluongng wrote: post #14

I don't get the negativity. This is a great upgrade for enterprise user persona and is a catch up comparing to Gitlab Issue or Linear. I hope they put more effort into this.

Serving the “enterprise user” (the enterprise project manager and product owner, specifically) personas is why most other solutions are already so unproductive and unhelpful for the people doing the actual work. That’s where the negativity comes from. It’s like a mechanic’s ratchet having all kinds of bullshit attached to it to measure how many turns it makes and which socket’s getting used the most: that’s probably…

I think that's one way to look at productivity. I used to think like that when I was in a dysfunctional team as well. However, I do see value in issue tracking as I have seen how it helped drive top-down decisions on a large scale with high impact. An effective issue tracker can improve how resources are allocated, and create incentives, and promotions in smaller teams. The bigger the org, the harder it is to make this kind of decision correctly so there is value to be made here.

Re: Evolving GitHub Issues

#59

Post by mynameisvlad »

nikeee wrote: post #56
mckn1ght wrote: post #47

Earlier quoted context omitted.

Labels have been able to do this for years, why are they not a sufficient solution? And even if they elevated these to first class items, nothing is stopping maintainers from still closing them or letting them be closed without the issue having been actually fixed.

Because a label does not contain a reference to the issue that was duplicated. You still have to scroll through the issue's timeline to find it.

Neither do the statuses as suggested.

Your suggestion is to add a field that will only be used in a single status, which goes against the simplicity of GH Issues (which this update already makes contentious enough, looking at the comments here).

Also, realistically, there will be a mention of the issue in the final ticket, so is scrolling down to the bottom of the issue that hard? You're making it seem like it'd be buried in the middle of the timeline and while that can happen, I don't see that being anything but an edge case. Most tickets won't be referenced after they're closed as dupes.

Re: Evolving GitHub Issues

#60

Post by vundercind »

sluongng wrote: post #58
vundercind wrote: post #51

Earlier quoted context omitted.

Serving the “enterprise user” (the enterprise project manager and product owner, specifically) personas is why most other solutions are already so unproductive and unhelpful for the people doing the actual work. That’s where the negativity comes from. It’s like a mechanic’s ratchet having all kinds of bullshit attached to it to measure how many turns it makes and which socket’s getting used the most: that’s probably…

I think that's one way to look at productivity. I used to think like that when I was in a dysfunctional team as well. However, I do see value in issue tracking as I have seen how it helped drive top-down decisions on a large scale with high impact. An effective issue tracker can improve how resources are allocated, and create incentives, and promotions in smaller teams. The bigger the org, the harder it is to make th…

Tracking’s important. I think most of what matters could easily be achieved with simpler tools and less-intrusive processes, though, and in practice most of these attempts at hyper-legibility are misguided, largely because nobody’s even measuring the full cost of them.
Post reply on HN