6 ms·

Honestly sometimes the amount of things that you need to fill out just makes me use other software. I.e. kmail would never remember that I want my email threads

Honestly sometimes the amount of things that you need to fill out just makes me use other software. I.e. kmail would never remember that I want my email threads expanded (this example is not real, the kmail devs were very helpful with minimal info in this case). Does this really require I hunt down all this info from all around the place? Sometimes I don't even know where to get the info. What helps immensely (and I saw this in the Geyser MC project), the software can produce a snippet with all info the devs want with one command, and it even exports to pastebin taking out sensitive info. If you paste such a link in their Discord it even makes an overview with syntax highlighting in the chat. That really helps a lot on my (bug reporter) side. And thus on the dev side.

oefrha 6y ago
If you can’t be bothered to copy a few version numbers when trying to get free support, kindly “use other software”. People providing free support usually don’t give a damn about your “taking your business elsewhere”. Moreover, - People omit things they think are irrelevant, when they are. - I print all the relevant details when --debug is on, so people just need to copy that. Some people refuse to run that and insist on submitting “does not work”.
- teekert 6y ago
  I understand the -1, but you have to understand that to a user the choice is sometimes between: 1. Create crappy bug report and move on quickly to get things done or: 2. Do not create a bug report and move on immediately, to get things done I try to file whenever I can but when it's getting late and I want to go to bed I choose option 1 sometimes. Maybe I should choose option 2? For example, take the Nextcloud bug filing template on GitHub [0]. It's quite a long read but sure, worth the effort for free software I agree (Nextcloud is my favorite project, my life is in there, on my server)! However, I may not know exactly where these things are: ``` #### Web server error log <details> <summary>Web server error log</summary> ``` Insert your webserver log here ``` </details> #### Nextcloud log (data/nextcloud.log) <details> <summary>Nextcloud log</summary> ``` Insert your Nextcloud log here ``` </details> #### Browser log <details> <summary>Browser log</summary> ``` Insert your browser log here, this could for example include: a) The javascript console log b) The network log c) ... ``` They also want config.php, contents of `sudo -u www-data php occ app:list`, ask you to do this: Login as admin user into your Nextcloud and access http://example.com/index.php/settings/integrity/failed Also all versions: ### Server configuration \*Operating system:\* \*Web server:\* \*Database:\* \*PHP version:\* \*Nextcloud version:\* (see Nextcloud admin page) \*Updated from an older Nextcloud/ownCloud or fresh install:\* Moreover, I'm quite afraid to put my domain names or even more sensitive info onto a public website if I just copy and paste. All I'm saying is that a big button that generates everything a dev needs with sensitive stuff redacted (which should be doable here and yes maybe I should make a PR for that) will make the experience a lot nicer for the reporter and the dev. As said, the Geyser MC project [1] can do exactly this and to me it is a game changer, the whole process was fast and pleasant and it was easy to test the automated builds they made in the branch based on my issue and report back in context on GitHub. Pasting the JSON their report feature generates into their Discord channel together with your question and their ability to just !docs/something point you to relevant docs with a small command feels like magic. I found the whole process inspirational. I love all FOSS devs. You are my heroes. [0]: https://github.com/nextcloud/server/issues/new?assignees=&labels=bug%2C+0.+Needs+triage&template=Bug_report.md https://github.com/nextcloud/server/issues/new?assignees=&la... [1] https://github.com/GeyserMC/Geyser https://github.com/GeyserMC/Geyser
  - oefrha 6y ago
    > I may not know exactly where these things are I've never judged any user poorly for saying "sorry, you asked for XXX, but I'm not sure where it is; here's my best effort bug report anyway". But "it's getting late" is not an excuse; it's getting later for people who need to read your crappy bug report. If you can't file a best effort report, don't.
    - teekert 6y ago
      Fair enough. It helps if at least the communciation is clear: Like "Fill it all or don't file" or "Try to file as much as you can". I really don't want to make it later for devs that give me so much. I'd be ok with: "Closed: Too little info" from a bot. I may decide to have another crack at it later when I have more time. Edit: Btw, I'm using software for fee but, I'm also beta-testing for free. It's not just a one-way street: "I derive value from a free product so I should never complain." Is that really true? I also invest time beta-testing (some times for products that make money on support or are open-core or are a gateway to paid software). Sure there are trolls, but there are also many users that make crappy reports that really want to help but just don't understand how (or why their report is a waste of everyone's time).
      - joncampbelldev 6y ago
        TFA and the person you're replying are not suggesting you can never complain (at least I don't think they are). There is a difference between not complaining vs raising issues constructively and valuing the maintainers time at least as much as you value your own time.
      - kelnos 6y ago
        > I'm using software for fee but, I'm also beta-testing for free. Assuming you're talking about a beta release for some open source software package, versus a full release, I don't think the distinction matters. You're using software that you got for free. It doesn't matter if it's beta- or release-quality. You aren't entitled to different/better support for it just because the developer chose to put out a version they admit isn't quite release-quality[0]. You're entitled to exactly the same amount of support as for a release version: none whatsoever. > "I derive value from a free product so I should never complain." I think that's framed the wrong way. I do agree that you should probably never complain about something you got for free; that smacks of undeserved entitlement. But constructive criticism and useful bug reports are (usually, depending on the maintainer) welcome. [0] A developer might put out a beta version for a variety of reasons. One reason, yes, might be because they intend to jump on support requests faster in order to shape things up for a proper release. But another reason might be because they simply wanted to share with people as soon as possible.
pbhjpbhj 6y ago
KDE, and it's related apps, is an interesting one. For a long time you could get the version info from a menu item (Help>About or something) in any of the K apps. But then they changed it to give no version info ... then the bug report tool asks up front what version you're using ... One of the great things with Steam when I started running it on Linux was it's debugging info that gathered details of your system so you didn't have to.
- bmn__ 6y ago
  > But then they changed it to give no version info This is still the case. Every KDE application has the menu entries Help → About $APPNAME and Help → About KDE which both show the relevant version numbers. I'm overwhelmingly certain this feature never went away because I am on a rolling distro and upgraded through pretty much all versions and I figure I would have noticed the absence of these menu entries. > then the bug report tool asks up front what version you're using That's incorrect. The menu entry Help → Report Bug… opens a dialog with version information that has a button Launch Bug Report Wizard which produces a link like e.g. `https://bugs.kde.org/enter_bug.cgi?format=guided&product=konsole&version=20.12.0 https://bugs.kde.org/enter_bug.cgi?format=guided&product=kon...`. Consequently in the bugtracker, the available information is already filled in. ---- By the way, this post is an example for the bullshit asymmetry principle, and I resent that I had to spend a magnitude more time to correct your misinformation than it took you to produce it. Please be a better netizen.
  - pbhjpbhj 6y ago
    Ok, I'm a 20y user of KDE, and a massive supporter. I still got the app version from apt (apt-get at the time) and framework version and still submitted bug reports - after registering and installing symbols to get decent backtraces. I even helped some people improve their forum posts by showing them how to get the relevant version numbers. There was a change, it was unhelpful. There were reasons, it was to do with changes in versioning on plasma frameworks - I could look up the details, but that isn't really important a few years hence. The jist of my comment is that structures within an application can help us non-programmers to make useful bug submissions; I cited 2 examples from my real life experience. Hopefully we agree on the basic premise I set out at least?

oefrha 6y ago

If you can’t be bothered to copy a few version numbers when trying to get free support, kindly “use other software”. People providing free support usually don’t give a damn about your “taking your business elsewhere”. Moreover, - People omit things they think are irrelevant, when they are. - I print all the relevant details when --debug is on, so people just need to copy that. Some people refuse to run that and insist on submitting “does not work”.

teekert 6y ago
I understand the -1, but you have to understand that to a user the choice is sometimes between: 1. Create crappy bug report and move on quickly to get things done or: 2. Do not create a bug report and move on immediately, to get things done I try to file whenever I can but when it's getting late and I want to go to bed I choose option 1 sometimes. Maybe I should choose option 2? For example, take the Nextcloud bug filing template on GitHub [0]. It's quite a long read but sure, worth the effort for free software I agree (Nextcloud is my favorite project, my life is in there, on my server)! However, I may not know exactly where these things are: ``` #### Web server error log <details> <summary>Web server error log</summary> ``` Insert your webserver log here ``` </details> #### Nextcloud log (data/nextcloud.log) <details> <summary>Nextcloud log</summary> ``` Insert your Nextcloud log here ``` </details> #### Browser log <details> <summary>Browser log</summary> ``` Insert your browser log here, this could for example include: a) The javascript console log b) The network log c) ... ``` They also want config.php, contents of `sudo -u www-data php occ app:list`, ask you to do this: Login as admin user into your Nextcloud and access http://example.com/index.php/settings/integrity/failed Also all versions: ### Server configuration \*Operating system:\* \*Web server:\* \*Database:\* \*PHP version:\* \*Nextcloud version:\* (see Nextcloud admin page) \*Updated from an older Nextcloud/ownCloud or fresh install:\* Moreover, I'm quite afraid to put my domain names or even more sensitive info onto a public website if I just copy and paste. All I'm saying is that a big button that generates everything a dev needs with sensitive stuff redacted (which should be doable here and yes maybe I should make a PR for that) will make the experience a lot nicer for the reporter and the dev. As said, the Geyser MC project [1] can do exactly this and to me it is a game changer, the whole process was fast and pleasant and it was easy to test the automated builds they made in the branch based on my issue and report back in context on GitHub. Pasting the JSON their report feature generates into their Discord channel together with your question and their ability to just !docs/something point you to relevant docs with a small command feels like magic. I found the whole process inspirational. I love all FOSS devs. You are my heroes. [0]: https://github.com/nextcloud/server/issues/new?assignees=&labels=bug%2C+0.+Needs+triage&template=Bug_report.md https://github.com/nextcloud/server/issues/new?assignees=&la... [1] https://github.com/GeyserMC/Geyser https://github.com/GeyserMC/Geyser
- oefrha 6y ago
  > I may not know exactly where these things are I've never judged any user poorly for saying "sorry, you asked for XXX, but I'm not sure where it is; here's my best effort bug report anyway". But "it's getting late" is not an excuse; it's getting later for people who need to read your crappy bug report. If you can't file a best effort report, don't.
  - teekert 6y ago
    Fair enough. It helps if at least the communciation is clear: Like "Fill it all or don't file" or "Try to file as much as you can". I really don't want to make it later for devs that give me so much. I'd be ok with: "Closed: Too little info" from a bot. I may decide to have another crack at it later when I have more time. Edit: Btw, I'm using software for fee but, I'm also beta-testing for free. It's not just a one-way street: "I derive value from a free product so I should never complain." Is that really true? I also invest time beta-testing (some times for products that make money on support or are open-core or are a gateway to paid software). Sure there are trolls, but there are also many users that make crappy reports that really want to help but just don't understand how (or why their report is a waste of everyone's time).
    - joncampbelldev 6y ago
      TFA and the person you're replying are not suggesting you can never complain (at least I don't think they are). There is a difference between not complaining vs raising issues constructively and valuing the maintainers time at least as much as you value your own time.
    - kelnos 6y ago
      > I'm using software for fee but, I'm also beta-testing for free. Assuming you're talking about a beta release for some open source software package, versus a full release, I don't think the distinction matters. You're using software that you got for free. It doesn't matter if it's beta- or release-quality. You aren't entitled to different/better support for it just because the developer chose to put out a version they admit isn't quite release-quality[0]. You're entitled to exactly the same amount of support as for a release version: none whatsoever. > "I derive value from a free product so I should never complain." I think that's framed the wrong way. I do agree that you should probably never complain about something you got for free; that smacks of undeserved entitlement. But constructive criticism and useful bug reports are (usually, depending on the maintainer) welcome. [0] A developer might put out a beta version for a variety of reasons. One reason, yes, might be because they intend to jump on support requests faster in order to shape things up for a proper release. But another reason might be because they simply wanted to share with people as soon as possible.

pbhjpbhj 6y ago

KDE, and it's related apps, is an interesting one. For a long time you could get the version info from a menu item (Help>About or something) in any of the K apps. But then they changed it to give no version info ... then the bug report tool asks up front what version you're using ... One of the great things with Steam when I started running it on Linux was it's debugging info that gathered details of your system so you didn't have to.

bmn__ 6y ago
> But then they changed it to give no version info This is still the case. Every KDE application has the menu entries Help → About $APPNAME and Help → About KDE which both show the relevant version numbers. I'm overwhelmingly certain this feature never went away because I am on a rolling distro and upgraded through pretty much all versions and I figure I would have noticed the absence of these menu entries. > then the bug report tool asks up front what version you're using That's incorrect. The menu entry Help → Report Bug… opens a dialog with version information that has a button Launch Bug Report Wizard which produces a link like e.g. `https://bugs.kde.org/enter_bug.cgi?format=guided&product=konsole&version=20.12.0 https://bugs.kde.org/enter_bug.cgi?format=guided&product=kon...`. Consequently in the bugtracker, the available information is already filled in. ---- By the way, this post is an example for the bullshit asymmetry principle, and I resent that I had to spend a magnitude more time to correct your misinformation than it took you to produce it. Please be a better netizen.
- pbhjpbhj 6y ago
  Ok, I'm a 20y user of KDE, and a massive supporter. I still got the app version from apt (apt-get at the time) and framework version and still submitted bug reports - after registering and installing symbols to get decent backtraces. I even helped some people improve their forum posts by showing them how to get the relevant version numbers. There was a change, it was unhelpful. There were reasons, it was to do with changes in versioning on plasma frameworks - I could look up the details, but that isn't really important a few years hence. The jist of my comment is that structures within an application can help us non-programmers to make useful bug submissions; I cited 2 examples from my real life experience. Hopefully we agree on the basic premise I set out at least?