Tech Debt Template

[andrewballantyne]

Closes: #1788

I added the tech debt categories we are using internally on the board... might need additional attention as needed.

Is it worth it? Not sure.

/hold

We can talk about this structure

[lucferbux]

/lgtm

Seems reasonable enough for me, just adding the label, description and the category of the tech debt should be enough

[manaswinidas]

Just thinking out loud. Do we also add "Impact" and/or "Proposed solution/Workaround" (similar to the bug/issue template) fields? Or maybe add this in the description of "What should we improve?" field? I think this will give us a clear picture, better than us guessing the impact/importance of the suggested change.

[manaswinidas]

Also, community contributors may still click on this. Do we clarify the term "Internal"? I know we can't restrict this to only members. Coz we have non-members raising tech debt issues too.

[andrewballantyne]

Also, community contributors may still click on this. Do we clarify the term "Internal"? I know we can't restrict this to only members. Coz we have non-members raising tech debt issues too.

@manaswinidas I would prefer actually to let those outside of our flows just log feature requests... I don't imagine tech debt is a public conversation point. It's more "I want this" which is a feature request.

I think it has a lot of value to keep things tight for community contributions... "Bug" or "Something New" is an easy decision tree. "Something New" vs "Changing Something We Have" (tech debt) seems a bit too granular for us to float up to the base logging features.

My two cents. Anyone else? I welcome all feedback in contradiction.

[openshift-ci]

New changes are detected. LGTM label has been removed.

[manaswinidas]

@andrewballantyne I agree. I was just worried that community members might mistake an infrastructure-level change for a tech-debt change and might log a tech-debt issue. A warning about what "(Internal)" means would be a good addition IMO, and maybe redirect them to use the feature request template in case they do so.

[alexcreasy]

I think it has a lot of value to keep things tight for community contributions... "Bug" or "Something New" is an easy decision tree

@andrewballantyne - yes I agree with this sentiment. We want to encourage people who use the project but have no time / interest / expertise to contribute code to have as frictionless path as possible to tell us something is broken, or they'd like to see something else added.

I also don't see an issue if a community member wants to get into the nuts and bolts of the codebase and raises a tech debt ticket - we should certainly consider if it has merit - we always retain the option to respectfully decline their suggestion.

I think the "Internal" prefix is a good way for the first category of user I mentioned to quickly realise it's not the template they're looking for and discount it -- giving them the binary choice of "something's broken" v "I wish it did this".

Likewise if someone gets involved and wants to pick the second template - well more power to them (... probably 😄)

[andrewballantyne]

All tickets fall into our untriaged bucket which normal users cannot change. We will see all issues I imagine via a quick PR or from the triage team. Anyone logging anything is fine imo. But I don't think our internal flows are really needed to be a common flow for normal community contributions.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

Approval requirements bypassed by manually added approval.

This pull-request has been approved by:

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[andrewballantyne]

I believe this has satisfied the conversations. If needed we can do another pass.