Proposal: Add an autolabels section to DEREK.yml to automatically label issues

[rgee0]

Add an autolabels section to DEREK.yml so that any issues raised containing the words within this section are automatically labelled:

e.g.

autolabels:
    - proposal
    - question
    - enhancement

Also add - autolabels to the features section to enable/disable

[alexellis]

This would be useful for us - will it be generic enough to support the requirements from Puppet?

[rgee0]

The Puppet requirement may require a mapping:

autolabels:
    - keyword: 'labelToApply'

This would provide a greater level of flexibility.

[alexellis]

Valid YAML may be:

autolabels:
    - name: keyword
       value: labelToApply

Still.. let's work to an MVP before embellishing - I'll post this into the #derek channel

[davejrt]

As a first step this looks great. We've got some other unique requirements at puppet that we may end up needing later down the track, so notifying someone on a PR if their unit test didn't pass in travis...or they've not included a puppet manifest, the puppet version, OS version in the text in their issue. Based on that we might want Derek to comment and say, you've not included this, in much the say way it responds to PRs now that don't have dco sign off

[alexellis]

Ok.. do you have some examples of the labels you'd like @davejrt ?

[davejrt]

Bug
Enhancement
Question

Those are probably the three we use most commonly.

[alexellis]

Same here.. these are quite subjective labels though. One thing I wanted to start for OpenFaaS was labelling for different areas.

area/swarm
area/kubernetes
area/watchdog

etc

[alexellis]

We ask for the information on the system in the issue template so the auto-labels here would be really useful from the start. (via @rgee0 )

[alexellis]

Since Derek had some original inspiration from Docker's Poule tool by @icecrime I thought we could refer to Arnaud's concept on a keywords -> labels mapping:

https://github.com/moby/moby/blob/master/poule.yml#L23

What do we think?

[rgee0]

I think the approach makes sense, albeit configured via the yaml for versatility