Create a hubot script package

[patcon]

DISCLAIMER: I am posting this issue on my own behalf, and do not reflect my company's final position on this.

EDIT: My company is now actively using this script: https://www.gittip.com/myplanetdigital

Currently working at a company (@myplanetdigital), that is trying to be supportive of the open source communities that help us do what we do. I have a personal goal of helping to integrate gittip into our culture.

Thinking it would be awesome to create a hubot script that allows anyone in the privileged company chat to contribute to projects/users from the company "pot".

Here are my thought on the rough spec. Would appreciate feedback :)

hubot gittip list: show all the ongoing tips
hubot gittip add: add a new tip
hubot gittip remove: remove an existing tip
hubot gittip edit: adjust an existing tip
hubot gittip [total]: get total dollar count of weekly giving

As a precaution, the weekly limit of the total gifts, should probably be set via an env var like HUBOT_GITTIP_QUOTA.

Thoughts? Thinking about MVP right now that solves what I understand to be our needs, and then maybe some nice-to-haves:

• keep track in hubot of who is the go-to person for each tip, so we have some accountability and context on who initiated which tip.
• To help with participation, we could perhaps figure out a way to let each person have a slice of the quota to pass on (doing this in hubot rather than on gittip itself).

cc: @balupton @RobLoach @yrassoulli @emarchak @arvinsingla

[chadwhitacre]

Fun idea! :-)

Does the Gittip tips.json API give you what you need for this?

https://github.com/gittip/www.gittip.com#api

[patcon]

Looks like it could do the trick @whit537! Thanks for a point in the right direction :)

[clone1018]

Here's what we're using for my NodeJS based bot if it helps you out any:

https://gist.github.com/clone1018/6894765

[patcon]

Thanks @clone1018!

[patcon]

Relevant thoughts potential usage of top_givers api call:
https://botbot.me/freenode/gittip/msg/7553666/

[patcon]

Super-messy, but it's doing to do the trick for us. I'll wrap it up into its own hubot script package soon :)
https://github.com/myplanetdigital/slackbot/blob/master/scripts/gittip.coffee

[patcon]

I'm hitting this issue with case-sensitivity. Anyone know a good way around it, or should I open up an issue to accept routes in the API with lowercase usernames?

https://www.evernote.com/shard/s27/sh/e74ba3a9-f7d5-48ff-95fd-c41e86e5d408/4c6d0cf518e2404d502e3a99c951215e

[balupton]

Open an issue. Case sensitivity is silly. ;-)

[seanlinsley]

Which part of the API is case-sensitive? public.json returns the same data for Gittip and GIttiP

[zbynekwinkler]

Usernames are stored case sensitive and so returned with user preferred case. On input gittip should accept any case and normalize it. If it does not, please open an issue. BTW: I have no idea what I am looking at with the evernote screenshot.

[patcon]

@seanlinsley redirects in the browser are one thing, but this returns a 302:

curl https://www.gittip.com/gittip/public.json

I suppose that following redirects could be handled in a client lib, but seems uneccessary complexity. fwiw github is caps insensitive:
https://api.github.com/users/PatCon

@zwn sorry, didn't give context given the issue context, but it's our chat bot, and we build the POSTed endpoint directly from the user input :)

@balupton will do 👍

[clone1018]

Hrm, I think we should still redirect the user to the proper URL. Serving actual results on a url that's not 1:1 with the database is :(

[balupton]

@clone1018 definitely, the proper URL should always be redirected to. I think the argument here though, is that by making the API case insensitive, like the way GitHub does, then both https://api.github.com/users/PatCon and https://api.github.com/users/patcon are both the proper URLs. In exactly the same way case-insensitive file systems work, as well as the GitHub API. For instance, if the database is case insensitive, like most file systems, then we wouldn't even be having this issue.

[patcon]

@clone1018

Serving actual results on a url that's not 1:1 with the database is :(

I'm genuinely curious, why is that? It would strike me as a pattern that only contributes rigidity. I haven't noticed that pattern in any respected services that I use. Sorry, I'm not trying to be confrontational, but I am curious :)

A singular example: https://github.com/PatCon

[clone1018]

I'm not sure I have an actual argument for or against, but it feels wrong. The only potential reason I can think of would be if a system used "username" as a unique, case-sensitive ID but that would be the failure of that system.

[patcon]

Here was a relevant convo in rails. People raised the same thought about urls being intentionally case-sensitive, but supposing there are cases where it isn't wanted, the solution there was to just tackle it in the router middleware and not bother redirecting:

http://stackoverflow.com/questions/2291907/rails-routes-how-to-make-them-case-insensitive

EDIT: Rats. Sorry, this convo should be in the other thread. Moving there.

[patcon]

Stubbed out a repo so I could add some issues without creating noise in this issue:
https://github.com/myplanetdigital/hubot-gittip

I'll close this issue when there's a full release on npmjs

[patcon]

Done and done. Cheers!
https://npmjs.org/package/hubot-gittip

[chadwhitacre]

💃

!m @patcon

@patcon How about linking this under "Clients" on the Gittip README?

[patcon]

Rockin. Can do, sir.

And I understanding correctly that it's a new header?
https://github.com/gittip/www.gittip.com/blob/master/README.md

[chadwhitacre]

I was thinking it could go under "API Implementations"?

https://github.com/gittip/www.gittip.com/blob/59ad6d709c10577359b7a13bb496942041375dad/README.md#api-implementations

[patcon]

Thanks. Assuming the "clients" comment is safe to ignore, but def let me know if I misunderstood.
#1666

[chadwhitacre]

@patcon Ah, yes, sorry. That was a mistake on my part, I mean "API Implementations." :-)