I should add, it was also be beneficial if the reverse integration were in place:
If an issue is investigated and found to be “Resolved: Not an issue”, then it gets removed from the Jenkins release “Community reported issues” list
That also goes to a little more integration potential. If an Closed issue is newly reported as an issue in a (newer) release, the JIRA Issue would be reopened for investigation the first time it’s added, as well as being tagged. That potentially creates extra work on the maintainers side to close out bogus issues, but in combination with the above would provide more accurate information to the community and via feedback loop, maybe lead to better reporting of issues.
IIRC “back then” I had to log in to be able to vote. Maybe that would help a little bit for the spam.
When I just checked, there was a cancle button on the votes asking for a Jenkins issue. (That’s also what I remembered)
Only backfiring thing is now, that I added a(nother) “Good” vote by accident.
I used to use these votes to see, if I want to try an update in the first place or wait. With the current state I’m not sure if it is usable for that.
The problem with that is, no issue reference means that feedback is not really helpful. People may not like the release because they have real problems, but don’t tell us why. Confusion around votes without issue references shows up from time when we discuss potential future LTS baselines.
This is my wording from many years ago and English is my second language. You’re welcome to provide a better suggestion; the idea is that not every issue you encounter is relevant enough to list it here to serve as a warning to others. “Major issue” perhaps? “Regression”?
IMHO bad data is worse than losing some feedback.
The Jenkins project is clearly swamped by reports. Reducing the amount of noise would hopefully free up some time to solve actual issues.
At present the data displayed on the changelog is not helpful and the existing procedure distracts devs instead of providing valuable data.
I’d like to suggest that when users click any of the links to report bad experience with the release they are redirected (possibly via an intermediate page explaining the procedure) to jira to report the issue there.
Jira has information on the version in the environment field so it should be possible to count the number of issues reported per release.
This could be broken down into the categories used in Jenkins which also addresses @Ian_W 's concern that the current categories are not clear.
Having the amount of open blocker, critical, major, minor and trivial issues per release displayed on the changelog would provide the most current and correct information to users planning the installation/upgrade.
Good question. Maybe the reverse is true. For now, JIRA is not always helpful to find the issue quickly and search there is pretty slow.
It takes me usually some time to find the exact issue I am looking for. “Similar issues” take forever to load. I wouldn’t expect that we would get any quick “gut feeling” feedback if we would make the search tightly integrated with JIRA. Some form of quick search, yes, but not much more than that.
For version number to be useful we would need to take into account the weekly and the LTS streams at the same time. It is a different thing to have a “version the original reporter worked against at the time of the report” vs. “all potentially affected versions”. Not sure the latter analysis is done for most cases, except for security issues.
For this issue as well I would recommend to fix the underlying issue rather than relying on a (known bad) workaround.
The fact that the jira search is slow causes other issues as well all of which are taking away valuable time from the devs to work on real issues. E.g. duplicates reports because users don’t look for/find the issue.
At present the data displayed on the changelog is not helpful and the existing procedure distracts devs instead of providing valuable data.
It’s never not been helpful. We regularly review changelog feedback (as well as other reported issues) when deciding on LTS baselines. I regularly review changelog feedback after a significant change I authored is merged to learn about regressions quickly.
Having the amount of open blocker, critical, major, minor and trivial issues per release displayed on the changelog would provide the most current and correct information to users planning the installation/upgrade.
Assume every open issue filed against core, cli, remoting, and a handful of other components in Jira affects the latest releases. Nobody updates every issue every week to mention the latest release.