it is not one of the supported fields in v2 APIs for example afaict
Of course. I’m just saying, when the time comes to do this work, several projects need to coordinate.
It is indeed! We’ve just discovered this missing field while moving our API calls to v2.
1 Like
Thanks @mvo!
I prefer the first approach, so that it’s more obvious to developers what the field requires.
if you go with email-only fields, please keep the ability to set a subject via the entry like
mailto:ogra@ubuntu.com?subject=foobar
or add an additional “mail subject” field to the form that will get automatically used.
as someone who owns a bunch of snaps being able to distinguish/sort via the mail subject is very helpful.
@mpt The store already has an email for the account, so we can already get in touch via email with anyone if that’s necessary.
That said, forcing people to provide an email that will be made public sounds unwise as people often won’t have that email and won’t want to make their own email public.
On the other hand, forcing people to provide a URL instead of an email is also not a great improvement, since a URL isn’t really a protocol that defines what kind of system will be waiting on the other side of the click.
So what we have is really something that tells a human being how to take the next step towards reaching someone that can respond for the snap. As such, I quite like the idea of leaving it up to the publisher to decide how they wish to be contacted in that specific case, with either an email or via a system pointed to by a URL.
@ogra That looks bad on a terminal and doesn’t copy & paste properly. One can easily filter that by customizing the email itself.
@niemeyer well, if you check i.e.
It gets masked as “Contact Oliver Grawert” in the store UI currently.
I agree it doesnt look particulary sexy, snapd also seems to be filtering out the mailto protocol prefix in the terminal output so the normal “ctrl+click” you can do on most modern desktops to auto-spawn the mailer from a terminal for protocol addresses sadly doesnt work (so yeah, the mangling makes you end up with a copy/paste job):
$ snap info mjpg-streamer|grep contact
contact: ogra@ubuntu.com?subject=mjpg-streamer
Despite its ugliness, I really like the current freedom the field gives me as a devloper/snap maintainer (and I actually get regular emails though the contact link with user feedback, so it cant be too bad) and i’d be happy if it could be kept that freely configurable.
What if we provided a “contact the developer” form instead of using mailto at all? No need to worry about the subject anymore.
@noise We need to filter out the field to at least prevent it from being set to invalid email addresses as done in the example above.
@kyrofa Then you force people to reply to emails instead of allowing the project to be contacted as it usually is. I expect this will usually point to a tracker of some kind.
i assume you mean me not @noise above …
the url is perfectly valid under the XDG specification and will be handled fine by xdg-open (which the “ctrl+click” action normally hands it to), you can try it yourself with running:
xdg-open mailto:ogra@ubuntu.com?subject=foobar
this will open the default mailer of your desktop with properly set recipient and subject lines.
1 Like
It sure does:
No, I really meant @noise there. This is logic we need in the store. We want a clean email for such cases, not a URL.
I agree with @kyrofa, if we have some mechanism of coordinating between projects which would provide the relevant notifications we could cascade the work more efficiently.
Also, snapcraft should be the last project where these keys are added as it is the most user (developer) facing component of all the pieces and doing so before other components would accept it would just lead to a bad developer experience.
For testing an early adopters, there is always the option of using passthrough.
This field is not for Snap Store admins or notifications. It is for end users to contact the publisher by e-mail, if the publisher wants to allow that. Some publishers might choose to use the same e-mail address. I expect most commercial vendors would use separate addresses.
For example, on Google Play, Microsoft has one e-mail address for its Office apps, and separate e-mail addresses for each of its other apps.
I completely agree. That’s why I said “— optional”. A Web site would be required, but an e-mail address would not be.
Great, we’re aligned about allowing email, and making it optional.
Why would we force people to provide a web site? What if one doesn’t want to provide it? As in, “I don’t want to be contacted about this software”. It seems better to have an empty field than http://example.com.
We’re still talking about the “contact” field, right?
Making a webpage public is probably easier than an e-mail address, for example a Facebook fanpage would work.
That’s still an artificial way to enforce the publisher to establish a contact point. It’s not about how hard it is to create a web site. This is an informational field that allows publishers to inform how they wish to communicate about the given snap with the general user, where not wanting to establish a public contact point also sounds like a reasonable answer to this question.
If we ever want to establish an enforced contact point, it’s easy to add a form to the snap page that delivers a notification to the publisher, privately and without the need to disclose any private information.
1 Like
I don’t think it matters whether the mechanism is artificial. For example, snapcraft complains that 'version' is a required property if you omit it from snapcraft.yaml, though in theory snapd and snapcraft could (afaik) function quite well without it. It’s required merely because it’s highly informative to end users.
I’m not wedded to making the Web site field compulsory. I do think it would improve the overall quality of the store, in three ways:
- reducing the number of people who, determined to contact an app’s publisher, would end up contacting store admins by mistake
- reducing the number of people who, determined to contact an app’s publisher, would post a dummy review for that purpose
- providing a much more expressive medium for publishers to convey their credibility (domain name, security cert, design quality, support resources… ) than snap pages /
snap infoalone could ever do.
But maybe the cost of making the field compulsory (more effort required to release a snap) would outweigh the benefits to the store, at this point in the snap platform’s development.
1 Like