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
While looking at bugs I notice that people currently report bugs in snaps against the “snapd” project in launchpad, e.g. https://bugs.launchpad.net/snapd/+bug/1782989 - I wonder if this is because there is no way to contact the snap publisher. It would be really nice if we could make add something mandatory. Having ratings&reviews might also help here, even if those are not meant to track bugs at least it provides some sort of feedback channel to the publisher.
To further bolster this argument. I recently had feedback from a developer who was frustrated by our platform. A third party had published his software in the store, but hadn’t provided any details for contact or support.
The upstream developer got erroneous issues in their bug tracker for a snap they never published, and have no way to contact the person who did publish the snap. I’ve seen this multiple times over the last few months.
This is causing developers to be frustrated with our platform, and one reason they gave why they would be less likely to consider snapping their own packages in future.
2 Likes