Clarify contribution expectations in contributing.md

[jmcook1186]

Sub of #657

What
Update contribution guide top better explain what contributions we want to see and how to improve the likelihood of a contribution being accepted.

Why
As a user I want to understand the ways I can best contribute to the IF and what the contributor experience will be like. This will help me to contribute more effectively.

Context
We want to make it very clear to all users what contributions are most valuable and what the contributor experience will be like. This includes setting expectations around response times, being clear about what we consider to be in our (core team's) remit to maintain, what quality thresholds will be applied to pull requests, how to identify good tasks to work on, where to ask questions, etc.

Here are some salient points from our internal discussions:

• To build up the IF ecosystem we need to make sure people know what they can use with some confidence it will work ok, and where to find the cutting edge code that might be more untested and more likely to be buggy, but with the latest features.

• Signs that issues are open to work on should be very obvious. Labelling is fine - but we should move from help-wanted to a combination of good-first-issue and core-team-only - everything not tagged core-team-only is implied to be available for community contributors, with good-first-issue being especially suitable for first time contributors.

• Here’s an example of good practise in contribution management from Django, for inspiration: https://docs.djangoproject.com/en/dev/internals/contributing/

• we should also be clear about which issues are for the core team only, maybe with a core-team-only label

• likely process for unsolicited PRs:

  • PR triage to determine whether the changes are ones that we might want to merge into the target repo. Then full dev review and QA testing in advance of merging. Willingness to delay decisions about merge-ability beyond a single PR triage call if necessary. manage expectations that unsolicited PRs might sit on the backlog for multiple weeks while we mull them over, and might just get closed out.

• add guidance to the contributing docs about how to stay engaged and take next steps after completing a good-first-issue

Prerequisites/resources
None

Statement of Work

Update contributing.md with clear guidance on:

• labels
• our triage process and acceptance criteria
• next steps for engaging more with the project
• guidance on what type of contributions we want, and what we are unlikely to accept
• clear explanation about plugins and the preference for plugins to stay in third party repositories

Acceptance criteria

• ...
• ...