Re: WikiToLearn repos on invent

[Christoph Cullmann (cullmann.io)]

On 2023-06-15 11:13, Ben Cooksley wrote:

On Thu, Jun 15, 2023 at 6:34 AM Christoph Cullmann (cullmann.io [1])
 wrote:


On 2023-05-14 22:50, Christoph Cullmann (cullmann.io [1]) wrote:

Hi,

given the last activity is one or two years ago,
would it make sense to move the stuff in

https://invent.kde.org/wikitolearn

to

https://invent.kde.org/unmaintained

and archive it there until it is revived?


Given nobody objected, could that be done?


All projects in the group have now been archived.


Thanks,

it still shows up prominently in the groups overview,
but I guess that can not be that easily fixed.

Greetings
Christoph


--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: WikiToLearn repos on invent

[Christoph Cullmann (cullmann.io)]

On 2023-05-14 22:50, Christoph Cullmann (cullmann.io) wrote:

Hi,

given the last activity is one or two years ago,
would it make sense to move the stuff in

https://invent.kde.org/wikitolearn

to

https://invent.kde.org/unmaintained

and archive it there until it is revived?


Given nobody objected, could that be done?

Thanks
Christoph



Greetings
Christoph


--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

WikiToLearn repos on invent

[Christoph Cullmann (cullmann.io)]

Hi,

given the last activity is one or two years ago,
would it make sense to move the stuff in

https://invent.kde.org/wikitolearn

to

https://invent.kde.org/unmaintained

and archive it there until it is revived?

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Gitlab update, 2FA now mandatory

[Christoph Cullmann (cullmann.io)]

On 2022-10-28 22:57, Ben Cooksley wrote:

Hi all,

Following some additional analysis of the situation I've now adjusted
the policy surrounding enforced use of 2FA.

Going forward it will only be enforced on people who are one of the
following:
- KDE Developers
- KDE e.V. Members (including the Board)
- KDE e.V. Staff (whether they be contractors or employees)

In addition, 2FA may be enforced on any person who has access to a
system that contains sensitive information, including but not limited
to stats.kde.org [1], metrics.kde.org [2] and collaborate.kde.org [3],
or who has additional privileges on those systems outside of those
granted to users by default. It may also be enforced if a person
becomes involved in a project in a meaningful way (ie. a long term
contributor) that does not result in them obtaining a developer
account or access to sensitive information.


Hi,

thanks a lot, this seems to be a very sensible solution for me.

That will still allow people to easily comment in things and make first 
time contributions without any extra hassle.


Greetings
Christoph



Cheers,
Ben

Links:
--
[1] http://stats.kde.org
[2] http://metrics.kde.org
[3] http://collaborate.kde.org


--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Gitlab update, 2FA now mandatory

[Christoph Cullmann (cullmann.io)]

On 2022-10-25 20:53, Albert Astals Cid wrote:

> > Hi,
> >
> > whereas I can see the security benefit, this raises the hurdle for one
> > time contributors again a lot.
> >
> > Before you already had to register to get your merge request,
> > now you need to setup this too (or at least soon it is mandatory).
> >
> > I am not sure this is such a good thing.
> >
> > I see a point that one wants to avoid that e.g. somebody steals my
> > account  that has enough rights to delete all branches in the Kate
> > repository via the web frontend.
> >
> > Could the 2FA stuff perhaps be limited to people with developer role or
> > such?
>
> Yes this would be ideal. We don't need to require 2fa for people who just
> started contributing or want to give some feedback on a MR/ticket.
>
> This should be possible with the following features:
> https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforce
> -2 fa-for-all-users-in-a-group
>
> We can just require 2fa for developers because with great powers come
> great
> responsibilities.
>
> Cheers,
> Carl

  i concur - after spending so long trying to attract casual 
contributors,
putting up a huge barrier like this is just not helpful. So, 2FA for 
people
who area able to actually mess stuff up, absolutely, we have 
responsibility
here and that's fine, but for casual contributors, that is precisely 
the

sort of thing that just outright makes people go "lol no" and go away
again, and is that really something we can afford?


From personal experience I agree, i was going to report a VLC issue, 
their
gitlab also uses mandatory 2FA and I was very close to just giving up, 
and

that was something that kind of bothered me to a certain degree.

I agree with making 2FA non mandatory for non KDE "powerful" account 
holders.


Cheers,
  Albert

  I absolutely applaud the attempt at increasing out trustworthiness 
as a
community, and 2FA for people who can actually push things certainly 
helps
us get to that, but i also can't help but notice that the particular 
choice
of making it a blanket community involvement requirement, that is, in 
this
particular case, was made with a somewhat narrow focus, so... just 
thought

i'd lend my voice to the "Yeah, please don't make our hard won casual
contributors go away before they even get here".


Hi,

could we have this? Only mandatory 2FA for accounts with more rights?

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Gitlab update, 2FA now mandatory

[Christoph Cullmann (cullmann.io)]

On 2022-10-25 21:29, Christoph Cullmann (cullmann.io) wrote:

On 2022-10-25 20:53, Albert Astals Cid wrote:
  i concur - after spending so long trying to attract casual 
contributors,
putting up a huge barrier like this is just not helpful. So, 2FA for 
people
who area able to actually mess stuff up, absolutely, we have 
responsibility
here and that's fine, but for casual contributors, that is precisely 
the

sort of thing that just outright makes people go "lol no" and go away
again, and is that really something we can afford?


From personal experience I agree, i was going to report a VLC issue, 
their
gitlab also uses mandatory 2FA and I was very close to just giving up, 
and

that was something that kind of bothered me to a certain degree.

I agree with making 2FA non mandatory for non KDE "powerful" account 
holders.




hi,

one other side note, e.g. my GitHub account login stays after valid 2FA 
auth

valid in my Chromium browser even over reboots on my normal machine.

Is that something one can configure or is GitLab just not able to 
support this?


Makes the use on the home pc a lot less annoying.


Just forget that question, my 'remember me' checkbox was just not on ;)



Greetings
Christoph


--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Gitlab update, 2FA now mandatory

[Christoph Cullmann (cullmann.io)]

On 2022-10-25 20:53, Albert Astals Cid wrote:
  i concur - after spending so long trying to attract casual 
contributors,
putting up a huge barrier like this is just not helpful. So, 2FA for 
people
who area able to actually mess stuff up, absolutely, we have 
responsibility
here and that's fine, but for casual contributors, that is precisely 
the

sort of thing that just outright makes people go "lol no" and go away
again, and is that really something we can afford?


From personal experience I agree, i was going to report a VLC issue, 
their
gitlab also uses mandatory 2FA and I was very close to just giving up, 
and

that was something that kind of bothered me to a certain degree.

I agree with making 2FA non mandatory for non KDE "powerful" account 
holders.




hi,

one other side note, e.g. my GitHub account login stays after valid 2FA 
auth

valid in my Chromium browser even over reboots on my normal machine.

Is that something one can configure or is GitLab just not able to 
support this?


Makes the use on the home pc a lot less annoying.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Gitlab update, 2FA now mandatory

[Christoph Cullmann (cullmann.io)]

On 2022-10-25 14:55, Ahmad Samir wrote:

On 25/10/22 14:31, Christoph Cullmann (cullmann.io) wrote:

On 2022-10-25 13:52, Ahmad Samir wrote:

On 25/10/22 13:29, Harald Sitter wrote:

On Tue, Oct 25, 2022 at 1:22 PM Ahmad Samir 
wrote:


Can a first time contributor create a fork, create multiple/100 
MR's

and spin up CI jobs? if yes,
then, first time contributors can disrupt the system.

Weren't there some suspicious accounts that were using our gitlab
instance for bitcoin mining (I
could be wrong, I vaguely remember someone from Sysadmin team 
talking

about something like that)?
were these first time contributors or ones with developer accounts?


I'm sure 2fa doesn't help with that (:


I am not a cyber security expert, but isn't 2FA comparable to captcha
stuff? it's not hard, but it takes some extra time. Which forum would 
a
spammer target? the one with the "create account and login 
immediately"

or the one with "create account, verify captcha hell, verify email
address"?


That is true, but did we have concrete issues with spam accounts?

And if yes, a one time captcha solving is a lot lower barrier the to
need to do 2fa auth for a trivial issue
Comment or merge request.

At least for any part I work on in KDE the issue is manpower.

Any step to make it more easier to help is good.
Any step to make it harder is bad.

I see the point why we not work on GitHub,
I don't like to be dependent on some random company
that in worst case can randomly pull the plug.

But I somehow don't understand why we need to enforce
this now even for new accounts without rights.

I must confess I would like it even more if 2fa
would only be required on doing some action that
Is problematic and not just on any issue or merge
request comment. But I assume that is not feasible.

Greetings
Christoph



FWIW, when I log in to GitHub, they email me a pin number that I have 
to put in the web page, for me it's exactly the same level of 
inconvenience:

- "check email, find pin, copy, paste"
- "check app on phone, type pin"


A mail is a lot easier on many devices,
at least for me.

My Kindle Fire can read my mails, but per default has zero otp stuff I 
could use.


Same for my different work computers.
All can get mail, none had before any such application.

Therefore, yes, GitHub or the Steam Store work for me
Without any extra setup effort. A mail address was
Required anyways.

And no, not even per default KDE Plasma ships with
any obviously well integrated otp client.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Gitlab update, 2FA now mandatory

[Christoph Cullmann (cullmann.io)]

On 2022-10-25 13:52, Ahmad Samir wrote:

On 25/10/22 13:29, Harald Sitter wrote:
On Tue, Oct 25, 2022 at 1:22 PM Ahmad Samir  
wrote:


Can a first time contributor create a fork, create multiple/100 MR's 
and spin up CI jobs? if yes,

then, first time contributors can disrupt the system.

Weren't there some suspicious accounts that were using our gitlab 
instance for bitcoin mining (I
could be wrong, I vaguely remember someone from Sysadmin team talking 
about something like that)?

were these first time contributors or ones with developer accounts?


I'm sure 2fa doesn't help with that (:


I am not a cyber security expert, but isn't 2FA comparable to captcha 
stuff? it's not hard, but it takes some extra time. Which forum would a 
spammer target? the one with the "create account and login immediately" 
or the one with "create account, verify captcha hell, verify email 
address"?


That is true, but did we have concrete issues with spam accounts?

And if yes, a one time captcha solving is a lot lower barrier the to 
need to do 2fa auth for a trivial issue

Comment or merge request.

At least for any part I work on in KDE the issue is manpower.

Any step to make it more easier to help is good.
Any step to make it harder is bad.

I see the point why we not work on GitHub,
I don't like to be dependent on some random company
that in worst case can randomly pull the plug.

But I somehow don't understand why we need to enforce
this now even for new accounts without rights.

I must confess I would like it even more if 2fa
would only be required on doing some action that
Is problematic and not just on any issue or merge
request comment. But I assume that is not feasible.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Gitlab update, 2FA now mandatory

[Christoph Cullmann (cullmann.io)]

On 2022-10-24 11:23, Ingo Klöcker wrote:
On Montag, 24. Oktober 2022 09:19:49 CEST Christoph Cullmann 
(cullmann.io)

wrote:

I think it is rather worse that now first time contributors have this
requirement.


Do you have proof for this, e.g. a study, or is this just your 
Bauchgefühl

(gut feeling)?


I can not proof this.

I only know that even for myself this makes it a lot more work to login,
if I don't start to setup an application for that on my tablet and main 
machine

and work machine, too.

But I see the point that it makes sense for accounts with elevated 
rights.




There is plenty of proof (e.g. TBs of leaked password databases) that 
lots of
people use insecure passwords and that lots of people reuse the same 
"secure"

password everywhere. 2FA protects those ignorant people. If the 2FA-
requirement on invent helps to make more people aware of 2FA, then 
that's a

good side-effect.

Besides, my hope is that with FIDO2 "soon" passwords will be a relic of 
the

past.


That is a nice dream, but IMHO very unlikely in the near future.

Greetings
Christoph



Regards,
Ingo


--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Gitlab update, 2FA now mandatory

[Christoph Cullmann (cullmann.io)]

Hi,


Could the 2FA stuff perhaps be limited to people with developer role
or
such?


It is technically possible to only apply the mandatory 2FA rules to
only certain groups as Developer accounts are simply membership in
teams/kde-developers.
See
https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforce-2fa-for-all-users-in-a-group
for the documentation on this.

Given that we are using Invent for authenticating our various other
services and the users of those aren't necessarily developers (while
still having access to sensitive information) it seemed more prudent
to enforce 2FA for everyone to ensure all our systems have a minimum
baseline of industry best practice protection in place.

This also avoids any issue when people are granted a developer account
and suddenly find themselves subject to a new requirement.


I think it is rather worse that now first time contributors have this 
requirement.


A lot of people already complain "why can I not just use my GitHub 
account',

now they need to setup this in addition.

And yes, beside for invent.kde.org, I never needed to use my Google Auth
App beside for some hosting.

All other things I use that have 2FA use different methods that don't 
need

any such app on my phone.

Therefore that is more then just 2 clicks for a lot of people.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Gitlab update, 2FA now mandatory

[Christoph Cullmann (cullmann.io)]

On 2022-10-23 08:32, Ben Cooksley wrote:

Hi all,

This afternoon I updated invent.kde.org [1] to the latest version of
Gitlab, 15.5.
Release notes for this can be found at
https://about.gitlab.com/releases/2022/10/22/gitlab-15-5-released/

There isn't much notable feature wise in this release, however there
have been some bug fixes surrounding the "Rebase without Pipeline"
functionality that was introduced in an earlier update.

As part of securing Invent against recently detected suspicious
activity I have also enabled Mandatory 2FA, which Gitlab will ask you
to configure next time you access it. This can be done using either a
Webauthn token (such as a Yubikey) or TOTP (using the app of choice on
your phone)

Should you lose access to your 2FA device you can obtain a recovery
token to log back in via SSH, see
https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#generate-new-recovery-codes-using-ssh
for more details on this.

Please let us know if there are any queries on the above.


Hi,

whereas I can see the security benefit, this raises the hurdle for one 
time

contributors again a lot.

Before you already had to register to get your merge request,
now you need to setup this too (or at least soon it is mandatory).

I am not sure this is such a good thing.

I see a point that one wants to avoid that e.g. somebody steals my 
account
that has enough rights to delete all branches in the Kate repository via 
the

web frontend.

Could the 2FA stuff perhaps be limited to people with developer role or 
such?


Greetings
Christoph



Thanks,
Ben

Links:
--
[1] http://invent.kde.org


--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: KDE Documentation & new Job

[Christoph Cullmann]

On 2021-07-05 21:00, Noah Davis wrote:

It was great to have you!


Yeah, you brought our websites from the stone age header/footer
PHP hell I and others left to rot to something
a lot more maintainable and nicely i18n'able ;))

Thanks a lot for all the work on that (and NeoChat & Co.)!

Greetings
Christoph



On Mon, Jul 5, 2021 at 11:17 AM Carl Schwan  wrote:


Hi folks,

Starting next week I will be starting a new job at Nextcloud and
will be leaving my current job at the KDE e.V. I added a small
report of the stuff I did during my contract with the KDE e.V. and
also a list of tasks I won't be doing anymore and would appreciate
if someone step-up to continue doing them at:
https://carlschwan.eu/2021/07/05/kde-documentation-new-job-at-nextcloud/

Thanks a lot to the KDE Community and KDE e.V. for entrusting me
with the task to make the KDE documentation better.
Cheers,
Carl


--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Proposal: remove the restriction on normal Bugzilla users being able to change the Severity field

[Christoph Cullmann]

On 2021-06-19 16:21, Nate Graham wrote:

Hello everyone!

Some time ago, we instituted a restriction preventing normal Bugzilla
users from being able to change the Severity field of Bugzilla
tickets. The reason for this change was to stop users with excessive
ego from marking their own tickets and tickets they care deeply about
as having the "critical" Severity level.

However due to technical limitations in Bugzilla, we were unable to
prevent users from setting the Severity to "critical" (or anything
else) at the moment they create the bug report, which introduced the
odd situation of a user who accidentally sets the Severity level
incorrectly by mistake being unable to correct the mistake!

This policy also prevents volunteer bug triagers from correcting the
Severity level of miscategorized tickets (e.g. marking crashes as
"crash" and feature requests as "wishlist") without being specifically
granted permission by sysadmins, Christoph Feck, or me. This is a
barrier to participation in bug triage.

My sense is that this policy created more problems than it solved, and
it did not even succeed in solving the original problem anyway. I
would like to propose letting unprivileged Bugzilla users change the
Severity field once again. The priority field would still be
restricted to privileged users.


I am for this proposal.

In the case of "problematic" bug reports, the severity level
changes are in my eyes the smaller issues compared to the
discussions that normally are done in such bugs that
shave away the good will of our developers/bugsquashers.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: The status of freenode (the IRC network used by KDE)

[Christoph Cullmann]

On 2021-06-15 15:59, Kenny Duffus wrote:

On Tuesday, 15 June 2021 14:50:51 BST Andrius Štikonas wrote:
Given the imposion today, can we not just close old matrix rooms with 
m.room.tombstone and point them to new rooms linked to Libera?
In the short term that might be a bit disruptive because matrix users 
will have to switch to new rooms. But it we
keep waiting too long we might end up in a bigger mess. And at least 
IRC users showed that they are capable of
switching servers, so maybe we shouldn't assume that matrix users are 
less capable.




On matrix we have a large number of users and the issues of aliases
which complicates stuff, so that is why we are choosing to migrate
them. Just be patient a bit longer

On IRC nothing can be done to migrate users which is why they are
unfortunately left to move themselves


Hi,

I think we should be a bit patient and honor the work sysadmins and 
others put into this.


Greetings & thanks for all that work on this pressing issue!

Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: All About the Apps Goal

[Christoph Cullmann]

On 2021-04-23 21:04, Ben Cooksley wrote:

My personal suggestion would be to pick a few applications and try
to work
with them to get the tooling up. E.g. Krita, Kate, KWrite and
Okular. And try
to automate. Don't have the application developers maintain all
those
variants. It's too much! Maybe it's possible to get craft to a point
that it
can build for all of those platforms? Maybe it's possible to
generate the
required files directly with cmake? Give the devs one place to add
their
dependencies. Give them easy tools they know. If they have to invest
looking
into how to package for snap they will ask "what do I get over apt?"


Craft already looks after Windows and MacOS, and is developing the
capability for Android and Appimage (which some projects are already
using on the Binary Factory for both). Once the Android and Appimage
stuff has matured further we'll likely start requiring projects use
Craft rather than permitting bespoke tooling to be used.


I would prefer that, too.

I use the Craft produced installers for the Windows Store and
I hope to better test the Appimage stuff created there, too,
for Kate.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Rebranding the release service

[Christoph Cullmann]

On 2021-02-15 15:36, Nate Graham wrote:

On 2/15/21 6:01 AM, Jonathan Riddell wrote:
Here at KDE we've always struggled a bit with branding and the 
announcement of formats for the bunch of releases that was originally 
"KDE" then "KDE SC" then "KDE Applications" and at Akademy 2019 we 
decided to debrand it and make it a release service with lots of 
different stuff in it.  We had monthly update announcements that 
included those releases on the months when they happened and otherwise 
included everything else released over the past month.  But the format 
doesn't seem to have caught on by various metrics.  So the promo group 
had some chat about different formats you can read at 
https://phabricator.kde.org/T14091 



Currently the plan is to reband it probably with the name KDE Gear.   
That gets released every 4 months (same as currently) with a big 
announcement for it and everything in it.  It's still a collection of 
apps and supporting libraries with no connection to each other except 
they happen to be KDE projects which don't want to do their own 
release work.  Then every 4 months on the months between times we have 
an update article highlighting all the other stuff that has been 
released by KDE.  The bugfix releases for KDE Gear happen monthly as 
currently and only have a minimal announcement.


We hope this format will get some more traction with engagement from 
outside press and social media buzz.  Any comments welcome.


+1, I think this makes sense. I like "KDE Gear". It's short and sweet
and suggestive, but not descriptive.


+1, too

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: WikiToLearn status

[Christoph Cullmann]

On 2021-02-14 15:18, Christoph Cullmann wrote:

Hi,

during some reviewing of what we link from e.g. kde.org and Co. I 
stumbled

over the current state of the WikiToLearn wikis.

It seems most of the recent changes (of at least the last 30 days)
are spam ( see links in 
https://invent.kde.org/websites/kde-org/-/issues/9 ).


The development list seems to be vacant since 2018 
(wikitole...@kde.org)

and same for the git repositories, more or less, if I don't misread the
status on invent.kde.org.

I pinged i...@wikitolearn.org (as mentioned on their websites), so far
no response.


Meanwhile I got some answer, moderation seems to be an issue.

Perhaps one of the WikiToLearn team can reply here with more details
how people could help out.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

WikiToLearn status

[Christoph Cullmann]

Hi,

during some reviewing of what we link from e.g. kde.org and Co. I 
stumbled

over the current state of the WikiToLearn wikis.

It seems most of the recent changes (of at least the last 30 days)
are spam ( see links in 
https://invent.kde.org/websites/kde-org/-/issues/9 ).


The development list seems to be vacant since 2018 (wikitole...@kde.org)
and same for the git repositories, more or less, if I don't misread the
status on invent.kde.org.

I pinged i...@wikitolearn.org (as mentioned on their websites), so far 
no response.


Is this project still alive?

Some feedback e.g. here

https://invent.kde.org/websites/kde-org/-/issues/9

would be great.

Perhaps this is just some temporary glitch in wiki moderation.
I didn't revisit the longer history there.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Fundraising in KDE

[Christoph Cullmann]

Hi,

On 2020-09-23 00:53, Carl Schwan wrote:

Hello everyone,

Nate gave an excellent talk at the Akademy about how we can konquer the 
world
and reach new horizons with our software. One of the first steep for 
Nate is
for the e.V. to start paying more developers to work on core KDE 
technologies.


I believe there is an even more important steep before, finding the 
money to

pay the developers. The current incomes of the e.V. are €183.883 while
the expense
is €258.851. No need to be good in maths to understand that we are 
losing money.
This is normal because we were hoarding too much money for a long time 
without
spending it, but this is still not a sustainable situation and if we 
start

paying developers we will need to find even more money.

KDE's current incomes come from donations from companies (€60 000) but 
also from

doing one time donations (€35 000) or recurring donations (€9000) from
individuals. There is also a lot of companies that help by sponsoring 
the

Akademy and other events organized by KDE. The numbers above are only
my prognostics
looking at the current trends.

Many thanks to all these wonderful people donating money to the e.V. 
but this
is unfortunately not enough and if we want to start paying developers 
we will

need to change our fundraising strategy radically.

One of the reasons why we don't raise as many funds as we could is 
because of
the failure of our recurring donation system. When the money raised 
through the
one-time donation system increase by 50% in just one year, the 
recurring

donation system lost 10% of its donors at the same time.

Currently, we are using CiviCRM as our donation system, CiviCRM is a 
Customer
Relationship Management for non-profit and non-governmental groups. 
CiviCRM
is a complex web application and has many features for non-profit, we 
are
currently using the CiviContribute extension to manage the recurrent 
donations.


Unfortunately, like the numbers are telling, this doesn't work well. We 
have
technical difficulties with the system. The problems are not new and 
there were
multiple attends to fix then by hiring CiviCRM specialized consultants. 
KDE e.V.
recently hired new consultants, and I'm crossing my fingers that this 
time it

will work. This would at least solve some problems for the time being.

Another problem to solve is the design of the website: To make it 
short,

[relate.kde.org](https://relate.kde.org) is ugly and needs a visual
refresh and an update of the content. So I developed a new theme, 
available

[here](https://invent.kde.org/carlschwan/civicrm-relate-docker/-/tree/main/aether).
It's not perfect but a lot better than the current one and it was quite 
a

horror story (more on that later).

And the last problem is also how we are positioning our donation 
system.
Currently, it's a traditional organization membership fee and this is 
the reason

why we are using CiviCRM. When someone pays €100 per year, they become
a KDE e.V.
supporting member. Their donation helps KDE e.V. in its activities 
(sponsoring

sprints, servers, ...). This works if we want KDE to remain a small and
traditional organization developing software as a hobby, but I don't 
think this

is our goal. Our vision is:

"A world in which everyone has control over their digital life and 
enjoys

freedom and privacy."

And to achieve this vision, we need to grow, get more people involved, 
making
sure that people can make a living by contributing to KDE and also 
contribute
to the less fun area of KDE (the thing that nobody cares about but is 
really

important like accessibility).

I believe that if we were to communicate more clearly how by donating, 
we are
able to improve our software and moving forward with our vision, it 
should

encourage more people to donate.

Moving forward I don't think CiviCRM is the solution for KDE. I'm quite 
happy
that the immediate problems will hopefully get resolved soon but we 
need a

better long term solution.

CiviCRM requires constant maintenance and since the business model is 
having
a network of consultants, it wasn't developed with easy of use in mind. 
For
example it doesn't use the standard PHP package manager `composer`, but 
require
instead of downloading each package manually and keeping track of the 
version

manually.

CiviCRM uses the infamous Drupal 7 theming engine for rendering the 
pages.
It means that instead of working with a templating engine like 99% of 
the web
frameworks, Drupal 7 works with hooks, hooks are function that gets 
called
when rendering a certain portion of a page. This creates a very 
inflexible
way to create a website and with some part of the layout that can only 
be
changed using JavaScript. CiviCRM doesn't help by creating a dumping 
its forms
without any way to customize the appearance unless you again use 
JavaScript to

change the HTML dynamically.

The good news is that CiviCRM will soon switch to Drupal 8 and use a 
normal

templating engine, but it also means 

Re: MPL2 instead of LGPL

[Christoph Cullmann]

On 2020-08-17 17:47, Ivan Čukić wrote:

> I've read now multiple times about projects replacing their use of
> LGPLv3 [1] with MPL2 [2]. I would be interested in what people in the
> KDE community think about that.


Maybe an alternative to MPL could be these:
1) GPL with runtime exception (if GCC's standard library can use it, I 
guess
we can as well) 
https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html

2) Boost license as it is also created for a set of template-heavy C++
libraries


If one wants to write a modern C++ library that makes heavy use of
templates in the API and which proprietary consumers should be able to
use is this clause alone reason to prefer the MPL2 over the LGPL or is
my concern unfounded?


Now, if you don't want to sue anyone, the "10 lines" thing is not a 
problem.

:)

You can ask around people that have C++ libraries published under LGPL
if they had clients confused about the licensing. There is quote a lot 
of FUD
about (L)GPL often created by companies with dual-licensing models (not 
gonna
mention any names here) so I could see a company being afraid of using 
an LGPL
library. But, on the other hand, if you clearly explain what LGPL means 
in the

context of your library, I'd say LGPL will not be a problem.

Hi,

for KSyntaxHighlighting we did choose to go with MIT licensing instead 
of LGPLvX.


That allows all kind of integration for proprietary software,
but will allow people to keep their changes, too,
which might be not what all people like.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: KDE Apps name trademarks

[Christoph Cullmann]

On 2020-07-09 20:10, Nicolás Alvarez wrote:

El jue., 9 de jul. de 2020 a la(s) 10:49, Christoph Cullmann
(christ...@cullmann.io) escribió:

There is no evidence that this upload contains any virus/miner/...

And even for the GPL it is enough if he provides the sources on 
request

and only to the customers that bought the app.


That's not true:
- If I buy the app and it includes the source code, I'm allowed to
redistribute the binary, as long as I include the source code too
(GPLv2 §3.a).
- If it *doesn't* include the source code, then it has to include a
written offer to provide the source code "to any third party" (GPLv2
§3.b), and I'm allowed to redistribute the binary as long as I include
either the source code (§3.a), or pass along the offer for source code
that I got from the seller (§3.c). If you download it from me and I
include that offer, you can request the source from the seller, even
if you didn't buy the app from them.


Yes, that is all fine, but you see the point that one needs to buy it
at least once to check that. It might not be me, you can do it and pass
it to me and I can then request the stuff.

If they fail to hand out the sources then, there is an issue.

But as long as nobody buys it and any of the above isn't honored, there
is no legal issue.

Anyways, I am not sure if the GPL violation is at all a point here,
I doubt they will not give out the sources, they just want to rip
off the average Joe/Jane/.. app store customer that cares not at all
to get the sources or doesn't investigate at all that he could get
this for free.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: KDE Apps name trademarks

[Christoph Cullmann]

On 2020-07-09 17:42, Michael Reeves wrote:

As current  maintainer of kdiff3 I would oppose trade mark enforce
ment. Unless we have clear proof this is an altered version. I am
perpared to push out my own free download if noone in this community
wants the job. That will end the current problem quite nicely.


Hi,

having the binary-factory.kde.org variant in the store would be great,
if you can help with this, e.g. submission howto is on

https://kate-editor.org/post/2019/2019-11-03-windows-store-submission-guide/

I can help with filling the stuff, if you provide a tested installer.

Greetings
Christoph



On Thu, Jul 9, 2020, 10:27 AM Jack 
wrote:


On 7/9/20 9:48 AM, Christoph Cullmann wrote:

On 2020-07-09 14:18, Jonathan Riddell wrote:

On Thu, 9 Jul 2020 at 12:29, Christoph Cullmann
 wrote:


You might be able to do that, but as soon as you start to try to
keep
people
from using the names, the cost-free, bureaucracy-free and layer

free


zone ends.


Sending an e-mail to the Microsoft store doesn't need to cost
anything, and it would have more effect if there can be a claim

of

trademark.  Claiming copyright infringement as discussed on this
thread is also sensible but it does need more work and will need

at

least the cost of buying kdiff3 from their store.


Hi,

sending just a mail will for sure not be enough, as the license

allows

anybody to upload our stuff there.

You can start to claim that the name is trademarked but then this

will

only work if the other party doesn't claim it is not or that we

don't

have
a policy that forbids to upload something with that name + get

money

for it.

I think the suggestion of a letter to Microsoft was about the
potential
copyright violation, not about trademark.  They could confirm
whether or
not there is an offer of source code within the package without
having
to buy it.


--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: KDE Apps name trademarks

[Christoph Cullmann]

On 2020-07-09 14:18, Jonathan Riddell wrote:

On Thu, 9 Jul 2020 at 12:29, Christoph Cullmann
 wrote:


You might be able to do that, but as soon as you start to try to
keep
people
from using the names, the cost-free, bureaucracy-free and layer free

zone ends.


Sending an e-mail to the Microsoft store doesn't need to cost
anything, and it would have more effect if there can be a claim of
trademark.  Claiming copyright infringement as discussed on this
thread is also sensible but it does need more work and will need at
least the cost of buying kdiff3 from their store.


Hi,

sending just a mail will for sure not be enough, as the license allows
anybody to upload our stuff there.

You can start to claim that the name is trademarked but then this will
only work if the other party doesn't claim it is not or that we don't 
have
a policy that forbids to upload something with that name + get money for 
it.


There is no evidence that this upload contains any virus/miner/...

And even for the GPL it is enough if he provides the sources on request
and only to the customers that bought the app.




I really don't think we should start this.


Why? Nobody has given any reason against it so far.


Because this starts to create a threatening atmosphere.

I am allowed to package e.g. Kate (TM)?
Must I rename it?
What are the conditions?
Might they change?
Can I sell it? e.g. can I sell a DVD with a distro with that stuff on 
it?





We would need to draft some TM use policy, too.


Yeah we'd need to write some simple policy that would allow normal
uses like Linux distros and package archives, but they're not trading
using our app names for the most part so it's not a big issue.


But there it starts.
What are the conditions?
Is it ok to have e.g. "Kate" on some website of your distro and sell the 
distro?
But it is bad to e.g. have "Kate" in the name of an application when you 
sell that?


I really think this only produces both a bad taste about if our stuff is 
really free

to use and more work than needed.

If somebody uploads trojans/... to the MS store, that is MS's problem, 
they review/scan

the stuff there.

If we know that there are such things inside a package, one can inform 
them even without

any trademark/name/... issue.

If people upload our stuff and make money with it, be it so, that's 
their right granted
by our license. One can check if they provide the sources after you buy 
it and request it,

but I won't start to invest work to do such stuff.

And I would not expect the e.V. to waste resources on such endeavors.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: KDE Apps name trademarks

[Christoph Cullmann]

On 2020-07-09 13:14, Jonathan Riddell wrote:

On Wed, 8 Jul 2020 at 17:51, Paul Brown  wrote:


Should we add ™ next to the app names?


I don't think putting TM next to the name is enough, though. IANAL,
so take
the following with a grain of salt: in my experience (I had to
register
several names of magazines back in the day) you always have to go
through some
registry office or another to confer any validity to you brand name.
It is not
hard and it is not expensive, but it is a bit of a hassle.


It is enough to put the TM symbol next to the names, this asserts an
unregistered trademark and is cost-free, bureaucracy-free and applies
internationally.


You might be able to do that, but as soon as you start to try to keep 
people
from using the names, the cost-free, bureaucracy-free and layer free 
zone ends.


I really don't think we should start this.

We would need to draft some TM use policy, too.

e.g., would the normal distro be able to use the name? Or only if we 
like
the package? Is it allowed for others to upload the stuff somewhere cost 
free?
e.g. see the https://chocolatey.org/packages/kate package, is that ok? 
or not?


Better promote our own offerings better and be done.

(naturally only my personal opinion)

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: KDE Apps name trademarks

[Christoph Cullmann]

On 2020-07-09 01:23, Nate Graham wrote:

On 7/8/20 4:27 PM, Johannes Zarl-Zierl wrote:

On Mittwoch, 8. Juli 2020 20:27:58 CEST Christoph Cullmann wrote:

Otherwise we must keep in mind we are open source and yes, this is
possible.

(and perhaps promote the KDE e.V. uploaded stuff better)


+1
IMO the most important thing here is to prevent someone else giving 
KDE a bad
reputation by providing a low quality app. The best way to do that is 
to
provide an official app - I think people will use that one if they 
have the

opportunity.


Yeah.

Uploading these apps ourselves seems to be the obvious solution. This
will also undercut any 3rd-party uploads that cost money, because who
would pay money for a counterfeit version when the original thing
straight from the authors is free?


Yes,

but that will need people that help with this.

At the moment, Hannah, me, and a few others do that, but there is no 
real workforce

to get more stuff uploaded at the moment.

(I even didn't update e.g. filelight since last year or so, just Kate 
and Okular)


For Kate and Okular I am happy with the current state, there are some 
open bug reports,
but as far as I can see nothing really grave like "crashs the whole 
time" or "eats all my data".


Still, it would be nice to reach out to more developers on Windows, not 
sure how that is done best,

my blog posts did seem to have a very low impact.

Btw., the internal store statistics show Kate will soon peek over the 
50k acquisitions border, Okular is a bit over 40k.


Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: KDE Apps name trademarks

[Christoph Cullmann]

On 2020-07-08 20:20, Ben Cooksley wrote:
On Thu, Jul 9, 2020 at 6:09 AM Christoph Cullmann 
 wrote:


On 2020-07-08 18:12, Jonathan Riddell wrote:
> Recently we've noticed some KDE apps ending up on the Microsoft Store
> uploaded by unknown third parties.  Maybe to up some credit score for
> their developer account.  Maybe to install bitcoin  miners.  We don't
> know the motivations.  Since it's all free software the licence allows
> it.

Hi,

have you some links to these applications?


I believe Jonathan will be referring to
https://www.microsoft.com/en-gb/p/kdiff-3-diff-utility/9ndvvx243rfh?activetab=pivot:overviewtab#


Hi, thanks for the link.

Guess such things are unavoidable.

If the uploading person is some KDE community member, I assume one could 
talk with him/her/...


Otherwise we must keep in mind we are open source and yes, this is 
possible.


(and perhaps promote the KDE e.V. uploaded stuff better)

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: KDE Apps name trademarks

[Christoph Cullmann]

On 2020-07-08 18:12, Jonathan Riddell wrote:

Recently we've noticed some KDE apps ending up on the Microsoft Store
uploaded by unknown third parties.  Maybe to up some credit score for
their developer account.  Maybe to install bitcoin  miners.  We don't
know the motivations.  Since it's all free software the licence allows
it.


Hi,

have you some links to these applications?



One option is to claim Trademark on all our app names.  This isn't
hard, we just add the ™ onto the name anywhere we have it on our
website starting with kde.org/applications [1]. Some apps such as
KOffice have done this in the past anyway.  This doesn't cost
anything, only a registered trademark (which uses the ®. logo) costs
money.  It might give us more ability to take down random people
posting our software on app stores.  It might also make us look more
corporate than we want to look and put off Linux distros from shipping
our software.

Should we add ™ next to the app names?


As other already posted, I don't think this is sufficient nor do I think
that is really the direction we should move to. (at least for Kate, I am
fine with the status quo).

Greetings
Christoph



Jonathan



Links:
--
[1] http://kde.org/applications


--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Update on Status of Gitlab Migration

[Christoph Cullmann]

Hi,

I just want to express my big thanks for all the work that went into 
this!


Thanks to all people involved in making this happen and 
maintaining/improving all

our other infrastructure.

Besides, happy Easter and become/stay healthy!

Greetings
Christoph

On 2020-04-11 11:35, Ben Cooksley wrote:

Good morning Community,

I'm pleased to report that this week we reached a major milestone,
with all the necessary technical components now being in place on our
side for our migration to Gitlab to take place.

This includes the replacement of the tooling that supports the anongit
network, as well as implementation of a system to sync changes from
Identity to Gitlab in real time.

As part of this, the anongit network following the migration to Gitlab
should pick up new repositories, along with changes to default
branches, project descriptions, repository names and their path, and
the deletion of repositories within 10 seconds of the change taking
place on Gitlab (effectively making it real time)

We are currently looking to confirm how repositories will be organised
on Gitlab, after which we should be able to confirm how and when we
perform the migration.

Please note that only code hosting and code review will be
transitioning at this time - CI and tasks will follow later on.
Existing reviews on Phabricator will not be imported to Gitlab as part
of this process and will need to be closed out on Phabricator.

To help assist with this, it would be appreciated if all holders of a
KDE Developer account could please login on our Gitlab instance (at
https://invent.kde.org/) and ensure they are listed as a 'Developer'
of the KDE group. You can do this by checking the 'Groups' tab of your
Profile on Gitlab.

Should you not be listed as a Developer of the group, and you have
previously logged into Gitlab, please visit KDE Identity and make a
change to your details there, which will trigger a sync of your
account to Gitlab.

Should anyone have any questions on the above, please let us know.

Thanks,
Ben Cooksley
KDE Sysadmin


--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Qt, Open Source and corona

[Christoph Cullmann]

Hi,

just one quick question about this part:

But last week, the company suddenly informed both the KDE e.V. board 
and the
KDE Free QT Foundation that the economic outlook caused by the Corona 
virus
puts more pressure on them to increase short-term revenue. As a result, 
they
are thinking about restricting ALL Qt releases to paid license holders 
for the
first 12 months. They are aware that this would mean the end of 
contributions

via Open Governance in practice.


I have seen no mails regarding this plan at all on the 
qt-interest/development list,
was that discussed/announced anywhere else beside in the discussions 
about this contract?

(or did I just miss that on the other lists?)

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Qt, Open Source and corona

[Christoph Cullmann]

On 2020-04-08 15:39, Boudewijn Rempt wrote:

On woensdag 8 april 2020 13:13:41 CEST Jens wrote:

The issue is for KDE is that we can't prepare ourselves. We can't fork 
Qt,

because we lack the manpower to safely do so currently.


But if we work together with other participants in the Qt community,
then it might be feasible. In fact, I think it's necessary to start
bringing together a group of stakeholders and start preparing for a
fork.

Actually, at least as the last possible option, if any further
cooperation breaks down, I agree with this.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Regarding KDE Privacy policy

[Christoph Cullmann]

On 2020-02-25 19:22, Albert Astals Cid wrote:
El dimarts, 25 de febrer de 2020, a les 18:47:16 CET, Nate Graham va 
escriure:

I find myself in agreement.

I have access to the kuserfeedback data and to be honest I'm rather
dissatisfied with its actionability. There's nothing detailed like "x
percentage of users change the default wallpaper" or "y percentage of
users switch to double-click" that we could actually use to inform our
UI design--let alone anything that could be used to personally 
identify

anyone. The actual data set is so tame and uninteresting that I agree
that we could change our policy and release the stats just to show
everyone that we have nothing to hide.


You can log anything you want, if you think knowing users that have
non default wallpapers or that switch to double click, log that.


That is totally correct, guess the Plasma developers did just start with 
the

basics (like Kate, too).

But given we praise our self that the data we collect is properly 
anonymized
and doesn't contain any private stuff, having it available for the 
public

would make this even more transparent.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Regarding KDE Privacy policy

[Christoph Cullmann]

On 2020-02-25 18:47, Nate Graham wrote:

I find myself in agreement.

I have access to the kuserfeedback data and to be honest I'm rather
dissatisfied with its actionability. There's nothing detailed like "x
percentage of users change the default wallpaper" or "y percentage of
users switch to double-click" that we could actually use to inform our
UI design--let alone anything that could be used to personally
identify anyone. The actual data set is so tame and uninteresting that
I agree that we could change our policy and release the stats just to
show everyone that we have nothing to hide.


+1 from me. (e.g. for the Kate stats)

Greetings
Christoph



Nate



On 2/25/20 5:44 AM, Veggero Nylo wrote:

Hi!
Currently, data transmitted by KUserFeedback is available only by 
opening a sysadmin ticked explaining why you need access in the 
first place. I can see the reasoning behind this, but I do not think 
this is a good idea for developers and users. I think that releasing 
the aggregated data under CC0 license would be better, as also 
proposed by Martin here: 
https://mail.kde.org/pipermail/kde-community/2017q3/003808.html. I 
think this would benefit user trust, as right now they have to trust 
what the KUserFeedback KCM without really being able to see what data 
KDE developers are actually able to see (as most users won't be able 
to look into the code); on the other hand, if the data was publicly 
released, they would be able to see the data themselves and know 
exactly what developers are going to see. I also think this would 
benefit developers, as there might be a significant number of 
developers who could be interested in looking to the data, maybe just 
a single value, without being able to fully justify access to all the 
data (the fact that you have to write a justification becomes a 
negative factor that makes looking at the data less interesting); 
furthermore, even if they get access to the data, they would be unable 
to discuss it in KDE communication channels as those are public, nor 
on phabricator tasks to support their patches, effectively making the 
data much less useful. Also, the current policy might result in a 
privacy problem, e.g.: I once needed data from stats.kde.org 
 regarding website views over time. I was 
granted access to it, and I now can see every singe website viewer, 
with their country, OS, browser, etc - much more than I actually 
needed. If the aggregated data was to be released publicly, I would no 
longer need for stats.kde.org  access, and I 
would no longer be able to access private data that I did not actually 
need. Finally, I do not fully understand why the data needs to be kept 
private in the first place, since it is supposed to be anonymous and 
contain no user content.

What's your opinion on this?
~ Niccolò Venerandi (aka veggero/niccolove)


--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: KUserFeedback integration for Kate

[Christoph Cullmann]

On 2020-02-02 12:27, Christoph Cullmann wrote:

Hi,

I created some initial merge request for basic user feedback
integration into Kate:

https://invent.kde.org/kde/kate/merge_requests/60

To do this properly like described in
https://community.kde.org/Policies/Telemetry_Policy
I would like to have people review this change and raise issues that
might violate our policy.

For now, we just collect some usage statistics.

Please provide your feedback either on this list or on the merge 
request.


I got two positive reviews for this.

I merged this now, to be used in 20.04.

I added the relevant info to

https://community.kde.org/Telemetry_Use

If something is still bad/missing/..., please ping us on 
kwrite-de...@kde.org

or open some issue for that! Thanks!

Greetings
Christoph



Thanks!

Greetings
Christoph


--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

KUserFeedback integration for Kate

[Christoph Cullmann]

Hi,

I created some initial merge request for basic user feedback integration 
into Kate:


https://invent.kde.org/kde/kate/merge_requests/60

To do this properly like described in 
https://community.kde.org/Policies/Telemetry_Policy
I would like to have people review this change and raise issues that 
might violate our policy.


For now, we just collect some usage statistics.

Please provide your feedback either on this list or on the merge 
request.


Thanks!

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: New homepage for kde.org

[Christoph Cullmann]

On 2019-12-08 21:12, Ingo Klöcker wrote:

Hi,

is this still a legal issue if one anonymizes the IPs during 
processing?


I don't think it matters whether it would be legal. What matters is 
that
people whose browsers are set to send "Do Not Track" (or who have opted 
out of

tracking some other way) shouldn't be tracked in any way.


No visitor of the page is tracked in any way with such stats.

You get just plain "X access to this page" with maximal country/town
granularity.

There is no kind of visitor tracking as it would happen if you accept
the piwik cookie.

Greetings
Christoph



Regards,
Ingo


--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: New homepage for kde.org

[Christoph Cullmann]

On 2019-12-08 18:12, Ben Cooksley wrote:

If you want any form of statistics, then it has to be Piwik (now
called Matomo btw)

Processing of our logs for web statistics purposes is not permitted by
our privacy policies (see https://kde.org/privacypolicy.php).

It is also much more problematic to process logs as people have no way
of opting out from that processing because every request is logged -
whereas Piwik/Matomo gives them the ability to opt out.

Hi,

is this still a legal issue if one anonymizes the IPs during processing?

e.g. https://goaccess.io/ will only store the anonymized stuff
in the database for longer term storage and there is zero way
to track this back to individual visitors.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: New homepage for kde.org

[Christoph Cullmann]

On 2019-12-07 23:52, Nate Graham wrote:

This looks excellent.

I have just a few suggestions:

The Applications section could be simplified by omitting the 2x3 grid
of apps on the top, since those same apps are then presented with nice
screenshots and text immediately below.

The Community section feels like it has too many pictures in it. Maybe
pare that down to just 3, like an Akademy group photo, the GSoC photo,
and the LaKademy 2018 photo.


Hi,

I think, too, the new page looks very nice!

I am with Nate, that for the pictures, on the start page, less is more.
Having some there is really a great idea, to show that we are an active 
community

of people. But a few would be enough and we can have some sub-page with
pictures from our past events.

Technical side note: given one of our aims is privacy, do we really need 
the piwik stuff

or would normal web logs with statistics enough for our purpose?

We could aim to be a cookie free (and external resources free) site that 
doesn't track

people at all.

I am not that convinced we need the statistics that much.

Greetings
Christoph



Nate


On 12/7/19 2:56 PM, Carl Schwan wrote:

Hello everyone,

I started working on a new homepage for kde.org, the WIP result
can be viewed at https://kde.carlschwan.eu/index-new. The text is
still, boilerplate, but I wanted to know if the current direction
of this webpage is a good showcase of our softwares and our
community.

Any early feedback? ;)
Cheers,
Carl

PS: if you have good photo recommendations, for the community
section please share, for the final version this section will only
be loaded when the visitor scroll to it so there won't be any
performance impact if I had more photos ;)



--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: 4th global climate strike - should KDE take action?

[Christoph Cullmann]

On 2019-11-04 15:56, cahfof...@tuta.io wrote:

Hello Christoph,
thanks for your fast answer.

You're rigth, the general interest in this topic is very low at this
moment, there were neither positive nor negative reactions.

I would not be able to start a KDE e.V. online voting as I am not a
member of the KDE e.V. .
Your's faithfully
cahfofpai


Hi,

I will just CC the e.V. list with this mail, perhaps somebody is 
interested there.


Given I am more inclined to not take part in such "political"
actions not actually software development related,
I will not step up to request some vote for this.

Greetings
Christoph



4. Nov. 2019, 15:43 von christ...@cullmann.io:


On 2019-11-04 15:32, cahfof...@tuta.io wrote:


Dear KDE community,

two questions:
Christoph and David suggested to do a poll on this topic to get a
consent within the community. Is such a consent finding process
already established, for example described by an official document by
the KDE e.V., and was such a community wide poll ever done before?
During the discussions for the last global climate strike people
mentioned there are ongoing conversations in the KDE e.V. on 
improving

the community's climate impact - what's the current state of this
discussions and are there any results yet?



Hi,

we have only e.V. internal voting setup procedures

https://ev.kde.org/rules/online_voting.php

and I think that would be enough to do for this, if somebody triggers 
that.


Until now, there seems to be zero positive feedback about this request 
on this list anyways,

not sure if voting makes then any sense.

For the state of discussions about climate impact: I think we have not 
yet reached

any decision there e.V. internally.

Greetings
Christoph



Sincerely yours
cahfofpai


30. Okt. 2019, 15:24 von david.hu...@mailbox.org:


Date: Tue, 29 Oct 2019 21:57:42 +0100
From: Christoph Cullmann 


On 2019-10-29 12:18, cahfof...@tuta.io wrote:
> Dear KDE Community,
>
> On 29th of November, the fourth global climate strike will take place.
>
> For the last global climate strike, a banner was placed on the website
> (https://web.archive.org/web/20190921055543/https://kde.org/
> <https://web.archive.org/web/20190921055543/https://kde.org/>) and a
> social media post was published
> (https://mastodon.technology/@kde/102821138461667105
> <https://mastodon.technology/@kde/102821138461667105>).
>
> Should we (as a community) take action at the next global climate
> strike? A blog post and / or a social media post about the progress of
> internal discussions about KDE's climate impact and how it could be
> improved came to my mind.
>
> What do you think?

Hi,

I am not sure the last action in this regard was well perceived by 
all

parts
of the community or KDE e.V.

Given we lacked time for the last strike to clarify this better, 
would

it be
a good idea this time to e.g. at least have a poll inside the e.V. 
if we

want
to support that?

Greetings
Christoph



Hi,

after reading the discussion from september, I think a poll is the 
minimum.

Even withot the next climate strike, I feel we have to do the poll.

Cheers, David



--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org



--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: 4th global climate strike - should KDE take action?

[Christoph Cullmann]

On 2019-11-04 15:32, cahfof...@tuta.io wrote:

Dear KDE community,

two questions:
Christoph and David suggested to do a poll on this topic to get a
consent within the community. Is such a consent finding process
already established, for example described by an official document by
the KDE e.V., and was such a community wide poll ever done before?
During the discussions for the last global climate strike people
mentioned there are ongoing conversations in the KDE e.V. on improving
the community's climate impact - what's the current state of this
discussions and are there any results yet?


Hi,

we have only e.V. internal voting setup procedures

https://ev.kde.org/rules/online_voting.php

and I think that would be enough to do for this, if somebody triggers 
that.


Until now, there seems to be zero positive feedback about this request 
on this list anyways,

not sure if voting makes then any sense.

For the state of discussions about climate impact: I think we have not 
yet reached

any decision there e.V. internally.

Greetings
Christoph



Sincerely yours
cahfofpai


30. Okt. 2019, 15:24 von david.hu...@mailbox.org:


Date: Tue, 29 Oct 2019 21:57:42 +0100
From: Christoph Cullmann 


On 2019-10-29 12:18, cahfof...@tuta.io wrote:
> Dear KDE Community,
>
> On 29th of November, the fourth global climate strike will take place.
>
> For the last global climate strike, a banner was placed on the website
> (https://web.archive.org/web/20190921055543/https://kde.org/
> <https://web.archive.org/web/20190921055543/https://kde.org/>) and a
> social media post was published
> (https://mastodon.technology/@kde/102821138461667105
> <https://mastodon.technology/@kde/102821138461667105>).
>
> Should we (as a community) take action at the next global climate
> strike? A blog post and / or a social media post about the progress of
> internal discussions about KDE's climate impact and how it could be
> improved came to my mind.
>
> What do you think?

Hi,

I am not sure the last action in this regard was well perceived by 
all

parts
of the community or KDE e.V.

Given we lacked time for the last strike to clarify this better, 
would

it be
a good idea this time to e.g. at least have a poll inside the e.V. if 
we

want
to support that?

Greetings
Christoph



Hi,

after reading the discussion from september, I think a poll is the 
minimum.

Even withot the next climate strike, I feel we have to do the poll.

Cheers, David



--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Finding sponsors for kde ev membership application

[Christoph Cullmann]

On 2019-11-02 22:11, Carl Schwan wrote:

Hello KDE community,

I'm contributing since more than a year to KDE. Mostly doing wiki
work and websites development but also promotion and more general
development. And I would like to become a KDE e.V. member.

If I correctly understand https://ev.kde.org/getinvolved/members.php,
I will need to find 3 existing e.V. members to support my
application. So if you are already an e.V. member and think I
should become one too. Please contact me and support my application.


;=) I support you!

Just fill out the

https://ev.kde.org/resources/ev-questionnaire.text

stuff and send it to me in private mail, I will
re-post that to the e.V. list.

Greetings
Christoph



Regards

Carl Schwan
https://carlschwan.eu


--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: 4th global climate strike - should KDE take action?

[Christoph Cullmann]

On 2019-10-29 12:18, cahfof...@tuta.io wrote:

Dear KDE Community,

On 29th of November, the fourth global climate strike will take place.

For the last global climate strike, a banner was placed on the website
(https://web.archive.org/web/20190921055543/https://kde.org/
) and a
social media post was published
(https://mastodon.technology/@kde/102821138461667105
).

Should we (as a community) take action at the next global climate
strike? A blog post and / or a social media post about the progress of
internal discussions about KDE's climate impact and how it could be
improved came to my mind.

What do you think?

Hi,

I am not sure the last action in this regard was well perceived by all 
parts

of the community or KDE e.V.

Given we lacked time for the last strike to clarify this better, would 
it be
a good idea this time to e.g. at least have a poll inside the e.V. if we 
want

to support that?

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: KDE should rather act then just "strike" (Re: Should KDE join the (Digital) Global Climate Strike this friday?)

[Christoph Cullmann]

Hi,

btw., the 20th is over, shall we perhaps remove the banner again?

Looks somehow strange now.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: KDE should rather act then just "strike" (Re: Should KDE join the (Digital) Global Climate Strike this friday?)

[Christoph Cullmann]

Hi,

I learn by social media that KDE is now endorsing this very strike. 
Well, I
obviously do not. There are better activities actually worth endorsing. 
Too
bad some people think they can simply go and speak on whole of KDE's 
behalf? I
feel bitter having to distance myself from a "KDE" position, despite 
thinking
to be part of KDE. (also be aware of the irony to add tiny resource 
usages to
websites with those additional banners, and KDE now linking to some 
place
which endorses Twitter & Facebook, incl. Twitter & Google tracking on 
the

website... not my future but another crisis)


I must confess I missed that we decided to participate, too, but digging
in the mails of this thread it seems the board of e.V. did so. (if I 
don't misread

Aleix mail)

This is OK for me, as for that the board got elected, to do some 
decision

when we can't wait for weeks to vote on something.

Thought I would have appreciated if at least a 5 lines post of the 
announcement

that "KDE joins this" would have been done on the planet or here to make
clear what happens. I am not sure that communicating this over twitter 
only

is the best way to do that, given we have the lists/planet/dot.

(not that twitter is bad to advertise it to the world)

I think this would have been be possible to discuss more properly if one 
didn't bring this up

a few days before it needs to happens.

Some people in the thread said they had this strike marked since months 
thought it seems
nobody thought about communicating it to our community here a bit 
earlier that "let's do this

this week".

Greetings
Christoph

P.S.

:-) You might not remember, but I did put up the "we oppose software 
patents" strike banner
more than a decade ago on kde.org and got burned a lot for that, even 
thought we discussed that internally

at that time.

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Invent/gitlab, issues and bugzilla

[Christoph Cullmann]

Hi,

On 2019-07-04 22:49, Boudewijn Rempt wrote:

On donderdag 4 juli 2019 22:18:32 CEST Elv1313 . wrote:

Ok, lots of email in the last few hours, lets recap a bit.

1. "Top" projects don't like GitLab issues because they are too
simple. Can we try to make a comprehensive list of issues on a pad
somewhere? So far, I see:


I did make a comparison between bugzilla as it is current and gitlab;
I don't think anyone could conclude from that there is any chance of
gitlab's issues feature being capable of being improved to the point
where it can replace bugzilla. It is, simply enough, _not designed to
do that_. It is not designed to be a bug database, it's a developer
task tracker. Not a good one, but it is NOT a bug tracker. Everyone
should stop thinking it is. We've had enough mails today to prove that
beyond all doubt.

Nobody should advocate anymore for replacing bugzilla with gitlab's
issues. That ship has sunk.


2. For point 1.3, maybe this is where the solution is. @Boud, you
mention that Krita "ask" failed. Can you provide more insight here on
why?


It failed, as I have said, because the software was modeled on
stackoverflow. That is, on users helping each other. Users cannot help
other users with support questions; they do not have the knowledge for
that.


Is there anything to learn so we can try better?


A good user support system is smart and offers a shortlist of most
common answers to any question. It does not require logging in for the
user. Zoho helpdesk might be a good user support system; none of the
open source user support systems is usable. Me and the rest of the
Krita team looked at all of them.


How about
redirecting users directly to a ticket system for top-10 projects?
Ticket systems are overkill (and problematic) for 95% of the KDE
projects, but seem a step forward for larger projects. Or maybe send
people to "a forum" first? For my largest non-KDE project (AwesomeWM),
when we switched to GitHub (from FlySpray), we updated the contact
page of the website to point to StackOverflow.com, SuperUser.com and
Reddit above the GitHub Issue link. This worked fine for a relatively
medium-large user base (of geeks).


AwesomeWM's userbase is exceptionally technically capable. Our users
are just about capable of shouting out on Reddit things like "Help! I
have an issue! Help me! I have an assignment due tomorrow!" Without
giving more detail.


3. The login (identity.kde.org) issue. Maybe I am not on enough
mailing lists, but what is the situation regarding generic OAuth2
login for a subset of non-developer services? Is it only an
integration issue or a political one? Being able to login with
Google/Facebook/GitHub/Yahoo/Microsoft/GitLab/Gnome(?!) accounts with
a path to upgrade to "proper" account seems to currently be the
popular and future proof way to handle this. This is better from a
security standpoint because all of them support 2 factor
authentication in a way *normal people* can understand (aka, a
notification on Android phones). Of course it doesn't help with GPG
and SSH public key wallets and other dev related concerns. That's not
relevant for most users.


I don't know; I do know that even the least technically able of my
users has managed to get a bugs.kde.org account. A KDE Identity
account so they can post on the Forum is a far bigger challenge.


4. For point 1.5, this isn't really solving anything. Sure, a better
BZ with all the powerful features would be nice. It would not solve
the PR<->Issues integration problems at all, which still leaves half
of the people here unsatisfied.


I have no idea what you mean with PR<-->Issues integration problem.


It would not be welcoming to projects
looking to move into the incubator because they are used to a more
integrated pipeline.


Are they? Please provide hard proof.


It would also leave the whole problem of slowly
making the services more bot friendly, which is the future.


What do you mean with that?


4.1 This would leave the sequestration of BKO and IKO into 2
ecosystems. This makes bots more complex and makes porting good open
source bots such as mergify.io even harder since it would be more
painful than just a GitHub<->GitLab API compat (or if they ever
support GitLab). Bots are a solution to many of the problem outlined
here, such as when is a pull request acceptable to merge or some magic
rebase/squash/fixup bots.


To me, that sounds like a lot of very technical gibberish, and as far
as I can understand it, totally irrelevant. What is "mergify.io" and
how did that ever come into this discussion?


I wanted to write a lengthy reply, but Boud got already all my points 
covered,

I just agree.

For mergify.io and other automation:

I think the bots you want for the development stuff, like automating 
merge request
reviews (are all tests fine, ...) are good to have, but this is 
unrelated to
user bug reports. I doubt it will hurt to have user bug reports on a 
different
system for this, as long as we have trivial 

Re: Invent/gitlab, issues and bugzilla

[Christoph Cullmann]

On 2019-07-04 19:02, Nate Graham wrote:

On 7/4/19 10:39 AM, Boudewijn Rempt wrote:
Is it really true that gitlab makes reporting bugs easier for our 
users? I.e., does it offer easier login, an easier way to add screen 
shots and screen recordings or crash logs?


In my experience, yes. Being able to use a single account for
everything is a big benefit. And being able to add multiple images and
files inline via drag-and-drop is a huge improvement over Bugzilla
IMO. Then again if Bugzilla 6 offers this, that will remove one
advantage of GitLab issues.


I actually think the state on https://bugzilla.mozilla.org/ is quiet 
usable, they tuned it the last X years.

But yes, a lot of this is missing in the current Bugzilla 5 :(




Is it really true that gitlab makes it easier for our users to make 
reports of a better quality? Like, better wizards, forms, support for 
smarter templates, more ways to cross-check a bug report with other 
bug reports, or cross-check the internal consistency? Is it easier for 
a user reporting a bug on gitlab to tell us which OS, version of OS, 
version of the application they are using?


Does gitlab offer convenience features for our users like replying by 
email? (I know that some people think email is on the way out, but in 
real life, everyone has email -- and if it were going out -- is there 
integration with instant messaging?) Does gitlab make it easier to be 
notified of events related to the issue?


I'm not sure about these.


We all know that gitlab has a rich text editor. This is modern, but 
how important is that, actually? And how important is it to have a 
rich text editor in our issue reporting system right now? Are we 
experience a decline in the number of user reports because more and 
more people don't want to use bugzilla?




Anecdotally, yes. I very commonly hear users on social media write and
say things like "I don't file KDE bugs anymore because Bugzilla is
ancient and incomprehensible". Though to be fair, they also commonly
say that it's because we don't do a good enough job triaging bugs, or
that KDE developers are too mean and abrasive when dealing with users,
so take it with a grain of salt.


Actually, do we really want that every user bug reporter opens an 
account on invent.kde.org?


I actually think the split of accounts between phabricator/gitlab vs. 
bugzilla is no bad but a good feature.


Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Invent/gitlab, issues and bugzilla

[Christoph Cullmann]

On 2019-07-04 18:11, Boudewijn Rempt wrote:

On donderdag 4 juli 2019 17:54:23 CEST Nate Graham wrote:

If so, then it seems like the ideal state of affairs would be to 
replace
Bugzilla with GitLab issues as a new bug-reporting front-end for 
users,
and then there would be a separate back-end like what Phabricator 
Tasks

currently offers us that's visible only or mostly to developers, where
the issues can be categorized, organized, and discussed, and
higher-level projects can be coordinated with something. If we can get
something like this, that seems like the ideal outcome to me.


No, exactly the other way around. Bugzilla should stay for users
reporting bugs -- it's the user generated reports that need all the
managing, not the developer tasks. Do we really want to spend time
maintaining scores of labels so we can tag, ourselves, manually, the
platform for a user report and all the other things? Gitlab is just
not suitable for a user-facing issue reporting system. Bugzilla is
better at that, much, much better.


I agree with that.

Bugzilla is nice for user reports, it provides powerful features
to manage a lot of bugs. Some future update will bring all niceties
that ATM only are available on https://bugzilla.mozilla.org.

GitLab issues are nice, too, for e.g. internal developer tasks, like
the Phabricator tasks.

I don't see any issue in keeping this separation that way around.

If teams want to organize/plan their stuff on GitLab with issues, all is 
fine.


But to fragment the user reports over two systems (and it is actually
worse: over bugzilla + XXX projects on gitlab) or to move the user bugs
to some system not that suitable seems weird to me at least.

Actually, out of my experience, the bugs.kde.org UI is the least problem 
we
have, but more the tremendous amount of bugs (even if you discard 
duplicates/invalids)

and the lack of manpower to handle them.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Invent/gitlab, issues and bugzilla

[Christoph Cullmann]

On 2019-07-04 13:35, Luca Beltrame wrote:

Il giorno Thu, 4 Jul 2019 13:31:49 +0200
Wolthera  ha
scritto:


community to handle, so it is probably more efficient to wait for
bugzilla 6 in any case.


Speaking of that: does anyone know if there is a roadmap for Bugzilla
6? I'd say the comparison should be done with that as well once it's
out.


Bugzilla 6 is running late, the latest release plan is somewhen this 
year, see


https://github.com/bugzilla/bugzilla-ux/wiki/Bugzilla-6-Roadmap

But there is activity for this, if you take a look at the work they do 
with

integrating the bugzilla.mozilla.org stuff into that branch.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Invent/gitlab, issues and bugzilla

[Christoph Cullmann]

On 2019-07-04 12:08, Luca Beltrame wrote:

It does, see above why. As a downstream I don't want to chase the
projects to see which platform they use for reporting bugs. And yes, I
have direct experience professionally with another, unrelated FOSS
project (Bioconductor) which doesn't have a "central" bug reporting
infrastructure and leaves to the maintainers how to get their reports:
it's an absolute hell to wade through.

I don't want to see this in KDE.


Me neither.

This would make a lot of things harder.

e.g. how to be able to easily move bugs between products on gitlab and
bugzilla? At the moment it is very easy to move bugs application got
reported to e.g. the right framework. If we have more than one 
infrastructure

for bug reports this will no longer be that easy.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Invent/gitlab, issues and bugzilla

[Christoph Cullmann]

Hi,


Overall, I think KDE in general should be more active and confident in
taking steps to consolidate and modernize its software offerings and
technical landscape, especially if adoption of key future 
infrastructure
solutions seems to be happening already in many comparable places 
(e.g.

discourse, as used by mozilla, nextcloud, and all over the place, or
gitlab being in use by gnome, debian, purism, manjaro), etc.



I disagree. I'm fine with modernizing bugzilla to bugzilla 6. But
gitlab's issues feature is not powerful enough to handle the amound of
bug reports I have to handle. In other words, I cannot do my work with
gitlab's issues feature. It might look more modern, but it just
doesn't have the power.


I agree with this.

In our company we multiple times reviewed bug trackers (for migrating 
from
Bugzilla), but none actually had a good enough feature set to be 
considered,

beside perhaps Jira (which is non-free/open).

I would wait for the Bugzilla 6 release to judge if the UI arrives in 
the 21th
century before making any decisions what to use. Just that GitLab is 
more

modern doesn't give it all the features one needs.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Invent/gitlab, issues and bugzilla

[Christoph Cullmann]

On 2019-07-02 15:14, David Edmundson wrote:


Plasma Mobile projects are not included in bugzilla. So, gitlab issues
is the only "decent" alternative for bug tracking. If we disable
issues, then the only alternative I see is to report issues to
Phabricator, which, from my point of view, should be avoided.


Things can be added to bugzilla.


I think it would be highly appreciated to have just one Bugtracker for 
all
things and until further decisions are made if one wants or not to move 
away

from Bugzilla to just add all needed products/components there.

I think that is easier to understand for bug reporters and makes it much 
easier
to triage bugs that are some more generic framework/library issues 
occuring

in multiple end projects.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Anonymous contributions

[Christoph Cullmann]

Hi,

Whether or not we can be sure that a string is a name should not be 
relevant to us.


Just answering to say that this is actually what we're actually
discussing in this thread.

Can/Should we accept anonymous contributions (and thus we should not
care about a string being a name) or not?

I think the most sensible answer from the whole thread was the one
from David Edmundson "we should contact a lawyer".


should we then ask the e.V. if we can get a statement from some lawyer 
if it makes a difference
for us legally if we start accepting "Foobar " in 
addition to "Unverified Something "

as authorship identification?

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Anonymous contributions

[Christoph Cullmann]

Hi,

On 2019-04-12 21:43, Sune Vuorela wrote:

On 2019-04-12, Eike Hein  wrote:

Pseudonyms don't jive with that for me. Someone not entrusting me with
their real name feels regressive vs. our current community standards.
It's a bit uncomfortable.


I have kind of the same feeling. Though real name doesn't have to be
legal name.

the question is: don't the trust "us" or the world?
If you ever meet them in real-life at some conference, it could be 
completely different.


Because I use my real/legal name for my work on KDE, the company I work 
for got some weeks ago some
ugly "misuse..." complaint because some other company thinks I named an 
Phabricator task inappropriate.

(name clash)

And because they could easily track me back to my work place with 
trivial searching, they went there with their
complaints. I can see that some people want to avoid such hassle. In 
some companies that could spell serious trouble.


Greetings
Christoph

--
https://cullmann.io | https://kate-editor.org

Re: Anonymous contributions

[Christoph Cullmann]

Hi,


I tried to re-license parts of KTextEditor in the past.
Real names help close to nothing if the mail addresses are no longer
valid or the people don't respond, even if valid.
You just can't track them, unfortunately there are more "Max Schmidt"s
around on the world then lets say "Christoph Cullmann"s.


Yes, Albert Astals Cid is much easier to track than randomguy, i'm
99.99% positive there's only one Albert Astals Cid in the world,
there's millions of randomguys, so please don't say "you just can't
track them" because it's obviously not true, sure for more common
names it's still not trivial, but it is much easier if you have
someone's name than if you don't.


I must confess, even with your "unique" name, I wasn't able to get your 
postal address
nor a phone number with just a bit of "searching". (I found only ancient 
student stuff)

But that might be my inability to use search engines for that task.

Meaning: if your mail addresses I know no longer work, I will be lost 
for any follow up,
or? I assume, as you are highly active and well integrated I can ask 
some of your friends
online and will find you, but that won't work with any non-highly 
connected contributor.


But you are right, a name can help, but I highly doubt without "large" 
resource spending
just a name without any more data like at least your last real address 
etc. will do not help

that much if you need to "stalk" people afterwards for legal paper work.

Greetings
Christoph

Re: Anonymous contributions

[Christoph Cullmann]

On 2019-04-11 20:36, David Edmundson wrote:

We would need to ask a lawyer.
I only know enough to know that I don't know enough.

Hi,

independent of any lawyer, my 2 cents:

As we did never verify any names nor identities, is the discussion not 
mood?


We already accept contributions, by lets make up "Max Schmidt 
", if he/her/... sends in a reasonable patch.


We never check: is that the real name? Is this person existing?

I actually started to accept "alias" named contributions after asking 
me:
I am more happy with a person that tells he/her/... uses an alias or do 
I want to be lied to with some fake name that sounds ok?


For re-licensing and similar stuff:

I tried to re-license parts of KTextEditor in the past.
Real names help close to nothing if the mail addresses are no longer 
valid or the people don't respond, even if valid.
You just can't track them, unfortunately there are more "Max Schmidt"s 
around on the world then lets say "Christoph Cullmann"s.


If you want to re-license and the last known mail addresses don't work 
out for you, you are doomed with or without names.
Actually, from a legal stand-point I am not even sure if some "I am ok 
with re-licensing" mail from some random mail address would be legally 
ok,
I doubt that, you can't do other kind of contracts with plain text mails 
either, at least e.g. not in Germany.


But that's something a lawyer knows best, true.

Greetings
Christoph

Re: Big Hairy Audacious Goal: Privacy Software

[Dr.-Ing. Christoph Cullmann]

Hi,

> On Mon, 21 Aug 2017 21:58:32 +0200
> Alexander Neundorf <neund...@kde.org> wrote:
> 
>> On 2017 M08 18, Fri 18:14:22 CEST Sebastian Kügler wrote:
>> > "In 5 years, KDE software enables and promotes privacy"
>> 
>>  ... does that kind of imply that we need to offer a range of
>> applications which cover the most privacy-sensitive topics, e.g. a
>> competetive web browser ?
> 
> On the one hand, yes. On the other hand, our goal should be realistic,
> and I don't think "offering our own competitive web browser" ticks that
> box. We've been there, we've done that, we succeeded to some degree in
> the most spectacular way (think where KHTML successors are shipped and
> what they brought to the eco system) and failed in other dimensions
> (think about the state of KHTML and our own web browser offering
> nowadays).
> 
> What's probably a lot more realistic and worthwhile is
> to we make integration for web browsers that do respect privacy work
> really well. Integrating Tor really well would also be a good idea in
> that regard.
Actually, we are ATM trying to incubate a new "browser" as replacement for
the old Konqueror that is more or less unmaintained and will then vanish.

(was discussed during the konqueror BoF at Akademy this year)

It is QWebEngine based, see

http://blog.qupzilla.com/2017/08/qupzilla-is-moving-under-kde-and.html
https://community.kde.org/Incubator/Projects/QupZilla

But this process is only at its early stage.

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234

Re: Telemetry Policy

[Dr.-Ing. Christoph Cullmann]

Hi,

> On 08/14/2017 05:30 PM, Ivan Čukić wrote:
>> Hi all,
>> 
>> While I do see the point behind 'off-by-default', I think it will ruin
>> the purpose since nobody will turn it on.
>> 
>> I'd propose having it on by default (at least) for pre-releases.
> 
> I'm not convinced. KDE publically runs on a platform of respecting
> user privacy (it's part of the vision). On-by-default metrics run
> the risk of someone calling bullshit on that, plus it's giving up
> on a privacy-related differentiator if, unlike others, we're off-
> by-default.
I would vote for "off-by-default", too.

At the moment, we can not even judge how much data we receive with that
policy, we can still re discuss that if we really see we get not enough
feedback to have usable data.

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234

Re: KDE GPG Keyserver

[Dr.-Ing. Christoph Cullmann]

Hi,

> On Mon, Jul 24, 2017 at 5:11 PM, Sandro Knauß <skna...@kde.org> wrote:
>> Hey,
>>
>>> I recommend using the keyserver (pool) that's recommended by the official
>>> GnuPG FAQ [1] or, even better, sticking to the default, unless you have a
>>> specific reason for not using those. If you are concerned about your
>>> privacy then you should rather look into using a keyserver on the Tor
>>> network.
>>
>>  A specialied keyserver makes sense, if we want to improve the situation with
>> GPG Keys. We already use the Kes to sign releases, so we may want to check if
>> these keys are available and why not use our own pool?
>> * we can improve more rules for keys like >1024 bits no DSA, no unlimited
>> keys,...)
>> (Debian also has his own keyring, where they have far more rules than a 
>> simple
>> sks-keyserver)
>> * This makes sense in terms of get a more unified way to test on our systems
>> that a key is "known"... We had already this discussion of where to get a key
>> for a signature on the devel list...
> 
> FWIW, the reason for not having a server is what Christoph said about
> maintaining stuff we don't technically need. Hosting our own server
> adds no tangible value over deferring to the pool. Which goes doubly
> so because the way debian's keyring is used is as a moderated frontend
> server (IIRC), rather than a public access pool server everyone can
> push keys into... apples and oranges.
> Whether or not we should have a thing like debian is a discussion we
> could have I suppose, though personally, I don't see the paperwork and
> knowledge overhead such a setup would entail going well with our
> community.
Yes, and given we want to lower the maintainance effort in other parts of the 
server
setup we have, I don't really see why we open here yet another can of worms.

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234

Re: KDE GPG Keyserver

[Dr.-Ing. Christoph Cullmann]

Hi,

should we really start with adding such stuff to 'our' infrastructure we need 
to maintain given
there are enough other keyservers out there?

Greetings
Christoph

- Am 24. Jul 2017 um 15:04 schrieb Boudhayan Gupta bgu...@kde.org:

> Ingo: I just set up gossip with the SKS pool but it hasn't synced anything
> yet.
> Luca: No. I can set up hkp over 80 if it's really needed, but I'd rather
> not (if we want to use that server to run something else over port 80).
> 
> 
> Freundliche Grüße
> Boudhayan Gupta
> KDE e.V. - Community Working Group
> +49 151 71032970
> 
> On 24 July 2017 at 14:47, Luca Beltrame <lbeltr...@kde.org> wrote:
> 
>> Il giorno Mon, 24 Jul 2017 12:51:42 +0200
>> Boudhayan Gupta <bgu...@kde.org> ha scritto:
>>
>> > You can of course add a new line to ~/.gnupg/dirmngr.conf to add this
>> > keyserver to your list of keyservers.
>>
>> Is this reachable also on port 80? My workplace blocks hkp ports.
>>
>> --
>> Luca Beltrame - KDE Forums team
>> KDE Science supporter
>> GPG key ID: 6E1A4E79
>>
>>

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234

Re: [kde-community] Randa Meetings fundraising - please spread

[Christoph Cullmann]

In addition, one could link on that page all blogs we already wrote which
we nicely collected on:

https://community.kde.org/Sprints/Randa/2016#Blogs

- Am 6. Jul 2016 um 9:31 schrieb Gaël Beaudoin ga...@gaboo.org:

> Hi all,
> I think social networks buttons to easily share the fundraiser are missing.
> Have a nice day,
> Gaël
> 
> Le mer. 6 juil. 2016 à 09:27, Thomas Pfeiffer < thomas.pfeif...@kde.org > a
> écrit :
> 
> 
> Hi Sandro,
> 
> going to the fundraiser website, I noticed that it is out of date:
> 
> It still talks about Randa 2016 being in the future. Shouldn't it be updated,
> 
> and instead of talking about what we _will_ do there, talk about what _has 
> been
> done_
> 
> there, and than changing the message to "If you want us to be able to continue
> doing
> 
> such great things, please donate to fund future meetings."
> 
> It's not much of a surprise to me that a campaign focused on funding a 
> specific
> 
> meeting loses drive after that specific meeting is over. The meeting happened,
> so
> 
> obviously we had enough money to do it, now why donate more for it?
> 
> If we want the fundraiser to still be engaging, we have to change the message.
> 
> Cheers,
> 
> Thomas
> 
> 
> On 04.07.2016 16:42, Sandro Andrade wrote:
>> Hi there,
>> 
>> We've reached the last week for Randa Meetings 2016 fundraising [1]
>> and we're completely behind the goal :( That's mostly because our
>> audience depletes rapidly after some weeks and we lack some
>> promotional device (and man-power/energy) to keep pushing it forward.
>> 
>> Now we need to boost its last breath, for example by:
>> 
>> - Writing a nice blog post, everyone is welcome to do that and even
>> more for those of you who holds a quite popular blog. That's proven to
>> be quite effective lately.
>> - Promoting the campaign in regions other than Europe by translating
>> and spreading.
>> - If you were in Randa, telling what you achieved and call for donations.
>> - Doing anything else you feel could help ..
>> 
>> [1] https://www.kde.org/fundraisers/randameetings2016/
>> 
>> Cheers,
>> --
>> Sandro
>> ___
>> kde-community mailing list
>> kde-community@kde.org
>> https://mail.kde.org/mailman/listinfo/kde-community
> 
> ___
> kde-community mailing list
> kde-community@kde.org
> https://mail.kde.org/mailman/listinfo/kde-community
> 
> ___
> kde-community mailing list
> kde-community@kde.org
> https://mail.kde.org/mailman/listinfo/kde-community

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] KDE dinner in Berlin - October 3

[Christoph Cullmann]

Hi,

> Hi,
> 
> I'm game, I'm arriving for QtWS on Saturday around noon, so I guess
> have enough time to rest before the dinner.
> 
> One of my favourite places in Berlin is
> http://www.tiergartenquelle.de/, a few meters from the S-bahn station
> Tiergarten. They are usually full on Saturdays, so we would need to
> make a reservation.
will be in Berlin from the 1th, so you can count me in, too.

Just point me to the place to go ;=)

Greetings
Christoph

-- 
----- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Participate with KDE at Qt World Summit 2015

[Christoph Cullmann]

Hi,

if still help is needed, I can join, as I need to stay in Berlin for work start 
on October and
can get some free days. ;=)

Greetings
Christoph

- Am 19. Aug 2015 um 10:38 schrieb Eike Hein h...@kde.org:

> On 09.08.2015 12:48, Sune Vuorela wrote:
>> So. For those who wants to join in, please contact me and I will see to get
>> the tickets allocated.
> 
> Sign me up -- happy to help man the booth and other
> things.
> 
> 
>> /Sune
> 
> Cheers,
> Eike
> ___
> kde-community mailing list
> kde-community@kde.org
> https://mail.kde.org/mailman/listinfo/kde-community

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Give People Access to Great Technology - a possible vision

[Christoph Cullmann]

 On Friday 19 September 2014 19:04:53 Valorie Zimmerman wrote:
  On Fri, Sep 19, 2014 at 9:56 AM, Andrew Lake jamboar...@gmail.com wrote:
   
   Image: http://wstaw.org/m/2014/09/19/A_possible_vision.png
  
  I would say Plasma and Frameworks at the center.
 
 I think it's right to put the KDE desktop in the center in addition to the
 KDE
 frameworks. It's Plasma and the application which are our base and where we
 are coming from. It's this whole set which gives us the integration points we
 can use to expand to cloud, to devices, to other services. The desktop is a
 great starting point.
+1 ;)

Looks quiet nice.

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Sad news (fwd)

[Christoph Cullmann]

 Thats terrible news.
 
 As a community would it be appropriate to write up a short retrospective of
 Mojtaba? Perhaps combined with a photo, some information about him, his work
 and his life and post it on one of the larger KDE blogs?
 
 I don't know how Iranian burial customs work and we should check in with his
 family and friends (Mehrdad perhaps if you could help out) but with their
 allowance it seems as a nice gesture to do towards someone who has been a
 part
 of our community as well as worked on things that benefit us all (beyond our
 own community).
 
 What do everyone else think?
+1, if his family would be ok with that.

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Proposal One: KDE (Core) Apps and Suites

[Christoph Cullmann]

 There are a few reaons to sync releases:
  * Most of the devels of KDE Applications apps don't want to do the
  releases
 themselves after 15 years of a release team doing it for them
  * Having synched release schedules for KDE Applications like we have done
 for 15 years allows me to know easily if an application is on freeze or not,
 if suddenly as a developer I have to keep track of 160 different release
 schedules, count me out of doing fixes in those apps.
  * We have lots of applications with no real maintainer but I can still go
 there, fix something that is i18n related and know it will be release next
 month with the next KDE Applications release, with your plan of everyone
 releases its own stuff my fix would never reach the user.
+1 :)

I can only say, with my Kate maintainer hat on: I have enough time, to fix the 
biggest faults,
shout on people breaking the compile  tests, do some reviews and port Kate 
from KDE x to y.

I don't have the time to think up release dates and package releases.

I appreciate the work the KDE release team does in that area since ever!

And I really think per application releases are just overkill for most 
applications.

At the moment, I am happy to know: If somebody has KDE SC x.y installed, he has 
the state of Kate
from that time.

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community