wiki, bugzilla, feature requests
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 signature.asc Description: This is a digitally signed message part
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
Re: wiki, bugzilla, feature requests
I'm proposing: - if there is a bug for something, and a wiki page, link them together. - scheduling, assignment, and dependency data should be put in bugs - whiteboards to sketch annotate document etc should always be in the wiki -Rob signature.asc Description: This is a digitally signed message part
Re: wiki, bugzilla, feature requests
tis 2009-09-22 klockan 23:27 +1000 skrev Robert Collins: I'm proposing: - if there is a bug for something, and a wiki page, link them together. - scheduling, assignment, and dependency data should be put in bugs - whiteboards to sketch annotate document etc should always be in the wiki I fully second this opinion. Wiki is great for documentation and the like, but very poor for tracking progress (or lack thereof). Regards Henrik
