QA/Bugzilla/Fields/Status/NEEDINFO

TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

• Wiki Home
• Development
• Design
• QA
• Events
• Documentation
• Website
• Localization
• Accessibility
• Marketing
• Diversity
• Wiki Help

• Bug Report
• Bug Triage
• Projects
• Regression Test
• Automated Tests
• Bibisect
• QA Meetings
• QA FAQs

NEEDINFO is a value for the Status Field in Bugzilla.

This page explains the purpose of NEEDINFO and describes the steps the QA team takes when using it.

The Meaning of NEEDINFO

"NEEDINFO represents a bug that cannot be reproduced and fixed until more information is provided. If a bug has been in this state for more than 180 days, it is considered as dead end, and can be closed."

Steps

When setting the status to NEEDINFO, the QA team tries to do the following:

1. Be very clear about what information is being requested

1. Politely ask the reporter to address the request
2. Let the reporter know the appropriate status to set the bug to after information is requested

We have some pre-written responses that provide enough information about the status.

When Information Is Provided

The information provider sets the status back to UNCONFIRMED when the questions are answered. Otherwise, Bugzilla does it automatically (but it is more noisy to subscribers).

When Information Is Not Provided

See our automated tasks: First notification and Follow-up message.

History and Rationale

In 2013, members of the QA team had a lengthy discussion about the meaning of NEEDINFO. Changes were proposed in order to identify what exactly NEEDINFO means. Up until then, NEEDINFO had been a status which existed in perpetuity, where it oftentimes sat indefinitely as the user was no longer following their bug and therefore would never provide the information requested. In general, there was agreement that this status should give us an idea of what bugs will realistically ever get attention again, not just be a placeholder for any bug that we request information for and then just sits there indefinitely. Which led to the current definition.

There were several reasons why this idea was agreed upon:

• Relatively standard across large projects
• Gives a more appropriate idea of where bugs stand (i.e. are they essentially dead and never moving forward, or are they likely to need further work by QA or developers)

• Encourage users and contributors to be proactive about bug reports
• General reminder that a bug exists: users often simply forget about them
• Give NEEDINFO a specific definition that is workable