Adding Stale label

[eamanu]

In this PR I propose add the stale label on devguide.

Also, move OS-X label to above for a correct alphabetic order.

I would like document the awaiting * labels, but I don't know if in this section (Github label for PR) is the correct. Some opinion about it?

[willingc]

Sounds reasonable to me. @brettcannon or @Mariatta any objections?

Small typo with suggested change. Thanks @eamanu.

[brettcannon]

No objections to me, we just have to make sure to actually make the label if this gets merged. :)

[eamanu]

No objections to me, we just have to make sure to actually make the label if this gets merged. :)

Hi @brettcannon thanks for the review. I think the label is already created https://github.com/python/cpython/labels

[aeros]

Thanks for the PR @eamanu! I recently added a section for the stale label to my PR (#530), but I removed it since it would probably be better to do it a separate PR (as you had done).

I think this is a great start, but I have some recommendations regarding the section. I figured it would be more readable to include it in the comments rather than trying to add a suggestion for each line.

Used for stale PRs or inactive for a long period of time. This label helps core developers identify quickly the PR candidate to be closed or make a ping to the author.

Grammar fixes:

Used for PRs that are stale or have been inactive for a long period of time. This label
helps core developers quickly identify PRs that are candidates for closure or require
a ping to the author.

Rather than using the word "stale" to describe the label, I think we should try to elaborate on what would be considered a stale PR. From my understanding, a PR could be considered stale if the changes are no longer relevant or if the author hasn't responded to feedback for a long period of time:

Used for PRs that include changes which are no longer relevant or when the author hasn't responded to feedback in a significant period of time. This label helps core developers to quickly identify PRs that are candidates for closure or require a ping to the author.

Lastly, we also should try to fit the maximum number of characters per line for formatting purposes. The maximum per line in reST is 80 (including indentation whitespace). Using the above suggestion, the lines would look like this:

stale
    Used for PRs that include changes which are no longer relevant or when the
    author hasn't responded to feedback in a long period of time. This label
    helps core developers quickly identify PRs that are candidates for closure 
    or require a ping to the author.

Tip: Using Python's builtin len() function in the interpreter is an easy way to measure the number of characters in each line. That's how I've been doing it recently. Writing a simple script for fitting as many words in each line within the 80 char limit would be better for large changes, but using len("text here") is quite convenient for small changes.

[eamanu]

Hi @aeros167, thank you for the review.

Thanks for the PR @eamanu! I recently added a section for the stale label to my PR (#530), but I removed it since it would probably be better to do it a separate PR (as you had done).

I would like to document the awaiting-* labels. But I don't know if here is the correct sections. What do you think.

stale
    Used for PRs that include changes which are no longer relevant or when the
    author hasn't responded to feedback in a long period of time. This label
    helps core developers quickly identify PRs that are candidates for closure 
    or require a ping to the author.

I like how sound this, so I will add the suggestion. Thanks

[aeros]

@eamanu:

I would like to document the awaiting-* labels. But I don't know if here is the correct sections. What do you think.

We didn't include them in the initial iteration of the PR label section since those ones are automatically managed by the bots, but I don't think there would be an issue with adding them. That should probably be done in a separate PR after this one is finished though.

[willingc]

Thanks @eamanu 👍