Content
Please rethink meaning of "rejected" state for bug reports
Added by Rob Guinness over 7 years ago
Hi,
I realize I am new to the OpenProject community, but I would like to give some constructive feedback on my experience so far and in particular my experience with bug reports.
Overall, I like the OpenProject software, and if I compare it with Redmine, it is superior in many ways. However, compared to Redmine, I experience a lot of bugs with OpenProject. I have been trying to report these diligently in order to help the system improve. I haven’t taken yet tried to actually fix any of the bugs I’ve reported, but as an open-source supporter, I hope this would be in my future.
Recently, I reported a bug (WorkPackage #27082), but it was rejected. I was told the reason is that this particular component is going to be replaced in v8.0. This led me to ask whether bugfixes will be provided for the v7.x line of OpenProject after v8.0 is released. I was told that they would.
As such, IMHO, bugs reported against a OpenProject 7.x should remain in an open state until they are actually fixed. I was told that rejected “is the state used for bugs that we won’t fix”. But if this is an open-source community, then who is the “we”?
Placing a bug report into a rejected state (which means when you filter for open bugs, it will not show up) makes it much less likely that a community member is going to work on a fix. It’s one thing to give a bug report low priority (e.g. because it doesn’t effect many users or is a very minor issue), and it’s entirely another thing to reject a bug report simply before the core developers are focused on a major upgrade to the software, which is the only conclusion I can draw based on the reasons given for the rejection. For one thing, this gives users and developers an inaccurate view of the number of open bugs in the v7.x line. It also discourages future reporting of bugs in that line.
I hope the community finds this feedback helpful.
Replies (2)
Hi Rob,
thank you for your feedback. Let me first express that we appreciate all bugs and feedback reported from the community as long as the discussion is taken in a respectful manner (which is not always the case in these forums). We did not meant to offend you by marking it as rejected and thank you for speaking out.
The decision to reject it was meant as it was expressed in the ticket: We (OpenProject GmbH) are not working on a fix until that component is removed. In the same sense: The bug is irrelevant to us once the editor component is replaced in 8.0.
But of course you are correct that this takes away the opportunity for a community member to discover and address the bug on their own for versions prior to OpenProject 8.0. Since we address the majority of all bugs on our own, we don’t always keep this in mind when moving tickets around our development schedules.
The same issue was discussed earlier in this forum post, where I investigated into the issue and found that it dated back to before forking from redmine, where the feature was disabled (and re-enabled through a whitelist in the meantime): https://community.openproject.com/topics/7712?board_id=7&r=7713#message-7713
There’s an accompanying feature in the wish list to port it right over: #25260
I believe with this knowledge in mind, the bug you reported can be rejected, but it was not rejected for this reason in the first place, so I find your criticism to be correct.
Since we’re currently mainly driven through enterprise support and paid feature development, some often-wished-for features may be down-prioritized simply we cannot (yet) afford to build them or can only do so on our free time.
Please let us know what we can do to improve the community, get more people to improve and fix bugs, or weigh in on the discussion and prioritizing of bugs and features on the wish list.
Best,
Oliver
Hi Oliver,
Thank you for the in-depth explanation. This is very helpful. Yes, definitely this can now be rejected with the reference to the open feature request.
I understand about the prioritization of bug fixes vs. new features, etc.
As a side note, I think this particular issue with Textile could also be addressed by improved documentation. It seems that in OpenProject some syntax of Textile is supported, whereas other syntax is not. Since there is a link from OpenProject’s wiki formatting help page to http://www.textism.com/tools/textile/, one could reasonably assume that the syntax described there is supported by OpenProject, but this is not the case. That’s OK, in my opinion, that not all features from Textile are supported, but the documentation should be more clear on the matter. I do understand that Textile will be eventually replaced, but this could be a low-effort resolution of this issue and perhaps others.
Regarding the last point, is there some forum where prioritization of bugs/features and roadmap-related topics are discussed, in which community members could participate? I believe this would go a long way towards engaging the community to contribute. In cases like OpenProject, where a single company dominates the development, it is important to engender a sense that decision-making is shared with the wider community.
Kind regards,
Rob