Joe Schaefer <joe_schae...@yahoo.com> writes: >What I would like to see from this project is less arguing >about irrelevant concepts and more features in the working >copy, ideally to make fewer network trips for better performance >or to support queued commits so sysadmins need not panic over >work stoppages due the the central server being down.
Not sure I should respond, but: First, patches welcome as always. Second, while I had time to have the (IMHO useful) discussion with Mark, I don't have time to code right now. It's not like the alternative was that I'd be writing code (sadly)! :-) -Karl >----- Original Message ---- >> From: Mark Mielke <m...@mark.mielke.cc> >> To: Karl Fogel <kfo...@red-bean.com> >> Cc: Hyrum K. Wright <hyrum_wri...@mail.utexas.edu>; Mark Phippard >> <markp...@gmail.com>; Subversion Dev <dev@subversion.apache.org> >> Sent: Sun, January 17, 2010 10:31:47 AM >> Subject: Re: Subversion in 2010 >> >> On 01/17/2010 02:55 AM, Karl Fogel wrote: >> > I'm *totally* trolling now, and I'll own up to it... While I actually >> > agree with a lot of what you've written in this thread, I think this >> > conflation of bugs with tech debt is a mistake. They're not the same >> > thing at all. I almost wrote that in a reply, but then realized that >> > I'd seen this often enough that -- help me, I have truly gone to the >> > dark side -- I thought it might be worth a blog post. So: >> > >> > http://www.rants.org/2010/01/10/bugs-users-and-tech-debt/ >> > >> > It would only be proper to flame me there, I suppose :-). >> > >> > Seriously: I don't think the SVN project, or any other project, should >> > treat the bug list as tech debt. It's not. >> > >> >> Lots of good points in there, but I think the underlying different in >> perspective comes from our definitions of a bug. >> >> You suggest that a bug might include new features or enhancements, or that >> it >> might include anything that behaves differently from how the designer >> expects it >> to behave. >> >> A good and well resourced designer should already understand how a >> particular >> piece of implementation will behave in each possible code path or use case. >> In >> the case that they do not, this means they skipped a step, or incurred >> technical >> debt, in a means to deal with some other imperfect situation such as lack of >> resources or lack of full understanding of what they were changing. >> >> Another argument could be that the technical debt has no impact on the >> users, >> and there is no intent to pay it back. I think this could be a design >> decision >> that was made to limit the capabilities of a feature from the start with no >> intent to ever extend the capability. This is a bit fuzzy as the users may >> not >> agree with the design decision - but "bugs" to extend the capability should >> probably be closed immediately with "No intent to fix", meaning that they do >> not >> fill the product back log. >> >> There are other sorts of bugs that are so low priority that they will never >> be >> attacked. These also should be closed as soon as it can be decided with "No >> intent to fix." They introduce noise in the product back log and prevent >> reviewers from being able to rank the issues effectively. In a corporate >> policy >> we had once, any defects that were not going to be scheduled for the next >> release, or the next release + 1, could be closed as "No intent to fix". >> >> To contrast your conclusion that more bugs means more users which can be >> good, >> I'd like to point out that having more users means that each bug has the >> potential to affect more users. More users means existing technical debt has >> more impact, and is more desirable to be addressed. >> >> In any case, on a issue by issue basis, we could probably say "100% >> technical >> debt" vs "100% new development request" vs anywhere in between - but my >> intent >> in mentioning it was to point out that: >> >> 1) If a project becomes overwhelmed with technical debt (however >> defined), >> it can and will stifle new development. The designer resources available are >> split between working on old and new instead of being able to work together >> on >> new. >> >> 2) If new development is introducing defects faster than they are being >> fixed, this is a recipe for product failure. >> >> I also think that "more bugs" only means "more users" in the sense that they >> are >> more use cases which are exposing *already existing* bugs. Assuming it is >> truly >> a bug, and not a design limitation or feature request (unexpected vs >> expected >> behaviour perhaps), then the technical debt already existed. The user base >> was >> just too small to expose it before. >> >> All said, I think you and I might agree more than disagree, if we were to >> actually identify on an issue by issue basis, which "bugs" are technical >> debt vs >> design limitation or feature request. It seems to me that terminology is >> thekey >> difference over a subject which does deserve discussion in every project >> which >> is serious about ensuring customer satisfaction. >> >> Cheers, >> mark >> >> -- Mark Mielke > > > >
