Gitea: Triaging Wizard #78
Labels
No Label
Service
Buildbot
Service
Chat
Service
Gitea
Service
Translate
Type
Bug
Type
Config
Type
Deployment
Type
Feature
Type
Setup
No Milestone
No project
No Assignees
5 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: infrastructure/blender-projects-platform#78
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 document is a design proposal of Wizard interface for users to improve bug report submitting.
This document mostly based on discussion on Triaging Module Meeting, notes can be seen there: https://devtalk.blender.org/t/2024-02-29-triaging-module-meeting/33580
Everyday around 20 new reports are submitted to Blender. A lot of new reports are the first one for the sender. There are too many things that can be missed in the report, and it is part of the job of the triaging team to spend its time and time of the user to collect all required info.
The Wizard should be the best interface for users to ensure that all necessary info will be added into the report. Each field of the report needs to be checked to be filled by correct and most informative info. Also, wizards are proposed to make it most user-friendly and simple (affordable) for any beginners.
Examples of Wizard
Currently there are 4 available way to have Triaging Wizard
1.1. This should be customizable as just a new Gitea repository with pull requests.
1.2. Changes in dialogs need to be reflected to user pages without 1-2 days delay. Is there a way to update part of Gitea/projects.blender everyday? Locate this on a separate domain?
1.3. Changes to bug reporting infrastructure are available to all users/versions of Blender without having to update/download additional tools.
1.4. It's possible to automate system information collecting in case the Wizard is runned on a user pc, is there a way to automatically attach stack-trace files, system info, messages from blender terminal, and other useful things without asking them from the user?
1.5. After Mano’s check: Can Gitia template page for bug submitting support dynamic page form and some kind of scripting? How long should we wait for that?
2.1. Is this bundled with Blender? If so, is it enabled by default?
2.2. Is there a way to update config (question tree) afterward? Can this addon be built-in and require an internet connection?
2.3. How do new users know to use this tool instead of the existing “Report a Bug” button?
2.4. Such addon should not lock current blender instance, is it possible to have such Addon with separate window or with dialog system which will be unrelated with undo ando etc?
2.5. Sometimes users can not run blender at all, so such Wizard come to be locked to help in bug report submission.
3.1. Is it bundled with Blender or a separate download?
3.2. Can this tool be updated from the internet after it has been downloaded?
3.3. How do new users know to use this tool over the standard “Report a bug” button? Add to “Help” menu? Create a pop-up upon Blender crash informing the user of this tool?
3.5. In the case of maintaining such a tool by Blender, which license should it have? Is it possible to use external libraries..?
4.1. Is the Foundation ready to add such things in Blender itself? Separate editor?
4.2. This kind of Wizard can not be used in case Blender can not run.
4.3. There is no way to update question-tree after blender has been downloaded? Maybe kind of extensions?
Questions for Blender Foundation
How many resources can such a project take?
How can the triaging team help here?
Initial plans to start
We already can edit the bug-report template page to add more info for users in the page of bug submitting.
Additional features
These features are available for a case of local executable application for bug submitting / Wizard. All of these features are preferable to have and can make bug submitting as efficient as it even possible. But just to start the Triaging Wizard project, it's okay to just know that all of these functions are possible to be added in future, this is not locked things:
I think this type of wizard should be on a website, not built into Blender. Otherwise we'll get users running outdated versions. Some improvements on the Blender side to collect logs and submit them would be good though.
Integrating a wizard into Gitea is probably the best solution, using Javascript to dynamically alter the web page. Some part could also use Go templates. Though I think there is some benefit to not coupling this implementation too tightly to Gitea, for easy testing and in case want to make it a dedicated website later.
It would go into this repo. Updating Gitea with changes to that repo is done manually at the moment, but it's simple and non-disruptive. I think it could be automated to run every hour.
https://projects.blender.org/infrastructure/gitea-custom
I think this would be worthwhile to do. About resources, it would be simplest if someone in the triaging team could implement and maintain this. We don't currently have anyone whose job it's obviously to do this, but I think many developers are capable of doing this. So if needed we could figure something out.
During the triaging module meeting roughly two weeks ago, a discussion was had about potentially splitting the triaging wizard work into two parts:
For the "updating the issue template" task, some people were hoping we could make use of the
visibleoption available in Gitea 1.22 (currently in development) to adjust the visibility of certain input fields. It is documented as part of the issue template documenation here: https://docs.gitea.com/next/usage/issue-pull-request-templatesJust to get a general idea of the time line of things, once Gitea 1.22 officially releases, what is the expected time line for the Blender foundation to update to this version of Gitea, assuming no show stopping bugs?
We'll probably update within a month after the release? Not really in a rush and might wait for a a bugfix release or two before doing it.
I don't understand why this template should depend on that specific feature. I would expect you'd use javascript and CSS to manipulate what is visible quite heavily anyway, and if you can do that this Gitea feature doesn't seem important.
The goal of the triaging wizard project is to improve the bug reporting process to get higher quality bug reports. One area that could be improved upon is the bug reporting page. This can be done via two methods:
Option 2 is much more flexible, but requires more work from the parities involved. And so far I don't think anyone has volunteered to do it. I'm not sure if this is just because we're still in a planning phase, or if there's issues with avaliable time and/or knowledge.
So as a intermediate step, we were exploring the idea of updating the issue template now (which is very simple to do), then replace/expand upon it with the more flexible custom Javascript and CSS work later on.
To update the issue template, we don't need the
visibleoption from Gitea 1.22. But if we had access to it, we could do a little bit more in this intermediate step.I was just checking on the timeline of events for the update to get an understanding on if we should just progress with updating the issue template now with the current limitations, or wait until Gitea 1.22 comes out then update then. Or do two updates. One now, then another for Gitea 1.22. That is assuming we do progress with updating the issue template (It was just a proposed idea in the last meeting, and I wanted to gather more information to make a more informed decision in the next meeting).
If you have opinions about the triaging module just skipping the issue template work and going straight to javascript and/or CSS work, then let us know.
Ok, thanks for the details.
I'll keep an eye on the Gitea releases, we can probably updated within a few weeks of the release if needed. But I can't predict when they will release.
I don't really mind one way or the other if the triaging team wants to use just the template or go immediately to more advanced Javascript. I don't have good insight into how much template changes would help, if it seems useful to the triaging team they should feel free to make the changes.
Based on feedback from members of the triaging team, it seems likely that we will be going forward with updating the Gitea issue template as an intermediate step.
I have a question for the Blender admins:
Help -> Report a bugin Blender, you are taken to adeveloper.blender.orgpage that parses your system information and redirects you to Gitea.Help -> Report a bugbutton to go straight to our new template without passing information throughdeveloper.blender.org. However all old versions of Blender will continue to use the old template resulting in a transition period.Assuming this is fine, then the triaging module will progress with working on updating the issue template.
I am willing to volunteer some time to update the issue template, but if someone else wanted to do it, just say so.
We did have a discussion about the usefulness of the
Visiblefeature avaliable in Gitea 1.22+ for this intermediate step. There was a general agreement that it can be useful in some situations, but probably isn't neccesary for this first stage.So we will progress under the assumption that it won't be avaliable.
It would be helpful to see what the new template will look like, to figure out the best way to hook that up to Blender. It might be possible to make the redirect smart enough to reformat the text for a new template, or maybe it's impractical.
I don't know where exactly this redirect is configured, @Sergey set this up. I think it's just a one line regular expression in nginx or Apache.
The main idea proposed for improving the report form with this intermediate step is to break the report form up into seperate steps. So instead of having 1 text box, we would have multiple. Here is a quick mockup Germano made a while ago. We do plan to make alterations to this, but I don't expect the layout to deviate much.
The new link to prefill information will look something like this:
For example:
https://projects.blender.org/mano-wii/testes/issues/new?template=.gitea%2fissue_template%2fbug.yaml&field:os=MYOPERATINGSYSTEM&field:gpu=NVIDIAGPU&field:v_broken=402
Hopefully it should be simple enough to use regular expression to extract this information and redirect it to the relevant fields.
@brecht The redirect is handled by the developer.b.o site. We could move the logic from regex-based to a script, to ease its development and maintainability.
For moving forward I would really strongly advocate against adding any formatting or web-application specific logic on Blender side. The way how it was done is a mistake. The way it should be done is to have an intermediate URL, to which Blender says it wants to submit an artifact of specific type, with specific fields. For example,
https://redirect.blender.org/?type=bug&action=submit&os=macOS&gpu=Apple M2. It would not take long time to set it up, and it will solve a lot of problem w.r.t template, fields, issue tracking system, etc, in a way that keeps all Blender versions work without spreading the redirect/adjust/versioning code all over the webservers.I guess extracting the OS, GPU and Blender version from the old redirect is not that difficult, to keep compatibility with older Blender versions. Even just with regex if needed, it doesn't have to be very smart.
I'm not sure what the next step would be though. If this is moved to a script, which language would that be in? Can someone from the triaging team implement that, or do you prefer to handle it?
Just so I'm understanding correctly, this is generally what would be prefered:
developer.b.ois updated to properly fill out the new template.redirect.blender.orgin a clean format, allowing it to be easy adapted to lots of different websites and bug report templates should things change in the future.There's still an issue. At this point we're maintaining two redirect systems.
developer.b.ofor old versions of Blender andredirect.blender.orgfor new versions of Blender.And if the issue template under goes another major adjustment (which may happen if we implement some custom stuff), then both redirects would need to be updated again. Which just adds extra work.
Maybe we update the existing template,
developer.b.o, and setup new versions of Blender to useredirect.blender.org. Then if the bug reporting template under goes another major change in the future, we set it up as a "new template", reconfigureredirect.blender.orgto point to the new template and leavedeveloper.b.opointing to the old template?Another possibility is that by the time this "future major change" happens, the the versions of Blender using
developer.b.omay be really old, and if we don't want to have two bug reporting templates, thendeveloper.b.ocould just show you a simple HTML page with your system information, Blender version, etc, and a link to the new bug reporting page.@brecht I think the easiest would be to use PHP, as that system is already equipped with everything needed for it (and is already used for task redirection). And also think easiest would be if I put some things in-place, before someone else can pick the code up. As this will also be a nice opportunity to consolidate the task redirector in a more clean manner.
I would stay away from the Web-server level regex, as it is very hard to debug, and we do not have any staging environment for it. And there are also complications coming form the fact that some other sites are on that config.
@Alaska Depends on priority. If it is something really UNBREAK-NOW, then sure, we can go deeper in technical debt with the
developer.b.oURL. Otherwise I'd advocate for not going deeper in debt, put redirector in-place, and then update Blender to the new reditector. If I can focus on it, it should not take that much time to implement.I've committed an initial state of the redirector: https://projects.blender.org/infrastructure/redirect-website
It probably still need love and such, but is a beginning.
For moving forward I think something like this:
developer.b.oredirectsThe last two could happen in any order.
The site has been deployed. It is ready to handle direct requests to it. I did not make it so the old developer.b.o type of URLs are routed via it just yet.
I've made a PR against Blender to use the new style of URL: blender/blender#121215
Great to see progress, thx everyone involved 🥇
During discussion around the issue template design, there was a request to limit the size of files that users can upload.
Upon investigation, it appears this can be done by editing the
app.iniGitea uses with something like this:How do the Blender admins feel about this?
We may want to have a disucssion on what the limit should be before making any changes if you want to do them.
I dont think limiting the max size will help us much.
There are enough (somewhat legit) cases that need space
I am not against the emphasis on simplification, just dont think it is possible in every case to push it below 50MB (in some cases - e.g. when users get an exported file from another software that they dont even have access to - it might be impossible to squeeze it down in blender alone).
In practice, this will probably end up with the user just uploading the file somewhere else. We could just refuse to accept external storage as well (because links can end up being dead after a while), but as mentioned, I do believe there are cases that just (rightfully) demand some space.
Imo, time is probably better spent making some good guides/tutorials on the process of simplification rather than putting a hard barrier on upload sizes (and then dealing with the "secondary" issue of external storage).
Triaging Wizardto Gitea: Triaging Wizard