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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Sam Ruby: Life after Bug Tracking Systems

18 点作者 arjunb大约 16 年前

4 条评论

pieter大约 16 年前
Having a bugtracker or not is a tough decision. You have to keep your ways of communicating limited to a few channels. You _will_ need to address the social aspect of your project in one way or another. It's probably either a mailinglist or a bugtracker. Having both means one of them is probably heavily underused.<p>What you see a lot with projects is that everything happens through a bugzilla. New features, feature requests, bugs are posted there, some invalid because the user doesn't understand a program. The 'bugtracker' aspect forces you to put your message in a certain style.<p>With mailinglists like git@vger you get a mixture of posts. Some are from newbies that don't understand the system, some are comments on the current system and most of them are patches or status updates. Having a mailinglist allows a user more freedom in the form in which he wants to communicate, which lowers the barrier. You also get a nice mixture of users and developers on the same channel, by which you get better feedback.<p>The flipside of that is that you don't have any overview. You'll have to manage bugs yourself. If you want something fixed, you'll either have to make a patch yourself, get somebody else interested or just keep bringing the bug to attention.<p>Now compare this to a bugtracker. You post a bug there and nobody will look at it until you make a patch yourself, get somebody else interested or keep bringing the bug to attention. See the difference? Exactly.
jballanc大约 16 年前
As I read this I immediately thought of Ditz (<a href="http://ditz.rubyforge.org/" rel="nofollow">http://ditz.rubyforge.org/</a>).<p>The idea behind Ditz is that, if your project has no centralized "truth", then a bug tracker that represents centralized "truth" doesn't make much sense. Instead, Ditz keeps track of your bugs right there in your Git repo, so when you check out that 3 month old experimental branch, all of the bugs that still existed on it are right there for you to read about.
steve_butler大约 16 年前
I think this represents life <i>before</i> bug tracking systems:<p>XML Parsing Error: not well-formed Location: <a href="http://www.intertwingly.net/blog/2008/07/18/Life-after-Bug-Tracking-Systems" rel="nofollow">http://www.intertwingly.net/blog/2008/07/18/Life-after-Bug-T...</a> Line Number 42, Column 101:String.fromCharCode(0xdc00+n%0x400);}else{return '&#38;#'+ncr+';'}});for(var i=body.length-1;i&#62;0;i--){if(cp1252[body.charCodeAt(i)]){body=body.substr(0,i)+'&#38;#'+cp1252[body.charCodeAt(i)]+';'+body.substr(i+1);}} ----------------------------------------------------------------------------------------------------^<p>But seriously, I'm curious what he has to say. In lots of companies the bug tracking overhead overwhelms the actual work done.
Kaizyn大约 16 年前
Bugtracking doesn't matter if you aren't working for a profit-seeking enterprise or other enterprises that pay people to write software for them. For these situations, telling the users to fix the bug themselves and send in a patch will never ever fly.
评论 #537205 未加载