Add "GitHub Labels" section to "triaging.rst"

[aeros]

Component of #296.

Currently, this is just a draft including a brief summary and a couple of labels. Working on adding most of the other common labels and applying the correct formatting for the table before opening it for review. Only includes labels that are going to be addable by those in the Python triage team (currently only from the CPython repository). Let me know if I missed any.

Labels to add:

DO-NOT-MERGE
expert-asyncio
invalid
needs backport to X.Y
skip issue
skip news
OS-X
sprint
type-bugfix
type-documentation
type-enhancement
type-performance
type-security
type-tests

[aeros]

@Mariatta Thanks for the suggestions. I'll remove the table formatting for now so that the summaries for each of the labels can be more easily modified. I imagine the phrasing of each of the labels might go through a significant number of changes before they're ready, so I'll add the table formatting back as a final step.

Edit: This also applies to any character-width related issues, since that will be addressed when the final table formatting is applied. Currently the primary focus is on the textual content.

[tiran]

Could you maybe try to batch some of your commits and not push every commit separately? I'm getting notifications via GH and email for every commit. It's very likely that I'm not the only one. Thanks :)

[aeros]

@tiran Oh my apologies, I hadn't realized that it would send a notification for every commit in a draft PR, that was the whole reason why I opened it as a draft in the first place. I thought that was one the primary purposes of a draft PR, to avoid notifying anyone before the PR is fully ready. Is there a way to change that behavior?

Sorry, I can instead perform the individual commits locally, and then push to the branch being used for the PR.

Edit: Looks like that was the last label anyways, so that should be the last of the commit spam. If there's any feedback, I'll try to make sure that I don't push every single one of the commits separately. I'm familiar with the basics of Git usage, but I'm still quite new so thanks for the advice.

[aeros]

Finished adding all of the labels, so I opened the PR for review. The label descriptions could probably use additional details or improved phrasing. Since they said they could be mentioned in the PR involving the GitHub labels:

/cc @ericsnowcurrently @brettcannon @willingc

I'll add back the table formatting after the labels themselves are reviewed. It's quite a pain to make changes to the text within rst tables.

[brettcannon]

@aeros167 draft PRs are meant for people working within your team or if you really need CI to check something. Otherwise for an open source project, draft PRs just generate noise and clutter the PR queue with PRs that are not meant to be reviewed.

[aeros]

@brettcannon Apologies, it looks I was misusing the draft PR feature for this one then. I probably could've just done all of these commits to my local fork before opening the PR, it was just convenient to see all of the test results after each commit. This is was the largest PR I've attempted thus far, so the process was a little bit different. In the future, I'll make sure that I only use the draft PR feature to perform a final CI test check so that I don't spam you guys with notifications.

[Mariatta]

Draft PR is kinda new to us, I think we're all still learning the difference.
One main difference is that it doesn't request review from codeowners, so that would be useful in CPython project.

[willingc]

Thanks @aeros167. A few comments about scoping the labels to pull requests for CPython.

[aeros]

@willingc Thanks for the suggestions! I updated the section based on them. I agree that it makes more sense for this section to be focused on PRs in CPython. The section could get quite excessively large if it included labels across multiple projects, and as you said, the project could simply include its own labels in a separate section within its repository.

As a long term improvement, I think it would help if some of the labels were a bit more universal so that triagers could assist across different Python repos more easily. Mariatta mentioned that her and Raphael were working on a bot to manage labels across repos over on discuss, so that might make that process significantly easier.

I was able to batch all of the suggestions that made commit-able changes into a single commit, but I was unable to figure out how to combine that with the title change (since that suggestion didn't include a suggested change to directly commit). Hopefully that's still an improvement from before with regards to the notification spamming.

[willingc]

Thanks @aeros167 for the changes and for taking the time to improve your workflow too 😄

I'm good with these changes. I will leave for @Mariatta and @brettcannon to approve and then we can merge or edit some more. Thanks!

[Mariatta]

I reformatted the GitHub labels section using definition lists.
I think this is good to go, and we can iterate later.

Thanks all!

[aeros]

@Mariatta thanks for adding the commits, currently away from home on vacation for another week (: