Re: wiki, bugzilla, feature requests

Robert Collins wrote:
> AIUI we use the wiki [over and above being a source of docs] to /design
> features/ and manage [the little] scheduling that we, as volunteers can
> do.
>
> I think thats great.
>
> However, we also have many bugs that are not strictly-current-defects.
> They are wishlist items.
>
> What should we do here?
>
> I've spent quite some time using wikis for trying to manage such things,
> I think its a lost cause. Use them for design and notes and so forth,
> but not for managing metadata.
>
> I suggest that when there is a bug for a feature that is being designed
> in the wiki, just link to bugzilla from that wiki page.
>
> And for management of dependencies and todos, assignees and so forth, we
> should do it in bugzilla, which is *designed* for that.
>
> -Rob

I'm mentally grouping the enhancement bugs into three categories:
  - real features : requiring user-visible configuration
additions/alterations.
   These are what the wiki Features pages were intended for. So users
could come along after the feature is released and read the
documentation about the feature and its intended/possible uses. Also
these pages linked to the roadmap for publishing the user-visible schedules.

  - operational enhancements : largely bugs which are improving some
workings but not relevant to users configuration. These might get
mentioned in the wiki as part of some other discussion or the planning
like SourceLayout may be so tricky we require a dynamic page to track
the changes well.

  - pure code enhancements : pretty much bugs but not problem-causing
bugs. These don't suit the wiki at all and might stay as enhancement
bugs only.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE7 or 3.0.STABLE19
   Current Beta Squid 3.1.0.13