Issue tracking incorporated in a repo?

[Michael Diamond]

On Wed, Oct 19, 2011 at 2:26 PM, Snidely <snidely.too at gmail.com> wrote:

> On Oct 19, 8:24 am, Michael Diamond <dimo... at gmail.com> wrote:
> >  In general, I believe you should be adding as
> > little metadata as possible - if you fundamentally disagree (which I
> > completely understand) b is the wrong tool for the job.
>
> I think I have more than one opinion about this, and scale of the
> project is a factor in which one I respond with.  I think b is quite
> suitable for many small-team projects, especially when team members
> file most of the issues.  As the team gets more diverse, or when
> outside input becomes significant, adding standard metadata helps
> bring consistency to the reports and that may be a necessary
> overhead.
>
> I have the idea that procedures are necessary, but that too much
> procedure can be as bad as too little, so I try to find my way to
> where  "it's just right".  And I offer up my comments here to help
> other readers find the sweet spot.
>

Agreed, there is always some amount of required metadata, and the bigger the
project, the more you need.  It can be very useful to track all sorts of
extra info, like resolution types.  But in my experience, in a lot of cases,
people track a lot of metadata they don't actually have any use for.  When,
for example, was the last time that you needed to see the list of bugs
marked WONTFIX?  My theory is it's better to start with less metadata and
work your way up when you realize you need it - that's why, for example, b
works without users (to assign issues to) if you just want one simple list
of issues.

This isn't to say at all that bigger issue trackers are inherently bad, but
they fill a niche b doesn't even compete with, and isn't trying to.  My
point was simply that if someone likes lots of metadata, they're not going
to be very happy with b - and I'm alright with that :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20111019/8b11054a/attachment-0002.html>