[Triage] Instructions for assigning "good first issue"

[AThousandShips]

Still ironing out the last details, and waiting for the ongoing refactor before finalizing the links and structure

This is generally based on experience with new contributors and what I've seen as sources of friction with PRs

[CreatedBySeb]

Looks good to me! I think this type of guidance is helpful for these sort of cases where there is a significant 'feel' component since it gives an insight into what may be worth considering.

[AThousandShips]

Will rebase and bring out of draft today or tomorrow

[Rudolph-B]

Looks good to me!

[rsubtil]

Looks good to me! (Also clarifies some doubts I had about it, which is great 😌 )

[Meorge]

Suggested change

	resolves this issue. See :ref:`good first issues <doc_good_first_issues>` for details on how
	resolves this issue. See :ref:`Good first issues <doc_good_first_issues>` for details on how

I think since this is a section in the documentation, it should be capitalized to match? Without the capitalization, I would intuitively read this as being a link to a list of issues marked with "good first issue".

[AThousandShips]

We don't do that generally, I'd say that the rest of the sentence makes it clear what it links to, but can adjust to make it more clear, I don't think the change to capital "G" would make any difference on what it seems to link to

[Meorge]

Perhaps changing to "See the section on good first issues below" would be another good alternative? That way it's clear it's the documentation section, rather than actual examples of good first issues?

If you still feel the existing wording is fine, though, it's not something I feel too strongly about 😅

[Meorge]

Stating that "anything not appropriate for new contributors" should "never be considered good first issues" feels redundant to me. The items listed here also all feel to me like they're fairly notable, so they could be expanded upon like so:

Suggested change

	- Anything :ref:`not appropriate for new contributors <doc_new_contributor_rules>`,
	in particular refactors, issues that require new features to resolve, as well as stylistic changes
	and "nitpicking".
	- Refactors: Code in the engine is often written the way it is for a reason, and that reason may not be apparent to new contributors. A new contributor may end up breaking the underlying logic for working code, or bring it away from the Godot code base style, if they attempt to refactor it.
	- Issues that require new features to resolve: As per the :ref:`new contributor rules <doc_new_contributor_rules>`, someone must have a minimum number of merged PRs before they can contribute new features.
	- Stylistic changes and "nitpicking": As stated above, Godot's code base has an established style and conventions which new contributors may not be familiar with.

If you decide to try this out, feel free to work on the wording!

For a more concise list, I think having each item without the following justifications for each one would be okay. I personally like providing the reasoning for each item, but at the same time they may be fairly obvious and thus unnecessary.

[AThousandShips]

I want to reduce the potential for duplication here by directing to a ground source for what this means, but I'll adjust it a bit. The note about refactoring is not really what is important here I'd say, the point here is that we shouldn't assign issues that are not appropriate for a new contributor this label as that isn't necessarily obvious

But I'll look at improving the wording a bit still

[Meorge]

Suggested change

	At the same time, avoid assigning the label if you are not sure about it being appropriate. Make sure to remove it if things change.
	If things change and you realize resolving the issue will be more work than originally believed, you can remove the label.

I feel like the existing version of this line contradicts the previous lines a bit. The previous lines basically say to me, "You can assign this label even if you're not 100% sure it applies, don't worry, mistakes happen." Then, this line says (to me) "Don't assign this label if you're not 100% sure it applies".

As per my suggestion here, I'd probably end with focusing on the fact that the label can be removed if necessary, and describe how to determine if it's necessary.

[AThousandShips]

I still want this emphasis here, there's a difference between being overly cautious and being reckless about it, the former sentence is meant to say "if you feel reasonably certain go ahead and assign it, it's okay if it's wrong", and the latter "if you doubt it's appropriate, don't assign it"

I'll try to reword it to be more clear

[AThousandShips]

Will take a look at the feedback tomorrow!