Issue template design discussion #121260
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
7 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#121260
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This task is being created to open up discussion surronding the design of the proposed idea to update the issue template.
What is the issue template?
The issue template is the file that dictates the appearance of the bug report form: https://projects.blender.org/blender/blender/issues/new?template=.gitea%2fissue_template%2fbug.yaml
Targets of the re-design
Design discussion:
Discussion about the design can be broken into two parts. The report form (what the user sees when filling out a report), and the final report (what gets posted in the issue tracker after a user clicks
Create Issue).Discussion will primarily be focused around what needs to be changed from the current proposed design: https://projects.blender.org/Alaska/bug-report-testing/issues/new?template=.gitea%2fissue_template%2fbug-v1.yaml
Report form:
There are a few discussion points:
To fill this out automatically, select 'Help -> Report a Bug' from the top of Blender). Having this information repeated increases the chance the user will read it, but it also increases the length of text the user needs to read, which may result in them skim reading or skipping it. What are your thoughts on this?Please provide the version number, branch, commit date, and hash of the version of Blender...vsPlease provide the Blender version number.... They generally communicate the same request in different word counts.Short description of issueandSteps to reproducesections are merged together. This was done to avoid some 9confusing UI](https://projects.blender.org/blender/blender/attachments/c35edd72-9c34-4206-afdd-9c216b47429d) with regard to uploading files in Gitea. Should these be merged? Seperate? Or should we just remove one in favour of the other?Final report:
The main discussion point is to do with the appearance of the report once it's made. Here is an example report for reference: Alaska/bug-report-testing#37
Operating System:and textmacos-...). Is this acceptable or do we want to investigate methods to reduce the amount of wasted space (E.G. Reduce the nunber of headers)?Previous points brought up by people. Please correct and expand on this if you want.
@mod_moder
To fill this out automatically, select 'Help -> Report a Bug' from the top of Blender. Letting the user know that they can fill out the report automatically multiple times encourages them to do it, reducing low quality information in the relevant fields.@lichtwerk seemed to be fine with the current design, keeping in mind some of the limitations we need to deal with (E.G. The confusing UI with file uploads resulting in the
Short DescriptionandSteps to reproducesection being merged)@brecht I think if you add more text in one place it means people will just pay less attention to text in another place. We were already at that threshold where many people don't read more. Plus the field descriptions seems more verbose than necessary for the information they convey.
In an attempt to address the feedback from Brecht, I have reduced how verbose I am in the description, and re-arranged sentences to make them shorter.
https://projects.blender.org/Alaska/bug-report-testing/issues/new?template=.gitea%2fissue_template%2fbug-v2.yaml
If anyone has any opinions (E.G. Is some of it still too long, still too verbose?), feel free to share them.
Major changes that happened:
Blender versionrather thanversion number, branch, commit date, and hashI think it can be shorter still. Sentences like "Please provide details about what operating system you're using." add no information.
Some other nitpicks:
I would further simplify it, something like this:
https://projects.blender.org/brecht/bug-report-testing/issues/new?template=.gitea%2fissue_template%2fbug.yaml
Do we need the repetition of "Use Help > Report a Bug in Blender to automatically fill this out." for every field? Can we mention it once in the "Instructions" bullet-point list? Or you think it might not be enough?
I'm a bit torn on that. To my knownledge, a lot of people skip the
Instructionssection and go straight to filling out the details, which means that under some circumstances we can end up with not much useful information in these fields. So repeating it in the description of these fields will help. But repeating it also looks a bit ugly.I do plan to make adjustments to the
Instructionssection, or the location of the relevant bullet points to encourage people to read the important points.I think its also make sense to even add image with this text or screenshot with example such this is important that user will not type this things manually but will use blender.
I'm not sure we can add images, and I personally wouldn't add them.
I means this such important (didn't really want to ask to do that)\
I've incorporated many of Brecht's changes in the latest prototype. https://projects.blender.org/Alaska/bug-report-testing/issues/new?template=.gitea%2fissue_template%2fbug-v3.yaml
The main differences are:
Select 'Help > Report a Bug' from the top of Blender to automatically fill this out.instead of Brecht:Use Help > Report a Bug in Blender to automatically fill this out.NVIDIA RTX, AMD RX, Intel Arcin the GPU placeholder. Someone's going to mistake their AMD/Intel CPU as their GPU and provide wrong information. TheRTX, RX, Arcwill help guide them in most situations.I'm going to bed now, and I'll read any further feedback in the morning.
When I make a pull request for this, who should I add as reviewers?
What about description for the label (not sure)? Like
If this is regressionorName of addon should be firstorEdit mode issue should have the prefix like "Modeling: "My main concern is the issue of "Too Long, Don't Read".
It would be great if this tutorial could be mentioned or even highlighted intentionally,
and hopefully, it could be updated for the current platform.
If the tutorial were to be redone, I hope it could be made much simpler and quicker so that even beginners understand what to do.
If it's redone, I'd like the process to be carefully designed, addressing various aspects.
For example, users sometimes just paste the crash report directly instead of uploading the original .txt file, which they should be instructed not to do.
When would users encounter this template?
If they're already using "Help -> Report a Bug," then the specifics of the template probably don't matter much other than the instruction.
Otherwise, I want to increase the likelihood of users using "Help -> Report a Bug" through methods like tutorials and screenshots.
In the worst-case scenario, if they're not using "Help -> Report a Bug," they shouldn't be able to report any bugs.
I've noticed that people may navigate to the bug report page from Gitea.
I wonder if it's possible to add a reminder page between clicking "Get Started" and the actual bug reporting page, similar to how many websites ask if you're over 18 before allowing entry.
The major point is that if they are using "Help -> Report a Bug".
Most texts or instructions can be totally wiped out and allow more words for other instructions, such as teaching users how to describe steps of reproduction, etc.
Users already have access to a kind of written tutorial. This is included as a link in the top of the reporting form.
A video tutorial may be easier for some users to understand. However to keep things simple I won't include it in the intial change (mainly because the tutorial is outdated). A link to the video can easily be added into the issue template later on without requiring changes to Blender or other Blender websites.
The bug report template dictates the layout of this screen: https://projects.blender.org/Alaska/bug-report-testing/issues/new?template=.gitea%2fissue_template%2fbug-v3.yaml
This screen can be accessed by going through Gitea to the bug report page or by selecting
Help -> Report a bug. The only difference withHelp -> Report a bugis that some information is pre-filled based on information provided by Blender.Based on the current prototype, the only information that isn't relevant is the
Select 'Help > Report a Bug' from the top of Blender to automatically fill this out.parts.I answered my question myself right in the paragraph, and I suggested things in my paragraph and mentioned my intention.
The following information are all "irrelevant" because they can be pre-filled by "Help -> Report a bug".
So my suggestion and intention stays the same as my previous paragraph.
I think more words doesn't really mean they are informative. but rather things are being diluted and make bug reporter more annoyed with paragraphs that they need to read.
I'm sorry, I misunderstood your previous comment.
Do you mean the whole
Operating System... Select Help...then a text box? (Plus the same for Graphics card and Broken version).We still need at least the title and the text box even when a user clicks
Help -> Report a bug, other wise the information won't appear on the final report the user makes. We could reduce the amount a user needs to read by combining these three into one text box, but then we're almost back to the current issue template.This could be resolved by making a custom bug reporting page rather than relying on Gitea templates. (And the plan is to hopefully go custom at some point)
to me it's not a problem. perhaps I don't know the initiation of the change,
but I assume the change is always looking for "Improvement".
At least I see things only moving backwards with the current template due to the concerns of "Too long, Don't Read".
It doesn't not only terrify users imo, but also discourage users spending their time and mental energy reporting the bugs.
thus, all my points basically focus on: taking whatever efforts to let user use "Help -> Report a Bug".
It's simple, easy, and informative, just not many users are using it now.
I know you need a "placeholder" of information. I am thinking if it's possible to arrange things differently.
Assume All users are using "Help -> Report a bug" to prefill most information, then they shouldn't worry about this section at first glance.
Let's say they will get into section of "Short description, steps of reproduce" right away for their chief complaints.
and those prefilled information may be put at the end and less noticeable.
so my idea now sticking with tools available with Gitea is roughly like:
Initial Markdown?
Checkbox to confirm I am using Help -> Report a bug to report this bug. (if not check you can't report the bug?)
Text Box for description and steps of reproduce.
images, file to uploads, etc.
Markdown to say the following information is prefilled, etc.
text box with prefilled information. (can we lock the text box? or can we hide this area like a folded panel?)
other minor things?
@Bradley_G Yes, the vast majority of people will, and should, be using Help -> Report a bug. But there are still a significant number of folks who, for some reason, get into a state where Blender can't even open. Sometimes it's their hardware and sometimes it's our fault. So in general bug filing needs to be open from the site in some form.
Considering that, continually reminding this type of user that they could have used Help -> Report a bug could be a little off-putting.
I think the template's purpose is to, as much as reasonable, reduce low quality reports. So I'd probably say the following:
Perhaps the template can be grouped differently as was alluded to. The following top section grouping would make the form smaller, less repetitive, and maybe less scarry:
@Bradley_G We can kind of have this setup.
Here's some quick mockups based on what I think you wanted:
Mockup 1
Mockup 2
@deadpin
We could try putting the system information at the bottom. So users describe their bug, then fill out system information. And if system information is pre-filled by the
Help -> Report a bug, then the user can just skim read it.https://projects.blender.org/Alaska/bug-report-testing/issues/new?template=.gitea%2fissue_template%2fbug-swap-order.yaml
We can have drop downs. But the list is fixed. For example if this is used on the
Broken Versionarea, then we can't accept reports from people using daily builds of Blender without adding every single commit and Blender version to the list.It would be nice if there was a "Other" in the drop down and then a text box appears for you to fill out the information manually, but to my knowledge that's not avaliable and we'd have to make something custom to do that. Unless we hace the text box always visible.
Here's a quick template using the drop down for OS to give an example: https://projects.blender.org/Alaska/bug-report-testing/issues/new?template=.gitea%2fissue_template%2fbug-dropdown.yaml
Sorry, when I was talking about the length of description, I was talking about the length of the descriptions I was adding to the isue template.
As for putting restrictions on the length of information users can fill out, I don't believe we can do that with Gitea, and we'd have to go with something more custom.
We can have a checkbox for this. The main issue is that this checkbox will be visible on every report made with the template until we gain access to the
Visibleissue template feature being added in Gitea 1.22. And Gitea 1.22 is still under developement and it seems like it might be a few months before it officially releases.Unless we make a custom bug reporting page.
Which option are you talking about:
Simple grouping
Full grouping
This is not something that can be controlled by the issue template and will need to be handled seperately.
Good point
I should of explained the confusing UI I was talking about. The issue is that if you have more than one large text box, then each large text box can accept files as input. However, the files you've already upload "disappear" when you click away from it. Here's a animated GIF showing it off.
Ah, for this one I actually meant the final report page, not the template. e.g. the example from Alaska/bug-report-testing#37 I'd prefer less dead-space at the top of the report there.
For manually filing in the template we'd only need the most recent supported releases: 2 LTS builds, maybe the current version, and then the past 5 or so daily builds. We want to nudge users into reporting bugs on releases we support and using recent daily builds. Would be nice if the build bots could auto-populate the list for us each time a new build is dropped. This is just a nice to have I suppose.
Cool, for OS builds this could be a good route to take if it covered our bases sufficiently. There's not much variation in Windows builds (even 10 vs. 11). Prevent the user from messing up as much as possible.
Let's request that feature.
I meant something in the middle between those 2 solutions. You can have 4 text boxes, just make them closer together and put them on the same line with the header if possible?
I've done some investigation, and I don't believe we can pre-select information in dropdowns (as would happen when a user clicks
Report a bug). Sadly that basically eleminate the ability to use dropdowns in the issue template unless someone figures out how to pre-fill issue templates from a URL.I don't believe we can do that with the current limitations of the issue template.
Through out the discussion there has been a few requests for changes/features which aren't avaliable within the current limitations of the Gitea issue template. And my answer has basically always been ("We could do that with something more custom, which we plan to do later")
During previous triaging meetings, there was discussion to do a fully custom bug reporting page, but progress hasn't started on it (Not sure if there is a lack of knownledge or time or other factors impacting this). So we were looking into a intermediate step of updating the Gitea issue template, then do something custom.
However, if the limiations of the GItea issue template are too great, we can cancel the issue template update and go straight to a custom bug reporting page. Do people have thoughts on this?
With regard to concerns about repeating the
Use Help -> Report a bug.There are two ways a user can make a bug report. Through Blender by selecting
Help -> Report a bugwhich makes all the mentions of it useless. Or thoughprojects.b.o -> Issues -> New Issue -> Selecting the bug report formin which case the reminders are useful to haveWe can actually put the
Use Help -> Report a bugin theprojects.b.o -> Issues -> New Issuepage. So only users going throughprojects.b.o -> Issues -> New Issuewill see it. Like this:Is it possible to create a bug report template which does not show in the "select template to create issue" list on Gitea?
Then the "Help -> Report a bug" option could redirect to an unlisted template which is formatted and described differently than the one users can navigate to via the Gitea UI.
This is possible. The main way I could identify to do this is to place the issue template outside the folder
/.gitea/issue_template/and then it can only be accessed if you know the right URL. An example place to put it is./gitea/hidden_issue_template/or./gitea/issue_template/hidden/How does @brecht and @Sergey feel about this? Having two nearly identical templates. A hidden one that
Help -> Report a buguses. And one visible from Gitea that encourages users to useHelp -> Report a bug, but provides them with instructions on how to find the information in case Blender isn't opening.Somehow it does not feel the proper solution to the repetition problem, and it could be confusing when the form looks differently depending on how you accessed it (surely, it is not the same exact form technically with that proposal, but that is quite hidden from users).
If the text is good and clear and we happy to it for the submitting reports via the web interface, then I don't think we should be doing something special or different for a report with pre-filled information.
One of the main issues at the moment is the repatition of the
Use Help > Report a bugtext. It can be scary for some users, especially users who can't open Blender, confusing to see for people that are using the button, and repeating it can look unprofessional.This prototype (based on feedback from others) hopefully solves this issue: https://projects.blender.org/Alaska/bug-report-testing/issues/new?template=.gitea%2fissue_template%2fbug-v4.yaml
Use Help > Report a bugis only mentioned 3 times.The new prototype also solves the issue of a user selecting
Help -> Report a bugthen having to read through their system information before they can fill out the details of their issue. This is done by placing the system information below theDescription and Steps to Reproducesection. This will hopefully reduce readering fatigue before the user actually gets to filling out the details about the bug.What are peoples thoughts on these changes?
@Alaska I think the updated version looks good! With that I don't think we'd need to separate forms for the web-site and for submission from Blender. So that's extra good ;)
The wording around
Use 'Help > Report a Bug' from the top of Blender to automatically fill out this information.seems a bit strange or a typo or something got lost.Use 'Help > Report a Bug' from Blender's main menu to automatically fill out this information.?I think it's fine. But I'm tired and have been looking at this way too much, so my judgement may be wrong.
I used to have
Select 'Help > Report a bug' ...instead ofUse 'Help > Report a bug'.... Is that better?As for your sugestion, my main concern is that people can't make the connetion between
Main menuandtop of Blender. For example, I would call the menu that appears when you first open Blender theMain menu.I like the newest update.
I was originally in line with Mockup 2, but I completely understand the confusing UI issue of file upload.
I think we can further simplify some wording in the descriptions: (142 words, 886 characters down to 111, 704)
hopefully it helps.
Current Prototype (The same one I shared earlier): https://projects.blender.org/Alaska/bug-report-testing/issues/new?template=.gitea%2fissue_template%2fbug-v4.yaml
Remaining issues brought up by people that we can still try to address:
I don't think we can do that with the issue template, but apparently this can be configured in the app.ini for Gitea.Phillip is against this in favour of proper documentation on how to simpify a file.Steps to reproducebox.Provide exact written stepsvsProvide exact steps. Or explictly telling people not to upload videos? (Which may cause confusion if not communicated properly because we're telling them to not upload videos, but asking them to add videos as extra details.)Help -> Report a bug..bator.shthat just runs Blenders Python and a python script that can collect most of the information for users. And we can direct users to use that in case Blender isn't opening. This can be added to thewritten tutorial for collecting informationpage (still needs to be createdPage is now WIP).Please ensure you have permission to share any files you have uploaded, and avoid uploading age restricted content if possible.So users who skip it will be told to read it when they try to create the bug report.Poluted issue trackerimage attached below.Visiblefeature being added in Gitea 1.22+ we can deal with this issue. But Gitea 1.22 probably isn't out for a few more months.VisibleandHide Labelsfeature to create our own headers (Visibleis only avaliable in Gitea 1.22+ which probably won't be out for a few months). There is also the option to modify the report formatter: https://github.com/go-gitea/gitea/blob/main/modules/issue/template/template.go#L292 . But this will need feedback from Blender admins.Checklist for these points:
Inform users not to upload videos - Still need to decide on wording.
Written guide for collecting info manually - WIP
Required checkbox - Can be added in later
Wasted space on final form - Still need investigating
File upload limits- Phillip is against this, and would prefer to have clear guides on how to simplify files.Min max word counts on input fields - To be handled separately.
.bat and .sh files for collecting system info - Should be handled separately.
Video tutorial of how to fill out the form - To be done later
If anyone else has any medium/large concerns, bring them up. I would like to deal with larger concerns here so the pull request is just minor changes.
I also noticed the checkbox was removed. not sure the initiation, but I think having a check box for "Help -> Report a bug" draws people's attention to it so they may less likely miss it.
I don't really mind if the checkbox text will be shown on the final report or not, because developers must really know how to read a report, while users have difficulty about how to write a report. Indeed, if the checkbox text can be hidden from the final report in the future, it will be great, but it's not a must imo.
I don't know if this issue is stuck or waiting for new Gitea or other changes.
But in case it is stuck, I think the triaging team can make decisions amongst themselves and go ahead when they are happy with it. A bunch of us can give feedback, but if the triaging team thinks it's an overall improvement for them that's what matters, even if not every comment is addressed.
I've primarily left this issue open for others to provide their feedback (this issue was listed in the previous triaging meeting notes, so more people may of come here due to that)
As for the delay on opening up a pull request, I want to wait until blender/blender-developer-docs#58 is committed, and have another discussion with the triaging team about the "wasted space on the final report" issue (which I haven't gotten around too yet).
@deadpin and @mod_moder with regard to the "wasted space on the final report" issue. In the table below you will find two images.
Visiblefeature (Gitea 1.22+) to replace the headers with our own smaller ones.As you can see the custom headers save some space, but not much. What are your thoughts on this? Are the custom headers still wasting a significant amount of space? Is the amount of space being wasted still important now that the information has been re-ordered?
A few other ideas can explore are:
Operating System:) to the system information text when the information passes throughredirect.blender.orgafter a user clicksReport a bugin Blender.filledand we lose theThis information is requiredbenefit of the new template. Which means users that try to submit a bug report directly through Gitea can submit near blank bug reports with ease.Hmm, honestly, not great :-/ I'd actually like to keep the 'static' system/version information at the top since each report is going to be a different length and it would be annoying to have to scroll different amounts to see it easily all the time.
I've never taken a look at the templates but I don't understand why the font & line-spacing are like 4x larger than normal for those OS/version lines. That doesn't happen for normal markdown reports.
Why is the final render so different than the following:
Operating system
Windows-10-10.0.22631-SP0 64 Bits
Graphics card
NVIDIA GeForce RTX 4090/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 551.61
Broken version
4.2.0 Alpha, branch: main, commit date: 2024-05-15 18:22, hash:
eab9e057736fWorking version
No response
Description and Steps to Reproduce
When using the
Join Geometrynode in Geometry nodes to join two points together, their material is reset to default. This only happens when joining tow or more "long" points.Steps to reproduce issue:
The markdown for the above -- does the template really provide no way to just output the below?
The system information at the bottom arrangement primarily benefits the report form. So when a user selects
Help -> Report a bug, all the pre-filled information is at the bottom out of the way, and the main part that needs filling (steps to reproduce) is at the top.So we should figure out if this benefit on the report form is better than the disadvantage on the final report. Everyone is free to share their thoughts on this.
The labels in the issue template get translated into this by Gitea:
### LABEL\n\nThe 3 hashtags make it a big header, then the \n are new lines.
We could modify Gitea's issue template parser to resolve this issue (E.g. Change it to
**LABEL**\n), but I don't think we can do this through Gitea's "custom folder" feature (which is how we should ideally be customizing Gitea). But I might be wrong about this.Also, I'm not sure I explained this properly.
The Triaging module discussed the idea of a "triaging wizard". A revamp to the bug reporting interface and various tools to help people making bug reports provide better information. It's a relatively large task for the triaging module, so there was the proposed idea of updating the Gitea issue template as a intermediate step.
If the new issue template isn't better overall, then we don't have to do this intermediate step.
If we wanted to keep changes to a relative minimum, we can do something similar like this (Split the "Steps to reproduce" section into it's own text box and mark it as "Required").
And here's an example of what a report made with this template looks like: Alaska/bug-report-testing#41
On a side note, this approach has other benefits. For example users can add as many system information details, and broken and working Blender versions they want. Rather than being limited to one item for each field.
The down side of this approach is that people might describe their bug in the "System information" section. And we have the confusing file upload UI issue:
So the order of inputs on the form influences the order in the resulting markdown?! That's surprising, and awful, if that's the case :) I figured there'd be a way to say exactly where "Input Foo" goes inside a markdown skeleton or something. Though yeah, having the information at the top is still more useful to me at least.
I would 100% have to use custom CSS rules on my side as the amount of margin for those H3 headers is absurd and not helpful in generating readable reports IMHO. So I'd learn to live with it I suppose.
I don't want to delay any further really from my side. Getting required fields in place should prevent a few completely useless reports as is.
As far as I can tell, that's how it is.
It's alright to delay this until it's good. This is a bug report form many people will see, and reports many developers/triagers will see. So making sure it's good is important.
We could go with this approach. It keeps changes to a relative minimum, and adds a
Requiredfield.Input from everyone else is also welcome. Do you prefer this "minimal change" version? Or something similar to previous prototypes?
Just to get some discussion going again. There are two main template re-designs proposed now.
Here is a comparison on the two options we seem to be considering:
Note: The feedback I'm mostly interested in is on the splitting up of inputs (E.g. Splitting the report form out into System information and Steps to reproduce sections. Or OS, GPU, Broken, Working, Steps to reproduce sections). Descriptions and wording of description is always open to adjustments.
Guided Report
Report form: link
Example report: link
Description:
The system information section of the report form has been broken up into small "guided" parts.
Requiredtext boxes, forcing users to fill out the form.Simple Split
Report form: link
Example report: link
Description:
The report form has been split into two parts. A system information and a steps to reproduce section.
Required"Steps to reproduce" text box, forcing users to fill out the most important part of the form.requiredis in-effective, and people can still easily make bug reports using the default system information.On a side note, some of the features we were interested in (E.g. The
Visiblefeature to add checkboxes to the report form, but not the submitted report) were limited to Gitea 1.22+. Gitea 1.22 is now out. So we will likely be able to use this feature in the near future.Notes for admins: Don't rush a Gitea 1.22 update. It seems like this redesign may take some time to finalize. And Gitea 1.22 seems to have had a bit of a troubled development, so it is best to wait for a few bug fix releases.