Open Guts opened 5 months ago
Thank you for submitting your proposal to the 2024 QGIS Grant Programme. The 2 week discussion period starts today. At the end of the discussion, the proposal author has to provide a 3-line pitch of their proposal for the voter information material. (For an example from last year check https://github.com/qgis/PSC/issues/58#issuecomment-1567892412)
Reporting bugs and other feature requests is quite difficult for average QGIS end-users, who are more geomatics than IT oriented. As GitHub's interface is not internationalized and oriented towards developer collaboration, there is a challenge in enabling end-users to interact more easily with the developer community.
This QEP proposes to ship a feedback form/widgets as a QGIS in-app tool in order to improve the way we gather end-user feedback.
I totally agree, raising an issue is still hard for non english and non tech users. Being able to push issues from QGIS, and being able to keep the context is interesting too.
I've done this in a corporate environnement, where users could just push a simple issue descriptions, and we kept a screenshot and all technical context under the hood.
However, I feel like this can be something not totally sustainable. Here is why :
I feel like the really issue is that Github is non-english unfriendly. In beta version, translation of comments is on its way. UI not yet https://github.blog/changelog/2021-07-19-machine-translation-for-discussions-content/
It is already possible to auto translate interface, but it is ugly : https://github-com.translate.goog/qgis/QGIS/issues?_x_tr_sl=auto&_x_tr_tl=fr&_x_tr_hl=fr
I'm don't think we can solve this by making a proxy of github on our side, this is too big to maintain in the long run.
And last point, when rewriting QGIS' website, PSC decided to not translate it. The workload for translator teams is too high and we bet that AI translation tools are solving the issue for us.
I know this will be an issue in France, but this has a massive cost, and we are at a point of history of having partial translations deserve the project.
However, pivoting this proposal to a generic plugin that organizations could parameterize to their internal git forge would be excellent, I dream of it. Then the GIS admin can extract its critical issues to QGIS upstream (and hopefully fund fixes) .
I also have concerns about this leading to more non-English bug reports.
I just don't think we have the people power available to manage these effectively and ensure that the relevant information is accessible to developers with the ability to actually fix the bugs.
I don't know if it's just an idea in the mockup, but I'm also strongly against collecting the social handles of the users (ie the linked in / twitter details). I can't see any reason we'd want this or in which it would be valuable for us. (More broadly, I'm extremely against any sign of "official" QGIS endorsement/support to Twitter in any way, given the disgusting cesspool of intolerance and extremism that it's become under Musk's guidance).
Lastly, if the user has to sign up to Github and then go through the hassle of creating a token themselves, that seems to me to be much more complex then just signing up to Github and filing the issue directly :laughing: . I realise it alleviates non-English use of Github, but creating a token is a scary/complex process for anyone completely new to Github regardless of how nicely we wrap it up in a wizard on QGIS' side... Maybe there's ways to avoid the user requiring their own key, eg through some custom service hosted on QGIS infrastructure which handles the actual GitHub API portion and issue filing using an internal hidden QGIS token?
Thanks for your interest and for taking time to write here @haubourg and @nyalldawson.
We create a hard dependency on Github API, which we don't manage. If it changes, QGIS feature will stop working.
I think there is some confusion here. To create the issue, no call to the Github API is necessary. It's just a URL with query parameters corresponding to the issue form. Click me to have an issue with prefilled fields.
About adherence to a platform (and a proprietary one!), the risk is not important here:
On the other hand, I find it more questionable that QGIS embeds a hard-coded dependency on the fonts.google.com service (in the fonts downloader), which is certainly handy but also serves as a tracker for the world's leading advertiser.
We don't educate users to go themselves learn GitHub, so the load of adaptating to Github's changes will be on our shoulders.
Is educating users to raise their Github skills a goal or even a mission for the QGIS project? I don't think so. Why not educate developers to learn using QGIS on Windows 11 for a mapping work expected for the next week? Just kidding obviously but in my opinion, this comment is emblematic of a developer's posture and how much the project can be more developer's centric, and we can look at things from another angle: why should a QGIS user learn to use a software forge, which is the developers' software?
I don't know if it's just an idea in the mockup, but I'm also strongly against collecting the social handles of the users (ie the linked in / twitter details). I can't see any reason we'd want this or in which it would be valuable for us. (More broadly, I'm extremely against any sign of "official" QGIS endorsement/support to Twitter in any way, given the disgusting cesspool of intolerance and extremism that it's become under Musk's guidance).
Sorry for that, I was in a hurry and wanted to give a graphical view of the idea and, as the dialog's title reveals it, I just quickly modify a form used in QTribu (Geotribu's plugin) where social accounts are used in the publication workflow. So, yes it's definitely just an idea. No worries and sorry for that.
Users have to create a token, but they expire at least yearly. How to help them renew them?
Lastly, if the user has to sign up to Github and then go through the hassle of creating a token themselves, that seems to me to be much more complex then just signing up to Github and filing the issue directly 😆 . I realise it alleviates non-English use of Github, but creating a token is a scary/complex process for anyone completely new to Github regardless of how nicely we wrap it up in a wizard on QGIS' side... Maybe there's ways to avoid the user requiring their own key, eg through some custom service hosted on QGIS infrastructure which handles the actual GitHub API portion and issue filing using an internal hidden QGIS token?
I have to digg more into the Github token management for 3rd party but I think we can declare QGIS as an identified application (like services a codecov, pre-commit.ci, git guardian, etc.) that can manage some tokens.
Not sure if hosting a middleware is required or not.
We will have more issues, which is good, but maybe harder to triage and manage. And we will have more non english issues, reducing the pool of possible triagers.
I also have concerns about this leading to more non-English bug reports.
Sorry my English isn't sharp enough I guess 😆 ! In my opinion, I don't think we should accept issues in languages other than English. I'm talking about translating the form: labels, buttons, placeholders, tooltips, help, and so on. We could also offer the user a button to translate the content of his issue on external services (deepl, google translate...), making the work easier for him.
QGIS Enhancement: end-user feedback and workflow
Date 2024/03/2
12Author Julien Moura (@guts) and Julien Cabièces (@troopa81)
Contact julien.moura@oslandia.com
Version QGIS 3.40
Summary
Reporting bugs and other feature requests is quite difficult for average QGIS end-users, who are more geomatics than IT oriented.
As GitHub's interface is not internationalized and oriented towards developer collaboration, there is a challenge in enabling end-users to interact more easily with the developer community.
This QEP proposes to ship a feedback form/widgets as a QGIS in-app tool in order to improve the way we gather end-user feedback.
Functionally, this would take the form of a reporting form fully integrated in Qt, with input fields corresponding to the issue forms
Features envisaged :
To give an idea, here is a quick and dirty form:
QGIS currently includes a crash management mechanism (called crash handler) that generates pre-filled issues with information about the environment. The aim is to reuse the existing code and extend it to handle more use cases.
Example(s) and inspirations
There is already some plugins that implement a report workflow for the plugins ecosystem:
Affected Files
Votes
(required)