[wp-hackers] Re: Unanswered tickets

[Jacob]

Well, I should have made clear that some of the submitters probably 
wandered off after there was no traction after a certain period of time, 
"Hello, anyone home?" I think with a recent example, once it was made 
clear that the reporter had to clarify, the reporter came back and did 
so, which lead to a resolution. With a year past, I'm not sure the 
original reporter might still be interested in WordPress. I know in a 
year time, whatever ticket I have created and not committed will 
probably have no involvement from me until I once again came back to 
WordPress.

spencerp wrote:
>
>> At least that is how I would feel if I had my own open source 
>> project, but I'm pretty sure that with 500+ tickets, limited time, 
>> and various degrees of I-really-don't-care-for-that-ticket that 
>> project might fall into the same state.
>
> That's basically why I suggested this earlier:
> http://comox.textdrive.com/pipermail/wp-hackers/2007-December/016738.html
>
> Sure, it's a task in itself... Means they'd have to hack/edit Trac 
> software itself to do what needs to be done. But, at least the tickets 
> wouldn't constantly be bumping from version to version or whatever 
> else.. The tickets would SIT THERE in the "TICKET BIN", assigned to 
> their respected Milestone Bins. They wouldn't need to go any where 
> UNLESS the ones with "SVN Commit Rights" MOVES them to the Milestone 
> it's intended for...
>
> So when looking at the RoadMap page there... there wouldn't be 500+ 
> tickets sitting under Milestone 2.4... There'd only be what was sent 
> there from bin.. that the SVN Committers moved there from "Ticket 
> Bin". This would help alot too, for like.. setting a certain amount of 
> tickets to be applied to that Milestone for under a certain Release 
> Date schedule. So you don't have to constantly bump tickets from like: 
> 2.4 to 2.5 then those same tickets get bumped from 2.5 to 2.6 or 
> whatever...
>
> All those (uncertain with what to do with) type tickets can remain in 
> the Ticket Bin, out of the way, and be there to be able to decide on 
> it's destination later. And if need be, and they think it would be 
> best in another version bin.. they could just move it from 2.4 
> milestone bin to the next one...

Well, in that, I mean part of the reason there are 500+ tickets is 
because there isn't a lot of love, which until recently a lot of love 
that should have went was not. It is a tough decision to close a ticket, 
because it leaves you to wonder if anyone else will show up to resubmit 
the bug. Some of the bugs might be edge cases, which may never show up 
until a unit test or acceptance test is written that finds it again (I 
keep forgetting the guy that writes those). You take the risk closing 
out old bugs and alienating the bug poster, "WTF? That bug still causes 
me nightmares!"

I disagreed with your proposal, and I don't know if I replied to say 
that. The good news is that the next version of Trac (0.11) is going to 
have a workflow that might allow for a little of what you say, in that 
you can create more statuses, such as "confirmed" status in that someone 
tested and confirmed. Really, I think your proposal would create more 
work and more red tape to go through to get bugs committed. The current 
rule/suggestion that if a ticket doesn't have a patch, then it belongs 
in the next milestone is a good one. If you want to show a ticket some 
love and write a patch, then those that do can bring that patch down the 
trunk milestone.

This would keep the trunk milestone with a few tickets that have patches 
and therefore should be debated and committed and all others will exist 
in the next milestone. However, I'm not sure how far the core devs are 
going to take this. It would be much better if someone would adopt a 
ticket and supply a patch for it.

I suppose my point has always been that there is only so much the core 
devs can do and should do. I don't believe they can provide a patch for 
every 500+ bug, it is a community effort, but really if the community 
doesn't care for a bug then that bug will remain until it is superseded 
or obsoleted. In the best case, every week would be like this last week 
and WordPress milestones wouldn't contain such a large amount of old bugs.

However, I think that most popular open source projects might wish for 
having only 500-600 open bugs. I'm not sure how I feel about closing out 
bugs just because there is no current love for them. Someone might come 
along later and the bug will peak their curiosity and that bug will 
exist no longer in open state. Basically in some ways, bug hunts are 
good to refresh peoples memories of bugs that once knew and reclaim old 
friends, "Dude, I so totally remember that bug, whatever happened? Let 
me take care of you."

>
>> I don't particularly agree with your assertion that the more complex 
>> tickets should be committed before the simple ones. You can most 
>> likely knock out 10 simple tickets in the time it would take to write 
>> and argue the points for a more complex one. Take the cookie 
>> authentication change. It took weeks to finish that and it is still 
>> open for opinion/discussion, which I think is a good thing. I think 
>> security is extremely important, but you can't hold back everything.
>
> Unless I used the wrong wording, I basically said it would be better 
> to knock out simpler tickets when "you" can... =P Especially when 
> waiting around on whether the Admin Redesign is coming in or not... 
> While the "wait" is there for the BIG stuff... they my as well knock 
> out or squash the simple stuff quick... I wrote this in previous 
> email: "And what better to knock out first, than the simpler 
> tickets... Especially with an Admin redesign coming soon, you can only 
> touch so much tickets without interfering with it.. I know I pointed 
> out SOME tickets that were pending on the Admin redesign... but they 
> were also planned for 2.4 though, as well as the Admin redesign 
> stuff... "

Hmm, I had thought that was what you meant, but didn't quite know how to 
word my assertion. Please excuse my earlier statement.


May I suggest, since you don't know that much of PHP, that you become 
involve with automated testing. You really only need to know the PHPUnit 
methods (there is a great resource phpunit.de and you can copy/refactor 
the current tests to your needs), in that way you learn PHP, and 
seriously help the community. I'm probably going to jump onto the codex 
and write up a tutorial on helping the automated tests test writing 
since that needs to have as many people/testers as possible.

At the very basic, regression testing involves var_dump()-ing functions 
with test input (both correct and *incorrect*[1]) and using var_dump() 
on the output. Once you figured out what the function dumps upon given 
input, you can then use the PHPUnit $this->assert*() methods to make 
sure that whatever input is given is continued to be given, else a 
regression bug occurred.

That is probably the quickest and easiest automated testing. It doesn't 
drill down into the core of the functions and test all the possible 
branches the function can take, but still, if the regression test 
failed, then somewhere out there, there is a function/plugin/theme that 
is going to break based on the change.

The best thing would be for more unit tests, since it would prove the 
low level testing of a bug and possible fixes for correcting that bug. 
The best part about regression/acceptance tests is that they can be 
written by non-developers and most of the articles I've read recommend 
that they aren't written by developers.

[1] With unit testing or any kind of testing you are purposefully trying 
to break the software. If I enter "-1" instead of a positive number, 
will I break the functionality? In that, you want to write 
unit/functional/acceptance tests with both correct and incorrect input 
and still expect correct output or some fallback value which states that 
you need to enter correct input (acceptable response, meaning the 
function was aware that incorrect input was passed and had checks to 
insure that it would not continue). However, I don't think I've taken my 
own advice since I've tested mostly correct input instead of the latter 
in most cases because well, with regressions, you aren't really trying 
to break the function, just trying to see what it returns. Most of my 
tests would fall in to the regression testing with the plugin in line 
with unit testing.

-- 

Jacob Santos

http://www.santosj.name - blog
http://wordpress.svn.dragonu.net/unittest/ - unofficial WP unit test suite.

Also known as darkdragon and santosj on WP trac.