Re: koffice

--===============0141714144==
Content-Type: multipart/signed;
  boundary="nextPart8617281.MJfeg9MQYy";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart8617281.MJfeg9MQYy
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On Wednesday, February 2, 2011, Alfredo Beaumont wrote:
> Asteazkena 02 Otsaila 2011(e)an, Aaron J. Seigo(e)k idatzi zuen:
> > * people are wasting their own energy and putting the success of Callig=
ra
> > and KOffice needlessly into jeopardy in the process
> >=20
> > * they are spreading discontent throughout KDE with this approach to
> > things
>=20
> I guess this is reciprocal. It's the KDE aproach to things which is causi=
ng
> all this problems and making people waste energy.

er, no. the koffice community created this situation quite on their own.  a=
t=20
this point, there is little that can be done from the outside to make it=20
better other than trying to prevent it from spreading outwards to other are=
as=20
of the community.

then again, maybe that was indeed part of the problem, if not in the way yo=
u=20
meant it here. maybe KDE as a whole should have been able and willing to=20
provide more support for koffice and their community issues over the last f=
our=20
(or whatever) years? maybe expecting effective leadership to be demonstrate=
d=20
in each individual team, even the larger ones, consistently over time is no=
t=20
realistic. and/or perhaps we're not doing enough to create and support=20
effective leadership skills across KDE so that more teams can engage in=20
direction setting and community maintenance in a healthy way.
=20
is there anything that those who have been involved in this would have=20
benefited from, say, 3 years ago that they didn't have access to? (hindsigh=
t=20
is supposed to be 20-20, so let's see if we can take advantage of that ;)

> No sense for an arbitration process when there's no
> value in the arbitration topic.

the value is/was in keeping the problem contained and with a path to=20
resolution so that it can eventually be put behind us. regardless of merit =
or=20
value, making sure that:

* those involved do end up getting taken care of (they deserve it, as human=
s=20
and as our friends)

* those not involved don't end up being impacted by it

is critical and worthwhile all on its own.

remember occurances like certain people showing up at GNOME conferences wit=
h=20
"I Love Mono" stickers? that's the kind of divisive behaviour that happens=
=20
when matters escalate unchecked. i don't want to see that happen in KDE, an=
d=20
so regardless of the value of the KOffice name, spending time on arbitratio=
n=20
is worth it if only to try and keep harmony.

and yes, this is also why we're trying to stay vigilant about not letting=20
these struggles spill out into other areas of KDE (e.V., sys admin, etc.)
=20
> And yes, I agree with you, this is not good at all, but it's not unexpect=
ed
> at all, so maybe it should have been foreseen and thought about it more in
> depth.

hindsight is 20-20, but in this case it may have been foreseable, maybe as =
far=20
back as 3+ years ago. i'm very interested in what we can learn from this=20
particular history and how we can turn that into new tools for others to us=
e=20
in the future so that no one has to repeat this kind of exercise in our=20
community again. (ok, perhaps moderately unrealistic to expect that sort of=
=20
perfection, but we can try, right? :)

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

KDE core developer sponsored by Qt Development Frameworks

--nextPart8617281.MJfeg9MQYy
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)

iEYEABECAAYFAk1Jv40ACgkQ1rcusafx20N0YgCgpns0YvLZ++lLvWerHWOaCbeX
ZXIAninkktrmwhiU1GfBmCq6S4sDvle0
=cHot
-----END PGP SIGNATURE-----

--nextPart8617281.MJfeg9MQYy--

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

_______________________________________________
koffice-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/koffice-devel

--===============0141714144==--