See https://go.dev/doc/contribute#commit_messages , The rest of the description elaborates and should provide context for the change and explain what it does. Write in complete sentences with correct punctuation, just like for your comments in Go. Don't use HTML, Markdown, or any other markup language.
Does this mean that the Contribution Guide need to be revised?

Hi @qiulaidongfeng, I think that section of the Contribution Guide is talking about avoiding HTML and Markdown in commit messages, vs. Russ above is talking about automatically editing GitHub issues.

@qiulaidongfeng The bot accidentally edited your PR description, because GitHub pretends that every PR is an Issue. The bot is only meant to be editing Issues, and I changed it to explicitly ignore PRs. Apologies!

For example :
@gabyhelp rewrite

CL 512155

[CL 512155](https://go.dev/cl/512155)

[CL 512155](https://go.dev/cl/512155)

Yes, that's the PR that it accidentally edited. Again, my apologies.

This post by @gabyhelp is definitely useful: #67943 (comment).

In #68028 (comment), it's visible that gabyhelp currently doesn't filter out PRs in the list of potential "similar issues", which it probably should. GitHub API treats issues and PRs similarly, but PRs are a subset of CLs.

I think the only issue is the title (Similar Issues). In general if something is very related I think we should surface it. If an issue gets filed and gabyhelp posts hey there is a PR that seems to be about this issue, that's very helpful. The plan is to include all Gerrit CLs eventually too. (At that point we'd probably want to deduplicate GitHub PRs against Gerrit CLs.)

@gabyhelp 's success is more about GitHub search being a big fail.

As an example I have just filled #68102 because a search of GOBIN didn't show anything relevant. See https://github.com/golang/go/issues?q=is%3Aissue+GOBIN+-author%3Adolmen

I agree that this feature is definitely useful, and I also agree with it being mostly useful because GitHub search is borderline useless¹ at this point.
What I'm a little confused about is the line at the bottom of the comment; "Emoji vote if this was helpful or unhelpful".
In my case it did not show any duplicates, however the post was definitely helpful in that it affirmed that I did not miss any.
Am I supposed to react to this?
In technical terms, a true positive is of course good, and a false negative is bad, but if the list contains only (close enough) false positives when there is no true positive, should that be counted as a true negative?
Maybe a different emoji for that, and a clear guidance on which emoji to use for what?

Though I understand if that'd be too much noise for people who don't have my particular set of 'tisms, just my 2¢ here.

Indeed. Thanks for the reminder. Done! And apologies again for having the internal-vs-external split at all. I'm just as annoyed by it as all of you. (It's literally just the same site with a different URL to force a different, stricter authentication path.)

@prattmic This should be fixed now.

On the other hand I miss the github's formatting that shows whether the issues are closed or not clearly, and gets updated. Is there a way to mix both somehow?

Sure. Once I get better tests written I will add "(closed)" markers.

@rsc but that doesn't cover "and gets updated" part. I guess the "(closed)" markers will just be a snapshot of the state at whatever time the bot processed that comment?

IMO all these options are worse than going back to the initial state where we let GitHub dynamically format the issue links and sacrifice a bit of readability in the emails.

Just found this thread and would like to +1 the idea to unfurl github links in comments.

Related, I would love if it could add syntax highlighting to existing code-blocks that don't have it. It makes it so much easier for me to read when the highlighting is applied.

@seankhliao Can you point to specific issues with this problem? Thanks.

@deefdragon Different people have different but very strong opinions about syntax highlighting. I'm going to focus on clearer wins.

• unfenced code: Bug Report: JSON Deserialization Case Sensitivity Issue in Go #67689 , runtime: time.Sleep problem on Windows 10, but not Windows 7 or Linux #61042 , go v1.17.x breaks the (os.exec) Cmd.Start() functionality on Windows #49044
• unfenced stacktrace: net/http: Transport memory leak #43966 , Panic when trying to serve http with embedded assets #43761
• jira style(?) code blocks: crypto/rsa: can generate digital signature when hash algorithm (digest method) is set to MD5 in FIPS mode #45565

you'll need to look at the edit history for these, since I found them with a google search of "edited by seankhliao"

In #67948 (comment), the similar issues were not helpful.

The first listed issue, #56471, is very related -- as I wrote in the description, I created #67948 as a spin-off from #56471. Perhaps gabyhelp could be updated not to list issues which are already mentioned in the description?

The other four listed issues are superficially similar but not actually related in a useful way.

I probably share your skepticism and concerns, but I don't fully understand the specific scenario you are concerned about. Can you say more?

I think one thing I don't want to happen is a bot ask me clarifying questions, for example.

Another example of something I've seen LLMs used for which I consider insulting would be a bot re-phrasing comments.

I guess personally I'm mostly fine with AI use-cases I'd call "classification" but would feel patronized by any use-case that tries to emulate (or interlope in) human interaction.

@rsc I don't envision a scenario. For me, it is a purely aesthetic matter: I have personally sworn not to interact with AI in my life. So when it becomes prevalent on this forum, I will have to leave. In this sense I feel getting alienated.

@rsc I don't envision a scenario. For me, it is a purely aesthetic matter: I have personally sworn not to interact with AI in my life. So when it becomes prevalent on this forum, I will have to leave. In this sense I feel getting alienated.

aesthetic or more like esoteric?

I think in the long term yes we'd want it to be able to do everything the current Gopherbot does. Right now we're focusing on what it can do that's new.

Thanks @seankhliao, you beat me to it. It would be nice if gabyhelp could recognize issues that are 'process'.

I already disabled it on watchflakes issues, and I will disable it on backports issues too.

I am happy to disable it on gopls release issues too. Is that any issue with title prefix "x/tools/gopls: release version v"?

@rsc yes all gopls release issues follow that format.

Thanks. Updated to skip both backports and gopls releases:

	if strings.Contains(issue.Body, `— [watchflakes](https://go.dev/wiki/Watchflakes)`) ||
		strings.HasSuffix(issue.Title, ` backport]`) ||
		strings.HasPrefix(issue.Title, `x/tools/gopls: release version v`) {
		continue
	}

Eventually we will hopefully be able to tell the bot to do this kind of thing. 😄

also package removal requests?
#68003 (comment)

Filed golang/oscar#37.

While I agree that linking to other approver issues isn't helpful, it actually is helpful that it linked to your prior may-start-trybots issue. (Though just having the issue title isn't great since it isn't obvious that it is your issue).

Fair enough

Though just having the issue title isn't great since it isn't obvious that it is your issue

Yes got me

Thanks! I see gabyhelp's comment doesn't bring new info in this specific case.

On the other hand, when there are already existing reports or the breakage was actually a reoccurring bug, or if the mentioned CL turned out to be causing other issues, the related issue feature could surface them and be helpful (of course, if that can be done correctly).

Thanks! Filed golang/oscar#63

Thanks! Filed golang/oscar#62

Bug is gone.

#71362 i think should be a bug report (like some others when people are too lazy to fill out the bug report template), and I would have expected the bot to make the same judgement (rather than just copying the proposal label).

I feel like the labels it manages can be somewhat redundant with all the other labels we have

perhaps it could instead manage issue types rather than labels?
https://docs.github.com/en/issues/tracking-your-work-with-issues/configuring-issues/managing-issue-types-in-an-organization

I've noticed that on some issues it has added the "LibraryProposal" label without also adding the "Proposal" label.

I'm not sure if that was intentional, but I'd personally like there to be one label that is present on all proposals regardless of what they affect, even if there's also more specific labels like "LibraryProposal", just because that makes it easier to quickly construct a filter to help answer the question "was there already a proposal for something like this?" while excluding all of the bug reports, etc.

@apparentlymart A bug may be related to a proposal without being a proposal. For example #74757 is a bug related to the #ToolProposal feature, but isn't a proposal.

I was kinda amused when this summary appeared while I had already been working on a manual summary in an earlier comment.

Subjectively, I think the generated summary was easier to consume than the huge list of links I ended up with. However, I must admit that I didn't actually try following most of the links because I thought I could guess what they were linking to based on what I already had in my head from writing my summary manually.

The "off-by-one" errors in the linking are unfortunate, but I did still enjoy the text summary of topics that had already been raised since GitHub had already hidden most of the discussion and so the issue degenerated into the same comments made over and over again. It seems like that slowed a little after the summary appeared and the discussion switched to some new topics, but the summary is now also hidden by GitHub and so duplicate remarks seem to have started again. It's unfortunate that GitHub doesn't have a concept of "pinned comments" that are prioritized for display regardless of how many other comments there are.

FWIW as someone that hasn't read the full discussion but is familiar with other similar previous proposals, I felt that the gabybot summary was useful and saved me a bunch of time. I feel that I know where the discussion has gone and know enough to decide whether I would like to contribute or dive deeper.

Not for CL NNNN, only CLNNNN or CL-NNNN (no spaces allowed).

Cc: @jba