TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Evolving GitHub Issues

110 点作者 joeig8 个月前

24 条评论

mjw10078 个月前
I think the biggest weakness of github issues is that the main content it shows when you visit an issue page is the original report.<p>That&#x27;s very often unhelpful because:<p>- it&#x27;s likely that the actual problem wasn&#x27;t understood at that point (it&#x27;s likely to be describing a symptom, rather than a bug)<p>- it&#x27;s quite possible the original reporter wasn&#x27;t very good at writing bug reports<p>- issues often remain open after the main underlying problem is fixed, because there&#x27;s some small remaining part that&#x27;s unsettled.<p>I&#x27;d much prefer it if the topmost part of the page was reserved for a space, maintained by whoever&#x27;s responsible for dealing with the issue, describing the current understanding of the problem and the current status.<p>Then the orignal report and further discussion could be laid out under that as at present.<p>It&#x27;s possible to get roughly this now, by repeatedly editing the initial message. But the UX isn&#x27;t ideal, and more importantly it isn&#x27;t culturally expected.<p>(Of course this isn&#x27;t a github-specific problem. But github are in a better position than most to offer a fix.)
评论 #41709762 未加载
评论 #41718251 未加载
评论 #41709707 未加载
vundercind8 个月前
Noooooo! I’ve been hoping for years and years to eventually land on a team that uses GH issues so I can <i>not hate</i> 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”.
评论 #41709246 未加载
评论 #41709658 未加载
评论 #41711159 未加载
评论 #41709038 未加载
评论 #41709214 未加载
评论 #41709880 未加载
评论 #41709774 未加载
ProxCoques8 个月前
If Issues could be restricted to repo maintainers (with everyone else using Discussions), it would make contributing to F&#x2F;LOSS projects far easier because you could easily see what the team was &quot;thinking&quot; (PR lists aren&#x27;t like that).<p>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&#x27;t tell what they need help with, so I don&#x27;t bother offering.<p>I have no interest in the Jirafication of Issue though. None at all.
评论 #41709068 未加载
评论 #41710319 未加载
评论 #41709873 未加载
评论 #41709780 未加载
holman8 个月前
I built the last major update to GitHub Issues over a decade ago now, and I was... kind of hoping for more. Feels more like it&#x27;s checkbox-driven development instead of sitting down and really planning long-term about what improvements could be made. Also it has React.
评论 #41714553 未加载
388 个月前
if GitHub really wants to fix issues, fix the god damn pagination. the current system is basically:<p><pre><code> comment comment [bunch of hidden comments] comment comment </code></pre> this is not better, at all. to get all comments, you have to constantly click &quot;more&quot; until all are loaded, IN A SINGLE page. then if you accidentally refresh or navigate away from the page, boom you have to redo the entire process.
评论 #41709891 未加载
sluongng8 个月前
I don&#x27;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.
评论 #41710313 未加载
mikeocool8 个月前
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.<p>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.
评论 #41709921 未加载
评论 #41713184 未加载
评论 #41711363 未加载
kayson8 个月前
Whats the point of issue types when we already had labels?
评论 #41709770 未加载
评论 #41709823 未加载
评论 #41711948 未加载
seanwilson8 个月前
A recurring pattern I see is someone will add an issue comment like &quot;This is great but we need to fix 1. this, and 2. that&quot;, and it&#x27;s just a mess keeping track of discussion threads related to 1 and 2, who is assigned to fix them, and if they&#x27;re done.<p>A hack is to add a [ ] checkbox in front of each task (by editing the comment yourself if needed), but then it&#x27;s not clear if the person that thinks they&#x27;ve completed the task ticks it, or if the original commenter ticks it after they&#x27;ve reviewed the work, and the comment will eventually get folded&#x2F;hidden.<p>Another hack is to add a review comment to a pull request anywhere in the code, which at least gives you threaded conversions and a resolved status, but you can&#x27;t mark who it&#x27;s assigned to.<p>Any more hacks here?<p>Maybe sub-issues will solve this, but if it&#x27;s similar to creating new issues, that&#x27;s quite heavy for small items.
skeptrune8 个月前
Biggest issue with GitHub issues is that large open source projects can&#x27;t easily signal to viewers which issues are a priority and which are dead or spam. Anytime I see a project with a bazillion issues (like Element), I worry about it&#x27;s health when maybe I shouldn&#x27;t because the project is actually fine and the maintainers just use some other ticketing system outside of GitHub.<p>Aggressive moderation to keep the # open is possible, but not ideal because it causes anxiety for issue-creators and prevents maintainers from finding out about bugs and feature reqs. Some first-class way to differentiate between backlog and todo on the repo would be my #1 request.
评论 #41718090 未加载
评论 #41711980 未加载
madeofpalk8 个月前
Our org&#x2F;team was very heavy users of the never-broadly-released tasklists revamp from a while back, and I was a huge fan of them.<p>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)<p>So I was disapointed to see they weren&#x27;t happy with that and rolled it into an explicit subtasks instead. I haven&#x27;t used it seriously yet for a project yet though. We&#x27;ll see how it goes.
6LLvveMx2koXfwn8 个月前
Was expecting a link to an outage report . . . pleasantly surprised as I&#x27;m currently on-boarding my team to Jira and it&#x27;s important that every innovation in this space is over-engineered :)
bob10298 个月前
This would cause more distraction than good on most teams I&#x27;ve been on. I have watched coworkers make it their entire career to play around with the GH project management &amp; issue stuff. The more features, the more distracted these people become. I have even caught myself getting distracted from time-to-time.<p>If we can&#x27;t effectively communicate work priorities between titles, comments &amp; labels, maybe we need to go back to email for a while.
vaylian8 个月前
sub-issues sound nice for grouping issues. But I think there could be an even better solution: Make it possible to declare issues to depend on other issues and milestones. That way you can filter issues out that can not be worked on because some more fundamental infrastructure has to be put in place first.<p>A PR can be linked to an issue. It should be possible to link issues to other issues and milestones.
评论 #41709851 未加载
jackhalford8 个月前
I know the ziglang project has been doing « sub issues » ad hoc by writing issue lists in a main meta issue. These enhancements will be welcome.
lars_francke8 个月前
FYI: Contrary to Tasklists (which were in beta but will be phased out) this does not support adding Pull Requests as sub-&quot;issues&quot;.
giancarlostoro8 个月前
Azure DevOps feels like nobody&#x27;s maintaining it. I wonder how long until they announce GitHub is going to be the end-goal for ADO.
jerrygoyal8 个月前
Any progress on improving slow performance?
评论 #41710995 未加载
RicoElectrico8 个月前
What about merging duplicates?
评论 #41710556 未加载
cynicalpeace8 个月前
These are some nice updates.<p>However, it made me think of how much time and money is spent just on organizing things, even when organizing something doesn’t make things go better.<p>In fact, the best teams I’ve worked on have a bias against organizing and a “just do it now” mentality. It depends on the specific case of course. But as a culture, software engineers have a bias towards organizing too much as opposed to not enough.
评论 #41709651 未加载
评论 #41709963 未加载
评论 #41710132 未加载
agos8 个月前
hoping to one day read &quot;Evolving GitHub Projects&quot;. Issues are good, but it&#x27;s really hard to work on them while projects are half baked
yu3zhou48 个月前
I wish I could turn off Issues without archiving a repo
评论 #41709117 未加载
评论 #41709120 未加载
mahkoh8 个月前
C-f thread<p>0&#x2F;0<p>We shouldn&#x27;t hope for the impossible.
评论 #41712956 未加载
poorman8 个月前
&gt; Earlier this year, we introduced the private beta of increased project item limits, expanding the capacity from 1,200 to 50,000 items in a project.<p>This reminds me why smaller companies can steal market share from larger companies. I can understand that at GitHub scale, it&#x27;s probably difficult to support more that 1,200 items per project. The result? The entire ecosystem has these limits imposed on them. A smaller company could easily support 50,000 issues for a repository since they are hosting fewer repositories.
评论 #41709400 未加载
评论 #41709095 未加载