Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

check_win_devel interface is "too cute" #2520

Open
MichaelChirico opened this issue Jun 28, 2023 · 2 comments
Open

check_win_devel interface is "too cute" #2520

MichaelChirico opened this issue Jun 28, 2023 · 2 comments
Labels
feature a feature request or enhancement

Comments

@MichaelChirico
Copy link
Contributor

I'm trying check_win_devel() on a package for which I'm not the primary maintainer.

Thus, the default behavior (e-mailing the primary maintainer as pulled from the DESCRIPTION) is not what I need -- I need to specify email= instead to temporarily override the primary maintainer.

My experience would have been much better if this option were made evident to me from the prompt -- the current UI gives 2/3 "no" options and 1 "yes" option, strongly implying that there's no way to avoid using the DESCRIPTION maintainer!

I ran check_win_devel() three times before resigning myself to "OK, I guess we'll have to send the report to the primary maintainer then..."

Only later did I think "Oh, maybe there's an option for setting the email?"

The easiest way for improvement here would be to at least mention the other option in this prompt:

if (interactive() && yesno("Email results to {.strong {email}}?")) {

Even better, IMO, would be a 4th option "4: Choose another maintainer", where we either enter the e-mail directly for this first prompt or as a response to a follow-up prompt.

@jennybc
Copy link
Member

jennybc commented Nov 2, 2023

Yes I agree your suggestions would be nicer, but require a lot of custom code beyond the current use of the existing multi-purpose yesno() utility. Maybe a compromise would be to alert the user to the email argument if they say "no". That would have shortened your saga to 1 attempt.

@jennybc jennybc added the feature a feature request or enhancement label Nov 2, 2023
@MichaelChirico
Copy link
Contributor Author

Yes I agree your suggestions would be nicer, but require a lot of custom code beyond the current use of the existing multi-purpose yesno() utility. Maybe a compromise would be to alert the user to the email argument if they say "no". That would have shortened your saga to 1 attempt.

that makes sense to me -- it solves the primary issue here which is the current setup distracts the user from the possibility to check if there's an email= argument. And we can leave the more elaborate design as a nice-to-have in case of a refactor down the road that would make it easier to incorporate.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature a feature request or enhancement
Projects
None yet
Development

No branches or pull requests

2 participants