Renovate: What should HonkingGoose do/not do with their triage rights?

[HonkingGoose]

Hi @rarkins,

I saw that you invited me as an outside contributor with triage rights to this repository, thank you for that! :smile:

What do you want me to do?
And maybe more importantly: what should I not do?

What is the basic idea for why you gave me those rights?
Are the maybe some triage tasks that you never get around to that you want me to do?

I don't want to mess things up for you, so that's why I'm asking before doing anything with these triage rights. :smile:

Greetings,

HonkingGoose

[rarkins]

Thanks for asking. GitHub's permissions aren't the most granular in the world, so let's see:

Triage gives these extra permissions:

• Apply labels: we try to keep Issues well-classified. We haven't documented the labels apart from using the native descriptions, but hopefully that's enough for most people. so if you see issues which are missing labels (e.g. if they apply to a particular datasource or manager, or have no priority, etc) then you can add them if you feel fit. FYI we hope to use labels even more with automatic documentation generation (e.g. if you're browsing the docs page for a particular manager, you can see the list of open feature request and bugs which are labeled for it)
• Close issues: you probably won't have a need for this, but you can do it if you're sure
• Reopen issues: yes, this can happen sometimes if we think it's closed by a new commit but someone comments to say it's not
• assign issues: yes, either to yourself, or also if a user says they'll work on it or creates an issue that they are volunteering to implement
• apply milestones: we don't use these
• marking issues as duplicates: sure..
• request pull request reviews: there might be occasions where one of the maintainers needs to re-review and you can help bump the process along

I also assigned you write access to the Renovate project board. The use for that is:

• Adding issues to it which are missing. We should perhaps have automation for this, e.g. automatically adding them to the Needs Triage status instead of leaving unattached by default
• Moving issues between columns. One of the most important non-code contributions people can do is help features and fixes go from "Needs requirements" to "Ready". We use "Needs requirements" to mean "more information or research is needed before someone could start coding this", and you will see many issues are stuck in this state

[rarkins]

BTW some of the above could also potentially make its way into our documentation if you so wish. Thanks again for your contributions so far, keeping a project this size clean and moving is quite a challenge/.

[HonkingGoose]

FYI we hope to use labels even more with automatic documentation generation (e.g. if you're browsing the docs page for a particular manager, you can see the list of open feature request and bugs which are labeled for it)

That's a really cool idea! That would provide excellent visibility as an end-user into what direction the project is heading.

Moving issues between columns. One of the most important non-code contributions people can do is help features and fixes go from "Needs requirements" to "Ready". We use "Needs requirements" to mean "more information or research is needed before someone could start coding this", and you will see many issues are stuck in this state

I don't think I really understand what you want me to do here... So can you perhaps expand on this?

You say many issues are stuck in the "Needs requirements" state, but are they stuck because nobody from the development team moves them to "Ready", or are they stuck because it's unclear what should be programmed?
Can you indicate what the major hold ups are? I'm not sure how you judge when a issue is "Ready" to be fixed with code?

BTW some of the above could also potentially make its way into our documentation if you so wish.

Good idea, this kind of thing should be documented somewhere instead of going in an issue that's going to get buried/closed later.

[rarkins]

You say many issues are stuck in the "Needs requirements" state, but are they stuck because nobody from the development team moves them to "Ready", or are they stuck because it's unclear what should be programmed?

It can sometimes be an oversight of the maintainers, but more often it's because there are requirements or edge cases to consider and the user hasn't got an opinion or time to think about them and contribute enough. Sometimes it can be because there's a need for some research and "design" decisions to be made, which may require maintainers to do, but it's not high enough priority to justify the time yet.

Can you indicate what the major hold ups are? I'm not sure how you judge when a issue is "Ready" to be fixed with code?

Hard to quantify, but I guess one way to think about it is:

• If you set out solving the wrong problem then you're bound to have the wrong solution
• "Ready" means we're sure what the problem is and there are little or no doubts about approximately how the solution should look

In a way "Needs requirements" both means "someone's going to need to put more thought into this before it can move forward to development" as well as "don't start this now because you might do something which can't be accepted into the code base".

[HonkingGoose]

I am a bit confused on what labels to use on certain issues. So for me, I would benefit from a tagging guide/table.

I noticed you wanted some of the "triage workflow do's/dont's" to be documented.

So, do you want me to open 2 new issues to discuss both of these items then?

• [x] One for the "how to tag stuff properly" documentation.
• [x] One for the "triage workflow" documentation.

[rarkins]

sure, go ahead

[HonkingGoose]

I've created issue #7608 and #7607 to further discuss each item.

Closing this issue, so that we can move the discussion to the relevant issues.