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.

[indutny]

Ok, I guess that the caine is not the thing that we want for io.js after all.

The idea behind caine is a semantic CONTRIBUTING.md and tagging of the issues according to it. I don't really know how this idea could be extended to fix the issues mentioned here.

[phpnode]

it's a shame that github does not provide the facility to send a private message to the person who opened the issue / PR, that would make caine a lot less intrusive.

[indutny]

@phpnode Caine is actually removing all it's messages after tagging the issue, so the thing don't really clutter the issue, and for the rest there is an unwatch button.

[bnoordhuis]

I think @domenic makes a good point: caine just needs to be a little less flowery. One or two lines with maybe a link to a README with more details.

As to email noise, just create a filter rule for Michael Caine <notifications@github.com>; let's hope no real Michael Caine shows up. :-)

[rlidwka]

How about it accepting commands like @caine, tag this as XXX from people who are interested?

I mean, original bot accepted commands only from issue creator. If she is new here, she'll have to learn how caine works (on top of how io.js works, how to create an issue, etc.).

I'd propose to offload it to people who are familiar with and interested in io.js already. We have 500 watchers in this repo, surely somebody will find time to tag stuff (and maybe help people who created the issue in the first place).

In the other words, caine is fine, but the desired behavior for bots almost always is "don't speak, unless spoken to".

[phpnode]

@rlidwka totally agree, this way it gives contributors an easy way to help out without having to bug a member of the core team.

[cjihrig]

This has been sitting for a while. Any verdict on Caine? If not, this should probably be closed.

[Qard]

It'd be nice to be able to summon Caine for old-style reviews by just mentioning it in an R= line.

[Fishrock123]

How about a caine: review tag?

Also, I think we are generally doing a lot better just with more collaborators, but I may be biased.

[Qard]

Now that I think about it...maybe the functionality of Caine could be a command-line tool for all the new collaborators to use for catching simple stuff like commit message formatting and such.

[chrisdickinson]

It'd be great to build some new tooling around the issue tracker, but I don't think caine will be that tool. It may be worth discussing what that tooling looks like in a separate issue. It appears that the increased number of collaborators have done a good job of moving things forward (good job, all!)

If there are no objections in the next 24 hours, I'll close this issue.

[bnoordhuis]

For the record, I kicked @caneio from the org just now.