Skip to Content.
Sympa Menu

pcplantdb - [pcplantdb] Bug DB, specs, project management

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: John Schinnerer <john@eco-living.net>
  • To: PCPLANTDB <pcplantdb@lists.ibiblio.org>
  • Subject: [pcplantdb] Bug DB, specs, project management
  • Date: Fri, 15 Apr 2005 12:41:20 +0000

Hi Chad and all,

> Chad Knepp <pyg@galatea.org> added the comment:
>
> I'm changing the severity to minor and the type to task. This seems more like a feature request to me,
> and not a super important one IMO.

(Above refers to Issue 14)

I entered it as I did because I think it is very basic UI functionality, and essential to a user dealing with potentially dozens and dozens of pages of results.

I myself have barely played with PIW searches, beyond looking at the first page or two, due to lack of this very functionality.

I would still prefer we have an actual func spec that lays out intended/desired functionality and priorities/milestones for implementing same.

Absent that, bugs or tasks that imply func specs can be entered ad hoc in the bug DB, though IMO that is a poor way to organize our time and resources and a poor way to design software.

And, this exposes the main problems with an essentially unmanaged project.

Anyone who doesn't like what someone else puts in the DB can just change it to suit themselves, as you have done with this bug.

And of course I can just change it back, and then we have a useless pissing contenst.

So I propose that we need to decide sooner rather than later how we can better deal with our lack of any formal fucntional/design specs and our lack of any formal project management.

Here's my brief on how it generally works places I've worked:

In software development companies, there is some sort of management strucutre around development and testing.

Specifically for testing, there is a 'test lead' or 'test manager' who for their assigned projects is responsible for the life path of a bug/issue.
They work with a development lead/manager, who is responsible for the life path of the software itself.

Testers enter bugs; the test lead/mgr reviews them briefly just to stay on top of what's up with the latest build and to make sure that testers are producing quality bugs.

Assignment of bugs is more often the job of the dev lead, who has a better handle on which programmers are responsible for what parts of the code.

Setting issue priority may be some combination of the two leads, and is often a point of contention between dev and test (not to mention sales & marketing, which we are thankfully free from...).

The dev lead tends to look at priority in terms of what needs to be done where and when based on software architecture and so on (all personal biases and political influences aside, in a perfect world, that is).

The test lead looks at priority in terms of what is most important for a quality product release (all personal biases and political influences aside, in a perfect world, that is).
Good priority setting is crucial for risk-based testing, which is ultimately the only viable model for real-world software, especially but not limited to commercial software.

Typically, priority-setting in the real world often involves conversations and arguments and meetings involving players from all of dev, test and S&M to decide priorities that will relate to users in the real world, whether commercial or open source software.

So - is anyone here up for dealing these sorts of organizational issues?

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