improvements for transferred issues

[devoncarew]

Improvements for transferred issues:

• if an issue has comments (apart from the initial body), feed the last comment into the prompt; this may help classification for transferred issues, which have presumably already had some discussion
• separate from this PR, delay a bit before triaging an issue: https://dart-review.googlesource.com/c/sdk/+/373020
• add some verbiage around 'take your time...' for the triaging prompt (this may improve the classification results?)

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

[github-actions]

PR Health

Breaking changes ✔️

Details

Package	Change	Current Version	New Version	Needed Version	Looking good?

Changelog Entry ✔️

Details

Package	Changed Files

Changes to files need to be accounted for in their respective changelogs.

Coverage ✔️

Details

File	Coverage

This check for test coverage is informational (issues shown here will not fail the PR).

API leaks ✔️

Details

The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.

Package	Leaked API symbols

License Headers ✔️

Details

// Copyright (c) 2024, the Dart project authors. Please see the AUTHORS file
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.

Files
no missing headers

All source files should start with a license header.

Package publish validation ✔️

Details

Package	Version	Status
package:dart_flutter_team_lints	3.1.0	already published at pub.dev
package:firehose	0.9.0	already published at pub.dev

Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation.

[mosuem]

(Just curious) Why the limit, if we have a huge context window available?

[devoncarew]

I think this is me being defensive? I can get some data, but I suspect that 90%+ of comments fit in this limit, and the ones that don't are almost always something like a little bit of content and a huge amount of pasted stack trace.

We could keep this as is, raise it substantially so that it really is only protecting against sending in too many tokens, or only have this size limit apply when we're tuning the model (which does have an overall size limit for the tuning data).

[mosuem]

I would put even more pressure on the LLM ;)

[devoncarew]

I do wonder if this phrase will make it spend more consideration on the response. I have heard that phrases like 'show your work' will make it produce more tokens, which effectively means that it's using more computation, which may then yield a better result.

I'm not sure that it'll help us here since the classification response is only ever going to yield ~1/2 dozen tokens (area-foo, type-bar).

[mosuem]

I don't know the first thing about prompting, but maybe add some more instructions, similar to what you wrote in this PR description? Something like This comment might contain helpful information for triaging, but if not, ignore it... or similar?

[devoncarew]

sgtm; I'll word-smith this a bit.