Use combobox vs checkbox on issue template to avoid to issue tasks

[oyarzun]

Currently checkboxes in issue templates are converted to issue tasks. Since most of the checkboxes are not actual tasks this PR changes those to use comboboxes instead.

I left the accept code of conduct since it might make sense as a task.

In the future, GitHub may fix this or provide a better alternative.
community/community#4319
community/community#4318
community/community#5197
community/community#5238

[neilcsmith-net]

Yes, the tasks thing is annoying! I was planning a review process closer to 13 release. There are other comments that have been made that would be good to address.

If we do decide to add actual versions in the selection, then should also include the version in the first dropdown. We can add updating the templates to the post-release jobs.

[neilcsmith-net]

I deliberately left out versions when porting from Airflow because we'll have to keep updating them. Still, pros and cons to that. Isn't it missing 9.x?

[oyarzun]

I figured that was the case, but it is useful information when attempting the track down where the regression started.
Yes, it is missing 9.x.

I suppose maybe it is better to have yes/no then have a text field to enter last version it worked.... or just text field for last version it worked?

[neilcsmith-net]

@oyarzun I agree. It does ask people to specify in the text, but better to try and capture - it was purely to reduce need to update the templates for each new release. @mbien also mentioned on dev@ about capturing the actual version in the first dropdown, so if we do one we should do the other. Can we do one review and set of changes in a couple of weeks? As we move to switch off JIRA. Happy for that to happen in this PR.

[mbien]

yes I think having a "latest" selection could cause problems. The user who files the issue might not have the same idea of "latest" as a dev has. E.g latest could be the latest in the package manager of a distro, not the latest available version.

Combo box is fine but would require periodic updates (as neil mentioned) - I would be also ok with a plain old text field. Not sure what others think about this.

[neilcsmith-net]

@mbien the reason for not having a text field in the first place was to try and pre-empt reports on older versions from being made. I'd like to keep that if we can, so updating at releases is probably the right way forward - not a huge addition given everything else that needs doing.

So at release, for the other (version) dropdown, we could have NetBeans 13, NetBeans 14 release candidate, Daily build?

[mbien]

@neilcsmith-net sounds good. I like your thinking of motivating users to update by leaving out older versions :)

[neilcsmith-net]

I've just updated some links on the website to point to GitHub following discussion on dev@ so we might want to consider merging changes sooner. Could we ... ?

• Update the first version list to show Apache NetBeans 12.6, Apache NetBeans 13 release candidate, Apache NetBeans latest daily build.
• Possibly could drop some versions in the "this worked before" section - maybe just Apache NetBeans 12.6, Apache NetBeans 12.5, Apache NetBeans 12.4, Apache NetBeans 12.3 or earlier?. The key point of this section is to catch recent regressions in latest release or RC / daily build.
• Change the Code of Conduct section to a dropdown - let's get rid of all the checkboxes / tasks!

[neilcsmith-net]

Thanks for the changes. Mostly looks great, but people need to accept the code of conduct - No shouldn't be an option. Hopefully one option works with dropdown OK.

[neilcsmith-net]

Thanks @oyarzun - feel free to merge from my perspective.