Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] issue tracker properties - feedback please

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: John Schinnerer <john@eco-living.net>
  • To: PCPLANTDB <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] issue tracker properties - feedback please
  • Date: Mon, 14 Mar 2005 23:25:37 +0000

Aloha,

What is the KISS philosophy?

Keep It Simple or Simpler (my version of the original... :-)

WHO IS ALLOWED TO MARK BUGS AS RESOLVED? ASSIGNEE, OR YOU, OR BOTH? AND DOES
CLOSED MEAN IT WAS NOT RESOLVED, AND SIMPLY CLOSED?

Good questions, will put more info in process/use docs for tracker.

Assignee marks as resolved - 'resolved' is a claim, not a fact... :-)

Whomever is responsible for deciding that an issue really *is* resolved will then check it out and either close it, or put it back to open.

For bugs: tester finds bug; assigned programmer does a fix and marks the issue 'resolved' - tester then regresses the bug, and either finds that it truly is fixed and closes it, or that it is still present and re-opens it (in which case it goes back to programmer to try and fix again...).

Tasks would be similar - in generic case, some "manager" will assign a task, assignee will perform the task and say they're done, and manager will verify task is done as assigned (or not) and then close or re-open the task depending on whether it's really done or not.

In our case some of us may also self-assign tasks, using the tracker as a way to manager our 'to-do' list with visibility/accountability to the team.

I AGREE THIS COULD GET CONFUSING FOR USERS. PERHAPS COMBINE UI AND GRAPHICS. ALSO, IT'S STRANGE THAT EVERYTHING IS AN ACTUAL COMPONENT EXCEPT FOR
'FUNCTIONALITY' - DOESN'T THAT PERTAIN TO ANYTHING?

Everything functional, yes. It doesn't pertain to for example graphics on the web site that are displaying incorrectly, etc. because they don't "do" anything (they don't have a programmatic function).
Anyhow, that's why 'category' is a tricky one...

> YOU MIGHT WANT TO HAVE
DESCRIPTIONS OF WHAT ALL THESE COMPONENTS ARE SO USERS KNOW. I WOULD MAKE IT
EVEN SIMPLER:

UI (INCLUDING GRAPHICS AND WHATEVER THE USER DIRECTLY SEES)
SOFTWARE (INCLUDING DB ENGINE AND CODE)
CONTENT (INFORMATION)

OR IS THIS TOO SIMPLE?

Always a tradeoff - more detailed categories can make it easier for the programmer to find the bug...*if* they are wisely chosen and properly used...

Chad and Rich, can you please comment on what would be useful categories for your side of the work...what 'category' areas would help you isolate/locate bugs efficiently?

-WHO WILL BE ASSIGNING BUGS (ONLY YOU?)?

In a larger team context, the team manager(s) usually do this - they have the big picture of which programmer is working on which portions of code.

With our current small team, we can probably self-assign most of them...most will be pretty obvious. I can certainly assign any that aren't totally obvious... :-)

-WOULD YOU WANT TO KNOW WHAT PLATFORM USERS ARE USING?

Yep, thanks for putting that back on my customization to-do list.
This is always another complicated field to pre-populate...I may just have a text field for it...or in the description/steps field...TBD.

-IF WE'RE GONNA BE RELEASING DIFFERENT VERSIONS, WILL YOU BE ASSIGNING THAT
FIELD FOR THE USERS?

This will be a drop-down list where the user picks the version they are testing. Versions will be added to the list as they are released.

-I KNOW USERS CAN ENTER THEIR NAMES, BUT SHOULD WE MAKE A FIELD FOR CONTACT
INFO? (SO YOU CAN GET IN TOUCH WITH SOMEONE THAT ENTERED A BUG TO ASK FOR
MORE DETAIL, IF NECESSARY.)

This is handled by adding a message ('comment' if you will) to an existing issue. Adding the message triggers e-mail notification of the change to those on the 'notify list', meaning those who want/need to be kept informed of that issue's progress/status/etc.

-TEXT BOX FOR STEPS TO REPRODUCE?

I would love to have separate fields for description and steps to repro. (and expected/actual results and platform as well...). This may be more customization than is worth it however, so they may all just go into the one big existing field. I want to get this on the road RSN...

-DO YOU WANT TO CREATE SOMEWHAT OF A STANDARD FOR THE SUBJECT LINE OF THE BUG?
OR WILL PEOPLE BE CALLING THEIR BUGS WHATEVER THEY WANT?

How to write a good summary line is an art, craft and science... :-)
I will provide some concise guidelines and examples and encourage people to follow them.

-WILL THERE BE FILTERS? SO USERS CAN SORT BUGS BY COMPONENT, STATUS, OR
OTHERWISE? CAN USERS CREATE NEW FILTERS?

Yep, plenty of ways to query, and yep, you can create and store your own queries and they show up linked in your sidebar when you log in (already part of the base Roundup product, thank dogness!)

-I KNOW YOU'LL BE CREATING TUTORIAL MATERIALS, BUT WILL THERE BE A HELP
FEATURE?

Not a super-duper integrated indexed searchable table of content help, no. Beyond the scope, etc.

I think a FAQ/user guide that grows as necessary will do the trick.
It's really a pretty simple system. Most users will only need to do a few things - search existing issues (with filters as necessary) and enter a new issue, mostly.

JohnH has been slammed at work, but will be re-setting me up with the latest version within a few days, for customization while I have this cushy housesitting gig...
More news as it happens...

thanks,
John S.

--

John Schinnerer - MA, Whole Systems Design
------------------------------------------
- Eco-Living -
Whole Systems Design Services
People - Place - Learning - Integration
john@eco-living.net
http://eco-living.net




Archive powered by MHonArc 2.6.24.

Top of Page