The second and third step are occasionally reversed - in that case either
the implementor writes a test himself, or he assigns the ticket to me, asking
for tests. I just act as a placeholder here for the "needs a test" stage. In
any case a bug that can be tested with reasonable effort won't be closed
unless there's a regression test present.

The tests are usually disabled, because often they cause Rakudo to die
until it behaves at least mostly correct.

But sometimes it's a bit different: there is a subsystem that needs
substantial refactoring or a rewrite, and lots of bug tickets queue up for
that subsystem. Somebody invests much time and energy into that subsystem,
starts a branch, develops the rewrite there, and finally merges the
changes.

That happend this week when Jonathan implemented a new signature binder,
which fixed both many problems with passing arguments to routines, and also
enabled classes to see outer lexical variables.

We have a script called autounfudge which goes through all the test
files, enables the disabled tests one by one, run them again, and if they
pass, it writes a patch that enables them.

That's not only useful for enabling the tests, but also for finding the
tickets which can be closed. A typical auto-generated patch looks like this:

So after a big branch merge somebody will run the autounfudge script, and
that spits out a list of closable RT tickets. In the case of the signature
binder that were about 15 tickets, which would have taken ages to find without
help in the 500+ open tickets.