[wp-hackers] Re: Unanswered tickets

[spencerp]

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.

Yeah, that happens often. Would be nice to maybe have some type of time 
period "email notifier", which the user could check a box for... Example:

** Get notified of replies to your ticket after: **

a) few days
b) few weeks
c) few months
d) few whatever else..

SO, if the user hasn't been checking up their own tickets for some 
reason (maybe too busy to) .. they would have a reminder there to do 
so... There should also be a statement some where that lets the user(s) 
know, that not all tickets will be considered nor submitted. Maybe there 
is that statement some where, I just overlooked it..?



> 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!"

Yeah, I agree with this as well. Perhaps putting "our" 
wives/girlfriends/boyfriends/husbands (whatever) on "dry dock", and take 
a few more nights a week giving some love-ins to Tract tickets would 
help... LoL

> I disagreed with your proposal, and I don't know if I replied to say 
> that. 
It's okay that you disagree. =) Actually, I wasn't trying to demand the 
proposal as such, just was throwing out thoughts, suggestions, and 
opinions. At least I feel better getting those out on the table though. =)

> 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. 

Ah, that would be nice. =D


> 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 see what you're saying here. I was just viewing it from the 
prospective of "wow, sure would be nice to keep all the tickets in ONE 
place, until they were chosen for a specific Milestone. Rather then 
constantly bumping them from Milestone to Milestone".

I know that they would have to get moved or bumped anyway though. After 
taking a break from this discussion, I realized it would be more "work" 
to just make a "BIN" and rewrite Trac. And it would also require moving 
the tickets to the "BIN".. then go back again later to move tickets from 
BIN to be under a Milestone.. (Said that, If the proposal was done that is.)

And yes, the core developers can't always create patches for all the 
tickets either. Nor do they have the time to be able to handle every 
single ticket before a release. It IS a community project, not just the 
core developers project. The "testers" are always going to out-number 
the amount of developers, and the amount of testers that don't know how 
to create patches, nor code to be able to make a patch is always going 
to exist too.

I know there are Bug Hunts and etc, but I wonder if "we" could some how 
maybe get the Community attention more on Trac? I know the Community 
knows of Trac, but I mean... some how constantly remind the public to 
help out there, get MORE people to help out and submit patches and etc. 
And I'm not talking about just the regulars that go to Trac. I'm talking 
about branching out and spreading the word where ever "we" can... Would 
be awesome if "we" could have a constant big flow of helpers, rather 
then just a designated day for "Bug Hunt"... Perhaps I'm dreaming, I 
guess someone should pinch me ...  =P


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

It's okay, no worries. =)

> 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.

I'll have to look into this then. I just don't have the time like I used 
to have though sigh. But, I'll try and get on something here though. 
Either start learning PHP, or, Unit Testing... Thanks for pointing that 
out. =)

(Sorry for not replying sooner, I was busy. On the plus side; Taking a 
break from this also helped me rethink everything. LOL)