uPOW 2001 week 6

Subject: uPOW 2001 week 6
From: Jesper Skov (jskov@redhat.com)
Date: Sun Feb 04 2001 - 05:41:32 CST

This POW is the first of at least two, hopefully more, POWs which are
intended to be zapped by AbiWord users instead of AbiWord
developers. Call it uPOW if you will, if you promise not to belittle
it compared to developer POWs while doing so.

Why do we need uPOWs? That's simple: there are only, by my reckoning,
about 10-15 active AbiWord developers. And at the moment we spend far
too much of our time on keeping the web pages current, triaging bugs,
trying to make sense of bugs, etc.

The development pace of AbiWord would improve if we could get some
users (who do not necessarily know how to program, but do want to
contribute) to help with these things. It might even make for better
handling of these things as we developers have a nasty habbit of
trying to get around stuff like this as easy as possible (so we can
get back to hacking :)

For information about (u)POWs, please see


--------------------------- uPOW 2001 week 6 ---------------------------

The bug database (http://www.abisource.com/bugzilla/) contains many
bugs in various states. Before we can make AbiWord 1.0 we need to have
it cleaned up and kept up to date.

For this reason I'd like to suggest that we start hosting a weekly
bugday like it's done for Mozilla and Nautilus. What this uPOW is
about is finding the person - or persons - to host this event.

This is your mission, should you choose to accept it:

 o Find a suitable weekday and time. Remember that the time should
   allow for as many people to attend as possible - that probably
   means late afternoon / evening GMT (allowing people from both
   European and American timezones to attend).

   Possibly alternate times of the event if we can find someone from,
   say, three different big timezones (European, American,

 o Find a suitable place to host this. I suggest:
    #abiword-bugs at irc.gnome.org

 o Prepare some web pages for www.abisource.org that contains all the
   necessary details for this event. Have a look at the Mozilla(zine)
   and Nautilus pages for inspiration.

 o On those pages, try to describe what makes a good bug report so the
   time reserved for the bugday can be spent on tracking bug problems
   rather than telling newbies how to use bugzilla (even though that
   is also part of the reason for being available - but help reduce
   confusion by providing good written documentation in advance).

 o If you are more people who want to host this, make plans for taking
   shifts, *and be there when advertised*. I realize that this is a
   volunteer effort, but there are few things worse than advertising
   help and then not being around.

   In other words, make sure the web page (and IRC channel topic)
   advertises the event a day in advance and stick to the schedule. If
   you don't have time to host the event, leave a cancellation message

 o Your main job on the channel will be to help newbies file bugs and
   coordinate efforts from people who stop by to help
   reproducing/triaging existing bugs. As for the latter, below is an
   outline of the necessary tasks - you may find it necessary to add
   more (or change some):

Bug database specific tasks [these should go on the web page!]

 o Bugs in "QA TO VERIFY" state should be tested for correctness and
   either reopened or closed.

   Make sure that you try to reproduce on a platform that was actually
   affected by the problem!

 o Bugs in SUBMITTED state should be considered for acceptance. Make
   sure the summary and description are sensible and detailed enough
   to allow it to be reproduced. If not, ask submitter for additional
   information. In particular, bugs which pertain to problems of
   loading documents need the document to be available.

   If the bug passes the criteria of necessary detail, accept it
   (i.e., move it to OPEN state).

   If not, and submitter is not forthcoming with additional
   information, move it to OPEN state, then "Mark bug as QA TO VERIFY,
   changing resolution to INVALID", noting the reason for this.

 o Bugs in OPEN state should be checked for uniqueness. If you find a
   bug similar to this one, close the new bug by "Mark bug as QA TO
   VERIFY, mark it as duplicate of bug # ".

 o Bugs in OPEN state should be enhanced where possible. Try to
   reproduce the bug as per the description and add any additional
   comments that may make this easier / simpler.

   If you can reproduce the problem, make a note of that in the
   bug. In particular if you have a different platform than on which
   the bug was first found on. Developers will usually avoid looking
   at bugs not reproducible on their platform of choice.

   If you cannot reproduce the problem, also make a note of it in the
   bug. If people cannot reproduce the problem on the same platform
   used by the submitter, it could be a problem with the description
   of how to reproduce the bug, or details specific to the submitter's
   platform environment. Work with the submitter to either fix her
   system (and close the bug as WORKS FOR ME, noting the resolution in
   the bug) or add the extra details necessary to reproduce the

 o Bugs in OPEN state should be properly prioritized. Crasher bugs
   should be 'Urgent' and 'Critical'. Features should be prioritized
   according to how desirable the enhancement would be.

   Other bugs in between depending on how serious the problem is, and
   how likely it is to affect people.

 o Developers will reassign bugs to themselves when they start working
   on them to prevent duplicated (wasted) effort.

   If a bug has been assigned to a developer for a long time (30+
   days), check with the developer if she's still working on it. If
   not, revert it to the free pool (reassign to owner of component).

Please note that the developers may not necessarily go for the highest
prioritized bugs (again, volunteer effort and all that). We're strange
creatures and often have a mind of our own - but a properly triaged
bug list is greatly improving the chances that we'll actually get
stuff done from the top of the heap.


This archive was generated by hypermail 2b25 : Sun Feb 04 2001 - 05:41:36 CST