Disable blank issue
Elliria opened this issue · comments
AutoKey is a Xorg application and will not function in a Wayland session. Do you use Xorg (X11) or Wayland?
Xorg
Has this issue already been reported?
- I have searched through the existing issues.
Is this a question rather than an issue?
- This is not a question.
What type of issue is this?
None
Choose one or more terms that describe this issue:
- autokey triggers
- autokey-gtk
- autokey-qt
- beta
- bug
- critical
- development
- documentation
- enhancement
- installation/configuration
- phrase expansion
- scripting
- technical debt
- user interface
Other terms that describe this issue if not provided above:
GitHub
Which Linux distribution did you use?
Kubuntu 22.04 LTS
Which AutoKey GUI did you use?
None
Which AutoKey version did you use?
No response
How did you install AutoKey?
No response
Can you briefly describe the issue?
GitHub offers this at the bottom of the introductory text when a new issue is being created:
This makes it possible for a user to click the Open a blank issue link instead of clicking the Get started button that contains our issue template.
Can the issue be reproduced?
Always
What are the steps to reproduce the issue?
- Visit the AutoKey Issues page.
- Click the New issue button.
What should have happened?
You should just be offered the Get started button.
What actually happened?
You are offered the Open a blank issue link and the Get started button.
Do you have screenshots?
Can you provide the output of the AutoKey command?
No response
Anything else?
This is an easy fix that involves the creation of a config.yml file with a statement in it that disables the blank issue.
How about an "Infrastructure" label?
I thought about a "Project" or "Project Management" label
(all caps removed ... :) ), but those didn't seem quite right.
I'd like it to be more inclusive than just "GitHub".
That sounds good. Anything that would let all of us know it's about the website and not about AutoKey. Maybe even administrative-tasks would work for this sort of thing. Come to think of it, I like the project or project-management labels, too.
Now, we have 4 candidates for the new label. I don't want to unilaterally choose one. I don't see one that is clearly superior to the others.
I wonder what other projects do, but I don't see an easy way to find out.
It looks like the Mumble project, that we've admired for some of their other practices, uses github.
We could always go with other, which would come in handy for a variety of situations, including this one.
"Other" seems worse than no label to me. I would guess that there won't be a lot of issues in this category. If that's the case, then it wouldn't be too hard to update them all manually if we decide to rename the label later and we have to deal with that breaking all the links.
I still like "infrastructure" the best, but any of the others would be OK.
It would be nice to have some input from others on this.
The infrastructure label would be fine. After all, it can easily be changed later if anyone has a different preference as long as all relevant issues get the new label first before the existing one is deleted.