[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Fwd: Re: [RFC] Software Process Improvement in Free Software, Closing the Quality Cycle, Inventing Non-Developer-Demotivating QA/QM/SPI]



Hi Martin,

Martin Schulze wrote:
Thomas Schorpp wrote:

Free software works by people simply doing things and contributing
them to the community.  If other people are interested, it will be
picked up.

Sorry, requirements for QM/SPI- projects is to assure that before start or error or failure risks would be too high.


I wonder if this means that QM/SPI simply does not fit in with Free Software?

no, not necessarily. but noone has done it so far, so it would be subject to research.


I was once in a discussion with non-software people to discuss the
question "Can a Free Software project fail?".  This is an interesting
question.  Can it or can't it?  If it can't, there would be no failure
risk, and even if it can, what is the failure risk?

theoretical the estimated critical mass of acceptance per (maybe a constant in no more maintained OSS-projects) (done )work-input, in valid range adjusted to a comparable scale. but its even more complex metrics math in practice.


To give you an example, writing a tool for foo which is not accepted
by the public but works sufficiently for your personal tasks would be
a total failure when viewed from the public but a large success for
the one person using it.  Even abandoned (maybe some sort of failure
as well) software may still be useful for some people.

"specialised" sw projects like expert systems for a group of "specialised" people should not "fail", even with small audience.

but the point of (my) interest should be: can it fail due to lack of QM/PMM. statistics say it can at 30% nowadays. in OSS distris you've the alternative: if kde fails temporarily you can run gnome, eg. so the full qm efforts of proprietary sw monopolists should not be necessary(?) here.



I suggest you do a QA process assessments of Debian and
write up your findings in a way Debian people will be able to
understand.  Based on this document, we can discuss further steps.

I agree with that, but I can do it only with participation of Your team, never alone.


Then please let us know how to help without bombarding the Debian
developers with buzzwords and acronyms most of them won't be able to
grok without a degree in software engeneering.

i've got none too (but some experience), i'm electronics engineer.
and i've adressed the qa-team first, not all developers, at that time.

from my view its just basic economy. but why tell me? i'm on it and it'll take its time. and i'm sure the SEI would admire YOUR feedback you tell me here. pls use their feedback mailadresses, too. they insist to be useful for developers (maybe in expensive courses, only?).

developers look at www.synspace.de , e.g., for freely available ISO 15504 (spice) or CMMx assessment sw tools. so you can learn quicker, just from their expert systems user interfaces.

BTW, do you know how many times i got beaten up on linux project lists and forums " can't you read or google, nerd? " ;)



So I should work out or point You to a basics introdution.


No.  You sould explain in detail what you want, what you mean and what
you want from us.  If we cannot understand each other, the cooperation
is bound to fail.

yes, i've mailed to this list to find out whats missing, beating me up for it wont surely help ;)


Regards,

	Joey


Y
Tom




Reply to: