Re: some background on bugfixing in NetBeans

Tom Wheeler <[email protected]> Sat, 24 Sep 2011 11:34:04 -0500
Newsgroups gmane.comp.java.netbeans.general
Message-ID <CAPsQDD+dwkaYj2tE7Qn8PgnZPNcVdWoteMASnMa6MDfGqBv0EA@mail.gmail.com>
I want to amplify a few points from John's message:

  - Issues that describe the problem well get more attention
  - Issues that come with a patch of good quality get even more attention

In other words, I have found by making life easier for the NetBeans
engineer who will ultimately push the change to production (because
I've described specifically how to reproduce the problem and submitted
a patch to fix it), the issue is more likely to get fixed.

However, there are bugfixes and there are enhancements. Both are
tracked in the same system (IssueZilla).  I think one continued area
of frustration is that the process for which features are chosen for a
particular NetBeans release is totally opaque to the community (i.e.
anyone not working for Oracle).

For example, I don't think anyone understands what effect, if any,
voting for an issue in IssueZilla has.  I also don't really know how
to set the priority for an issue.  IIRC, there used to be a nice set
of criteria in IssueZilla, like P1="severe problem with no known
workaround" and P5="minor cosmetic problem".  Now there's just a
rather unhelpful explanation "... available priorities range from P1
(most important) to P5 (least important)."

Finally, in the days since the NetBeans Governance Board meeting that
led to this discussion, I've found a Web site written by a former
developer relations person from Google:

   http://www.developer-support-handbook.org/

and would *strongly* recommend that anyone interested in improving
processes related to NetBeans read it.  The section on "Issue
Tracking" is particularly relevant to this discussion.

I'd simply add that the advice it gives could be improved by making it
more relevant to an open source project, where there is at least the
theoretical possibility that a community member could participate in
triage meetings, help develop a product roadmap or fix an issue on
his/her own.  Being a member of an open source project comes with both
rights and responsibilities.


On Fri, Sep 23, 2011 at 4:54 PM, John Ceccarelli
<[email protected]> wrote:
> Hi folks,
>
> I know there has been some discussion about bugs and some people expressed
> frustration that bugs were not being evaluated quickly enough by the NB
> team. I put together this email just so that the community can understand
> what's happening behind the scenes when a bug lays open without comment for
> a long time and what you can do to help. Your feedback is welcome.
>...


-- 
Tom Wheeler
http://www.tomwheeler.com/