Decide how to go forward with caine

[piscisaureus]

A github bot is useful but caineio was too spammy to be enabled in this repo.
Discuss with the TC what we expect it to do.

[domenic]

It would probably make more sense if this repo was used only for bugs, not for e.g. TC agendas or feature requests.

[TJkrusinski]

I've been watching the issues and PRs that have been coming through for the lifetime of the repo thus far and from an outsider-looking-in-perspective, caine (for it's short life) made understanding the issue from a high level and what the issue addresses, quick to comprehend. It also forced the issue authors to be specific as to what they want, or care, to share / contribute. I think if it were a bit less chatty it would be useful, especially trying to combat the things that caused nodebug to have to exist.

[rvagg]

Caine makes sense if we accept it as an evolutionary tool. It's too spammy for now but we only know that because it's been put in action and now it'll be fixed (somehow).

@indutny perhaps you should put a link to Caine's repo in the message it gives so people can contribute to it as well where they see obvious problems.

[kenperkins]

For those who care it's https://github.com/indutny/caine/issues, I've added a few pain points I've noticed as issues.

[chrisdickinson]

My primary issue with Caine at present is that it sets up a less-than-optimal "first experience" for folks submitting issues to the repo: it's the equivalent of calling customer service and having to go through an automated phone carousel. One doesn't leave with the impression that one is particularly important to the folks running the phone carousel. Categorizing, labelling, and assigning can be done in a much more friendly way by humans, I think.

What I'd like to see from Caine is a way for it to passively monitor issues and PRs and keep them from falling through the cracks -- by being able to address caine directly with commands like "caine: if this issue isn't updated within a week, close it." or "caine: remind me to check in on this PR in ."
In general, keeping the bot to a "only speaks when spoken to" rule of etiquette would be nice.

The other option is privilege escalation for non-contributors so we could emulate that long-desired github feature of "collaborators with issue management access without commit bit", but that seems like a shaky proposition.

Ultimately, I'd like to see a document added to the repo that covers PR review and issue management -- one that sets the tone for what's expected of folks with that responsibility -- and for more folks to be given a chance to contribute in that fashion.

[benjamingr]

What Angular does is really nice:

You have a markdown file explaining how to use it but in addition there is a GitHub app in which you fill things out in a form (or select from a dropdown for that matter) and it posts the relevant comment in the issue for you.

[indutny]

The idea of Caine is to free the hands of maintainers and remove manual repetitive labour. We could make it use markov chains to generate more unique and friendly text :)

Jokes aside, you may not have been experiencing this with node or not be tired of it, but the email storm that I get everyday makes me absolutely unhappy and unwilling to go through it. Sometimes inbox goes up to 120 emails, and most of it is not the stuff that I should/may care about.

Getting this things auto-assigned should help us a lot.

[bnoordhuis]

I agree with @indutny. The daily email torrent is a special kind of soul crushing and it's easy to become indifferent to or burn out on. IMO, some kind of curating is in order. Whether that's a bot, a GH app or volunteer labor, I'm fine with that.

[indutny]

What is our latest stance on the deploying Caine for io.js?

If I got everything correctly there was two main problems: wider bucket list (suggested by Bert), and user interaction (suggested by Chris).

How could we resolve this and make (at least) my life easier? :)

[rvagg]

@trevnorris voted to move the discussion to GitHub

Those who have problems with Caine's operation should speak up here, otherwise I think @indutny should feel free to enable it again.

[chrisdickinson]

May I suggest we (collectively) try unwatching the repo before re-enabling caine? This reduces the notification emails down to those on issues which you've participated in, or have been cc'd into; I've personally found this approach makes it much easier to see when I'm being pulled into a conversation intentionally (vs. trying to divine that from a deluge of emails).

For a while, I'm happy to (loosely) triage incoming issues and CC the appropriate contributor, if issues falling through the cracks is a concern. Eventually we could adopt something like @piscisaureus's proposed "new" tag on all untriaged issues and split triaging duties based on day of week, or some other system.

One concern I didn't represent well during the TC meeting (probably due to nerves, sorry sorry!) was that caine's current operation increases my email load & makes it noisier / slightly harder to see which issues have actually been updated. If we can get it to the point where it's pushing things through the workflow (by automatically adding "new" labels / assigning to "triage'r-of-the-day" / auto-cc'ing maintainers of a subsystem when that label is applied), I'm totally in favor of re-enabling it -- I think the current implementation is a great step towards that, but I'd like to make it less noisy / less accosting before re-enabling it.

[mikeal]

I like the idea of issue automation but it would be better if it were entirely tag driven. The automated responder is a poor new user experience and I don't think it's too hard to just add a "unclear" when that automated responder is needed that can trigger it.

[domenic]

The automated responder is a poor new user experience

Agreed in general, although I think if it were reduced to say two sentences instead of a wall of text that could help.