pcplantdb

[Richard Morris <webmaster@pfaf.org>]

John Schinnerer wrote:

Thoughts on actual bug in seperate message.

Here a few thoughts on project mangment stuff.

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

Agreed, but how to build that spec?

The way I'd like to do it is:
        Have a "feature request" Type in issue tracker.

        Submit all the things we want.

        Have pissing matches over priorities. Hopefully the
        Severity/Priority fields will rapidly change until
        we arive at group consensus.

        When happy could promote the Type to "Accepted Feature Request"

        These "Accepted Feature Requests" form the spec!

        This is an effective way to negotiate among the members.

Right now we've got to work out a) how to best use the new tool we have
and b) now to organise ourselves.

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

I'd be prepared to give it a shot. If it does not work we can fix it.

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

True we do lack formal project management or spec.

> 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.
Nice explenation of typical design process. Seems like its whats
happening.

> So - is anyone here up for dealing these sorts of organizational issues?
>
> John S.

So far we have had a very adhoc managment style. No one has really got
a formal managment task. You could say were somewhere between adhoc/consus.

Personally I've a tendancy towards consensus.
Unsure about a hierarcal system.

So far there are 5 users. Does it require greater structure?
(Steph/Lawerence have you signed up yet?)

Really do think alot of these discussions can should be taking place on 
issue traker. It will help keep us focused. Which is one advantage over
mailing list.

As to formal spec, I don't think were there yet. I see the stuff
Chad's doing as more R&D which needs to be a bit more open ended.
When the next dev release done, it will be much closer to actual
system we are going to use. I think this is a good way to do it
as it will give us all a time to look at how this think might work
and give good feedback with a real system rather than a pen and paper 
system.

Its all looking good to me.

Rich