feat(labels): update labels

[JP-Ellis]

I thought I would create a draft PR to get the ball rolling for updated labelling of issues. This is definitely intended to be a conversation started, and has been mostly copied from one of my other repos.

This would work as follows:

• This repo's .github/labels.yml contains the definition the labelling of issues across the Pact Foundation organisation. The changes are not pushed to each repository, and instead each repository must pull the changes from this repo. This allows each repo to adopt this at their own pace.
• Each downstream repo can have their own .github/labels.yml definition which extends this repo's .github/labels.yml to suite their specific neads.

The labels come in broad categories:

• Area: Tracks the part of the code that is being affected. Some universal categories including CI, documentation and testing.
• ~Effort:~ An estimate as to the amount of work, using a typical Fibonacci scale. While I have included this, it is more useful for tracking velocity and therefore I don't think is necessarily as important for open source projects.
  • 1
  • 2
  • 3
  • 5
  • 8
  • 13
• Difficulty: I think this is a more appropriate alternative to the effort label above. It is more straightforward to understand, and better from a maintainer experience as they can gauge what they're in for before taking on an issue.
  • Hard
  • Medium
  • Easy
• Priority:
  • Critical
  • High
  • implicit
  • Low
• Status: GitHub already keeps track of the open/closed status, but it can nice to have additional information as to the status.
  • Duplicate
  • Invalid
  • Awaiting Feedback
  • Triage
  • Wontfix
• Type: In effect, the conventional commit type, with a few additional types specific to issues.
  • Bug
  • Feature
  • Fix
  • Chore
  • Question
  • Tracking
• And lastly, a few additional labels which don't otherwise fit in the above
  • good first issue
  • help wanted
  • breaking change
  • security
  • smartbear supported

[JP-Ellis]

I've updated the PR with the following changes:

• Removed the effort group of labels as I do think it is overkill for open source projects.
• Adjusted the templated cron schedule to run weekly on downstream repositories, as it is unlikely that labels change all that frequently.

I would be pretty keen to see this PR merged. This repository's labels will be updated (hopefully not a big issue), and downstream repositories will not be affected as downstream repositories will need to pull in labels, as opposed to the this repository pushing the labels down.

I would like to start using these labels in the Pact Python repository to start with. This can serve as a more formal test bed, and we can see how well it works.

[tienvx]

I have several small things to discuss:

• I don't understand the area:upstream. Is that the source code of the pact-xxx project itself (under src directory)?
• The status:* labels seem all have black color.
• Is the type:bug and type:fix the same?

[JP-Ellis]

Thanks @tienvx for the feedback :)

• The area:upstream is to indicate that the issue does exist, but is caused by an underlying issue in a dependency. An example within the Pact ecosystem would be a bug in Pact Python, that upon investigation, is discovered to be a bug in the Rust core.
• The status:* are indeed black. They render as follows in GitHub:
• The type:bug and type:fix are two aspects of the same coin. One is used for the GitHub issues, and the other is for PRs. Happy to discuss further:
  • On the one hand, the fix helps line up with the conventional commit type
  • On the other hand, one could understand that type:bug for a PR implicitly indicates that this is a fix.

[YOU54F]

Looks good to me, I would love @sergeyklay to cast his eyes over at some point, as I know he worked recently on the labels in pact-python.

They look pretty aligned, at the moment, as in existing pact-pythons are covered with some additional , which are more related less to an indiv project but more at an org level which make total sense