Push less towards creating releases after merged PRs

Description

In first-published-tag-for-merged-pr a suggestion is shown to create a release on merged PRs. This suggestion:

• takes quite much attention (with page wide and background color) for something not every repository uses
• makes no sense for repositories which don’t use releases

There’s some discussion in https://github.com/refined-github/refined-github/pull/5769, to summarize:

I found the latter [showing existing release, red.] very convenient, but the new suggestion to create a release is really going in the way for a repo where I merge dozens of PRs daily and make tagged releases very infrequently

I also find the suggest to create a release quite annoying. Mostly on a private repo which doesn’t have any releases and won’t get any in the future either.

I don’t get the point. There are a hundred buttons that you don’t use on the page, are they all tempting you? There’s a big “Close and comment” button in every conversation, but you rarely do that. Should it be hidden?

---

I can see how useful the feature is for repositories which make heavy use of releases. My proposal is to see if we can improve the feature for repositories where this makes less sense. E.g. imho most private repos, or bigger repo’s with a slower pace of releasing.

Some ideas I can think of:

• Split the feature into showing an existing release and suggesting to create a release; this would make it easier for users to pick which part is useful to them.
• Hide the ‘create a release’ (or the whole check for existing release) when the repo doesn’t use releases at all, something similar already happens with the releases tab.
• Use a less attention grabbing UX for suggestion to create a release, for example a white background and a link instead of a button. (See prototype below.)
• Combine some of these things, e.g. less attention grabbing if the repository doesn’t have releases.

Screenshot

Example URLs

Example repositories where the suggestion to create a new release makes less sense (imho):

• 90% of the repositories at the company where I work (except a few that do use releases)
• All the repositories I use for static github pages (don’t use releases)
• https://github.com/torvalds/linux (don’t create releases so often / based on merged PRs)
• https://github.com/php/php-src (don’t create releases so often / based on merged PRs)

[fregante]

These two are good enough:

• Hide the ‘create a release’ (or the whole check for existing release) when the repo doesn’t use releases at all, something similar already happens with the releases tab.
• Use a less attention grabbing UX for suggestion to create a release, for example a white background and a link instead of a button. (See prototype below.)

[kidonng]

Kind of nit-picking, the Linux repo is not a good example, it’s just a mirror and doesn’t accept pull requests.

Back to the topic though, I think this feature is nice, but probably doesn’t fit our second rule. There are some users/repositories tend to do frequent releases (after 2-4 or even every commit), but that’s in the minority. This feature suggests creating a release after merging every pull request.

There are a hundred buttons that you don’t use on the page, are they all tempting you?

@yakov116 made a point:

This is a banner ot sticks out

This is the main issue here, banners are not something people should just ignore, and we don’t want to users to form that habit and make a “cry wolf” story.

There’s a big “Close and comment” button in every conversation, but you rarely do that.

I remember mentioning it somewhere, that depends on your workflow. But I would argue it is indeed used very often.