Patch Process

Definitely proves the old system was flawed. I think over the best couple month, the turnaround time for newly opened tickets has greatly improved. We should keep doing what we are doing now in terms of new tickets. I think the question thats concerning both of us is, what should we do with all the old stale tickets? Rails as 1076 open tickets at the moment. Still alot to go through by hand. (This is probably a new thread).

I'm pretty happy with the requirements we have stated right now. We can let those set for another month or so before we try to do something stricter like require a patch for every ticket (which I won't be opposed too).

I'm pretty happy with the requirements we have stated right now. We can let those set for another month or so before we try to do something stricter like require a patch for every ticket (which I won't be opposed too).

Tickets describing bugs are a great asset. It lets us know if something's broken, and also lets people who want to 'chip in' help out.

Rather than closing bug reports, try to reproduce the bugs that are mentioned. If you can't, then close the ticket telling the submitter what you tried, and that it worked fine for you. If you successfully reproduce the ticket, you can probably whip up a test case, or even a fix.

I feel your pain here...perhaps it would be better if keywords were used to remove things from the normal report and put them only in the reports where they belong (e.g., undocumented == the "Undocumented Patches", same with untested, etc.). That way it's not "closed" but the submitter is told that more information is needed.

--Jeremy

Thats the process that left us with 1000 open tickets. Lots of people don't respond or fix their ticket. This is just lets us with a bunch of inactive tickets in the queue. Close the ticket now, it says closed if the person abandons it later and if they are truly interested and getting it through, can can easily reopen it.

It seems the main issues are:

1. We have to many open, stale tickets. 2. If we close tickets we will hurt peoples feelings/people think that a closed ticket is a permanent state and that it should not be reopened.

IMHO the simple solution is that when one closes a ticket, the ticket comment should simply say something like "This ticket is being closed due to xxxxx. Feel free to repoen this tick once xxxx has been added, or to discuss the merits of this action. Thanks for taking the time to help your community!"

<advocate type="devil"> ... </advocate>

advocate.is_a? Devil

=> false

advocate.for? Devil

=> true

+1 on Steve's idea here. Having this little extra text should smooth things a little for those of us with less thick skin. :slight_smile:

Do these steps apply for documentation as well? I'm not sure how to write a test for a documentation change. :slight_smile: Is that possible?

Mike B.

> It seems the main issues are: > > 1. We have to many open, stale tickets. > 2. If we close tickets we will hurt peoples feelings/people think that > a closed ticket is a permanent state and that it should not be > reopened. > > IMHO the simple solution is that when one closes a ticket, the ticket > comment should simply say something like "This ticket is being closed > due to xxxxx. Feel free to repoen this tick once xxxx has been added, > or to discuss the merits of this action. Thanks for taking the time to > help your community!"

+1 on Steve's idea here. Having this little extra text should smooth things a little for those of us with less thick skin. :slight_smile:

I have reasonably thick skin. I'll also note that the tickets involved *did* have a message about what needed to be fixed and done to get the patch accepted.

The thing that got me going was that a report of a material defect in Rails was handled more harshly *because* it had a patch. Say what you like about how closing a ticket isn't the end of the world, it's pretty simple to understand that if my tickets get shuffled off the "Bugs which haven't been [...] fixed" page only when I provide a patch, I'm less likely to submit patches and I'll just stick to reporting the bugs.

What I'm agitating for is one of two things:

* Set a clear and obvious policy that defect reports without a complete test   case will be closed. I've noticed lifofifo went and closed a bunch of   tickets with "Please attach tests/patch", but reopened them again a couple   of hours later. Presumably the policy isn't to reject tickets without   test cases, then?

*OR*

* Change the policy that defect reports with incomplete patches get closed.   Comment on them, set 'patchstatus=incomplete' or a 'patch-incomplete' tag   or whatever, but don't *close* them. They're valid defect reports and   should be placed with the rest of the valid defect reports, wherever that   may choose to be. (Handling of invalid defect reports is the same whether   there's a patch attached or not).

I hope I've made myself clear this time around. Defect reports, inasmuch as they document a defect, should not be treated differently based on whether there's a patch. The patch handling process is a separate issue.

Do these steps apply for documentation as well? I'm not sure how to write a test for a documentation change. :slight_smile: Is that possible?

Same thing applies to test case fixes -- there's no test suite for the test suite. Presumably with those they'd just go through the three reviewers process.

- Matt

Do these steps apply for documentation as well? I'm not sure how to write a test for a documentation change. :slight_smile: Is that possible?

Oh yeah! Spellcheck :wink:

+1 on Steve's idea here. Having this little extra text should smooth things a little for those of us with less thick skin. :slight_smile:

Definitely, someone should start a wiki page with a few 'canned' paragraphs that can evolve over time.

Do these steps apply for documentation as well? I'm not sure how to write a test for a documentation change. :slight_smile: Is that possible?

The review steps do. But obviously until something invents assert_makes_sense_and_explains_the_concept_well we'll have to skip the automated testing.

I hope I've made myself clear this time around. Defect reports, inasmuch as they document a defect, should not be treated differently based on whether there's a patch. The patch handling process is a separate issue.

I see what you're saying here, and you're clearer this time around, or (more likely) I'm less caffeine deprived.

The reality is that patches and defects are already handled in a very different manner. We want quick turnaround time on patches to keep submitters happy, however defects are generally less time sensitive.

I've seen two potential solutions here, either open another ticket when uploading a patch and reference the defect report. Or simply reopen the ticket with a comment saying "This is still a bug".

Ideally when rejecting a patch that's attached to a 'bug ticket' we can simply get rid of the [PATCH] prefix to have it excluded from the reports.

> Do these steps apply for documentation as well? I'm not sure how to > write a test for a documentation change. :slight_smile: Is that possible?

Same thing applies to test case fixes -- there's no test suite for the test suite. Presumably with those they'd just go through the three reviewers process.

Same deal, get the reviews done, and obviously make sure the tests still pass :).

> I hope I've made myself clear this time around. Defect reports, inasmuch as > they document a defect, should not be treated differently based on whether > there's a patch. The patch handling process is a separate issue.

I see what you're saying here, and you're clearer this time around, or (more likely) I'm less caffeine deprived.

Unless *everyone's* caffeine deprived, I don't think I've been clear.

I've seen two potential solutions here, either open another ticket when uploading a patch and reference the defect report. Or simply reopen the ticket with a comment saying "This is still a bug".

OK, I'll reopen tickets with that comment if they get closed for dodgy patches.

Ideally when rejecting a patch that's attached to a 'bug ticket' we can simply get rid of the [PATCH] prefix to have it excluded from the reports.

Well, if the patch isn't valid, the ticket doesn't really have a patch, so that's perfectly reasonable.

- Matt

Hi, is it feasible to add a 'tiimeout/stale' option for the closing, rather than invalid/wontfix. At least then you'd be able to see more accurately why something was closed ? It also opens up the possibility of having a bot of some sort just sweep daily and time things out (while still retaining some traceability of the fact it was auto-closed rather than manually closed).

A.