--===============1682844581==
Content-type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature"; boundary=nextPart1303920.9IxqGGMt7G
Content-transfer-encoding: 7bit

--nextPart1303920.9IxqGGMt7G
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Saturday 12 March 2005 03:50, Maurizio Colucci wrote:
> > there's issues of code quality;
>
> This too is solved with the above proposal (coders have no reason to
> deliver bad code anymore).

i suppose if the bounty wasn't released until the code was accepted by the=
=20
maintainer and it follows KDE standards with regards to licensing, security=
,=20
maintenance, etc... then this is probably solvable, yes.

> > there's issues of
> > collecting and disbursing money; legalities that would come into play?;
>
> Of course, this issue must be solved. Some kind of deal with PayPal or
> http://www.dropcash.com/ should be made.

i was more thinking about sales taxes and such things =3D)

> > there's issues of more than one person working on the same BR and feeli=
ng
> > the shaft when one of them gets the bounty;
>
> Solvable: the bug gets assigned to the coder who has the highest
> "reputation". Reputation is a score that depends on how well he fulfilled
> previous assignments (donators should be able to give votes to
> implementors)

urg.. popularity contests. how does that translate to good code?

> > the fact that i don't see 20 people
> > voting on a bug coming up with any amount of money that correlates to t=
he
> > time involved in fixing things;
>
> My hope is that, once you give people a way to control how their money ge=
ts
> used, they will begin donating much more. This is the whole point.

what i meant is that given the number of people who pay attention to a give=
n=20
bug, i don't see a lot of money being put down on the average bug report.

> > the fact that it isn't the patchwork that
> > needs help, it's the larger development issues which this doesn't
> > address, and so on.
>
> No problem. The developer can decide the best way to implement the featur=
e.
> If it requires working on qt, or xorg, instead of KDE, he can do it. I
> don't see why the donator should care *where* exactly the code goes.

i mean the issues that take 100s or even 1000s of person-hours to do. the=20
things that take effort, coordination and lots of time. would bug/wishlist=
=20
donations have resulted in kparts or dcop? will they result in any of the=20
other infrastructural components that we still need?

look at the bugs and wishlist items on bugs.kde.org. they are for things th=
at=20
are obviously apparent to a user versus engineering type items that most=20
people need/want.

> Unless I misunderstood the role of "Friends of KDE", this seems to me only
> some kind of tax based on generosity.

no, it would be a fan club, in the same sense that the NRA is a fan club fo=
r=20
guns or the 10 Club is a fan club for Pearl Jam. both result in funds and=20
money going towards gun politics and Pearl Jam, respectively. the people=20
involved don't get to request who the gun lobbyists take for lunch or what=
=20
chords Pearl Jam uses in the songs on their next ablum. rather, these peopl=
e=20
get membership cards, cool shwag and benefits and association in a communit=
y=20
of like minded people. they do this because they believe that guns are=20
fun/important or that Pearl Jam makes great music.

it isn't a tax based on generosity, it's a levy for appreciation of what th=
e=20
people are doing and to get front row tickets at the next Pearl Jam concert.

the nice thing for Pearl Jam is that they have no artistic commitment to=20
people in the 10 Club. none whatsoever. if they stopped putting out music a=
nd=20
stopped touring and pissed off their fans, people would turn in their=20
memberships.

that said, there's no reason why a Club Konqi couldn't take regular surveys=
=20
and collate the needs / desires / etc of members, both individual as well a=
s=20
organizational, and incorporate that information into KDE releases. this=20
would be the equivalent of getting that front row seat to Pearl Jam. we'd=20
communicate which changes were a result of this feedback and help, of cours=
e.=20
and this is all doable by non-developers.

this is the sort of relationship i'd personally feel most comfortable with=
=20
when it comes to getting people involved.

> You seem to be ignoring the key point. Allow me to repeat:

i'm not ignoring it. i don't agree with it.

>     Most people will donate only if you give them some kind of guarantee
>     that their money will be used to develop the feature they want.
>     Contributors must be able to control how their money gets used.

then why have previous attempts at this failed? i just don't see any eviden=
ce=20
for this being true. are there any studies, let alone success stories, sayi=
ng=20
that this is how people work?

> My proposal exploits the selfish interests of people, and turns it into
> advantage for the free software movement. This is a key difference with
> yours.

i think people are lazier and more spenthrift than they are selfish.

=2D-=20
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

--nextPart1303920.9IxqGGMt7G
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBCM6yK1rcusafx20MRApjNAJ9ps2p02uuXk2/CLOTho2hfXm974ACgneQN
P4gHvid4Yfl1baxSvE3Tkcc=
=ekQb
-----END PGP SIGNATURE-----

--nextPart1303920.9IxqGGMt7G--

--===============1682844581==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability

--===============1682844581==--