Top Menu

Jump to content
Home
    • Projects
    • Work packages
    • News
    • Getting started
    • Introduction video
      Welcome to OpenProject Community
      Get a quick overview of project management and team collaboration with OpenProject. You can restart this video from the help menu.

    • Help and support
    • User guides
    • Videos
    • Shortcuts
    • Community forum
    • Professional support

    • Additional resources
    • Data privacy and security policy
    • Digital accessibility (DE)
    • OpenProject website
    • Security alerts / Newsletter
    • OpenProject blog
    • Release notes
    • Report a bug
    • Development roadmap
    • Add and edit translations
    • API documentation
  • Sign in
      Forgot your password?
      Create a new account

      or sign in with your existing account

      Google

Side Menu

  • Overview
  • Activity
  • Roadmap
  • Work packages
  • Calendars
  • Team planners
  • Boards
  • Forums
  • Wiki
    • Table of contents
      • Expanded. Click to collapseCollapsed. Click to showDeveloper
        • Hierarchy leafAccessibility Checklist
        • Hierarchy leafCode Review Guidelines
        • Expanded. Click to collapseCollapsed. Click to showContribution
          • Hierarchy leafGit Workflow
          • Hierarchy leafTranslations
        • Expanded. Click to collapseCollapsed. Click to showDeveloping Plugins
          • Hierarchy leafDeveloping an OmniAuth Authentication Plugin
        • Hierarchy leafRelease Process
        • Hierarchy leafReport a bug
        • Hierarchy leafSecurity
        • Hierarchy leafSetting up an OpenLDAP server for testing
        • Hierarchy leafTheme Features
      • Hierarchy leafDownload
      • Expanded. Click to collapseCollapsed. Click to showFeature tour
        • Hierarchy leafRelease Notes OpenProject 30
        • Expanded. Click to collapseCollapsed. Click to showRelease Notes OpenProject 30 - Overview
          • Hierarchy leafGlossary
          • Hierarchy leafRelease Notes - Accessibility
          • Hierarchy leafRelease Notes - Accessibility changes
          • Hierarchy leafRelease Notes - Add work package queries as menu items to sidebar
          • Hierarchy leafRelease Notes - Copy projects based on Templates
          • Hierarchy leafRelease Notes - Design changes
          • Hierarchy leafRelease Notes - Fixed Bugs
          • Hierarchy leafRelease Notes - Keyboard Shortcuts
          • Hierarchy leafRelease Notes - Project settings
          • Hierarchy leafRelease Notes - Ruby&Rails Update
          • Hierarchy leafRelease Notes - Security
          • Hierarchy leafRelease Notes - Timelines
          • Hierarchy leafRelease Notes - Work packages
      • Hierarchy leafHowto create animated gifs
      • Hierarchy leafMigration Squashing
      • Hierarchy leafMod security
      • Hierarchy leafNew work package page
      • Hierarchy leafOP3 to OP4 Debian upgrade
      • Hierarchy leafOP4 Ubuntu1404 Stable with MySQL in production
      • Hierarchy leafOpenProject 40 Development Setup
      • Expanded. Click to collapseCollapsed. Click to showOpenProject Foundation
        • Hierarchy leafBoards
        • Hierarchy leafMembers
        • Hierarchy leafOPF-Meetings
        • Hierarchy leafStatutes
      • Expanded. Click to collapseCollapsed. Click to showRelease Notes
        • Hierarchy leafOpenProject released on Bitnami
      • Expanded. Click to collapseCollapsed. Click to showRelease Notes OpenProject 40 - Overview
        • Hierarchy leafRelease Notes OpenProject 40 - Accessibility improvements
        • Hierarchy leafRelease Notes OpenProject 40 - Column header functions in work package table
        • Hierarchy leafRelease Notes OpenProject 40 - Improved Design
        • Hierarchy leafRelease Notes OpenProject 40 - Integrated query title on work package page
        • Hierarchy leafRelease Notes OpenProject 40 - Integrated toolbar on work package page
        • Hierarchy leafRelease Notes OpenProject 40 - OmniAuth integration for OpenProject
        • Hierarchy leafRelease Notes OpenProject 40 - Work package details pane
      • Expanded. Click to collapseCollapsed. Click to showSecurity and privacy
        • Hierarchy leafFAQ
      • Expanded. Click to collapseCollapsed. Click to showSupport
        • Expanded. Click to collapseCollapsed. Click to showDownload and Installation
          • Hierarchy leafInstallation MacOS
          • Expanded. Click to collapseCollapsed. Click to showInstallation OpenProject 3 0
            • Hierarchy leafDebian Stable with MySQL in production
            • Hierarchy leafInstallation Ubuntu
            • Hierarchy leafInstallation Windows
            • Hierarchy leafInstallation on Centos 65 x64 with Apache and PostgreSQL 93
          • Expanded. Click to collapseCollapsed. Click to showInstallation OpenProject 40
            • Hierarchy leafOP4 Debian Stable with MySQL in production
          • Expanded. Click to collapseCollapsed. Click to showMigration paths
            • Hierarchy leafFrom Chilliproject to OpenProject
            • Hierarchy leafMigration 15 to 30
            • Hierarchy leafMigration 24 to 30
            • Hierarchy leafMigration Redmine 2x › OpenProject 30
            • Hierarchy leafOpenProject 3 Migration
          • Hierarchy leafOpenProject 40
        • Expanded. Click to collapseCollapsed. Click to showNews
          • Hierarchy leafNew OpenProject Translations Plugin
          • Hierarchy leafNew Plugin on OpenProjectorg Local Avatars
          • Hierarchy leafNew design for OpenProject
          • Hierarchy leafNews Accessibility workshop for OpenProject
          • Hierarchy leafNews Glossary for OpenProject
          • Hierarchy leafNews Heartbleed fixed
          • Hierarchy leafNews Icon Fonts
          • Hierarchy leafNews OpenProject 30 Release
          • Hierarchy leafNews Release GitHub Integration Plugin
          • Hierarchy leafNews Success Story Deutsche Telekom
          • Hierarchy leafNews Timelines
          • Hierarchy leafOpenProject 3013 released
          • Hierarchy leafOpenProject 3017 released
          • Hierarchy leafOpenProject 40 released
          • Hierarchy leafOpenProject 40 will be coming soon
          • Hierarchy leafOpenProject 405 released
          • Hierarchy leafOpenProject and pkgrio
          • Hierarchy leafOpenProject news moved to a new blog
          • Hierarchy leafOpenProjectBitnami
          • Hierarchy leafPackager version with plugins released ("Community edition")
          • Hierarchy leafRegistration OpenProject-Foundation
          • Hierarchy leafRelease OpenProject AuthPlugins
          • Hierarchy leafUpdates on OpenProject
          • Hierarchy leafWe need your feedback for the the new fullscreen view for work packages
        • Hierarchy leafOpenProject Plug-Ins
      • Hierarchy leafWiki
You are here:
  • Forums
  • General discussion

Content

Please rethink meaning of "rejected" state for bug reports

Added by Rob Guinness about 5 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)

RE: Please rethink meaning of "rejected" state for bug reports - Added by Oliver Günther about 5 years ago

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

RE: Please rethink meaning of "rejected" state for bug reports - Added by Rob Guinness about 5 years ago

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

  • (1 - 2/2)
Loading...