[wp-hackers] Re: Unanswered tickets
wordpress at santosj.name
Fri Dec 21 05:18:30 GMT 2007
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
>> 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:
> 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
> 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
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
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*) 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.
 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.
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.
More information about the wp-hackers