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
http://www.abisource.com/pow.phtml
Thanks,
Jesper
--------------------------- 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,
Australian).
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
instead.
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
problem.
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:35 CST