The next bug tracking system (discussion currently)

Welcome! You are invited to report Bugs here. Simply take the next number, sort your bug in a category and add a new wiki word there. By clicking on your new wiki word in the updated page you would then be able to create a page where only your bug will be discussed.

---

Internal discussion

Andy: Why don't you consider building out the aview/posts plugin to your needs? It will already spawn numbered subpages and that's a good chunk of what you need. It currently displays all the posts but filtering would be a simple tweak and could be done on status or whatnot. Also, with an aview/posts derived plugin we would control the formating on the main page. You would probably want to co-opt the form from the mpi bug tracker to get version info.

Jochen: Hi Andy, I think I should point something out:o)

I personally don't need a bug report system for my site. But if I should (as I would like to) further contribute to ewiki, mainly with reporting bugs and suggesting some code, I will neither be able to do that nor to waste my time with the existing BugReports page as I simply can't seriously track the several open bugs there!

Further on I'm really not so deep into ewiki that I'd be able to build out aview/posts (actually I don't know exactly what you are talking about:o) But maybe you want to do that? Very quick?

For me it's very simple: I need a wiki. Now! I'd like to use ewiki. ewiki has currently many bugs. I will find them (in the plugins I want to use). And I'll report them if YOU give me an USEFULL and EFFICIENT place to do that. Otherwise I'll try to rape ewiki to make it fit my needs somehow, throwing away most of it and knowing that I'll probably never update it.

Or short: Sorry, but I really don't have time to worry about implementing a bug tracking system for you only because you (or milky) want to do that inside the wiki! I still think that's a stupid idea and would personally use some real out-of-the-box bug tracking system with anonymous posting for sure.(Don't ask me which - I've never looked for one).

Update: I just now found the BugNumberList which is already close to what I want to have. It simply lacks

• trailing status info for each bug (closed bugs shouldn't be moved or deleted in case for need to reopening)
• predictable bug numbering
• storing the bug description and discussion on a separate bug page
• and a higher chance to find it as newbie:o)

---

For this tracking page you should keep in mind:

• It's a good idea to place the status of bug in front of the bug number - looks better and it's far more easier to check for open bugs.
• As status word you can use whatever suits your needs. Recommended are open, closed and reopened. It is in your interest that open bugs are quickly discovered, so change solved bugs to an unobtrusive closed.

For your bug page you should keep in mind:

• Use bug number and bug description as headline
• Postings should be separated from each other by "----" in a new line
• Write your name (or nicname) at the start of your posting

state	BugNumberList	category	short description
open	*BugNo1/RecentChangesMayTrickYou	./plugins/page/	RecentChanges may trick you

---

more discussion

mario: I'm not fully pleased by calling bug pages (if we change to open single pages for single bugs) like "BugNoNN" - that's bad style. Rather the title should be a shortened description of it, and that's where it get's complicated to say the least. People don't invent good page names in a form (and rather include spaces), also not every bug report should start with "Bug..." but a script can never have so much logic to yield good names on behalf of the user.

Whatever, the incremental bug numbers are obviously better than the randomly choosen ones. (Just did that to reduce clashes, if anywhen two people issued a bug report at the same time, as I remember.)

Adding pages for bugs is indeed better for tracking, and finding them again later (no search required then). We could merge the *BugNumbersList onto BugReports and use a table format as shown above.

Jochen: As I mentioned above I think it's already bad style to use a wiki for bug tracking:o) So the only question is what both of you want to have.

Adding a page for each bug with increasing bug numbers is not only good for tracking, it's simple, it results in short page names, it's idiot proved (doubled number -> non-empty page), it works with none and lots of open bugs, it merges open, closed and reopened bugs and highlights the open ones, it's easy possible to rename bugs (as all links go to the bug number page), ...

Your idea of merging sounds good, I already start to forget what I've modified in 1.01e4:o) Personally I'd prefer a non-table bug list like

• open *BugNo1 - RecentChanges may trick you

because

• easier to format by hand (for me:o)
• my category idea was not really thought to the end (too many cases which probably will belong to more than one)
• without category no really need for a table
• even a short description could be a little longer than I'd like to see in a table

milky: It's kinda proof-of-concept if we maintain our BugReports in the Wiki. I'm still not convinced that we should open a new page for every bug (then the whole Wiki will become a bug database), but at least this was good from the documentation collection point of view (the wiki then was the best place to look for help).

Whatever, I'm already working on a fixed BugReports mpi, it only lacks a good method to create non-ugly (=non-numeric) page names. It is ok for an ordinary BugTrackingSystem to rely upon and to expose internal page identifiers; but in the scope of WikiWikiWeb and InterWiki this looks not so good IMO. Also I'll probably keep the table thing, since it is easier than to add the status field and make that change more easily. The bug categorization is a bit difficult, I don't know what we need here; but we should give this also a test run at least...

milky: A new BugReports system is almost there, which allows easy submission of short reports and includes an easy way to insert a notify: address for the submitter. Also it still will notify anybody subscribed to the BugReports page, so that also developers will get a message as soon as that happens. So that really turns out to be more user-friendly, allthough the table structure looks not all too well as Jochen predicted (but speaking page names are better nevertheless!). It only needs the state: change buttons, but that's easy to do.

---

BUG#3681 bug tracking system required

Jochen: Posting bugs to this page does if

• the number of open bugs is small
• bugs are simple (no need to talk about it)

At the moment I'm not able to keep track of all the bugs I mentioned, and I've not the time to do anything twice. So please think about using any handy bug tracking system. Even a simple forum could do a better job than a wiki I'd think...

• categorizing e.g. for plugins
• post answers (and find them:o)
• prevent loss of info (new entry = new post = thread)
• open/close state (e.g. closed thread)

No need for a user account (User: Oh, create password? Takes too much time, so keep your bugs...)

milky: Sure, this is no real *BugTracking system here; but as you pointed out forced registrations are no option, and the SourceForge provided bug tracker is far too annoying to use for visitors and developers.

But actually, this BugReports page worked quite well - until yesterday, when you stepped in ;) It really didn't see so many submissions in its whole lifetime.

Yes, it's true, we cannot seriously track the state if bugs. I often even don't include the bug numbers when uploading fixes into CVS. We've introduced the numbers exactly for that, but me was too lazy to make any use of it.

OTH, using a real *BugTracking system is also a political question here. Since we must proove usefulnes of ewiki, we must 'eat our own dogfood' - as it is called elsewhere ;)

So I have to say, it is actually only you, who could make use of a real bug tracking system; I probably wouldn't be subscribed to it, simply for the fact that it is yet another system to manage and then took time from real development. It is something different for huge projects like http://php.net/, because ewiki is a rather small project; though categorization of bugs would help a lot. So for us, it really was intentional not to use the SourceForge *BugTracking features. (my two cents, but if we ever have more developers - who knows...)

Jochen: I really don't think that we (or anyone) must use a wiki for anything. But ok, you want to stick with it, and I want that you solve the bugs:o)

So I'd suggest this BugTrackingSystem

milky: Looks interesting, I'm considering distributing the BugReports onto different pages right from the beginning. OTH we don't want users to have to think about the different subsystems, and instead just post a note about what they think is broken (symptoms). So this was merely for experienced users. But a nice idea nevertheless (the report <form> above could simple be extended to get a bit more business logic).

Jochen: Ok, grouping into plugins and so on might be a little over-designed. So lets just list all bugs, sorted by number. Then it might be possible for you to add a report form which adds the *BugNo to the list and creates the new page containing the problem description.

Btw: the currently used bug numbers seem to me like randomly chosen...? If the last bug was 1234 I'd prefer to get 1235 next.

Important for me now: If you say "Let's try with the BugTrackingSystem" than I would move my bugs to it, making it easier for us to track them. Else you could tell me what might be improved:o) UPDATE: please answer in BugTrackingSystem coz Andy did that, too.

milky: Deployed a new BugReports form here, which will create one page per bug, with easy notification (for submitters and anybody subscribed to RecentChanges).

*Henner That's not really working in the moment!!!

milky: It did work - your report was saved as "ErrorListofpluginhooks"; it just failed on good useability, in that no useful result message was printed and it did not correctly add the entry to our new bug list table. But I hope it works better today.

Jochen: I'll test it as soon as I find another bug:o) Please keep an eye on the state field - I think it's very important to highlight the open ones. Currently there are open and open ones.

MarioSalzer: New bug reports will be marked with open per default, it's just a few of the prev/older ones that I didn't enriched that way. And the new BugReports mpi/form seems to do quite well, and I'm going to use it for our SupportForum and other parts too. It's obviously better than letting a single BugReports grow beyond being readable.

Jochen: So it wasn't a bad idea:o)

BobRomeo: (18-10-2005) Should have enhancements:

• Text
  • On form with title /Use only plain words/ (for newbies) -or- /Don't use :./ or other special characters/ (Didn't get the wikifying of the title to the bugname until now)
  • On form with description /Description has WikiMarkup/
• Extra Status
  • reopened
  • bug (=certified by gurus)
  • resolved (if was a bug)
• Form
  • get name from authorname cookie or bug cookie
  • store email address in cookie
  • because of wiki input --> button for preview
• bugPage
  • unique bug# (when status is bug) for ReleaseNotes
• *StaticPage
  • BugReports should be a plugin or spage. Maybe new plugin *BugList ?

What's up with feature request in a buglist ?
BTW: I think this could become a support system with little extra effort.