[wp-hackers] Re: Unanswered tickets

[spencerp]

Woah there! Now that's a book! I'll have to respond to this tomorrow 
when I have more time..

Jacob wrote:
> 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.
>