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.

[ajpiano]

Though I like the idea of GitHub issues, the point is that we are planning to add support for other code hosting sites besides GitHub. We'd have to come up with a separate way of notifying BitBucket users if it's a Bitbucket repo, etc...

It isn't a matter of having a "Certain level of experience with github," which obviously is required if you're using GitHub... using issues is certainly less complicated than actually maintaining a repo ... it's whether we want to come up with slightly different notification methods for different services, or come up with a way of doing it that isn't specific to a particular service

[gnarf]

If we are using github to deliver the message, Issues aren't the best option. Not all repos (note jquery/jquery) have Issues enabled. Commenting on the commit that is the tag seems to make the most sense.

[buzzedword]

@ajpiano i see what you're saying. However, from a programmatic standpoint, what's stopping you from planning out a messaging class that can be mutated depending on who the hosting site is? That way, as you add support for further coding sites it's simply importing the configuration needed to connect to their API, while you already have an abstracted messaging service?

While we're talking architecture, building an abstraction layer for notifications would address communication altogether, and would make it relatively simple to pivot and add entirely new services to the mold. My mistake was assuming that one had already been built. I'll look over the codebase some more and see if I can come up with a more constructive comment.

[gnarf]

@buzzedword - Interested to see what you have to say.

Just to re-iterate what I and @scottgonzalez have said: email is less than ideal because it requires actually being able to parse the manifest file and get an email, which isn't a required field.

Github comment on tag SHA only requires there is a tag with a SHA, and the project is on github.

If an e-mail for a maintainer/author is available from a manifest (even from a previous version?), I suppose it also makes sense to send an e-mail.

It does seem like we will want a general case "notifier" module that can load up the github/email/bitbucket/etc modules and notify in the best available way.

[Mottie]

I was just thinking, why save a log? Maybe I'm missing something, but I don't see any reason why someone would need to search through the log history if they are actively troubleshooting the problem.

Why not just show the last 5 minutes or so of log entries on some page at plugins.jquery.com. So, if someone is having a problem, they can click on the test hook and just watch for an update.

[danheberden]

@Mottie, we'll probably only keep the latest like 500 lines of the log file for the sanity sake - having some back-log is necessary, obviously. As for the full log internally, that's helpful for when we need to find out what kind of crazy bug or problem is present.

[scottgonzalez]

While we're talking architecture, building an abstraction layer for notifications would address communication altogether, and would make it relatively simple to pivot and add entirely new services to the mold. My mistake was assuming that one had already been built.

@buzzedword The code does have this level of abstraction.

I was just thinking, why save a log? Maybe I'm missing something, but I don't see any reason why someone would need to search through the log history if they are actively troubleshooting the problem.

Why not just show the last 5 minutes or so of log entries on some page at plugins.jquery.com. So, if someone is having a problem, they can click on the test hook and just watch for an update.

@Mottie Pressing the test hook button won't help you diagnose a problem that occurred in the past. Tags are not re-processed.