[wp-hackers] Probably best to move tickets to 2.7 instead

[DD32]

Maybe someone can tie this into:

http://codex.wordpress.org/GSoC2008
===
Trac Social Bug Tracking Development 

Mentor: Lloyd Budd 

This is a project that doesn't involve WordPress code, but Trac is such an essential tool for WordPress participation. I thought to include this. 

WordPress has a large number of "casual" contributors, people that contribute only a few bugs or fixes. These contributions are essential, and are the lungs if not the heart of WordPress. A fun way way for anyone to easily identify their contribution would be interesting. 

Investigate what GNOME and Ubuntu (Launchpad.net) bug trackers include for "karma"-statistics testing and development ticket tracking. See what is available for Trac, which may be nothing, and work on a implementing a system similar to GNOME and Ubuntu's. 

Although "Trac uses a minimalistic approach" a solution should be possible because of Trac's extensible architecture..
===

What it comes down to in the end, is that the only bugs/features that'll get fixed with releases are those that people are willing to code for.
I mean, Personally, I'm not interested in fixing bugs in the template tags, or the XML RPC code, However, I am willing to work on the updator code, The plugin code, & general code. Unless theres someone Pasionate about a feature, its just not going to be high on anyones minds. (Hey.. If i was being paid, i'd probably work on absolutely anything :P)

What it comes down to is having enough time to 
1. reproduce a bug,
2. find the bug in the code,
3. fix the bug,
4. test the fix with everything else that might rely on the code,
5. Post the patch to trac,
6. Get people to test the patch, 
7. Find someone with commit access to commit it.

I think 4, 5, 6 are the main failings at present, Quite often you'll find a bug with a patch attached, and theres just no traction on it; the main problem in that case is seeing a need for it to get commited ASAP, and there being enough testing done on the patch, A Patch isnt going to be commited unless either a) The person has the best understanding of that piece of code its patching, or b) the patch has been tested and verified working A-OK by a few people. 

I know in the past theres been some calls from people that think patches should just be commited and then let the testers deal with it, That does work in the sense it gets more people testing it, But it also has the downside of patches not getting enough testing before being released, Some parts of the code may be used in several different places, in several different ways, While a change to it might seem ok from most angles, It might not work at all when the function is used elsewhere. And then down the line a few months, or after a release has done, someone will pipe up "Hey.. Why doesnt this work? It used to!"; Sometimes people completely miss rare use-cases, and without testing before commiting patches, down the line it can become questioning how the bug got there in the first place (Now repeat this entire paragraph with the fix for that bug).

Test-cases are brilliant, If people can be bothered writing them, and running them on changed code of course.
If WordPress had test-cases which covered a large part of the code, It would be relitivly simple for nightly testing to take place, and to notify of any regressions from the previous days code, It would even be possible for it to pin-point the exact patch which caused the regression to occur. 
I'm one of those people, I dont like writing test-cases, I just like to see a problem fixed; I dont like having to run test-cases, because i *know* if it was fixed or not (As i'd be trying to fix a bug in one place), But that kind of thought isnt good, as i said before, just because it works in one place, doesnt mean it does in another.


As a final piece; Take note of these trac keywords which WordPress reconises:
http://codex.wordpress.org/Reporting_Bugs#Trac_Keywords
If theres a patch which you believe has a patch attached which you think is suitable for commiting, tag it as such "has-patch tested commit".
If theres a ticket which your not sure how devs want to continue, tag it, "dev-feedback"
If theres a ticket which you think needs more opinions on before commiting, "has-patch 2nd-opinion" (or "needs-patch 2nd-opinion")
If theres a ticket with a patch, but it needs some good old testing, tag it, "has-patch needs-testing"

Looking through the Trac Reports, theres really only a small number of tickets which are marked as needing testing, a few which are brought to dev attention, and bugger all commit candicates. http://trac.wordpress.org/report 

I think the main thing that needs to happen, Is that tickets get tagged correctly, and that people test patches before they get commited.. But no-one likes testing patches.. its too much effort :)