Re: The <whatever> developer syndrome

Steve Hutton wrote:
> In article <[email protected]>, James Richard Tyrer wrote:
> 
>>Aaron J. Seigo wrote:
>>
>>>you've never known a professional who had fun doing what they did? to me fun 
>>>is not a swear word, nor the epitome of waste; it is (for me) a necessary 
>>>part of a sane life and the true creative experience. it may be otherwise to 
>>>you, and that's totally fine (not that it requires my permission, of 
>>>course ;). i would not demand that you have fun; i also desire for you to not 
>>>request that i relinquish my enjoyment so as to make *my* experience fit 
>>>*your* expectations. furthermore, my path (with which you may disagree with) 
>>>may end up leading to the exact destination you are striving for (and vice 
>>>versa). 
>>>
>>>there is more than your one answer to the question of life.
>>>
>>
>>Remember, this isn't about having fun.  It is about doing things which are 
>>not fun.  Not fixing the bugs because it isn't fun is an armature attitude.
> 
> 
> In the Open Source world, there are three answers to the problem of
> developers not doing what you want:
> 
> - join them and contribute to the areas that are important to you
> - fork
> - create a derivative work (subset or superset)
> 
> Before the 3rd option sounds too radical, consider that it is exactly
> what all the Linux distributions do.
> 
> If someone wants to create e.g. a context-menu free version of KDE,
> or a KDE that has only a single media player and single text editor,
> and adds other apps like Scribus, the code is there for the taking.
> 
> In any case I don't think it's worth getting worked up over how
> developers may or may not respond to feedback.  Individual feedback
> to Open Source projects still has a much better chance of having
> an effect than it does with commercial closed source products.  And
> if that's not good enough, hey, you have the code.  Seriously.

Thank you for you thoughts.  But, I don't see how any of your three 
"answers" are going to get the bugs fixed any better.

I believe that my suggestions are much more relevant to solving the bug 
problem.

I suggested that bugs which resulted from errors in coding be fixed first 
on the current stable release.  This would make the users happier and I 
believe that it is easier to fix such bugs on the stable release rather 
than trying to do it on the HEAD branch.

NEW SUGGESTION:  I was surprised to hear that many of the developers never 
actually use KDE.  That they only have HEAD installed on their systems. 
This is not good.  It makes for a large disconnect with the users.  So, I 
suggest the obvious: the developers use the current release and only use 
HEAD for development.

I think that I also suggested that new features should have some sort of 
late commit so that they would be worked on and tested till they were at 
least BETA quality before they were committed to the MAIN branch -- HEAD 
would be replaced with UNSTABLE which could have these changes applied 
before they were BETA quality.  This to prevent introducing more bugs if at 
all possible.

Another idea which came from something somebody said is that a bug should 
not be considered closed when it is fixed in HEAD.  It should be set aside 
   till the next BRANCH is tagged.  The reports could be purged -- reduced 
to a list of things to check the release for regressions.

My major point is that the bugs are getting out of hand.  We don't need to 
work more, we need to work better and smarter.  I think that Edwards Deming 
and Tom Petters have good ideas.  Are you familiar with them?

I suggested that the HEAD bugs be separated from the user bug reports.  Bug 
reports should not be kept forever.  HEAD bugs rapidly become obsolete. 
Perhaps they should be discarded after 90 days unless a developer decides 
to keep them.  And, it would appear that they become obsolete when a new 
BRANCH is tagged.  I also wonder if we should just purge all of the bugs 
for version 2.x.y; aren't they just irrelevant?

My example was that we are still building software like Detroit used to 
build cars.  First we build it and then we try to fix the defects.  They 
don't build cars that way in Detroit anymore.  They use Deming's methods 
for quality assurance.  In the case of software, this means that something 
should undergo some quality assurance testing before it becomes part of the 
MAIN branch.  It is easier to avoid creating bugs than it is to fix them later!

And, if we are really going for World domination, we must change our 
attitudes about the users.  Despite what was recently said, we NEED users. 
  It would be nice if most of them also became participants in the project 
rather than just users.  It is Tom Petters ideas that apply to this 
question.  It is not enough to have a better product if our idea of 
marketing is to say here it is -- take it or leave it.  Dare I say that we 
need to have customer service?  Or, at least care what the customer/user 
thinks.

--
JRT


Kde-cafe mailing list - [email protected]
http://ofb.biz/lists/listinfo.cgi/kde-cafe

DISCLAIMER: The views expressed on this mailinglist are the personal
opinions of the author and do not represent OfB.biz: Open for Business, KDE or the author's employer.