Inform user of errors

[scottgonzalez]

If there are user errors during processing, we should try to notify the user. We can get the user's email address from the post-receive hook. We should only notify on real problems that the user would care about; we definitely don't want to be spamming users.

[dnschnur]

An alternative to email might be to automatically open an issue in the project's Github tracker, update it with comments for any subsequent errors, then close it when the submit succeeds.

The downside is that this doesn't work if the project has issues disabled. In that case it would need to fall back to email or adding comments to the last commit for project.jquery.json.

[gnarf]

I like the commenting on the commit via github option... There is a @jquerybot user that we could use for this.

[ajpiano]

I think just doing e-mail straight up is a slightly better option, as it doesn't tie us to GitHub specific functionality....

[scottgonzalez]

We can do that, though users aren't required to provide an email address. I think commenting on the commit is ideal. We can have different behavior for different services. But starting with email seem good, since it's universal.

[gnarf]

I've been thinking a lot on this one...

• E-Mail works if we have an E-Mail, but the github commenting seemed SUPER effective when I went through and did it by hand.
• Commenting / emailing on tag commits with manifest parsing errors makes a lot of sense.
• For "other" errors, like bad tags (not semver), no manifest file found, etc. We might need to actually store an "outcome" for each tag in the repos sqllite db and hook some way to put in your repo information to look up errors.
• Splunk might be able to help? cc @clarkbox - These messages should all be stored in splunk and we should be able to go back and search for these things, could we provide a "report api" where people ask for the report on a repo and get it?

[johnnyfreeman]

ANYthing would be helpful! This is just torture.

https://twitter.com/prsjohnny/status/292000244818907136

Btw, I think the issues idea would be awesome! +1

[dnschnur]

In fairness, the manifest spec-file is very accurate and well-written; every manifest problem I've had boiled down to not having read the spec carefully enough. That said, there's enough room for little mistakes to be made that it's just plain difficult to get everything perfect if you're not already familiar with it.

[Mottie]

Why not just make a twitter account and post errors there. Then you can just search for your plugin.

Derp... that's what issue 82 is all about.

[scottgonzalez]

Why not just make a twitter account and post errors there. Then you can just search for your plugin.

Do you really think that's a good idea? Why would we go through the trouble of posting to Twitter when we can contact the developer directly via email or GitHub? Who would ever want to subscribe to such a feed?

Derp... that's what issue 82 is all about.

No, #82 is about announcing plugins that have been successfully added. It's a feed of plugin announcements.

[Mottie]

@scottgonzalez Who gets contacted? The author, maintainer(s), person who did the last push or everyone?

I'm asking because I still can't get AnythingSlider to register... =(

[scottgonzalez]

Right now nobody gets notified. That's what this issue is all about. If you're asking for help with your specific plugin, this is not the place. If you have input about who should be notified, we'd be happy to hear it.

[buzzedword]

+1 for github issues. If the plugin is being published through github, the argument of "tying it to github functionality" is void-- a certain level of experience with github is expected to publish a plugin to get a high quality experience. Anything less than that will only hamper efforts to provide feedback to plugin authors.