Closed carlonicora closed 1 year ago
Reference link: https://github.com/stevemao/github-issue-templates/
This is also related to the #167 Accessibility Pass so I expect this will be bumped higher on my priority list. Currently setting conservative milestone of 3.2, but I expect it will be done sooner than that.
Top of mind tasks for myself:
Tentative All-in-one Draft 1 for repo issues. Edit to look under the hood.
Operating System: Obsidian Version: Obsidian Theme: Obsidian RPG Manager Version: Do you use custom css snippets? Do you use a vault-syncing service like Obsidian Sync or Obsidian-Git?
If you have any Obsidian developer console logs related to your request, please include them in your ticket. You can toggle the developer console in Obsidian under View -> Toggle Developer Tools. Similarly, any screenshots or videos can be included at the end of your ticket.
I suspect that template is mostly adequate but we may need something different for pull requests as more goes into that.
How do you want to handle pulls? Do you have automated testing? Maybe read a Lovecraftian Alice in Wonderland for some ideas...
So... I tried to use the template for a few issues, and I think that it works. However, having one size to fit all
creates a complex template that tries to solve all the problem in one go, creating more issues than it solves.
I will use the template and see if it overly complicated for some types of issues or if it can work
Thanks
I did use it a couple of times myself, and found it cumbersome to use on smaller screens if the example portion was left in.
I think those can honestly be left out, and replaced with a more realistic "how to write good tickets" pinned thread if we experience issues after this.
I am using it, but I find myself removing lots of data. I am also sure we can add the templates directly in GitHub, so we can associate them to a specific type of task
<As a>
<I want to>
<so that>
I like this portion.
The more I think about it.. you are correct, we will need more. Because a bug report involving the UI we'll need to know some things, like the questions I was asking about what theme they are using and what rpgm version they are using. In a feature request, we do not need that.
The portion you highlighted is standard user story requirement. It should never contain UI elements or details.
It can be further extended (for testing purposes) with acceptance criteria which follow this style:
<Given>
[<And>]
<When>
[<And>]
<Then>
[<And>]
Multiple acceptance criteria can fulfil one user story
<Given> I have added more than one image to a component
<When> I open the component
<Then> I see the carousel of images instead of a single image
<Given> I am in the component
<When> I want to add a new image to the component
<Then> I should see a link to allow me to upload a new image
<Given> I found and clicked the link to add an image to a component
<When> I am shown a new modal form
<Then> I can see two options: "select a local image" and "Add an online image"
<Given> I see the new image selection modal form
<When> I want to add an online image
<Then> I am shown a URL input text where to add the URL of the image
<Given> I am adding a new online image
<When> I add the url
<Then> the preview of the image is loaded
<And> the button to add the image is unlocked
...
...
@sigrunixia can we close this one?
Yep! Closing!
Scope
GitHub issue lack a standard for presenting the information
Proposed solution
Prepare a list of templates in GitHub (https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/about-issue-and-pull-request-templates) to simplify the creation of new Issues and provide a blueprint on which information are required
Type of Issues
There are multiple types of issues, but I would group them together as: