A bug / problem reporting process for all

Well, let’s try this again.
No matter what I do, I can’t login. Different usernames, different passwords, no passwords, can’t login.
You know what’s happened is that WordPress became a little too popular a little too quickly.
Anyone remember that commercial from the dot-com era, where the group turns on their site and they’re delighted to see orders come in…
…until the nice stream becomes an unmanageable flood?

See this also. Your solution to put the bugs on the wiki could work, but if the WP folks aren’t checking it, it really doesn’t do us any good.
I recommend they take a little time to set up an installation of Mantis, which I’ve used several times and it works quite well. But, some solution needs to be initiated by the WP team, otherwise it’ll probably be a wasted effort.

We’re getting a bug tracker ready and are considering Mantis. Look for an official announcement on the forums. For those requesting a tracker, now is your chance to step forward and help us maintain the tracker. A bug tracker quickly becomes a worthless mess without a team constantly working to keep it healthy.
mf, thanks for getting a Wiki page going. Your help in updating that page as we lay out the bug reporting process would be appreciated.

Thanks rboren. I also noticed someone linked this from the main Wiki page – I didn’t want to do that but guess it’ll help.
I just added another detail to the bug reporting process: using the BUG: keyword in forum posts subjects – duh! I’ll be watching how this discussion evolves, also bumping it to the top as needed.

R. Boren also mentioned some important information in this post, mostly:
<UL>
<LI> We’re working on a bug tracker. perhaps implying SF bugtracker can be used temporarily but another better tool is being evaluated/installed
<LI> For this to succeed we need something along the Gnome Bug Squad to do the preliminar triage
<LI> One of the biggest jobs of a bug squad member is eliminating duplicates. I would suggest when a dup is found in the forums, simply add a note saying “It’s beeing discussed here“
<LI> Have a little patience while waiting for answers.
<LI> Your bug report should contain a clear description of the problem, any error messages printed out by WordPress, steps to reproduce the problem, the version of WordPress used, and a link back to the forum discussion of the problem.
<LI> The bug tracker [at SourceForge] should not be used as a support forum. That’s what the support forums are for.
</UL>
Thanks for your input, B.
mf.

I take that back — it has been edited.
But then where are bugs to be submitted that don’t have at least two responses?

Also, give a test run to phpBugTracker
https://phpbt.sourceforge.net/

Thanks for the feedback & editing, Shelley. I think every bit helps, as long as it doesn’t become “stop energy” ??
I think you were talking about Wiki updates ? Check the links at the bottom of each Wiki page (if you haven’t already), the PageHistory link has update information generated automatically.
Bugs posted to a forum that don’t have at least 2 responses sit at the forums, pending further discussion/confirmation. I thought about this when seing the previous text that described the bugs in the page as being “reported multiple times”. In my opinion if a bug is reported “at least 2 times”, it becomes worthy of investigating and documenting, since it’s been confirmed (in theory) by its finder and another user.
I already see some users editing in the Wiki and using the BUG: keyword. Keep spreading the word!

If you need someone to help with the tracker, I’m here.
And by the way, I’d strongly recommend an effort by the WP team to adopt some kind of automated doc-generator for the codebase, like PhpDocu.

Thanks all. This is exactly the kind of activity we need. Please keep it up. We’ll get a new bug tracker going once we get the server straightened out.
Also, if bug reports are accompanied by a patch, mark it on the Wiki page with a PATCH keyword or something of the sort.

Shelley wrote in another thread:

mf, I may back out a change you made in the wiki. You removed the separate page and placed all bugs on the main bug page.
But what happens when 1.21 comes out?
By linking on a separate page, we can keep bugs for each release separate.

WPBugs should only have current version bugs, IMO. It should also be the place were a short, precise bug reporting process is explained, so it’s not ignored – by someone going directly to WP 1.2 individual page, for example.
When 1.21 comes out, we move the content of WP 1.2 bugs to its own page for archival and only current bugs for 1.21 keep the attention. At that point the “archived” bug page should only have items that have made their way to the SF bugtracker.
Do you think this could be different / better ? Tx. for all the attention on this.
BTW I had a great read on your article about licences. ??

You used the magic term with me
stop energy
I’m outta here with my stop energy

Contributing bug fixes and plugins, writing tutorials, and helping to define process doesn’t sound like stop energy to me. If that is stop energy, we need more of it, not less.

This may be appropriate to link somewhere. Perhaps on the wiki page for bugs:
How to Report Bugs Effectively

There is a bugtracker now.