Issue triage guidelines

[tmeasday]

Given a variety of contributors, it might be a good idea to put together a basic algorithm for issue triage (and decide on a set of labels, etc).

Meteor's issueTriage.md is probably more complicated than what is needed here, but helped in guiding community members to get the number of open issues down from 1000+ and growing to around 600 (a major achievement, let me tell you!), so could be worth looking at for ideas.

So maybe it's best to start with some decisions. I'll post them as separate comments so folks can respond with their opinions.

[tmeasday]

Do we want people to ask questions / ask for guidance in issues?

[tmeasday]

Do we want people to open issues for permission/advice before creating PRs for new features?

[tmeasday]

[If no mono-repo] - do we want to be pedantic about which repo people open issues on?

[ndelangen]

I think it's way too complex to keep track of issues across many repo's. 1 of the reasons I'm in favour of a mono-repo.

[ndelangen]

I think any well-written PR should be enough, no need to write a issue first if someone proposes a fix or new feature.

[ndelangen]

Guidance via issues is something we should be doing, for now.

[ndelangen]

@tmeasday Anything actionable from this issue? How would you like to add this?

[tmeasday]

I'd like to add some simple triage guidelines to the contributing.md file. I can have a go at a pr

…

On Mon., 3 Apr. 2017 at 3:40 pm, Norbert de Langen ***@***.***> wrote: @tmeasday <https://github.com/tmeasday> Anything actionable from this issue? How would you like to add this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#733 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIFyuc_4c9pxvi9z9lE8zZ6ASdBoD3Lks5rsIY8gaJpZM4Mtz8W> .

[tmeasday]

See #748