Re: some background on bugfixing in NetBeans

Hello All,

The email is well written. There are some additional items which Tom Wheeler
mentions which may be worth adding. A better explanation of the priorities
would be very beneficial. I also like the wording around making the life of
the engineer easier. I think providing as much detail as possible about an
issue, or enhancement helps determine fixes, or priorities.

John

On Sat, Sep 24, 2011 at 12:34 PM, Tom Wheeler <[email protected]> wrote:

> 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/
>



-- 
John Yeary
--
http://javaevangelist.blogspot.com
http://www.johnyeary.com
*@jyeary*

"Far better it is to dare mighty things, to win glorious triumphs, even
though checkered by failure, than to take rank with those poor spirits who
neither enjoy much nor suffer much, because they live in the gray twilight
that knows not victory nor defeat."
-- Theodore Roosevelt