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

On Saturday 22 July 2006 13:25, Maks Orlovich wrote:
> No, it's not. Yes, the proposed policy itself affects only kdelibs. But
> the /nature/ of the policy affects everyone. This sets a precedent that
> something that's merely a matter of preference and not technical merit can
> be legislated as a policy in the project. And in fact, even making kdelibs
> different in a way that's not technically neccessary (constract with e.g.
> BC), introduces a small but existing psychological barrier for contributo=
rs
> to jump into kdelibs from other modules.=20

this contradicts every bit of experience i've ever had in software developm=
ent=20
and apparently others who have bothered to reply. for me, this includes doi=
ng=20
exactly what is being suggested for kdelibs in kicker for the last 2 years.=
=20
given that that is a kde project, let's do a comparison:

kicker had near zero contributors. adding a style guide didn't keep people=
=20
out, in fact it brought greater consistency to the code base while an amazi=
ng=20
number of new contributors showed up over those 2 years. it actually helped=
=20
these new people figure out how to contribute. and my applying a HACKING fi=
le=20
to kicker didn't make that spread to the rest of KDE apps; not even in the=
=20
same module. nor did i try to make that happen.

when at the GIT workshop this week the instructor took out some time to=20
discuss writing patches that have a hope in hell of making it into the linu=
x=20
kernel. one of the first things he mentioned was your patch must follow the=
=20
coding style of the project otherwise you can assume it'll never get applie=
d.

this coding style guide thing is extremely common both in industry and=20
volunteer projects and does have benefits.

> (And don't bring up kdepim, please.=20
> kdepim also has a long-lasting reputation for being hostile to new=20
> contributors).

ouch. yellow card.

i've followed this particular project (kdepim) since i started following kd=
e=20
sometime in 2000 and i will state unequivocally that kdepim was horrific to=
=20
get involved with during the 2.x and early 3.x work. i stopped contributing=
=20
to that body of code specifically due to that.=20

but then after yet anoter blow out the core group got together and worked o=
ut=20
how to have a set of maintainers that everyone could work with .. and one o=
f=20
the things they did was to bring in a common hacking style. since then kdep=
im=20
has been -much- better with new contributors and i've seen more new people=
=20
since than before.

in fact, i'd say they aren't hostile to new contributors at all anymore. it=
=20
was a reputation kdepim earned once many years ago but has since, IME and=20
IMHO, grown beyond. part of that growth was getting their codebase in order.

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

=46ull time KDE developer sponsored by Trolltech (http://www.trolltech.com)

--nextPart2285018.Lha6bVO12c
Content-Type: application/pgp-signature

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

iD8DBQBEwqUG1rcusafx20MRAtQmAJ9/6u4u3adddHNi8PlYkCoFukSd0gCfUFVT
4xDKKtQV6SDJ3ACnrKnODdg=
=8U7u
-----END PGP SIGNATURE-----

--nextPart2285018.Lha6bVO12c--