[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Allow money donations for precise bugs
From:       Sebastian Sauer <mail () dipe ! org>
Date:       2005-03-13 20:08:01
Message-ID: d126gj$un4$1 () sea ! gmane ! org
[Download RAW message or body]

Dirk Schönberger wrote:
> How about changing this to a two step process:
> 
> - Jack begins working and delivers within 3 months. He puts his code e.g.
> as patch as an attachment to the bug
>   He may get a part of the donated money
> - there is a "discussion phase", where it is guaranteed that the proposed
> feature is properly reviewed. This can also mean that the code is rejected
> and the process restarts.
> - if a "proper" solution is agreed upon, Jack gets the whole amount of
> donated money
> 
> The remaining problem is that there are still needed a couple of good code
> reviewers with enough time at their hand and enough knowledge about the
> overall architecture. Discussing proposed solution can be as complicated
> as re-implementing them themselves.
 
So, it's not only Jack who does spend time to get the wish implemented. At
least one or more reviewers, the maintainer, the i18n-Teams to get new
strings translated, documentation writters, testers, devels that find x
days/weeks/months later bugs in the code and fix it, etc. But Jack got the
money, put his patch in the wishreport and walked away to work on the next
wish to earn the next money.
Even without the problem, that only wishes got payed and to fix bugs (just
ask a devel, to fix bugs takes a lot of time) is just the work somebody
else will do. 
I also see a problem in maintaining the new code. It isn't that easy, that
somebody writes a patch, it got applied and that's it. There are much more
people involved. Even later if the wish is done ppl needs to maintain the
code. Please take a look at the revision-numbers of sourcefiles to get an
overview how much sourcefiles got touched. It's somewhat easy to add new
features, but to maintain the code, fix bugs and redesign parts to be more
flexible for new wishes is just those part of work that takes the most time
without getting really much attention.

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]