add Maintainer section to Helpdesk template

[ashley314]

Description

Update helpdesk template to include Maintainer section for closure information.

Issue(s) addressed

Resolves #23

Dependencies

None

Impact

Expected impact on downstream repositories:

Manual Testing Instructions (optional)

If you would like your reviewers to manually build and test the change, please include
instructions on how the change should be built and tested. Also include a short
justification on why manual testing is necessary for this change.

Checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have run the unit tests before creating the PR

[ashley314]

The issue description now populates to look like:

[ashley314]

Updating to checkbox for triage and root cause, will add a check box parser in #20

[ashley314]

@eap @gibbsp I tested this PR with my private repo and github actions. Ultimately it adds a "Maintainer Closure Notes" section to be filled in or checked off when JCSDA support teams close these issues. I will be able to add a function to the existing spreadsheet sync that can pull out the check boxed areas for Triage Category and Root Cause. I will also pull out any information dumped into the "Resolution Description" area. Let me know if you have any questions!

[gibbsp]

@ashley314 This is a good idea to have the maintainer notes added once the issue is resolved. Yannick didn't want the maintainer section in the original template because it came across as confusing (I think I told you this). Can we add Yannick to the reviewer list?

[ashley314]

@ytremolet adding you as a reviewer for the Helpdesk template updates. This PR adds a "Maintainer Closure Notes" section to the Helpdesk issue template. The section is visually separated from the user-facing fields with a horizontal rule to make the maintainer/user boundary obvious at a glance.

Why: We want to use GitHub Actions to automatically sync closed ticket data to our tracking spreadsheet. For that automation to work reliably, the spreadsheet needs consistent, predictable field names and structure to parse. By baking the closure fields directly into the issue template, with fixed ids like maintainer_category, root_cause, and resolution, we give the Actions workflow stable anchors to extract data from, regardless of how individual maintainers phrase their notes. This also standardizes what maintainers are expected to fill out before closing a ticket, which improves reporting consistency over time.

Let me know if you want to discuss further! Unfortunately github does not have closure templates - that would be neat!

[ytremolet]

My main concern there was that people (non maintainers) might either decide for themselves what the resolution is or be confused. We see that with labels already where people put the "ready for merge" flag on their own PR that, as a maintainer, I do not consider as ready. It's not the end of the world but it means we always have to double check and cannot trust the labels, which makes them a lot less useful. It's the same here, if anybody can edit, we might have to double check more than we want to. All these small things accumulate and take time and are not very interesting. I was hoping we can have a section that only maintainers can edit. Is that possible?

[ashley314]

@ytremolet there are a couple of ways we can protect that only maintainers have the final edit for fields that get recorded. Since we are planning on triggering a spreadsheet sync we can have the GitHub Action check which user is editing those protected fields (maintainer_category, root_cause, and resolution). If the user is a repo maintainer/ has write access, then the spread sheet will update the information. If the user is not, then the spreadsheet will keep it blank. I think this might be the cleanest approach.

We can also add an action that will revert the entire description back if a non-maintainer edits the description. I think that will take away important user input though.

Overall I think these fields will save maintainers time so they are not constantly trying to cross reference it with the helpdesk tracking spreadsheet. It will also save project managers time so they can sort the sheet, search for projects, and have an up to date view of what is actively being worked. That spreadsheet will look something like this (ignore the first few issues, this has been updating as I have been working out results and testing):

I should note that we will also protect the spreadsheet so only a few people have write access.

[eap]

This looks correct. Edit: Testing looks good.

As far as process. Predicting user behavior is tough and typically they will work around soft limits. I think this template change will be useful when used and we'll have to focus on directing users into the pipeline with some incentive, or alternatively using automation to force existing issues into the pipeline (which may end up being easier).

[ytremolet]

Yes, we can try and see how it goes. Note also that the liaisons who in principle will be in charge of this are in general not the repo maintainers. So we might need a list of liaisons + maintainers. I wouldn't base anything on who has write access because for most repos it's hundreds of people.

[ytremolet]

Do we need something like "new feature that wasn't there yet" category? Or does that fall in one of the others?

[ashley314]

Are we expecting partners to open a helpdesk ticket for when they want new features? Or is there a different path (AOP planning etc?) that goes into it? If it is a new feature, I'd say clicking "Other" and describing the new feature as a resolution works to cover that case. You all are more familiar with the types of support requests we will get though. These options are flexible so can edit where ever you see fit

[ytremolet]

Some people might not know the process, we'll see, it can be added later.