Skip to content
New issue

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

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

Already on GitHub? # 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!

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

No branches or pull requests

2 participants