Suggesting a few improvements for the ticket workflow on t.e.o

[Christian Boos]

Hello Trac developers,

I just realized that we still have on t.e.o most of the "original"
workflow [1], with all its flaws. That is, we have "reassign" leading to
the "new" status and "accept" leading to "assigned", when we should
really have something like "reassign" leading to "assigned" and "accept"
leading to "accepted" (i.e. the "basic" workflow [2]).

Well, what we really need could even be simpler than the basic workflow,
as I think we don't need "accept/accepted". The way we work on t.e.o, we
don't have component owners and we "assign" a ticket to ourselves only
when we're taking some responsibility over it (providing a fix ourselves
or applying someone else's contributed patch), so actually "accepting"
it, in the sense of "working on it". Besides, we very rarely assign a
ticket to someone else than ourselves (and should that need happen, we
could as well set the Cc), so using the `set_owner_to_self` operation
for "assign" would work just fine.

Therefore I suggest the following, adapted from basic-workflow.ini:

[ticket-workflow]
leave = * -> *
leave.operations = leave_status
leave.default = 1

assign = new,assigned,reopened -> assigned
assign.permissions = TICKET_MODIFY
assign.operations = set_owner_to_self

resolve = new,assigned,reopened -> closed
resolve.permissions = TICKET_MODIFY
resolve.operations = set_resolution

reopen = closed -> reopened
reopen.permissions = TICKET_CREATE
reopen.operations = del_resolution

+ keeping the change_owner and change_resolution we already have.

The [milestone-groups] would be the one from basic-workflow.ini,
resulting in "assigned" tickets being shown in yellow.


And this brings me to a semi-related topic: triaging woes...

I often find myself wanting to do some triaging, whenever I happen to
have a few minutes of time ahead of me. But then, while going through
report {20}, I quickly hit some ticket which is hard to triage, one
which I probably keep struggling with, so I try once more to figure it
out... and then the five minutes are over. What would really help me
here is a way to categorize the ticket as "not trivial to triage", a
two-level triaging step, so that the really new (or reopened) tickets
would stand out and if they're indeed trivial to triage, they can be
assigned to a milestone quickly.

So one way to handle this situation could be to put a ticket which takes
more than a few minutes to triage in the "assigned" state, keeping the
milestone unset. That way, one could do a "first level" triaging by
going through the list of new,reopened tickets with no milestone set,
and either triage them properly or give up by "assigning" them to
oneself. A "second level" triaging could be done by going through the
list of tickets with no milestone set and assigned to *someone else*
(what's not trivial for them could perhaps be trivial for me?). Finally,
a "third level" triaging would be to really go through the time
consuming ones, when there's enough time ahead.

Feedback on these ideas welcome.

-- Christian

[1] -
http://trac.edgewall.org/browser/trunk/trac/ticket/workflows/original-workflow.ini
[2]
http://trac.edgewall.org/browser/trunk/trac/ticket/workflows/basic-workflow.ini

[Remy Blank]

Christian Boos wrote:
> Therefore I suggest the following, adapted from basic-workflow.ini:

Sounds good.

> I often find myself wanting to do some triaging, whenever I happen to
> have a few minutes of time ahead of me. But then, while going through
> report {20}, I quickly hit some ticket which is hard to triage, one
> which I probably keep struggling with, so I try once more to figure it
> out... and then the five minutes are over.

I know that feeling. Your proposed workflow sounds reasonable.

TBH we also simply have too many tickets. And we accumulate them faster
than we fix them, so for each new ticket, there's a fair chance that it
won't be looked at ever again. The only real solution to that is to
filter them more aggressively at the input. Anyway, that's not the issue
you were trying to solve.

-- Remy

[Peter Suter]

On 07.10.2012 20:06, Christian Boos wrote:
> So one way to handle this situation could be to put a ticket which takes
> more than a few minutes to triage in the "assigned" state, keeping the
> milestone unset. That way, one could do a "first level" triaging by
> going through the list of new,reopened tickets with no milestone set,
> and either triage them properly or give up by "assigning" them to
> oneself. A "second level" triaging could be done by going through the
> list of tickets with no milestone set and assigned to *someone else*
> (what's not trivial for them could perhaps be trivial for me?). Finally,
> a "third level" triaging would be to really go through the time
> consuming ones, when there's enough time ahead.

So assigning-to-self would mean:
* "not sure how to triage" (if milestone not set)
* "accepting and working on it" (if milestone set)
Possibly a bit confusing?

Wasn't there a "triaging" milestone once?

-- Peter

[Christian Boos]

On 10/7/2012 9:54 PM, Peter Suter wrote:
> On 07.10.2012 20:06, Christian Boos wrote:
>> So one way to handle this situation could be to put a ticket which takes
>> more than a few minutes to triage in the "assigned" state, keeping the

>> milestone unset. [...]

>
> So assigning-to-self would mean:
> * "not sure how to triage" (if milestone not set)
> * "accepting and working on it" (if milestone set)
> Possibly a bit confusing?

One could also see it as:
* "I started working on it" (if milestone set)
* "I started triaging it" (if milestone not set)

A bit more in tune, but still, I get your point.

> Wasn't there a "triaging" milestone once?
>

That would be a valid alternative. We would still have to explain the
difference between "no milestone" (1st level triaging) and "triaging"
(2nd level), unless we find an explicit name ("undecided"? This would go
well with our "unscheduled" one).

-- Christian

[Dirk Stöcker]

On Sun, 7 Oct 2012, Remy Blank wrote:

> Christian Boos wrote:
>> Therefore I suggest the following, adapted from basic-workflow.ini:
>
> Sounds good.

Is there a reason why t.e.o. does not have two very important things:

a) a "needinfo" state, which is very helpful to mark these tickets, which
requires additional info. This is very helpful to find and close all these
tickets, where additional info is required, but never gets provided (For
JOSM we use that together with a resolved state needinfo, which is used
after some weeks).

b) a "duplicate" method (using xrefs from AdvancedTicketWorkflowPlugin,
which I really would like to have in core). This is very important, as it
helps to find duplicate reports and also to count the importance of
original ticket when many duplicates exist.

> TBH we also simply have too many tickets. And we accumulate them faster
> than we fix them, so for each new ticket, there's a fair chance that it
> won't be looked at ever again. The only real solution to that is to
> filter them more aggressively at the input. Anyway, that's not the issue
> you were trying to solve.

For JOSM we see that get more and more tickets since the software gets
more and more stable. Only now we very seldom get a crash, but lots of
tickets which describe many little problems.

Many of these are actually right, but most aren't worth the effort to fix
them immediately or at all. But closing them would also be wrong. So
depending on the fact how you handle tickets it must not be bad, that you
accumulate them. As long as you at least care for these which are
important (these, where there are requests of state, additional info -
these where there is activity).

Here again the "duplicate" thing would be helpful. Sometimes we have
irreproducible stuff, but we get lots of duplicates over the time which
shows us, that there must be a real issue, but very well hidden. Over the
time enough information in the duplicates accumulates to help finding the
reason.

--- the ticket workflow JOSM uses ---
[ticket-workflow]
accept = new,needinfo -> assigned
accept.operations = set_owner_to_self
accept.permissions = TICKET_MODIFY
dup = new,needinfo,assigned,reopened -> closed
dup.name = close
dup.operations = set_resolution,xref
dup.permissions = TICKET_MODIFY
dup.set_resolution = duplicate
dup.xref = Ticket %s has been marked as a duplicate of this ticket.
dup.xref_local = Closed as duplicate of %s.
infoprovider = needinfo -> *
infoprovider.operations = set_owner
infoprovider.permissions = TICKET_MODIFY

leave = * -> *

leave.default = 1
leave.operations = leave_status
needinfo = new,assigned,reopened -> needinfo
needinfo.name = need info
needinfo.operations = set_owner_to_reporter
needinfo.permissions = TICKET_MODIFY
reassign = new,assigned,needinfo,reopened -> new
reassign.operations = set_owner
reassign.permissions = TICKET_MODIFY

reopen = closed -> reopened

reopen.operations = del_resolution
reopen.permissions = TICKET_CREATE
resolution = closed -> closed
resolution.name = change resolution
resolution.operations = set_resolution
resolution.permissions = TICKET_MODIFY
resolve = new,needinfo,assigned,reopened -> closed
resolve.operations = set_resolution
resolve.permissions = TICKET_MODIFY

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

[Remy Blank]

Dirk Stöcker wrote:
> a) a "needinfo" state, which is very helpful to mark these tickets, which
> requires additional info. This is very helpful to find and close all these
> tickets, where additional info is required, but never gets provided (For
> JOSM we use that together with a resolved state needinfo, which is used
> after some weeks).

We use the "needinfo" keyword for that, but it's true that a "needinfo"
state would technically be more correct.

> Many of these are actually right, but most aren't worth the effort to fix
> them immediately or at all. But closing them would also be wrong. So
> depending on the fact how you handle tickets it must not be bad, that you
> accumulate them. As long as you at least care for these which are
> important (these, where there are requests of state, additional info -
> these where there is activity).

Keeping tickets open that we are very unlikely to ever fix sends the
wrong message, and leads to comments like "What, this extremely
important bug is still not fixed after five years? WTF!" as we see them
here from time to time (fortunately not too often). We could close them
as "value-to-work-ratio-too-low-sorry" to make that clear, but then we
would have people re-open them with a comment like "This can't be right,
this extremely important bug must absolutely be fixed!", so I'm not sure
we would gain anything.

-- Remy

[Dirk Stöcker]

On Mon, 8 Oct 2012, Remy Blank wrote:

>> Many of these are actually right, but most aren't worth the effort to fix
>> them immediately or at all. But closing them would also be wrong. So
>> depending on the fact how you handle tickets it must not be bad, that you
>> accumulate them. As long as you at least care for these which are
>> important (these, where there are requests of state, additional info -
>> these where there is activity).
>
> Keeping tickets open that we are very unlikely to ever fix sends the
> wrong message, and leads to comments like "What, this extremely
> important bug is still not fixed after five years? WTF!" as we see them
> here from time to time (fortunately not too often). We could close them
> as "value-to-work-ratio-too-low-sorry" to make that clear, but then we
> would have people re-open them with a comment like "This can't be right,
> this extremely important bug must absolutely be fixed!", so I'm not sure
> we would gain anything.

Well, a "still not fixed after five years" is actually a note, that
probably the bug has higher importance than thought before...

Also together with the voting system it allows to express user opinion
about bugs.

[Ethan Jucovy]

On Sun, Oct 7, 2012 at 6:19 PM, Remy Blank <remy....@pobox.com> wrote:

> Many of these are actually right, but most aren't worth the effort to fix

> them immediately or at all. But closing them would also be wrong. So
> depending on the fact how you handle tickets it must not be bad, that you
> accumulate them. As long as you at least care for these which are
> important (these, where there are requests of state, additional info -
> these where there is activity).

Keeping tickets open that we are very unlikely to ever fix sends the
wrong message, and leads to comments like "What, this extremely
important bug is still not fixed after five years? WTF!" as we see them
here from time to time (fortunately not too often). We could close them
as "value-to-work-ratio-too-low-sorry" to make that clear, but then we
would have people re-open them with a comment like "This can't be right,
this extremely important bug must absolutely be fixed!", so I'm not sure
we would gain anything.

Does t.e.o have a keyword for these kinds of tickets?  As a non-core-developer I'd like to help out and also get more familiar with the core codebase, and little bugs that aren't worth a core dev's time to fix sound like they might be good tickets to start on.  Or maybe moving them into a special milestone would make it clear that no core dev is likely to look at these, and also make them easy for someone like me to find?

Along the same lines, does t.e.o have any way for a non core developer to mark a ticket "has a patch, which works, [ideally has tests,] and "just" needs a core developer to review the patch?

I might be misunderstanding the nature of these tickets though ... I'm hoping you're talking about little bugs that aren't worth the time to reproduce and fix, rather than little bugs that require design decisions and new configuration settings or swappable components.  :-)

[Dirk Stöcker]

On Mon, 8 Oct 2012, Ethan Jucovy wrote:

> Along the same lines, does t.e.o have any way for a non core developer
> to mark a ticket "has a patch, which works, [ideally has tests,] and
> "just" needs a core developer to review the patch?

Most bug-trackers us a "[patch]" in the subject. Works also for t.e.o.

[Remy Blank]

Ethan Jucovy wrote:
> Does t.e.o have a keyword for these kinds of tickets?

For tickets where the ratio "value over work" is too low, no.

> As a
> non-core-developer I'd like to help out and also get more familiar with
> the core codebase, and little bugs that aren't worth a core dev's time
> to fix sound like they might be good tickets to start on.

That's not the same thing. "Entry-level" tickets are marked with the
keyword "bitesized". Their value can be anything, but the work needed is
small. Whereas in the other category, the value is generally limited,
but the work is large.

> Along the same lines, does t.e.o have any way for a non core developer
> to mark a ticket "has a patch, which works, [ideally has tests,] and
> "just" needs a core developer to review the patch?

Yes, we mark such tickets with the keyword "patch".

For more keywords (and general guidelines about triaging tickets), see [1].

-- Remy


[1] http://trac.edgewall.org/wiki/TracTicketTriage#Keywords

[Christian Boos]

On 10/8/2012 2:38 PM, Ethan Jucovy wrote:
> On Sun, Oct 7, 2012 at 6:19 PM, Remy Blank <remy....@pobox.com
> <mailto:remy....@pobox.com>> wrote:
>
> > Many of these are actually right, but most aren't worth the effort
> to fix
> > them immediately or at all. But closing them would also be wrong. So
> > depending on the fact how you handle tickets it must not be bad,
> that you
> > accumulate them. As long as you at least care for these which are
> > important (these, where there are requests of state, additional info -
> > these where there is activity).
>
> Keeping tickets open that we are very unlikely to ever fix sends the
> wrong message, and leads to comments like "What, this extremely
> important bug is still not fixed after five years? WTF!" as we see them
> here from time to time (fortunately not too often). We could close them
> as "value-to-work-ratio-too-low-sorry" to make that clear, but then we
> would have people re-open them with a comment like "This can't be right,
> this extremely important bug must absolutely be fixed!", so I'm not sure
> we would gain anything.
>
>
> Does t.e.o have a keyword for these kinds of tickets?

I think the tickets for which we receive this sort of angry feedback are
usually not the proper ones for getting started. And besides, it's not
that kind of reaction which motivates us, quite the opposite you can
imagine.

> As a
> non-core-developer I'd like to help out and also get more familiar with
> the core codebase, and little bugs that aren't worth a core dev's time
> to fix sound like they might be good tickets to start on. Or maybe
> moving them into a special milestone would make it clear that no core
> dev is likely to look at these, and also make them easy for someone like
> me to find?

*That* kind of tickets corresponds to the "bitesized" ones. We have
quite some of them already (48 as of today).

>
> Along the same lines, does t.e.o have any way for a non core developer
> to mark a ticket "has a patch, which works, [ideally has tests,] and
> "just" needs a core developer to review the patch?

These are the ones with either "[patch]" in the summary, or those having
the "patch" keyword. As Dirk said, the first form is common practice,
but we rather recommend the second. See for example the queries that use
this keyword in TracDev/ToDo.

Quite close, we have the tickets with the "review" keyword, when the
patch (or the topic branch) would benefit from peer review. And you
don't need to be a TracTeam member to point out the subtle (or even
obvious) flaws in our code ;-)

See http://trac.edgewall.org/wiki/HowToContribute#CodeContributions

>
> I might be misunderstanding the nature of these tickets though ... I'm
> hoping you're talking about little bugs that aren't worth the time to
> reproduce and fix, rather than little bugs that require design decisions
> and new configuration settings or swappable components. :-)

Like I suggested above, we have both sorts. We have those little bugs,
though I wouldn't say that they aren't worth the time to reproduce and
fix, it's more a question of "availability" to get at them. Those also
usually won't generate loud complaints ;-) And it's good to have the
problems documented and flagged as "open", see the various #KnowIssues
sections, e.g. MySqlDb#KnownIssues. Closing those tickets wouldn't make
the problem go away, and I think we very seldom close a ticket saying
"ok, this is a bug we must live with" when the source of the problem is
within our reach. For 3rd party bugs, it's another story, see milestone
"not applicable".

But we have the much bigger topics which are on the plate since a long
time (typically #31, #1024, #2456, etc. see report {32} for example),
and sometimes people in need of those features don't understand why
after so many years they're still not implemented... Well, they're not
implemented for the obvious reason: nobody did it (at all or in a
satisfying way).

So if those features haven't been implemented for 5, 6 or more years,
why not just acknowledge they'll never be implemented? Because that's
not true, they eventually will. Not all of course, but some, and it's
hard to tell which, as it only depends on people turning in and being
motivated enough to push them. Just look at report {33} for evidence.
The latest entry there is #1942, created August the 19th *2005*, and
thanks to the patient effort of many people, contributors and team
members alike, it's finally there (for 1.1.1). That's ... 7 years. And
it's by far not the only example.

Most of the "long timer tickets" are still open because they fit well in
the long term vision of what Trac should (or could) become. We'll
eventually get there, or at least continue trying to get there ;-)

These are the tickets on one of the mid-term milestone
("next-minor-0.12.x", "next-stable-1.0.x" and "next-dev-1.1.x") as well
as the ones on the long-term milestone (which had many names, "1.0",
"2.0", now "next-major-releases"). The ones on the short-term milestones
("0.12.5", "1.0.1" and "1.1.1") are already very close to be part of the
software itself.

We also have the special milestone "unscheduled", which is for tickets
advocating features or approaches we currently consider to *not* be
fitting that vision, or that they should at first better be implemented
by plugins, or simply that they may present a great idea but we're
clearly not willing to adopt it and make it our own. This doesn't mean
that the idea or proposal is ruled out, simply that its proponent would
have to do all the hard work for that feature by himself (and first
demonstrating some real commitment to the project as a whole).

I know R�my would have preferred to "wontfix" those, but I still stand
by my reasoning that this is a less harsh way to reject ideas: the door
is not closed; additionally, for "wontfix" tickets, we have to justify
ourselves a bit more than saying "we're not interested". Anyway this is
just concerning 224 tickets, which means that they're still 631
"fitting" tickets on the other milestones [1] (as of today and
notwithstanding errors in the triaging process).

So for me, it's *OK* to have those 600+ tickets, it's just hinting at
the *possible* future evolution of the software (and of course, only a
part of it).

I hope this wasn't getting too far off your original question ;-)

-- Christian

[1]
http://trac.edgewall.org/query?status=assigned&status=new&status=reopened&milestone=0.12.5&milestone=1.0.1&milestone=1.1.1&milestone=next-minor-0.12.x&milestone=next-stable-1.0.x&milestone=next-dev-1.1.x&milestone=topic-wikiengine&milestone=topic-multiproject&milestone=next-major-releases

[Dirk Stöcker]

On Mon, 8 Oct 2012, Ethan Jucovy wrote:

> Does t.e.o have a keyword for these kinds of tickets? As a
> non-core-developer I'd like to help out and also get more familiar with
> the core codebase, and little bugs that aren't worth a core dev's time
> to fix sound like they might be good tickets to start on. Or maybe
> moving them into a special milestone would make it clear that no core
> dev is likely to look at these, and also make them easy for someone like
> me to find?

If you want to contribute (here or somewhere else), a short note about how
to start (Target audience: Not only you :-)

a) Find something you want fixed/changed 'yourself'.

b) Read code and think a bit about how you would solve it.

c) Check whether there is already a report for it and maybe suggestions
how to solve the issue.

c1) There is: comment at the relevant ticket with a short text how you
think you will proceed to give maintainers a chance to guide you to the
right path when necessary.

c2) There isn't: Either create a ticket or use mailinglist for additional
guidance.

d) Start implementing.

d1) When necessary ask in mailinglist or ticket for help, but always tell
what you did and why you did it and where your problems are.

e) Supply a patch

f) Fix the patch according to the requirements of maintainers.

g) Constantly nag until it is applied :-)

You can skip b) to c), but usually it makes f) easier.

One thing which is always important for me. When asking questions,
describing strategies: Be short with the texts, but provide all
information which may be necessary (the more the better, as long as the
main question/suggestion stays short and understandable).

Why: From time to time for our software (don't know for Trac, but probably
the same :-) we have tickets describing in great detail how a specific
issue should be solved, but there is never any results from such posts. So
today I simply ignore long tickets or solution descriptions.

Same for questions. If it takes too long to understand a question I ignore
it. So keep the question short, but nevertheless provide the information
which may be necessary. Note, that usually you will not know which really
is necessary.

An anecdote: Lots of years ago it took me 2 days to create a bug report
describing in detail a strange bug. The author of the software had a short
look and found the bug in 10 minutes. He said that without that
information it would have taken days to find the reason. It was a very
small detail which helped him, which I would never have thought relevant
at all :-)

If you still don't find anything: #10562 should be easy and you would make
one of the users of one of my trac instances happy. :-)

P.S. I get constantly the question when to use mailinglist and when
ticket: When there is the slightest chance that information may be
relevant for others even if you stop implementing, then add it to the
ticket (If necessary repeat it in mailinglist a little bit later). If
questions are for your own learning, ask in mailinglist.

[Christian Boos]

Hello,

FYI:

On 10/7/2012 8:06 PM, Christian Boos wrote:
> Therefore I suggest the following, adapted from basic-workflow.ini:
>
> [ticket-workflow]
> leave = * -> *
> leave.operations = leave_status
> leave.default = 1
>
> assign = new,assigned,reopened -> assigned
> assign.permissions = TICKET_MODIFY
> assign.operations = set_owner_to_self
>
> resolve = new,assigned,reopened -> closed
> resolve.permissions = TICKET_MODIFY
> resolve.operations = set_resolution
>
> reopen = closed -> reopened
> reopen.permissions = TICKET_CREATE
> reopen.operations = del_resolution
>
> + keeping the change_owner and change_resolution we already have.
>
> The [milestone-groups] would be the one from basic-workflow.ini,
> resulting in "assigned" tickets being shown in yellow.

This workflow is now in place.

> And this brings me to a semi-related topic: triaging woes...

Adopted the suggestion to create a milestone for hard to triage tickets
("undecided").

-- Christian

[Remy Blank]

Christian Boos wrote:
> On 10/7/2012 8:06 PM, Christian Boos wrote:
>> Therefore I suggest the following, adapted from basic-workflow.ini:
>>
>> [ticket-workflow]
>> leave = * -> *
>> leave.operations = leave_status
>> leave.default = 1
>>
>> assign = new,assigned,reopened -> assigned
>> assign.permissions = TICKET_MODIFY
>> assign.operations = set_owner_to_self
>>
>> resolve = new,assigned,reopened -> closed
>> resolve.permissions = TICKET_MODIFY
>> resolve.operations = set_resolution
>>
>> reopen = closed -> reopened
>> reopen.permissions = TICKET_CREATE
>> reopen.operations = del_resolution
>>
>> + keeping the change_owner and change_resolution we already have.
>>
>> The [milestone-groups] would be the one from basic-workflow.ini,
>> resulting in "assigned" tickets being shown in yellow.
>
> This workflow is now in place.

The workflow has the somewhat funny property that it shows the following
entry for tickets assigned to me:

o assign Next status will be 'assigned'.

I know why this is so, the worklow system doesn't check with all
operations to see if any of them would actually do something. But maybe
someone has an idea how we could fix this.

Also, I miss being able to assign tickets to someone else. There's
nothing like offloading a big piece of work on somebody else :)

-- Remy

[Christian Boos]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/18/2012 10:38 PM, Remy Blank wrote:
> Christian Boos wrote:
>> On 10/7/2012 8:06 PM, Christian Boos wrote:
>>> Therefore I suggest the following, adapted from
>>> basic-workflow.ini:
>>>

>>> [ticket-workflow] ... assign = new,assigned,reopened ->
>>> assigned
>>>

... as this contains `assigned -> assigned` we have ...

> [...] the somewhat funny property that it shows the following

> entry for tickets assigned to me:
>
> o assign Next status will be 'assigned'.
>

Right, this is useless, so we should just have:

assign = new,reopened -> assigned

>
> Also, I miss being able to assign tickets to someone else. There's
> nothing like offloading a big piece of work on somebody else :)
>

... and for that:

- - change_owner = closed -> closed
+ change_owner = assigned,closed -> *

Enjoy! (but with moderation...)

- -- Christian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQEcBAEBAgAGBQJQgQRGAAoJENf0XkEiCfY2KVIH/3yJQ4Gr2ol2AFjsjpdecdQr
hZ66IOThFyfbsP68q70wijEkEaR6HTPEGjNhqmofAQ0FSyp4TZWJGx4260+OZtN9
cxj8960qdSTOkF/fmjr4nF7KKkFs4B9Gt69+SHClQS0YjWRv0iWkygFZCK+qtL6g
90Gi7zFUqon+XyxWB3T5pvJtCb1UVqUum46sQjJ8aoI8sCQdsNfbfzMhHqKvDeY0
TO+8jqR0O/GaEG2yZFOE1RbN+VCMCs2ZOuwvi+RFkFASbr9T8JZZKzL9ZvbRSFTh
yG1yL4gAjbiRL49dMN5Gm+rHLdI1+O1H6LGO3di4urhgPUDfB4UlRv/NvMI2q+g=
=CLyO
-----END PGP SIGNATURE-----

[Remy Blank]

Christian Boos wrote:
> Enjoy! (but with moderation...)

Thanks!

I have noticed another cosmetic glitch: since you added the colon at the
end of the hint, there's now a lone grey colon to the right of "leave as
opened", because the hint is empty.

-- Remy