Re: Proposal unify back our release schedules

[Nate Graham]

Hello folks,

At this point I think a face-to-face setting might help produce some 
closure here, so I've scheduled a BoF at Akademy for us to discuss 
release schedules; see https://community.kde.org/Akademy/2024/Monday#Room_2


If you're attending Akademy and interested in the topic, please join! 
There should be remote participation options as well.



Nate

Re: Welcome Farid!

[Nate Graham]

Welcome aboard, Farid!

Nate


On 8/5/24 12:05 PM, Lydia Pintscher wrote:

Hi everyone,

It is my great pleasure today to announce that Farid Abdelnour is the
new KDE Goals Coordinator. Farid joins KDE e.V. from Brasil. From
today on he will be making sure everything around the KDE Goals runs
smoothly and supports the Goal Champions in all organisational things
as well as talking about the KDE Goals to the wider KDE Community and
the public.
Some of you might already know Farid from his great work in Kdenlive
and I am looking forward to him bringing his expertise and enthusiasm
to the KDE Goals.

Please join me in welcoming Farid to this new position.


Cheers
Lydia

Re: Inquiry about Contributing to KDE Github Repositories

[Nate Graham]

Hello Harsh,

I'd recommend reading through our "get involved" page at 
https://community.kde.org/Get_Involved which should help to answer your 
questions.


Nate


On 7/20/24 11:08 PM, Harsh Giri wrote:
I hope this email finds you well. I am writing to express my keen 
interest in contributing to your projects and repositories. As an 
aspiring developer eager to learn and grow, I would greatly appreciate 
your guidance on the following:


  1. Could you*recommend some resources* to help me learn the 
technologies used in your projects? This would assist me in gaining the 
necessary experience to contribute effectively.


  2. As a beginner, I am looking for opportunities to start small and 
gradually increase my involvement. Are there any *"good first issues" or 
entry-level tasks* you could suggest?



  3. I am committed to becoming a valuable contributor to your 
organization. Could you advise on the best ways to demonstrate my skills 
and dedication? Thank you for your time and consideration.


I look forward to the opportunity to contribute to your projects and 
learn from your experienced team.


  Best regards,
Harsh Giri

Re: Proposal unify back our release schedules

[Nate Graham]

On 4/22/24 19:19, Albert Astals Cid wrote:

El dilluns, 22 d’abril del 2024, a les 17:12:46 (CEST), Nate Graham va
escriure:

Now, let's say we make Gear use Plasma's current release schedule by
syncing up the feature releases and adopting the Fibonacci bugfix
releases. If we don't end up changing Plasma's own release schedule then
we already make our promo store more coherent by letting the marketing
team do three big glossy announcements of user-facing products a year,
rather than being stretched thin for 6. Even if we make Plasma go down
to 2 releases a year, then we have two synced Gear+Plasma
"mega-releases" and 2 independent Gear releases--down from 6 to 4. Both
of these options would improve the promo story IMO.

---

Moving on, the biggest points of contention I see revolve around
Frameworks. Personally I want to push back a bit on the idea of
developing an app against released frameworks.


I disagree.

In my ideal world, applications should be able to be built against a one year
old frameworks, before the Qt6 port, Okular's minimum requirement was Ubuntu
22.04, which makes sure virtually everyone can contribute to it without having
to build the world.

There's virtually no need in Okular to depend against any new frameworks shiny
feature, the existing features are more than enough.

Cheers,
   Albert


This is true for Okular, but we can't guarantee it for other apps.

However I was fortunate enough to be sitting across a table from Volker, 
who explained this point to me in a way that my tiny brain was capable 
of understanding: :) that having a fast Frameworks release cycle allows 
people developing apps with features in Frameworks to not have to live 
on master like we do in Plasma.


I'd love to have everywhere in my slide of KDE what Albert has for 
Okular, but I there are other barriers to it that we need to overcome.


As a result I'll rescind my idea to slow down Frameworks feature 
releases. I do still think Frameworks could benefit from un-branched 
bugfix releases a week after the feature releases--after which point 
feature development would be open again.


And I still support unifying or aligning the Gear and Plasma release 
schedules.


Nate

Re: Proposal unify back our release schedules

[Nate Graham]

Ok, so happily I actually see quite a bit of agreement here, regardless 
of what else we do.


1. Fibonacci bugfix releases are good, and we could benefit from having 
Gear adopt these.


2. Severing implicit dependencies is a good idea. Shared libraries in 
Gear are especially problematic and could benefit from being moved to 
Frameworks.


3. Fast frameworks releases in some capacity are a benefit and we don't 
want to lose this.



All in agreement? If so, that would be amazing.

---

Now, let's say we make Gear use Plasma's current release schedule by 
syncing up the feature releases and adopting the Fibonacci bugfix 
releases. If we don't end up changing Plasma's own release schedule then 
we already make our promo store more coherent by letting the marketing 
team do three big glossy announcements of user-facing products a year, 
rather than being stretched thin for 6. Even if we make Plasma go down 
to 2 releases a year, then we have two synced Gear+Plasma 
"mega-releases" and 2 independent Gear releases--down from 6 to 4. Both 
of these options would improve the promo story IMO.


---

Moving on, the biggest points of contention I see revolve around 
Frameworks. Personally I want to push back a bit on the idea of 
developing an app against released frameworks. This is only realistic if 
you use a rolling release distro and are okay with waiting a month to 
use the new Frameworks code. For users looking to contribute with common 
discrete-release distros, it is not at all realistic as many Frameworks 
consumers require versions newer than what those users have on their 
system, so they have to build some Frameworks anyway (note: not all of 
them; kdesrc-build/kde-builder are smart enough not to do unnecessary 
work). The older the distro's packages, the more likely this is to be.


Furthermore, because Frameworks has time-based releases and no beta 
releases, in practice the QA is provided by developers living on master. 
If KDE developers deliberately avoid this, they're not participating in 
QA. There are of course other ways to improve Frameworks' QA as well, 
but continuing to encourage KDE developers to use distro-packaged 
Frameworks goes against the larger goal: we can't QA software versions 
we're not using.


While 12 releases a year of Frameworks feels fast, it's actually not. 
Gear also has 12 releases a year: 3 feature releases and 9 bugfix 
releases. And Plasma currently gets 18: 3 feature releases and 15 bugfix 
releases. The lack of bugfix releases is notable. With Plasma if a major 
bug is discovered a day after the release (which is common) I can ship a 
fix within a week, whereas for Frameworks, it takes a month. This is not 
a theoretical problem; it has happened many times over the years.


To me it has always felt strange that the product that benefits most 
from stability gets 4 times as many yearly feature releases as Gear and 
Plasma, but no bugfix releases at all. And there have been many 
occasions oven the years where new features in Frameworks could have 
benefited from a bit more QA time in master before final release.


In this sense I find Frameworks' release schedule to be both too fast 
and too slow: too fast for new features and too slow for bugfixes. 
Shouldn't the product with the strongest stability guarantee ship 
bugfixes at least as fast as Plasma?


If Frameworks got a feature release every 2 or 3 months and a guaranteed 
bugfix release one week after each feature release, IMO the result would 
be much better. We could ship fixes for important bugs faster, 
developers would be more incentivized to live on master and therefore 
provide their own QA, the period of time during which issues with new 
features could be caught before release would be doubled or tripled, and 
we could even still have 12 total releases per year.


---

Thus, if we make Gear's release cycle identical to Plasma's to get it 
faster bugfixes, and then we also lengthen Frameworks' release cycle so 
it gets the bugfix releases it could benefit from while slowing down its 
feature releases to improve QA, then the result looks a lot like Carl's 
proposal, and that's ultimately why it looks appealing to me.


This doesn't preclude breaking implicit dependencies and relocating 
software into groups/release vehicles more suited for them. I don't find 
the argument convincing that we ought to deal with pain to make this 
happen. IMO we should make decisions about the final form we want, not 
based on what we think will torture us into getting there. :)


Nate

Re: Proposal unify back our release schedules

[Nate Graham]

Thanks for taking the time to assemble this email, Carl. These are 
arguments I've brought up individually myself for years, and I think 
they have merit.


Taken together, for me they paint a picture of a project that was 
attempted, faithfully executed on, but didn't end up delivering the 
benefits we hoped for while introducing some new drawbacks that have no 
easy path to being resolved. I'm in favor.


I expect a vast amount of discussion to result from this proposal, and I 
think that's great. It'll be good to talk about it. But I suspect in the 
end we'll likely not achieve 100% consensus, and in that event I'd like 
for us to put it to a formal KDE e.V. vote so that the topic doesn't 
become stale and die after everyone's exhausted from a long discussion.


Nate




On 4/19/24 11:04, Carl Schwan wrote:

Hello Community,

I know this might be a controversial idea, but I would like to propose reunify
our release schedules. I feel like splitting our releases schedules between
Frameworks, Plasma and Gear is not working as well as we intended it to be when
we split the releases schedules for Plasma 5. This is for multiple reasons:

* We end up with 3 different products which are released at different times but
   are connected together. Apps and Plasma both need Framework, Plasma needs 
some
   packages from gear like kio-extra, Gear needs some package from Plasma like
   Breeze. Coordinating all these inter-groups dependencies is complex and was 
one
   the reason we had to do a megarelease for Plasma 6. Also for the end user, 
one
   product is a lot easier to understand.

* This results in very frequent releases which creates a lot of work for distros
   and talking with some distro maintainers they seems to agree that having a 
big
   releases every 4 months is better than having constantly a new minor or major
   release from either Framework, Gear or Plasma.

* We currently don't have a stable branch for Framework and it takes often up to
   one month for fixes to be deployed. The Framework releases is also not in 
sync
   with either Gear nor Plasma while these two modules heavily make use of 
Framework
   and contribute to Framework.

* We could have an unified LTS release including more than just Plasma. This is
   something that distros have been asking for some time already because having
   just Plasma receiving bug-fixes but not Framework nor the apps is not that 
helpful.

* In term of promotion, it is very difficult to advertise the 3 releases because
   combined we have an important release of either Gear, Plasma or Framework 
every
   few weeks. This is too frequent and often while a combined announcement would
   have enough content to be published in a tech newspaper. When splitting the 
content
   accross 2 announcements (Gear and Plasma), we reduce the content per
   announcement and this makes it less interesting for the journalists to write
   about us. This doesn't come from me, this is that some journalists directly
   told me.

* We won't have 3 different release teams but instead have a bigger one with a
   bigger bus factor. We could also unify the tooling for doing this mass 
releases
   a bit.

I do understand that there was valid reasons for splitting KDE Software 
Collection
for Plasma 5 but I don't think this worked out. These were as far as I know the
main arguments used for splitting the Software Collection.

* Trying to move away from "KDE" being recognized as the software instead of the
   community. This unfortunately didn't really work out, everyone is still using
   KDE to refer to the desktop. Even distros call their edition "KDE" and I 
don't blame
   them, it's difficult to find a better term than that as for example "Fedora KDE 
Spin"
   not only contains Plasma but also a lot of KDE apps. Splitting the releases 
won't
   help with that, we need to find a better approach or just let it go and 
accept that
   people will keep using KDE to describe the desktop/software.

* Better promotion of our apps outside of Plasma. This is a valid point but I 
think
   pursuing our current strategy of putting our apps in many app store to be 
more
   effective. We could also show the platforms support of each applications more
   prominently in our releases announcements like we already do on apps.kde.org
   (e.g. https://apps.kde.org/okular/). Generally Plasma releases fare a lot 
better
   in term of promotion than the gear announcements and showing the applications
   on an unified announcement would likely help spread the words about our 
applications
   better.

* Helps with outside usage of our frameworks. These didn't get as much success
   as we were hoping when splitting. I think having a stable branch for 
Framework
   might help but this is only a guess. It would be interesting to know of cases
   where people considered using some Framework and to know why they decided
   against or for it and if this proposal would helps or not.

In effect this proposal would m

Re: Let's welcome Nicole, the project lead and event manager in a new KDE Eco project

[Nate Graham]

Welcome to KDE, Nicole!

--
Nate Graham
KDE e.V. Board of Directors


On 4/3/24 07:43, Joseph P. De Veaugh-Geiss wrote:

Hi everyone, let's welcome Nicole Teale to KDE!

Nicole is the Project Lead and Event Manager for the newly-funded 
"Sustainable Software For Sustainable Hardware" project in the KDE Eco 
initiative.


She will support us by making sure the project stays on track, by taking 
care of bureaucratics with the German government, and by helping 
organize outreach events and workshops.


In her spare time Nicole likes all manner of crafts and craftiness, 
listening to music, and spending time with her family.


Please give Nicole a warm welcome to our excellent community!

Cheers,
Joseph

Re: Join the Goals sprint in Berlin!

[Nate Graham]

On 3/30/24 11:03, Albert Astals Cid wrote:

El dissabte, 30 de març de 2024, a les 16:01:57 (CET), Adam Szopa va escriure:

Hi everyone,

In a couple of weeks (20-24th of April, arrivals on the 19th) there is a
Goals sprint happening in Berlin.


A couple of weeks is not enough time for most people to be able to attend an
event that is in possibly another country and on top of that happens during
the work-days.

I know organizing events is hard, but please next time let's try to organize
things with more time :)


For what it's worth, this was first announced in January: 
https://mail.kde.org/pipermail/kde-devel/2024-January/002390.html


I agree that it's a bit late for the venue though. :/

Nate

Post-MegaRelease projects

[Nate Graham]

Hello everyone,

Congrats to the entire KDE community on the impending launch of the KDE 
6 MegaRelease! I'm so impressed with how folks came together to make it 
amazing. It's a very impressive release and I think people are gonna 
love it.


I've started pondering post-megarelease projects. We've spent so long on 
porting and bugfixing that I think it might be useful to shift gears to 
feature work, and I'd like to brainstorm potential large-scale projects 
and gauge the level of interest in putting resources into them soon.


Here are some ideas of mine to get the creative juices started:

* David's input method playground stuff [1] is amazing and needs to be 
developed and productized
* GNOME's Libadwaita app platform has been a runaway success for them; 
evaluate our offerings in comparison and see what we can do better

* Unified theming infrastructure for KDE apps, GTK apps, and Plasma.
** Relatedly: QML/JS in themes is dangerous; move away from it
* Start adding release notes to our apps' AppStream metadata [2]
* Finish up and ship the new Breeze icons
* HIG is outdated and mostly ignored, and needs an overhaul to make it 
useful

* Telemetry system has not proved to be very useful and needs an overhaul
* store.kde.org is full of low-quality or broken content; make a push 
for KDE people to take ownership of content moderation, QA, etc. Also 
any relevant and needed tech improvements

* Our virtual keyboard situation is not great and needs focused work
* KWallet needs an overhaul
* Have KWin (optionally) remember window positions on Wayland
* Build a "System misconfiguration detection hub" app [3]

Feel free to discuss, and propose your own!

Nate



[1] 
https://blog.davidedmundson.co.uk/blog/new-ideas-using-wayland-input-methods/

[2] https://github.com/ximion/appstream/issues/354
[3] https://invent.kde.org/plasma/plasma-workspace/-/issues/64

Re: KDE Contributor Niccolo Ve @niccolove Violates KDE’s Code of Conduct

[Nate Graham]

In this case I'm not sure it's even a CWG issue as the alleged offenses 
happened outside of KDE and the allegedly aggrieved party is not a 
member of the KDE community.


To me this looks like a sockpuppet trying to intimidate Niccolò into 
keeping silent about a public figure, and the accusations to me look 
somewhere between very flimsy and outright laughable, to say nothing of 
the hypocrisy of calling for someone to be kicked out of their community 
for having allegedly called for someone else to be kicked out of some 
other community. I think we can file this in the "nothing to see here, 
folks" bin.


Nate



On 2/14/24 11:44, Johnny Jazeix wrote:

Hi,

the Community Working Group (https://community.kde.org/CWG 
) handles these kind of topics, you 
should discuss the subject with them.


Cheers,

Johnny

Le mer. 14 févr. 2024 à 19:12, En Senada > a écrit :


Niccolo Ve (Nicco Loves Linux, @niccolove
 on the KDE Discuss board) has
been busy posting hateful and divisive content to Youtube that
violates KDE Code of Conduct.

First, he has an antisemitic attack on Bryan Lunduke who is Jewish:

https://www.youtube.com/watch?v=mhqeuO9RKKk&t=874s


He also incites harassment of Switched to Linux for views that he
doesn’t agree with:

https://odysee.com/@niccolove:1/nicco-loves-linux-trafotin-discuss-linux:0 


Whether you agree with either side, it is bad for KDE. This is
divisive, not considerate, respectful, collaborative, pragmatic and
supporting others in the community as stated in the CoC. I can’t
believe KDE would suport harassment and deplatforming, regardless of
either side. He should be expelled from KDE for violating the Code
of Conduct.

Re: Albert being rude in Okular merge requests

[Nate Graham]

Hello everyone,

It appears I sent this email intended for the Community Working Group to 
the public community email list instead. Autocomplete failed me and I 
failed to detect the error before hitting Send. My apologies in advance 
for the drama this is unfortunately likely to create. I would appreciate 
if everyone could pretend they never saw this email, or at least, avoid 
starting email threads discussing it. :)


Sorry everyone, and sorry especially to Albert, who definitely does not 
deserve for dirty laundry to be aired in public like this. It was my 
mistake and I take full responsibility. I'll buy to a beer at the next 
Akademy. Or a cake, your choice. :)


Nate



On 12/19/23 08:32, Nate Graham wrote:

Hello CWG,

Albert Astals Cid has been acting rudely in Okular merge requests 
recently and insulting the work of longtime contributors who deserve 
respect. For example:


- https://invent.kde.org/graphics/okular/-/merge_requests/862
- https://invent.kde.org/graphics/okular/-/merge_requests/869

In the latter one, Albert has succeeded in causing Ingo Klöcker 
sufficient stress that he's ceased the work, which disrupts activities 
directed and funded by KDE e.V. (Ingo is a paid KDE e.V. contractor who 
we are sponsoring to do this).


This kind of behavior is unacceptable and it needs to come to an 
end--not just this time, not just now, but going forward. For years 
Albert has gotten away with this kind of casual abrasiveness, and it's 
not acceptable. We can't let this be a "the situation resolved itself" 
kind of thing.


Nate

Albert being rude in Okular merge requests

[Nate Graham]

Hello CWG,

Albert Astals Cid has been acting rudely in Okular merge requests 
recently and insulting the work of longtime contributors who deserve 
respect. For example:


- https://invent.kde.org/graphics/okular/-/merge_requests/862
- https://invent.kde.org/graphics/okular/-/merge_requests/869

In the latter one, Albert has succeeded in causing Ingo Klöcker 
sufficient stress that he's ceased the work, which disrupts activities 
directed and funded by KDE e.V. (Ingo is a paid KDE e.V. contractor who 
we are sponsoring to do this).


This kind of behavior is unacceptable and it needs to come to an 
end--not just this time, not just now, but going forward. For years 
Albert has gotten away with this kind of casual abrasiveness, and it's 
not acceptable. We can't let this be a "the situation resolved itself" 
kind of thing.


Nate

Re: Plasma 6 new logo poll

[Nate Graham]

Hi Ilya,

This is mostly my fault as the poll did indeed have a "keep the current 
logo" option in the beginning, but I recommended removing it after 
seeing the poll live on discuss.kde.org. The reason for that 
recommendation was because the results of the poll are themselves a set 
of options for the Plasma devs to consider, and they (we) always have 
the option of not taking any of them. So from that perspective a "keep 
the current logo" option would be redundant and have the potential to 
reduce the number of options available for the Plasma devs to consider.


However I also see how the lack of a "keep the current logo" option 
makes people who don't want any chance and who aren't or don't see 
themselves as Plasma devs feel silenced. That was definitely not the 
intention, even though I can see how the result was perceived that way 
anyway.


And to reiterate, there was never intended to be any pressure on Plasma 
devs to choose a new logo. As I understand it, the ideal behind the poll 
was to pick the three most popular options and weigh them against the 
current logo.


Nate



On 12/6/23 00:34, Ilya Bizyaev wrote:

Hello Paul,

Could you explain why there is no option for the current Plasma logo? I 
would like to vote for keeping the existing logo, as I prefer it to the 
options listed in the poll. Shouldn't Plasma developers be able to see 
how the votes for the new logos compare to the current one, to make an 
informed decision?


Not voting at all is not a solution because it is ambiguous: it could be 
interpreted as not caring or supporting whichever new logo that poll 
ends up "electing". "Non-bindingness" is also not an answer, because the 
developers will feel pressured by the community to comply with the poll 
results, even though they will be incomplete.


Best regards,
Ilya


On 5 December 2023 21:17:53 CET, Paul Brown  wrote:

Dear Community Members,

We have trimmed down all the proposals from KDE aficionados for the
new Plasma
logo taken from here:

https://discuss.kde.org/t/how-about-a-new-logo-for-plasma-6/6206


to 6 (you know: as in Plasma _6_) and made a poll to determine the
all time
favourite.

If you would like to vote on the poll, please go here:

https://discuss.kde.org/t/plasma-6-logo-final-selection-and-poll/8001 


The three most voted options will be passed on to the Plasma
developers for
their consideration. Please note that this poll is **NON-BINDING** and
changing the logo will depend on the willingness of the Plasma devs.
They will
have the final say.

Either way, the change, if it happens, is unlikely to occur in time
for Plasma
6.0, as the project is currently in Feature Freeze. This means that
only
corrections, bug squashing, and minor tweaking is going on. Nothing
new may be
added at this stage. So if the devs do decide to change the logo,
this won’t
happen until at least Plasma 6.1.

This poll will finish and be closed in one week.

May the best design win!

Cheers

Paul

Re: planet forwarding to discuss?

[Nate Graham]

On 6/21/23 23:23, Phu Hung Nguyen wrote:

On 6/21/23 20:11, "Friedrich W. H. Kossebau"  wrote:
Please try to have the open mind to solve this e.g. by a flag to the 
planet

blog registration metadata, if people would like to participate in that
undertaking and have automatically also a discussion thread on a post.
Or an opt-out if you think everyone by default should think this is an 
awesome

thing to have.


I have code to do this for Planet ready on my laptop now. A separate 
feed will be created at planet.kde.org/discuss/index.xml containing only 
posts whose authors want them to be on Discuss (based on the config on 
Planet; we can deal with either opt-in or opt-out mode fine). Discuss 
then can be configured to use 
https://github.com/discourse/discourse-rss-polling (as suggested by 
@sitter) to read that feed.


Regards,
Phu



Thanks for making this possible to try out, Phu. I don't have a strong 
opinion regarding opt-in or opt out, but if we go forward with it, 
regardless of what we choose I would like my blog to participate--and 
then I will disable the built-in Wordpress comments, which are fairly 
limited in functionality and moderation tools.


Nate

Re: planet forwarding to discuss?

[Nate Graham]

On 6/21/23 17:53, Friedrich W. H. Kossebau wrote:> Well...

* blog posts had not been covered on forums.kde.org(?), so nothing to compare
* discuss.kde.org is intended to replace kreddit? so expectations transferred?
* "it's not a big ask to expect KDE devs to visit Discuss at times"
   in the very email that triggered my initial reply :)


It seems like the people who have expressed negativity or apprehension 
about the idea so far admit they don't use discuss.kde.org. And that's 
fine. But my recommendation for those folks (yourself included) would be 
to just continue ignoring it, because that's 100% okay and probably 
nobody is actually expecting you or anyone else to participate there.


I say let's try to have an open mind here. If we do it and it doesn't 
have the results we want, we can undo it in five minutes.



Nate

Re: planet forwarding to discuss?

[Nate Graham]

On 6/21/23 16:57, Friedrich W. H. Kossebau wrote:

Am Mittwoch, 21. Juni 2023, 16:20:21 CEST schrieb Nate Graham:

Regarding the topic of having comments split across multiple places, I'm
afraid that ship has sailed. I have comments on my blog, and the
discussion nevertheless gets split across Reddit, Mastodon, Phoronix,
and Discuss already.


Isn't it a difference if a discussion happens at some external place or if it
happens in some KDE place? People might rather expect the original post author
around in a KDE one, no?


The concern sounds quite theoretical and I'm not sure it's actually a 
problem in practice. Have you had this experience in the past?


Speaking from personal experience as someone whose blog posts are 
syndicated quite widely, I've never once run into the expectation that I 
would be available for comment on the old forum.kde.org, or the new 
discuss.kde.org. On the contrary, the only place I've experienced this 
expectation has been on Reddit, which we don't have control over.


Nate

Re: planet forwarding to discuss?

[Nate Graham]

Regarding the topic of having comments split across multiple places, I'm 
afraid that ship has sailed. I have comments on my blog, and the 
discussion nevertheless gets split across Reddit, Mastodon, Phoronix, 
and Discuss already. I don't have time to follow all of those, and I 
accept that. But there is nothing I can do about it.


It's much the same with the proposal here: people will discuss things 
where they want to discuss them regardless of what we do. The difference 
is that if we make it easy to discuss things on discuss.kde.org, there's 
a higher likelihood of the discussion becoming centralized there, and 
not on places we don't control and generally don't want to interact 
with. like Phoronix and Twitter.


Nate

Re: Telegram <-> Matrix bridges will be removed in September

[Nate Graham]

Hello folks,

If the discussion has not yet started, then it seems a bit premature to 
be making any decisions now based on potential future outcomes of said 
discussion.


If we do eventually agree to wind down the bridging services, the point 
about needing a long runway to communicate this to users and help them 
migrate seems valid. Can we agree to avoid making decisions about the 
bridges today that only make sense if the outcome of that discussion is 
"yes let's wind down the bridges"?



Nate

Re: Retiring Phabricator - Migrating tasks to Gitlab

[Nate Graham]

On 5/23/23 03:48, Ben Cooksley wrote:> Also, in Phabricator, Tasks 
have no real "home"; they just have project

tags, and they can have multiple such tags to be able to belong to
multiple projects. For example "VDG" and also "Plasma". Such a Task
shows up in both projects' workboards. But in GitLab, Issues need to
live in one place and only one place. So for such Phab tasks, we would
need a way to determine the single new home of the Task in GitLab, and
perhaps tag them with global-scope labels or something?


Yes, we would need to do a deconflicting process there.
Any thoughts on the best approach to that?


At least in the case where a Task is tagged with VDG and also something 
else, it probably makes sense to have it live on GitLab in the 
"something else" project/group/etc. Back in the Phab days, we used to 
tag everything VDG-relevant with the VDG tag, but on Gitlab it probably 
makes more sense to just CC the "@teams/vdg" group instead.


Nate

Re: (low-frequency) mailing lists | suggestions & summary of prior thread

[Nate Graham]

I get emails when people reply to my messages directly. And if you want 
replies to threads you've posted in, you can subscribe to the thread 
manually.


All of these behaviors are also user-configurable, of course--just like 
any sane forum.


Nate



On 5/24/23 16:18, Albert Astals Cid wrote:

El dimecres, 24 de maig de 2023, a les 9:35:38 (CEST), Joseph P. De Veaugh-
Geiss va escriure:

On 5/24/23 00:03, Albert Astals Cid wrote:

El dimarts, 23 de maig de 2023, a les 14:10:37 (CEST), Joseph P. De
Veaugh-


Beyond typical forum functionality, Discourse integrates well with email
and RSS. Something to consider for low-frequency mailing list groups:
there may be projects and communities that benefit by officially moving
communication to Discourse. Although I have no data to back up the
claim, I suspect having users interact on a more active platform could
generally increase engagement within KDE.

A nice feature of Discourse is: for mailing list subscribers who wish to
continue receiving posts in their mail clients,


Is it really? I remember once that i visited, commented on a post and
never
ever got emails when people answered me on that post. I am not a crazy
person that plans visiting discuss.kde.org every 5 minutes just in case
someone has answered me, the site must send me an email and in my 1 time
experience it failed to do so.


Is this with "mailing list mode" enabled?


No, because it from your description it doesn't seem what i want at all.

   I do not want to get emails for all the posts sent to all the places in the
site.
   I do not want to answer to things via email

I just want a sensible notification policy in which when someone answers to
something i posted I get a notification by email.



I think what you are describing is related to general email settings for
notifications. This can be found under Profile > Preferences > Emails.
This looks like the relevant place: "Email me when I am quoted, replied
to, my @username is mentioned, or when there is new activity in my
watched categories, tags or topics." Perhaps check your settings there?

Note there may also be relevant settings under Profile > Preferences >
Tracking for "tracking" and "watching", word choices which do not make
the distinction clear, in my opinion. Right now I am not well-informed
about the options here.


It is broken, it seems watching is more intense than tracking (which my non
English brain disagrees with) and watching is what i want. It also seems
broken in which you have to set it tracking and then to watching again for it
to actually work? (according to some random forum posts)

So what i want is apparently "When I post in a topic, set that topic to
Watching"

Let's see if i ever post to discuss.k.o again it works as promised.

Cheers,
   Albert



However, I am testing "mailing list mode" and I receive dozens of emails
a day for the categories I did not mute (see info below). I have not
tested the reply by email function yet, though.

Cheers,
Joseph


it is possible to follow
discussions via RSS or by enable mailing list mode in Discourse. It
takes some setting up; see below for more.

Info about using Discourse with email and RSS:
 * Users can enable "Mailing list mode", which allows one to receive

and respond to posts via email (i.e., just like a mailing list). By
default, users receive posts to /all/ categories -- limiting posts to
specific categories requires manually "muting" the other categories. See

the community wiki for more detail, including how to mute categories:
   https://community.kde.org/KDE.org/KDE_Forums#Mailing_List_Mode
 
 * Alternatively, one can follow specific categories, tags, etc. as an


RSS feed. Again, see the community wiki for details:
   https://community.kde.org/KDE.org/KDE_Forums#Following_RSS_Feeds

Re: Retiring Phabricator - Migrating tasks to Gitlab

[Nate Graham]

Great, this will be a good thing to have behind us.

Because workboards in GitLab are Label-driven via automation, I think we 
would have to make each workboard column in Phabricator transform into a 
custom label in GitLab so that Tasks' positions in workboards can be 
preserved when they move to GitLab.


Also, in Phabricator, Tasks have no real "home"; they just have project 
tags, and they can have multiple such tags to be able to belong to 
multiple projects. For example "VDG" and also "Plasma". Such a Task 
shows up in both projects' workboards. But in GitLab, Issues need to 
live in one place and only one place. So for such Phab tasks, we would 
need a way to determine the single new home of the Task in GitLab, and 
perhaps tag them with global-scope labels or something?


In Gitlab, it's Labels all the way down...

Nate


On 5/21/23 03:14, Ben Cooksley wrote:

Hi all,

As many of you will undoubtedly be aware, we currently have a bit of a 
hybrid approach with our use of GitLab, with some projects/areas still 
making use of Phabricator as they await the final import of these tasks 
across to GitLab.


That time has now arrived, as Phabricator is long since unmaintained and 
needs to be retired.


The only question is how this is best structured.

My thinking on this had been to establish a mapping of Phabricator 
project to Gitlab project (with some Gitlab projects possibly receiving 
multiple Phabricator projects). Where necessary we would create 
groups/projects under teams/ on invent.kde.org  
to house these, otherwise they'd be imported into the mainline projects.


For those projects currently using GitLab as a task tracking tool, any 
feedback you have on this would also be welcome.


In terms of the migration, we'd be looking to retain as much information 
as possible, however things like the precise column a task has on a 
workboard would likely be lost. The actual content of the task including 
details such as time and authorship, along with any comments would be 
retained though.


Thoughts?

Thanks,
Ben

Re: Where to get in touch with the Kirigami project?

[Nate Graham]

Hello Halla,
Mostly the Kirigami room on Matrix. See 
https://community.kde.org/Kirigami#Get_in_Touch.


Nate


On 4/3/23 08:39, Halla Rempt wrote:

Hi,

Maybe a stupid question, but what's currently the best place to discuss 
kirigami development? One of the Krita developers, Sharaf, has been trying to 
use Kirigami to create a new welcome screen for Krita, but he's run into 
trouble -- functionality disappeared, and there were some bugs, but we cannot 
seem to figure out where the active development discussions are happening...

Halla

Welcoming Natalie Clarius as KDE e.V.'s Hardware Integrator

[Nate Graham]

Hello KDE community!

I'd like to introduce Natalie Clarius (CCd) as KDE e.V.'s new Hardware 
Integrator! Natalie has been doing great volunteer work on KDE software 
for about a year, and now she'll be helping KDE e.V. to make sure that 
Plasma and KDE apps are in tip-top shape for our hardware vendor 
partners. Hardware products help to get our software into the hands of 
users more easily, so prioritizing development tasks on topics relevant 
to hardware/software integration is important.


This concludes the first round of KDE e.V.'s "Make a Living in KDE" 
initiative. And no, it's not an April Fools' day prank. :) Let's all 
give Natalie a warm welcome!



--
Nate Graham
KDE e.V. Board of Directors

Re: Update | BE4FOSS project coming to an end, KDE Eco continues to grow

[Nate Graham]

Thank you so much for your work to organize and push forward this 
initiative, Joseph! It's great to see how the ethos of energy efficiency 
has taken root in the community.


Nate



On 3/22/23 09:54, Joseph P. De Veaugh-Geiss wrote:

Dear KDE community,

I am sad to inform you that next week on 31 March funding for the KDE 
Eco "Blauer Engel 4 FOSS" (BE4FOSS) project will end. This means my role 
as Community and Project Manager for the project will also end.


This does not mean that the KDE Eco project is ending, not at all, but 
we may feel a shift in gears as the community transitions into the next 
phase. I will continue to be involved with the eco projects going 
forward, though at a reduced capacity as I take on a new role at KDE and 
thus new responsibilities (more info about this will be sent in the 
coming weeks).


KDE Eco continues to grow. Beyond "Blauer Engel 4 FOSS", there are many 
ongoing sustainability and efficiency projects at KDE, including the 
Sustainable Software goal, and more are coming. See the end of this 
email for some information and links.


These projects need your enthusiasm and energy (!) to stay alive and 
healthy. If you have thought to yourself, "I would like to contribute to 
the exciting work of the KDE Eco initiative", now is a great time to get 
involved. Please be in touch with me directly or the larger KDE Eco 
community via the mailing list and Matrix room:


   https://eco.kde.org/get-involved/

Or check out the Sustainable Software goal workboard:

   https://invent.kde.org/teams/eco/sustainable-software-goal/-/boards

Your involvement, no matter how big or small, is what makes success 
possible. And if you are already contributing to the KDE Eco initiative, 
thank you for your great work. I look forward to continuing what we have 
started!


We are in the process of applying for further external funding for KDE 
Eco projects, and I hope we can announce new funding in the very near 
future.


It has been truly a pleasure to work with the KDE community in the 
BE4FOSS project. I look forward to what comes next in making KDE and 
Free & Open Source Software the most sustainable and energy-efficient 
software.


In many ways, this pioneering work has only just begun!

Cheers,
Joseph

Here are just some of the ongoing KDE Eco projects:

  - The many objectives of the Sustainable Software goal, which you can 
read more about here:


     https://community.kde.org/Goals/Sustainable_Software

  - The three Season of KDE 2023 projects for scripting usage scenarios 
to measure the energy consumption of KDE apps. Read progress updates 
(with links to blog posts) for the excellent mentees Mohamed Ibrahim 
(KDE Eco Tester project), Nitin Tejuja (Selenium project), and Rudraksh 
Karpe (Blue Angel Preparation project) here:


    https://community.kde.org/SoK/2023/StatusReport

  - The energy measurement lab at KDAB Berlin as well as the Google 
Summer of Code proposal building an online portal for remote access to 
the lab (and possible CI-integration):



https://community.kde.org/GSoC/2023/Ideas#Project:_Measuring_Energy_Usage_Remotely_with_Online_Portal

Re: Recurrent <5$ USD monthly subscription.

[Nate Graham]

Hello Gary,

I'm happy you're happy, and thanks for wanting to donate! You can make 
monthly donations of 3€ or more at 
https://kde.org/fundraisers/yearend2022. Any smaller than that and the 
fees start to eat into the donations too much, and you could instead 
consider a yearly donation in the amount you wanted to donate per month, 
multiplied by 12.


Nate



On 2/26/23 04:00, Gary Espitia wrote:

Hi;

I use KDE and love the project; I want to, make recurring automatic 
donations, but the minimum set in github is 5$USD. If there's any reward 
I don't need it, I just want to be able to make the hassle-libre 
donation but set it to the amount I consider for whatever reason 
adequate, even if it's less than 5$USD a month.



Thank you for your attention.

Re: Proposal for using gitlab for kdereview process

[Nate Graham]

Overall I think it makes sense. The key players are all already on 
GitLab and it's where we do code review for established projects.


Nate


On 2/22/23 00:59, David Redondo wrote:

Am Samstag, 18. Februar 2023, 12:02:38 CET schrieben Sie:


I'm not convinced more paper work is going to help us increase the number of
participants in the review process (which is imho the big issue),


Hi Albert, I don't think it's will be paperwork, usually the mentioned
checklist was the first thing Harald links to people and is already mentioned
on the kdereview wiki page as things people will look at.


but if you're willing to document all this properly I'm happy to give it a

try and  be proven wrong :)


I will try to write something then for the wiki if noone objects.

David

Re: Welcoming Nicolas Fella, KDE e.V.'s new Software Platform Engineer

[Nate Graham]

Welcome Nico!

Now can you please fix X issue that I care about?!?1one

Just kidding. :) I hope working for KDE e.V. is a lot of fun!

Nate


On 2/14/23 10:07, Aleix Pol wrote:

Hi everyone,
During Akademy 2021, we discussed different positions for "Make a
Living in KDE". Today we are announcing the second of the 3 positions
described there. Everyone, please welcome Nicolas Fella (CC) will be
taking on the role of Software Platform Engineer.

Many of you will know Nico already for his work across our software
stack. For this contracting position, he will be working with us to
help make sure our software infrastructure is a happy place. Given our
current state there will be a lot of work related to porting to Qt 6,
but we expect it to extend this work into ensuring our offering is a
great basis to build your products on (be it apps, hardware, distros,
etc).

I know it's going to be tempting, but please remember to see this as
help rather than "oh great, Nico is going to fix X that I care about"
because this is hardly going to be the case, as Nico is one and our
codebase is vast.

Best,
Aleix Pol, KDE e.V. President

Re: Welcoming Thiago Sueto, documentation contractor

[Nate Graham]

Welcome indeed, Thiago! Great work already. Really impactful.

Nate


On 1/31/23 14:43, Adriaan de Groot wrote:

Hi KDE community,

KDE e.V. supports the KDE community in what it does -- making KDE software and
all the things around it. KDE e.V. employs people to organize events (and help
out with sprints), integrate hardware (if you are a vendor of a new device),
measure the ecological impact (via the KDE-eco initiative), promote KDE in the
media, and now also to write documentation.

The documentation position is one that fits in a multi-year project. We started
with gathering requirements and outlining a specific plan of improvements for
the documentation, then hired for documentation writing and tooling
improvement. Now Thiago joins us for the next steps, which means using the
improved tools and writing improved documentation.


Welcome Thiago (in CC) as our documentation-writing and -coordinating
contractor. He's pushed API documentation forward, written tutorials, has a
giant Kirigami MR ready and has been helping Nate with goals documentation as
well.

You can find @herzenschein in the KDE documentation Matrix channel,

https://matrix.to/#/%23kde-docs%3Akde.org?
via=kde.org&via=libera.chat&via=matrix.org&via=pyra.sh

and all over MRs in invent.k.o.

[ade]

Re: VDG application design sprint?

[Nate Graham]

On 1/24/23 09:42, Vinzenz Vietzke wrote:> Hey there,


Just to have it said: if you want to make it a in person sprint we 
(TUXEDO) can offer rooms, network, food etc. at our office in Augsburg.


Cheers,
vinz.



That is super generous, thanks so much for the offer, Vinzenz!

Nate

Re: VDG application design sprint?

[Nate Graham]

Very interested!

Ever since the GNOME folks created Libadwaita, I feel like their 
3rd-party app ecosystem has really taken off, and it seems like 
something they put a lot of planning and foresight into making happen. 
In KDE land we have a lot of 1st-party apps but not as much on the 
3rd-party side, and I'd like for us to have an equally compelling story 
there. I think the design, HIG, and UX perspectives--both user and 
developer--are key to making this happen, and a VDG sprint would be the 
perfect place to discuss those topics.


Nate



On 1/23/23 16:43, Nicolas Fella wrote:

Hi,

I think it would make sense for us to have a VDG sprint of sorts in the
near-ish future. This would allow to discuss some larger design topics
and set a vision for the longer-term future. I believe this is important
for us to be able to work together effectively.

I'd suggest to focus on application design topics, like layout,
structure, and arrangement of apps, and less on things like Plasma and
styles/themes. I'd also suggest to approach this more from a design/UX
PoV and don't let us be driven by implementation details. But these are
just my suggestions that are subject to debate.

Time/place/modality is all to be discussed, I'm mainly writing this to
gauge interest, so if you are interested let me know.

Cheers

Nicolas

Re: Retirement of Drupal 7/8 sites (kdevelop, skrooge, blogs, behindkde)

[Nate Graham]

On 1/16/23 02:33, Ben Cooksley wrote:
On Mon, Jan 16, 2023 at 12:08 PM Phu Hung Nguyen > wrote:


On 15/01/2023 08:04, bcooks...@kde.org  wrote:
 > For blogs.kde.org , I am in two minds as to
the best approach here, with
 > Wordpress and Hugo both appearing as candidates for this site.
 > Opinions welcome, especially if you are someone that currently
uses it.

I don't use this site, so I'm not gonna pick WordPress or Hugo.
However,
if Hugo is selected, I can do the porting to Hugo.


At this point it is looking like Hugo may be the preferred candidate for 
blogs.kde.org , but we'll see if anyone else has a 
view first.


For what it's worth, I'd prefer Wordpress for anything that uses a 
post/blog format. I find it to be easy to use and it's got loads of 
features. It's what I use for my site and it's helped keep my blogging 
productivity high. But I can appreciate the difficulty of syncing up the 
theming between Wordpress and Hugo sites--though we may have to tackle 
this anyway if the Dot ends up using Wordpress (which I also support).



Nate

Re: KDE Gardening?

[Nate Graham]

Hello Halla,

This is the community mailing list; have you tried contacting the 
gardening team about it directly? I imagine it should be a simple matter 
to omit Krita projects and repos from the workflow. I already ignore 
Krita bug reports when bug triaging, for similar reasons.


Nate


On 1/5/23 03:02, Halla Rempt wrote:

Hi,

I don't want to be a downer, but KDE Gardening is just making work for me, 
instead of helping out. Randomly replying to bug reports or merge requests 
without any knowledge of the project or how the team works only means more work 
for me, since I have to take action every time, and that takes time I would 
prefer to actually spend on my project.

I guess it's fine for totally unmaintained projects where nobody is involved 
anymore, like KDE bindings, but for actively maintained projects, it's not 
helpful. At least, I do not find it helpful.

Is there a way to actively exclude a project from this?

Halla

Funding opportunity for your projects

[Nate Graham]

Hello KDE community members and developers!

I'm writing to everyone about something very exciting: the NLnet 
Foundation (https://nlnet.nl) has made us aware that they have 
substantial quantities of funds available for FOSS projects that KDE is 
eligible for: up to 5€ per project. If you have an idea for a big 
project or feature you've always wanted to do but lacked the funding 
for, here's your chance!


If you're worried that your idea doesn't meet the criteria, don't be; 
practically everything KDE does is eligible for funds in the Open Call 
(https://nlnet.nl/news/2022/20221001-call.html) which ends on December 
1st, so there's still plenty of time for you to apply to get your 
project funded. Click that link for details.


Remember: what KDE does is good for the digital world. So if it's good 
for KDE and you can articulate its benefits, it's a worthy project!


If the process seems intimidating, you'd like someone to review your 
grant proposal, or you need guidance or assistance for any other reason, 
the KDE e.V. stands ready to help your grant proposal succeed. Email 
kde-ev-bo...@kde.org and we can help!



Nate



P.S. This information can also be found on 
https://community.kde.org/Make_A_Living

Re: There's a phishing campaign for KDE identities going on

[Nate Graham]

Thank you very much for warning the community about this, Albert! Take 
care, everyone.


Nate


On 10/19/22 13:44, Albert Astals Cid wrote:

I just got an email that said it had been sent my em...@kde.org that said
something along the lines of

Your email is being deactivated as you asked, please login here if it was a
mistake

And it sent to a place that was not in kde.org but looked loosely similar to
our web pages (kde logo, blue theme, etc) that was obviously trying to get me
to enter my login details.

Please be extra careful when using mobile or some other place where seeing
that the address doesn't really belong to kde.org may be harder.

And as always if you think you may have fallen into the trap, change your
password as soon as possible and tell sysadmin so they can try to see if your
identity was abused in some way.

Stay safe!
   Albert

Re: Drupal sites within KDE

[Nate Graham]

On 8/15/22 08:05, Phu Hung Nguyen wrote:
[1] this is not to say that a Hugo site cannot have comments. It can, 
but it seems that we don't need that functionality now.


If I'm going to move my blog to KDE infrastructure, I would consider 
comments mandatory. And I would prefer WordPress.


Nate

Re: Drupal sites within KDE

[Nate Graham]

On 8/11/22 06:05, Paul Brown wrote:

On Thursday, 11 August 2022 13:49:58 CEST Carl Schwan wrote:

Personally after having to deal with Wordpress at work, I think it offers an
horrible developer experience with tons of plugin violating the spirit of
the GPL, using PHP like it is still 00s (static and global variable
everywhere, almost no OOP, no namespaces, weird naming convention e.g.
$the_post, ...) and very poor internalization infrastructure. And so I
wouldn't recommend it


:(

Great interface for writers, though. As this is going to be used for mostly
writing, that should be taken into account also.


I agree with both of you: WP is kinda sucky for developers, but pretty 
great for users. That said, assuming those who maintain it don't have 
major problems (as Ben indicated) perhaps it would make sense as the 
direction to move in.


Selfish detail: my weekly blog runs on Wordpress and I've been thinking 
of moving the "This Week in KDE" posts to KDE infrastructure and opening 
it up to more contributors, so having an existing WordPress instance 
that the content would be plugged into would ease the transition.


Nate

Re: Telemetry in Plasma and Discover

[Nate Graham]

+Fabian Vogt and Luca Beltrame specifically

Thanks, that's a relief! Does this looks legit enough for openSUSE to 
stop patching out the KUSerFeedback integration?


Nate


On 7/11/22 18:50, Aleix Pol wrote:

It was discussed here:
https://mail.kde.org/pipermail/kde-core-devel/2020-November/091049.html

Aleix

On Tue, Jul 12, 2022 at 1:53 AM Nate Graham  wrote:


Hello all,

It's come to my attention that Plasma and Discover implemented support
for opt-in-telemetry without complying with the requirements listed at
https://community.kde.org/Policies/Telemetry_Policy#Compliance. The
Request for review was done solely in a merge request, not also on these
mailing lists.

I am retroactively emailing the kde-core-devel and kde-community mailing
lists to request review of the telemetry support in these KDE products
so that we can be in compliance with our own policies, should the review
be positive and use of opt-in telemetry continues.

Relevant commits:
-
https://invent.kde.org/plasma/plasma-workspace/-/commit/15dd744a3ba42cecc04f3e7a51148e9be3345c6d
-
https://invent.kde.org/plasma/discover/-/commit/f1f1597f4f2ea3870456a2f2ed184f9ebfc62bc3
- https://phabricator.kde.org/D5961

Nate

Re: Akademy 2022 Covid-19 Mitigation

[Nate Graham]

+1 for changing the policy to accept N95 and N99 masks as well. Speaking 
personally as a USA-ian, all I have is N95; the FFP2/3 stuff isn't 
generally available here because it's not a relevant standard here.


Nate



On 7/5/22 12:00, Andrius Štikonas wrote:

N95 is roughly equivalent level of protection as FFP2, so should be fine. One 
is US standard and the other is European.
(FFP3 corresponds to N99).

2022 m. liepos 5 d., antradienis 14:34:12 BST Neal Gompa rašė:

On Tue, Jul 5, 2022 at 7:49 AM Kenny Duffus  wrote:


Hi

Akademy 2022 is a hybrid event. Everyone can attend online

For the safety of everyone there, those attending in person will need to wear 
an FFP2/3 mask at all times and in all areas of the venue where we are having 
Akademy. We will be providing some free masks as well.

This is our baseline level that we will not be going below so that you can plan 
whether or not you feel it is safe to attend. If circumstances worsen we may 
also need to put in place additional measures that we will notify as early as 
possible.

There may be some venue staff in the common areas that we don't have control 
over who may or may not be wearing masks.

Details of registration to Attend Akademy, either online or in person, can be 
found on https://akademy.kde.org/2022/register



I mostly have N95 masks myself, as that's all I can acquire here. Can
those be acceptable too?

Telemetry in Plasma and Discover

[Nate Graham]

Hello all,

It's come to my attention that Plasma and Discover implemented support 
for opt-in-telemetry without complying with the requirements listed at 
https://community.kde.org/Policies/Telemetry_Policy#Compliance. The 
Request for review was done solely in a merge request, not also on these 
mailing lists.


I am retroactively emailing the kde-core-devel and kde-community mailing 
lists to request review of the telemetry support in these KDE products 
so that we can be in compliance with our own policies, should the review 
be positive and use of opt-in telemetry continues.


Relevant commits:
- 
https://invent.kde.org/plasma/plasma-workspace/-/commit/15dd744a3ba42cecc04f3e7a51148e9be3345c6d
- 
https://invent.kde.org/plasma/discover/-/commit/f1f1597f4f2ea3870456a2f2ed184f9ebfc62bc3

- https://phabricator.kde.org/D5961

Nate

Re: Akademy 2022 Call For Papers has been deleted

[Nate Graham]

On 6/10/22 20:01, Shlomi Fish wrote:

hi all,

i'm reminded of DOET:
https://www.shlomifish.org/philosophy/books-recommends/#design_of_everyday_things

A great book about designing for usability. Instead of covering software, it
covers everyday things like doors, taps or phones, and why or why not they make
sense. This book is amusing, insightful, and makes a very good read.

One of the central themes of the book is that users of these tools tend to
blame themselves for being unable to use the tools easily, while the fault is 
in fact in the tools, because they lack usability and are designed badly.


+1000, I love that book and it's very relevant here. There's definitely 
something wrong with the tool if someone experienced was able to make 
this kind of mistake with it.


As someone who submitted a talk, I found the input form to be rather 
cumbersome.


Nate

Re: Akademy 2022 Call For Papers has been deleted

[Nate Graham]

That sucks, but it sounds like it was an honest mistake, and data can be 
restored or re-created. Don't beat yourself up about it too much. :)


Nate



On 6/10/22 10:14, Albert Astals Cid wrote:

I have made a HUGE mistake.

I have deleted the Akademy 2022 event on conf.kde.org and with it all the 
submitted talks.

I am so sorry. I don't know how I ended up deleting the whole event when I just 
wanted to delete the test talk I had just submitted. I have failed you.

I have contacted the system administrators in case we are super lucky and we 
had a backup, but even if we do, some of the talks that had just been submitted 
are probably lost.

I have asked for all my rights in conf.kde.org to be removed since clearly I 
can't be trusted to use it.

Again I apologize for such a huge mistake.

Super sad,
   Albert

Re: Welcome Dina, our new event manager!

[Nate Graham]

Welcome, Dina!

Nate


On 2/19/22 03:34, Lydia Pintscher wrote:

Hi everyone,

I'm happy to welcome Dina to KDE. She's KDE e.V.'s new event manager
and will support us in organizing our events. She'll work closely with
the LAS and Akademy teams to put together great events for all of you.
Dina Nouskali is an event organiser and digital marketer. She has a
Bachelor in Marketing and Advertising and a Master in E-business and
Digital Marketing and a big passion for event organising. During the
last 10 years, she has cooperated with different companies and
organisations in organising conferences, cultural events, festivals
and workshops.

Please give her a warm welcome in KDE.

Cheers
Lydia

Re: How do we feel about non 100% KDE job offers being sent here?

[Nate Graham]

+1 from me on going for it.


On 11/25/21 09:25, j...@ohyran.se wrote:

(KDE and the lack of a central communicative hub we feel we can invest time in
is a immortal struggle after all so pushing for more activity feels like a good
thing)


I also want to agree with this sentiment specifically.

Nate

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

[Nate Graham]

On 6/19/21 9:26 AM, David Edmundson wrote:

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.


So what will we do to avoid getting this situation back?
I don't care if a user changes it once, but users who constantly set
their minor UI concern to critical gets tiring quickly. Angrily
closing doesn't work because you can get threads with multiple people
and then that isn't fair.

David


I might recommend taking those on a case-by-case basis, by removing 
severity-modification privileges for just the problematic users who 
abuse the system.


I have Bugzilla permission to do so, and perhaps this power could be 
granted to more people, like you.


Nate

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

[Nate Graham]

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.

Thoughts?

Nate

Re: Announcing KDE e.V.'s two new contractors to work on KDE's technical documentation

[Nate Graham]

It seems a little late to say "welcome", so... congratulations to 
Frederik and Carl! I think this marks the start of something fantastic!


Nate

Re: Telegram Bridge Migration

[Nate Graham]

On 5/14/21 2:19 AM, Kenny Duffus wrote:

Hi

TLDR: If you are an admin in one of our channels you could help ease the 
migration by inviting @kdetgadmin to the channel and making them an admin with 
the power to add admins

As some of you will be aware we have for a while been planning to migrate from our 
current IRC based Telegram bridge to a much more feature-full Matrix based bridge, kindly 
provided by Element Matrix Services on our matrix homeserver. The main feature being that 
on IRC and Matrix you will be able to talk to "real" users representing those 
on Telegram, media is also bridged better now

So instead of messages going matrix<>irc<>telegram they will now go 
irc<>matrix<>telegram

I have been slowly migrating a few channels over the last couple of weeks as we 
tried to iron out any issues

To enable and manage this we need to have admin in the telegram channels, some 
of you will have seen requests for this by myself, @sealne, and or @kdetgadmin

As part of running the bridge we now have a KDE Telegram Admin account 
(@kdetgadmin) that owns the bridge bot and also should have admin in any of our 
community Telegram Channels. This will minimise the bus factor risk in the 
future as well. Channel owners may also wish to give channel ownership to 
@kdetgadmin as well to give us as a community additional protection. 
@kdetgadmin will have a similar role to the KDE_GC user on freenode irc network 
going forward

Thanks for your help



Thanks so much for doing this, Kenny. It's hard to overstate how 
dramatically better the new bridge is compared to the old one. I've been 
able to move to Matrix full-time and leave all the Telegram rooms I was 
in before.


Nate

Re: All About the Apps Goal

[Nate Graham]

Hello Jonathan,

I don't think people disagree with the broad outlines of the goal, but 
it's not obvious to me how the merge request in question supports it. 
Despite tons of discussion in the MR comments, It's hard for me to 
understand what the MR does. There is very little explanation of the 
"what" and the "why". I think maybe that's what's missing, maybe?


If it's to enable Snap support in KDE Gear packaging automatically, it 
would be good to put that in the MR description. And if people's 
objection to this is unclear maintainership for caretaking the Snap 
configuration, maybe you can volunteer in your role as goal leader to 
maintain the Snap configuration stuff? My impression is that you already 
do this anyway for Neon, so volunteering to do that would mostly be a 
matter of reassuring people that you'll keep doing what you already do :)


Nate


On 4/23/21 3:58 AM, Jonathan Riddell wrote:
KDE's All About the Apps Goal hopes to use modern methods of getting our 
apps to users.  I seem not to have been clear about what I mean by that 
so time to check in and ask again.  These days apps (and websites and 
any software) gets developed by developers who are empowered to deploy 
them all the way to the user through suitable QA.  In the apps of KDE 
apps that means using app stores (flathub, snap store, appimagehub, 
microsoft store, fdroid, google play etc) and integrating the packaging 
for those stores into the apps repos themselves and our release tools.


This is a massive change of culture compared to what KDE has largely 
done until now where the packaging and deployment have been separated 
into often entirely separated organisations.  That does not seem to have 
served us well, our software has not taken over the world except by 
other orgaisations who have followed these practices, such as KHTML's 
derivative now being used by Microsoft Edge. It's not a setup done 
anywhere outside the Linux distros and KDE has long aspired to move 
beyond just Linux distros.


Our most successful apps have long gone ahead and done this, Krita is 
now available on the Epic Games store.  It seems strange to me not to 
want to emulate that success.  Moving packaging into app repos makes it 
smoother


Recently I made a minimum viable patch for the KDE Gear release tooling 
to bump up the version numbers where those apps have snapcraft packaging 
files.  However I've been told I shouldn't "overstate the nature of the 
goal" with an objection to integrating the packaging into the app 
repositories.


https://invent.kde.org/sysadmin/release-tools/-/merge_requests/15#note_205935 



I've little interest in putting lots of apps into app stores without 
this change of culture where app developers take some responsibility for 
the end result.  It would likely end up with unmaintained apps.


So would KDE developers prefer the status quo where our packaging is 
deliberately separated from our app development?  Or can we start with 
moving, where appropriate for the teams doing the work, to move 
packaging into the app repos and link the apps with the users?


Jonathan

Re: Appreciation

[Nate Graham]

Hello Tom,

I'm so happy that you're happy! Feel free to get involved, if you are so 
inclined. :) There are many ways! See https://community.kde.org/Get_Involved


Nate



On 3/24/21 7:59 PM, Thomas Lopez wrote:
For several days I had a strange issue in Gnome via PopOS, where my 
desktop would slow down a lot. Checking free -m, top, and journalctl did 
me nothing.


Finally just as I was about to give up on GNU/Linux, I tried KDE.

My issue is resolved completely, uptime is at nearly 24 hours and not a 
single bug.


YouTube videos no longer are slow and stopping often, from journalctl it 
seems vsync is even being used! That's awesome!


KDE is incredible, thank you all so much for your work.

Cheers,
Tom.

PS: Can you guys post a btc, eth, or ltc donation address on your github?
Sent from Mailspring

Re: RMS and open letter

[Nate Graham]

Hello all,

I would like to re-frame the discussion a little bit into terms we may 
all be more familiar with.


This letter we are being asked to sign is a lot like a controversial and 
flawed merge request: it contains elements that probably all of us agree 
with, elements that are controversial, and methods the address the 
problem that are controversial.


Thus many people who agree with the goal or some of the claims cannot 
approve the merge request (i.e. sign the letter) because of legitimate 
concerns about the implementation. This is a situation many of us run 
into daily, and we are familiar with the solution: revise the merge 
request (letter) so that it is less controversial but still accomplishes 
its stated aims. This way more people will be comfortable signing it and 
the discussion doesn't become a referendum on people's personal views on 
extremely sensitive subjects, which cannot end well.



So how would we revise this letter? We'd find the common ground that I 
hope all of us can agree on:


1. RMS is polarizing figure with close to zero social skills who has 
repeatedly put his foot in his mouth over a long period of time, making 
him a terrible ambassador for the movement he created.


2. The FSF board has exercised poor judgment and acted inappropriately 
both in reinstating RMS, and in even considering him for a public-facing 
leadership position in the first place.



Thus, the real problem here is the FSF's institutional structure and the 
judgment of its current members. A healthy body would have discarded RMS 
long ago due to his total lack of fitness for a public-facing leadership 
role. The fact that the opposite has happened shows that the FSF board 
does not function properly. The details of RMS's objectionable 
viewpoints are only relevant in that they serve to illustrate the 
board's poor judgment.


Accordingly, I feel that this letter ought to be revised to target the 
FSF board specifically, without so much of a focus on RMS himself or 
calling for blanket boycotts of the FSF (what would this even entail?). 
I think probably everyone could get behind that.


Nate

Re: Formal request to set up a KDE Discourse instance

[Nate Graham]

On 3/8/21 1:55 AM, Ben Cooksley wrote:
On Mon, Mar 8, 2021 at 2:55 AM Nate Graham I think doing GitLab stuff first makes sense in terms of usage of your

time. On that subject, I notice that both Jonathan and Carl (CC'd) have
offered to handle setting up the test Discourse instance, or assist
with
it. Perhaps we can do them in parallel, and accomplish a bit of
Sysadmin
onboarding too. :) What do you think?


We'll need to investigate the capacity and capability of our servers 
first to choose one that can potentially handle this (which as noted 
earlier, is substantially constrained by the demand of the Discourse 
developers to use Docker).


Is that something that can only be done by you, or is anyone else 
available for it? Might this be a good onboarding opportunity?



In the meantime, it will be interesting to see how the discussion plays 
out in the issue as there has been some interesting commentary already.


Seems like the discussion has tapered off with Discourse mostly being 
the preferred choice. Other alternatives brought up there seem to be too 
immature or not projected to fully meet our needs.



Nate

Re: Formal request to set up a KDE Discourse instance

[Nate Graham]

On 3/6/21 10:35 PM, Ben Cooksley wrote:
On Sun, Mar 7, 2021 at 3:51 AM Nate Graham <mailto:n...@kde.org>> wrote:> 
Ben, can we get Discourse added to the Sysadmin task queue? Again, no

pressure regarding schedule, but can we get it added there just for
work-tracking purposes?


I've now added https://invent.kde.org/sysadmin/task-queue/-/issues/31 
<https://invent.kde.org/sysadmin/task-queue/-/issues/31> for this.



In terms of scheduling it is currently behind [stuff]



Thanks Ben! Much appreciated.

I think doing GitLab stuff first makes sense in terms of usage of your 
time. On that subject, I notice that both Jonathan and Carl (CC'd) have 
offered to handle setting up the test Discourse instance, or assist with 
it. Perhaps we can do them in parallel, and accomplish a bit of Sysadmin 
onboarding too. :) What do you think?



Nate

Re: Formal request to set up a KDE Discourse instance

[Nate Graham]

On 3/6/21 6:54 AM, Clemens Toennies wrote:
Maybe it's an indication that putting monetary resources into these 
infrastructure projects (especially in light of KDE's current job hire 
initiative) would be a good idea?


To be clear, this is not to say anything about the imo outstanding jobs 
of the current voluntaries.


I've suggested it the past, and I believe this thread suggests that the 
amount of work exceeds the available resources by a significant margin, 
which reinforcing the proposal.


Ben, can we get Discourse added to the Sysadmin task queue? Again, no 
pressure regarding schedule, but can we get it added there just for 
work-tracking purposes?


Nate

Re: Formal request to set up a KDE Discourse instance

[Nate Graham]

On 2/28/21 3:17 AM, Ben Cooksley wrote:

I've now filled in most of the items i'm aware of at 
https://invent.kde.org/sysadmin/task-queue/-/issues 



Ah nice. Can we get Discourse added to that task list? As Eike said 
earlier, this would not imply prioritization, but it would be good to 
have it written down somewhere as planned work.


Nate

Re: Formal request to set up a KDE Discourse instance

[Nate Graham]

On 2/23/21 5:34 PM, Eike Hein wrote:

Hey,

This all sounds much too confrontational :-). Come on everyone, we can 
do this much better.


Ben, I don't think Nate's request implies prioritization. For folks 
outside a particular team it can be difficult to follow what the team 
has on their plate at the moment; you probably also wouldn't know the 
same about Nate's VDG/QA space.


Everyone knows that sysadmin is working hard all the time, but it has to 
still be possible to do roadmap planning. In fact it's one of the best 
ways to avoid getting overcommitted in the future. Declaring a goal 
and/or agreeing to work on it in the abstract doesn't mean it has to be 
done straight away or rushed, but it e.g. allows attracting contributors 
to the goal to get the work done, as also seen in the thread already.


Yes, Ben has made me aware that I don't actually have a good sense of 
what the sysadmin team is working on at any point in time. I'd love to 
be able to see at a glance which tasks are queued up in front of the 
things I'm eager to see done. Even something simple like a wiki page 
would be nice. It could even list ways for interested and technically 
competent people to help. That would be cool.


Nate

Re: Formal request to set up a KDE Discourse instance

[Nate Graham]

On 2/23/21 4:07 PM, Nate Graham wrote:

On 2/23/21 3:53 PM, Ben Cooksley wrote:
May I take this as a formal request from yourself that Gitlab CI is 
deprioritised and delayed?


Based on the extremely frequent requests we get concerning it in 
#kde-sysadmin I am not sure if your request here is in line with 
general community consensus.


Also, be aware that Sysadmin currently has other infrastructure level 
projects underway needed to get us off Ubuntu 16.04, which are 
currently delayed because we haven't had anyone volunteer to assist us 
with adding support for OAuth2/MyKDE to Reimbursements.
Based on the above, I assume you are also requesting that we delay 
this, and accept the corresponding security issues that will accompany 
it when Ubuntu 16.04 loses support in the coming months in order to 
get this actioned?


Hmm, I don't see where I suggested any of those things.

If you folks are really that overloaded, we need to figure out how to 
fix that. A workload that exceeds available resources doesn't help 
anyone. The last time this came up, people called for additional 
volunteers to assist. Did that end up bearing any fruit?


Anyway I apologize if my tone was off. I wasn't meaning to accuse 
sysadmins of anything, and I guess I didn't realize how overloaded the 
team is right now.


That being what it is, perhaps a more productive line of discussion 
would be to ask: "what do you need from us so that these things that 
need to happen, and that we all want, can reach fruition faster?" You 
don't have to suffer in silence! :)


Nate

Re: Formal request to set up a KDE Discourse instance

[Nate Graham]

On 2/23/21 3:53 PM, Ben Cooksley wrote:
May I take this as a formal request from yourself that Gitlab CI is 
deprioritised and delayed?


Based on the extremely frequent requests we get concerning it in 
#kde-sysadmin I am not sure if your request here is in line with general 
community consensus.


Also, be aware that Sysadmin currently has other infrastructure level 
projects underway needed to get us off Ubuntu 16.04, which are currently 
delayed because we haven't had anyone volunteer to assist us with adding 
support for OAuth2/MyKDE to Reimbursements.
Based on the above, I assume you are also requesting that we delay this, 
and accept the corresponding security issues that will accompany it when 
Ubuntu 16.04 loses support in the coming months in order to get this 
actioned?


Hmm, I don't see where I suggested any of those things.

If you folks are really that overloaded, we need to figure out how to 
fix that. A workload that exceeds available resources doesn't help 
anyone. The last time this came up, people called for additional 
volunteers to assist. Did that end up bearing any fruit?


Nate

Formal request to set up a KDE Discourse instance

[Nate Graham]

Hello faithful Sysadmins (with kde-community and Adam CCd),

I would like to formally request that a KDE discourse instance be set up 
as a testbed for now, with the ultimate goal of replacing the somewhat 
moribund forums.kde.org if people prefer it.


Over the years I've seen this suggested multiple times by multiple 
people, but without much movement. Since then, the Krita people have set 
up a Discourse instance themselves, outside of KDE infrastructure. Many 
other FOSS communities already use Discourse, including Debian, Ubuntu, 
Fedora, Manjaro, GNOME, and Mozilla.


I think it's time for us to follow suit and set up an official discourse 
instance on KDE Infrastructure.


Last I heard, there was an objection based on the fact that its 
deployment mechanism requires Docker. I don't care much for Docker 
myself, but if it's the only way to set up Discourse, I think it's time 
to bite the bullet and use it despite reservations, so we can facilitate 
this longstanding request from the KDE community.


Nate

Re: Rebranding the release service

[Nate Graham]

On 2/20/21 9:35 AM, Philippe Cloutier wrote:

Le 2021-02-20 à 10:38, Luigi Toscano a écrit :
In any case, "KDE Gear" sure is short and makes some sense if we 
consider it

related to Extragear, but for those who don't know KDE's history, I am
skeptical that gears are a good way to evoke applications.

It doesn't need to evoke applications, the idea is to have a brand.



Right; if it's not just applications, evoking applications is not as 
important. However, if it largely consists of applications, I suppose it 
remains non-ideal for the branding to primarily evoke internals.


FWIW, as a native English speaker, I like the word "gear" because it has 
multiple meanings, apart from the historical link to the word "Extragear":


1. Metaphorical synonym for "equipment" or "stuff"
2. Visual reference to the KDE logo/brand
3. Association with technical engineering disciplines, and KDE is known 
for rigorous, high-quality engineering


Overall I think it's a great brand name.

Nate

Re: Rebranding the release service

[Nate Graham]

On 2/15/21 3:18 PM, Albert Astals Cid wrote:

El dilluns, 15 de febrer de 2021, a les 14:01:25 CET, Jonathan Riddell va 
escriure:

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.


Ouch, y'all ended up liking my silly suggestion ^_^ Sorry about that.


Don't sell yourself short, Albert; I think it was really good!



Anyhow, I'm expecting we're not necessarily have to change stuff like branch 
names or RELEASE_SERVICE_VERSION_MAJOR cmake variables to adapt to this promo 
driven change, right?


I don't think so, no. Those are implementation details, and it would 
certainly be a pain in the neck to update them to reflect the name, only 
to change them again if we change the name in the future. My vote is to 
keep the internal strings the same.


Nate

Re: Rebranding the release service

[Nate Graham]

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.


Nate

Re: Hello from MyGNUHealth

[Nate Graham]

Welcome Luis! Very cool project.

Nate

Re: Announcing MyKDE

[Nate Graham]

Super cool stuff! Great work, Carl.

Nate



On 10/3/20 3:56 AM, Carl Schwan wrote:

Hello folks,
I'm happy to announce the successful deployment of the new identity system
in KDE, codename MyKDE. The new identity system is now available in
https://my.kde.org. You should be able to login into the my.kde.org website
with your normal KDE credential.

For the moment, only the wikis are using MyKDE but in the comming months
this should change with more and more services switching to MyKDE. I will
let you all know of the progress of the migration.


FAQ:


Why the move?
-

identity.kde.org is using OpenLDAP for user management with a small PHP
frontend allowing the account creation. And we had the following problems
with it:

* Account removal is hard, requiring significant manual intervention and
effort (several hours work in some instances)
* Account registration takes 30 seconds or more to complete, creating a poor
user experience
* Groups don't scale effectively
* Anti-spam measures are too crude

More on that in https://phabricator.kde.org/T8449

Will my data be migrated?
-

Yes, your data are migrated just by login into MyKDE once. This will migrate
all your group membership (KDE developer, Akademy Team, ...), personal
data and password.

For users who didn't log into MyKDE during the migration period. If you are
a KDE developer or KDE e.V. member, your account will be imported as a
disabled account and you will need to ask sysadmins to enabled it. For the
rest of the users of identity.kde.org who don't have a membership to groups,
your account will be removed. We think this is the best solution because there
is no need to store personal information that we don't need from users who
don't use the system anymore. If you want to conserve your account (and
username), please log at least once. We will send periodic emails reminding
you of migrating your account.

How do I register a new account in MyKDE?
-

For the moment the possibility of registering a new account is disabled in
MyKDE and the only possibility is to create an identity.kde.org account and
then migrate your account. This is due to the fact we don't want some
accounts existing only in MyKDE. This will naturally change when we migrate
fully to MyKDE.

How to I collect a badge?
-

MyKDE has the possibility to grant badges to users. For the moment there is
only one badge enabled: KDE developer. This badge is given to every KDE
developer and is displayed on their public profile (if enabled). When the
new Season of KDE website will be deployed, it will be also possible to have
an SoK mentor and SoK mentee badge.

I'm interested in ideas of new badges (and badge designs), so please let me
know if you have a genius idea that doesn't gamify KDE contribution (e.g no made
100/1000/10 000 commits badge).

Note that you are in control of that badge get displayed.

What is the public profile functionality?
-

One of the new features of MyKDE is the possibility to have a public profile.
This public profile is opt-in, so you need to explicitly enable it to make
it work and it can display a small bio, your avatar, name, username, social
network account, Liberapay account, and badges earned.

This is for example how it looks for me: https://my.kde.org/user/carlschwan/

Can I contribute to MyKDE?
--

Yes, the source code is hosted in https://invent.kde.org/websites/my-kde-org
and all the deployment information can be found here:
https://sysadmin-docs.kde.org/services/mykde.html

Cheers,
Carl Schwan
https://carlschwan.eu

Re: Fundraising in KDE

[Nate Graham]

> On 9/24/20 3:42 AM, Nicolas Fella wrote:

Hi,

I think the discussions about the technical implementation of our
donation system and whether or not to pay developers using the funds are
relatively orthogonal. Updating our current system is a good idea IMO
regardless of what comes out of the latter discussion.

If Carl thinks that CiviCRM is not a feasible solution from a technical
POV he has my full support for leading the work on a replacement system.


Like Nico, I would be inclined to trust Carl on this, as he just won an 
Akademy Award for his excellent work on KDE's web presence and 
infrastructure. :)


I'm not in a technical position to evaluate whether CiviCRM is capable 
of meeting current or future needs, but I feel like I've been hearing 
the system described as a problem to be solved for several years now. 
The fact that nobody seems very happy with it, and that it's been in 
this state for quite a while, does seem like it's a bit concerning.




> On 9/24/20 3:59 AM, Albert Astals Cid wrote:> [...] 
https://ev.kde.org/consultants/ is for "i want to implement X,
how much it will cost? 20K€? Fine here you have, now do it for me" not for 
"i have 100€ a year, please let me pitch in with more people so we can

hire a developer to work full time on improving Qt for KDE needs".


I agree, and this is why I think it's so important for the e.V. to start 
hiring developers. Right now the "hook" (so to speak) for donating is 
fairly weak. I think potential donators are much more excited about 
supporting the technical development of our software than they are 
supporting travel reimbursements, conferences, infrastructure, 
non-technical personnel, etc. (if they even know what the money is used 
for in the first place). Even though these expenses are very important, 
I think in the minds of the general public it's harder to connect them 
with tangible results.


On the other hand, if people knew that their money would help hire 
some/more developers, I think we could eventually reach 100,000€ per 
month just like Blender gets. And this money could also be used for 
critical non-development expenses as needed.



Nate

Re: Officially adopt "Noteworthy" label into KDE policy

[Nate Graham]

Thanks Julian, this looks great to me!

Nate



On 9/18/20 2:05 AM, Julian / xyquadrat wrote:

Hi all,

A few months back I suggested on behalf of the Promo team the 
introduction of a new label for issues and merge requests (see 
https://marc.info/?t=15869532709&r=1&w=2 for the thread).
The idea behind this "Noteworthy" label was to make it easier for Promo 
to keep up with all important new changes that are coming up in our 
software and reduce the possibility that something noteworthy gets 
overlooked.
Since then, the GitLab migration has been completed and such a label has 
actually been introduced (see 
https://invent.kde.org/dashboard/merge_requests/?scope=all&label_name[]=Noteworthy 
for an overview of Merge Requests tagged with "Noteworthy").


Given that the technical challenge is now solved, I'd like to propose to 
make this Noteworthy label official in the sense of adding it to the 
"Special keywords" section of Commit Policy (if there is a more 
appropriate place, please suggest it!) and encourage all contributors to 
start using it.


A few remarks:
- Of course all contributions are noteworthy and important. Promo does 
not want to discount the work that goes into small and unnoticeable fixes.
- If you are not sure whether a MR or issue should be "Noteworthy" or 
not, tag it with "Noteworthy" (-> be liberal with the label usage). 
Promo will then consider such edge cases in detail.
- Not all things tagged might make it into an official announcement. 
This is (usually) not due to us overlooking them, but because we have to 
carefully prioritize what we include. If you think something was left 
out that should definitely have been included, reach out to us on 
#kde-promo and we will be happy to discuss individual cases and solutions.


*Examples of noteworthy changes:*

  * User facing feature additions (e.g. /New useful effect added to
Kdenlive/)
  * Big changes in UI (e.g. /a KCM is rewritten in QML and now looks
distinctively different/)
  * Long-standing, annoying bugs (e.g. /Rework of the previously
bug-ridden MTP implementation in KIO/)
  * Large technology shifts (e.g. /Port to Qt 6/)
  * Significant performance improvements (best paired with concrete
numbers, but not necessary)

*Examples of changes not considered noteworthy: *

  * Small UX annoyances and fixes. Whilst those add up to something very
important, the individual changes (e.g. "more consistent padding in
dialogs") are not interesting to users.
  * Shifts in technology that do not affect the behavior of the product
(e.g. /porting from library X version Y to library X version Y+1/)
  * Minor changes to tools and backends used in the development process

Feedback and criticism is much appreciated.

Cheers and have a nice day,
Julian / xyquadrat

Re: Proposal: Recurring donations - increase flexibility

[Nate Graham]

On 7/29/20 12:44 PM, Albert Astals Cid wrote:

This was voted and approved by the KDE eV membership assembly a while ago, it's 
just that it is not as easy to implement as we would like and thus it still has 
not happened.

Cheers,
   Albert


Yeah I think everyone wants this, it's just a matter of getting it done. 
Perhaps the board mailing list would be a more appropriate place to 
continue the discussion since it's one of their tasks?


Nate

Re:

[Nate Graham]

Go right ahead! Here's a good starting point for you: 
https://community.kde.org/Get_Involved/development


If you're short on ideas, maybe look through https://kde.org/jj

Nate


On 7/14/20 4:47 PM, Ayush Kundu (RA1811035010045) wrote:
Hello there, this is Ayush from Calcutta, India and currently I'm 
pursuing my Bachelors in Electronics and Instrumentation Engineering. 
I'm highly interested in thd field of Computer Science and equally keen 
to contribute some open source. My areas of interest include Competitive 
Programming(C++, Java, Python, R) and Data Analytics. I would be highly 
grateful if you could provide me with an opportunity. Thank You.

Re: reddit r_KDE uses KDE logo in LGBT colors

[Nate Graham]

You might not be aware that the free open-source software movement is 
explicitly political and has been from the start. The whole point is a 
revolutionary liberation of software. As such, FOSS organizations 
generally try to be as inclusive as possible which results in an 
association with other related movements whose goals are the liberation, 
enfranchisement, or elevation of historically marginalized or 
discriminated-against groups. In all cases, the goal is the same: 
freedom from arbitrary and unfair restrictions.


Personally I don't see what the problem is. Endorsing LGBT rights does 
not imply a lack of endorsement for any other movement, any more than 
saying "I like pizza," implies anything about your feelings regarding 
dumplings or burritos.


Nate



On 7/12/20 4:13 AM, sabayon11 wrote:

I have a question:
Is it legal for reddit moderators of r_KDE to use KDE logo in LGBT
colors. Is it consistent with logo license?

https://www.reddit.com/r/kde/

Is it in line with KDE code of conduct - to support certain groups
that are politically active and be selective in this choice? For
example: why they don't support women rights in middle-east region?
Who have the right to decide?

Do you realize that it can stop certain people from funding KDE? Of
course on the other hand it can make others, like George Soros to fund
but does KDE really want to go in that direction and engage in such
politics. Pretending that it has nothing to do with politics is a pure
lie.

What other KDE contributors think about it? For example: do all KDE
funders support engaging software community in non-software activity?

I know that reddit is separate website and has nothing to do with this
forum, however this is social and community issue as well.

What about adding to KDE code of conduct: KDE is not engage in social
or political dispute. KDE doesn't discriminate nor support any groups
other than Free Software.

Personally I believe there are thousands of other better places on the
Internet to express whatever point of view someone has and KDE and its
community should not be involved in such activities.

It is now off. But this doesn't change the meaning of this action.
My first message about it to this list was on 3rd of July but has not
been accepted by moderators yet, so I had to subscribe.

Re: KDE Apps name trademarks

[Nate Graham]

On 7/9/20 9:42 AM, 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.


Thanks Michael! That seems like a good path forward.

Nate

Re: KDE Apps name trademarks

[Nate Graham]

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?


Nate

Re: auto-comment on bugzilla when making an MR?

[Nate Graham]

Awesome news! Thanks Harald!

Nate


On 6/16/20 4:54 AM, Harald Sitter wrote:

Tech that automatically mentioned MRs on bugs has been rolled out and
seems to be working nicely. CCBUG: only mentions the MR while BUG:
also marks the bug ASSIGNED. Enjoy.

HS

Re: The chat situation

[Nate Graham]

The incompatibility in capabilities between IRC, Matrix, and Telegram 
feels like it makes smooth communication between all three all but 
impossible. Maybe I'm wrong about this--hopefully I am! Because I think 
that if we're going to stay with Matrix, we need to somehow improve the 
UX in directions that attract all the people who currently use either 
Telegram or IRC with the goal of deprecating both. Because if Matrix 
can't be better than the two things it was intended to replace, then 
it's not a success, right?


If our Matrix instance is sponsored such that requesting support, 
maintenance, or development resources costs somebody else time and 
money, that seems problematic for the prospect of the issues under 
discussion being ironed out. Hopefully there are at least some things we 
can take care of on our side to improve the situation.


Nate

Re: The KDEPIM / Akonadi situation

[Nate Graham]

It's quite possible to take a large and technically flawed project and 
fix the technical flaws over time. Arguably this has happened in Baloo 
over the past year or two, and I see far fewer user complaints about it 
than I did in the past. It's working almost perfectly for me. I don't 
know enough about Akonadi's technical undrpinnings to say whether this 
will be possible there, or whether it's just an impossible undertaking 
though.


However I think there is a bigger challenge that just the technical 
issues. My interactions in bug reports have been quite negative, I have 
to say, and I don't feel like the developer culture is very welcoming 
right now. This probably has to change or else the project will fail to 
attract the kind of manpower needed to achieve a state of greater 
reliability, which I think needs to be the top priority in business-ish 
software. I'm currently using Thunderbird as my email client and it is 
boringly reliable. Everything works 100%, 100% of the time. There is no 
drama whatsoever, and no maintenance required. That's the goal.


Nate

The chat situation

[Nate Graham]

Carson's email about bridging #kde-devel to Telegram got me thinking: we 
should have a discussion about the situation we're in regarding chat 
services in KDE.


The current Matrix solution does not seem not optimal to me. I have 
really tried my best to be a good citizen and use Matrix as much as 
possible over the last year but I find myself gravitating back towards 
Telegram because of how much better the overall UX is, especially for 
fast-moving discussions and those involving images.


I haven't found a Matrix client that offers both a half-decent UX and 
also a reasonable featureset. The service suffers from lag, sometimes 
severe. Periodically the federation breaks, or the bridge between IRC 
and Telegram breaks, leading to people's messages silently vanishing. 
The implementation of the bridge itself impedes discussions between 
Telegram users and IRC/Matrix users because when a Telegram user replies 
to a post made by someone on IRC or Matrix, that person person can't see 
the message being replied to. Overall it just does not feel like a great 
user experience.


This situation really needs to be fixed, somehow. I'm not knowledgeable 
enough regarding chat software to be able to propose solution, but I 
don't feel like the status quo is something we should live with. Can we 
fix Matrix? Or should we migrate to something that offers a better UX?


Nate

Re: Beginner-friendly projects

[Nate Graham]

I agree that it's not very useful right now. I would recommend expanding 
it, because some projects truly are more beginner-friendly than others, 
just due to the nature of the code itself. However in the absence of 
that effort, removing it would probably make sense.


Nate


On 5/29/20 9:54 AM, Christoph Feck wrote:

Hello,

https://community.kde.org/Get_Involved says:

    "Beginner-friendly projects

     Here are some beginner-friendly projects with
     a variety of opportunities to contribute:

     * Elisa, a KDE music player
     * Krita, a KDE digital painting suite
     * KDE Connect, a tool to connect and integrate your mobile device
    "

Does this list make any sense? If the list should express the idea that
developers of these projects welcome newcomers, does it mean that our
other projects are not? If the list is supposed to state that the source
code is easy to understand for beginners, shouldn't we add much simpler
projects, such as KDE games, utilities, or simple QtQuick widgets?

Right now, I would suggest to just remove this section. Someone who is
really new to coding seems misguided.

Re: auto-comment on bugzilla when making an MR?

[Nate Graham]

On 5/20/20 9:44 AM, Luigi Toscano wrote:

Speaking as an extensive bug triager, if it does indeed represent a downgrade
in terms of organization and workflow, then we will engage with the GitLab
people to get the issues fixed. They are pretty responsive, and it's better
than using a dead, unmaintained version of a stagnant product.


This process will require time for sure, and some of the changes may not be
applied at all as not in line with the general way the system works (and also
the our internal changes to support it).

In the meantime, having the MR published in a bugzilla comment, and any other
integration mechanism, is surely welcome.


For sure!

I'm just saying, we shouldn't expect or plan to never move to GitLab 
issues. The proposal in this thread is just one of many things that we'd 
get for free if we were using it. The pressure to migrate will only grow 
over time.


Nate

Re: auto-comment on bugzilla when making an MR?

[Nate Graham]

On 5/20/20 6:50 AM, Boudewijn Rempt wrote:

On woensdag 20 mei 2020 14:33:42 CEST Filipe Saraiva wrote:

I like the idea, but I hope in future we use Gitlab issues as our tool
for bug management. :)


This has been discussed to death before... The plan is to use the issues to 
replace phabricator's tasks, not bugzilla.


I'm pretty sure that migrating from Bugzilla to GitLab Issues will 
happen eventually. GitLab Issues has a radically better UI for bug 
reporting and its improved integration with the rest of GitLab will be a 
really nice thing to have. Centralizing everything in GitLab would bring 
real benefits.


Speaking as an extensive bug triager, if it does indeed represent a 
downgrade in terms of organization and workflow, then we will engage 
with the GitLab people to get the issues fixed. They are pretty 
responsive, and it's better than using a dead, unmaintained version of a 
stagnant product.


Nate

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

On 5/1/20 2:09 PM, Ben Cooksley wrote:

Unfortunately sharing of projects/repositories across groups does not
impact on tasks and reviews.
This means that merge requests for Planet (which is currently shared
with "KDE") do not show up in the list of merge requests for "KDE".

Sharing repositories allows for a global listing only.
Are you saying that if we put plasma-framework in Plasma and share it 
with the Plasma group, then its MRs won't show up in the Plasma group's 
MR list? And that if we put it in the Plasma group and share it with the 
Frameworks group, then its MRs won't show up in the Frameworks group's 
MR list?


If so, that seems like it defeats one of the points of sharing a 
project/repo across groups. :(


Is this fixed in EE, or is it just a bug affecting all versions?

Nate

Re: Information regarding upcoming Gitlab Migration: clarifications

[Nate Graham]

On 5/1/20 9:02 AM, Johan Ouwerkerk wrote:

No, that is not the default.


Actually, it is: 
https://invent.kde.org/kde/kdesrc-build/-/blob/master/kdesrc-build-setup#L389




and download all
repos into ~/kde/src without any of the levels of hierarchy.



But it is sufficiently common that there is a dedicated setting for
it: `ignore-kde-structure`. Kinda does what it says on the tin ;)


Yes, and this setting is set by default. :)

Nate

Re: Information regarding upcoming Gitlab Migration: clarifications

[Nate Graham]

On 4/30/20 11:17 PM, Ben Cooksley wrote:

Not necessarily.

Git allows you to override the name that the local folder is called
when cloning, so there is no reason why we can't specify something in
the metadata to override the local name that the folder gets called in
your local checkout folder.
This would allow for example:

- frameworks/kcoreaddons on Gitlab continues to be called
'kcoreaddons' in your local checkout folder
- maui/dialer on Gitlab gets called 'maui-dialer' in your local checkout folder

This allows for the URLs on Gitlab to make sense, while simultaneously
allowing your local source checkout folders to continue to work in the
manner in which they do currently.
Note that we do not expect people to hit this in many cases - this is
about giving us the flexibility for the long term without imposing
unnecessary bureaucracy and limits on projects within the KDE
umbrella.

Automated tooling such as kdesrc-build and the proposed clone script
(that searches in namespaces) should be able to handle this without
much issue.
In the case of manually done clones, it is reasonable to expect people
to know what they're doing with their clones, and name them
appropriately in the event they have a collision.

Does this sound acceptable?


A little weird, but probably acceptable. I suppose it's no worse than 
having discover build an executable called "plasma-discover", which 
trips me up like five times a day :)


Nate

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

Thanks for the clarifications, Ben. Then I think the original proposal 
is perfectly reasonable and I fully support it.


Nate

Re: Information regarding upcoming Gitlab Migration: clarifications

[Nate Graham]

On 4/30/20 5:59 PM, Aleix Pol wrote:

El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid

Am I the only person that just has all the repos on the same folder? I thought 
it was the common thing to do :?


I do too


Same here. kdesrc-build's default settings do this, and download all 
repos into ~/kde/src without any of the levels of hierarchy. This would 
seem to require unique repo names, no?


The group categorization we've been discussing may be useful on the web 
UI for newcomers, but it has no value for your source checkout folder 
IMO, where it just makes it slightly more annoying to navigate from one 
repo to another.


Nate

Re: Information regarding upcoming Gitlab Migration: clarifications

[Nate Graham]

On 4/30/20 11:43 AM, Aleix Pol wrote:

IMHO needing tools ad-hoc to KDE development can be a barrier of entrance.
I feel like these things make us look distant, it's important that
people's skills translate automatically when they want to get started.


True, but if you're a new contributor, presumably our infrastructure 
would do the right thing the first time and you wouldn't need to use any 
migration script, right?


Nate

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

If I'm understanding things, we have solutions to most or all of the 
objections raised so far:


- Projects will be allowed to live in--or at least appear in--multiple 
top-level groups (e.g. plasma-framework could appear in both the 
Frameworks top-level group and also the Plasma top-level group)


- kdesrc-build and other scripts can be updated to allow people to 
easily check out repos using git prefixes (e.g. so that something like 
`git clone kde:dolphin` will still work regardlyss of a project's 
underlying group)


- cgit will continue to exist for three weeks to provide some transition 
time


- Each repo can have its own workboard in addition to the single 
group-level workboard


If the above are accurate, then I firmly support the proposal.

As for the actual grouping, I think it makes sense to have top-level 
groups for Frameworks, Plasma, PIM, etc. as originally proposed. I can 
support putting apps into category-specific groups (e.g. Multimedia, 
Office, Graphics, Games, etc) as long as apps could appear in multiple 
groups if needed for the case of apps that logically span boundaries 
(e.g. repos for PlaMo apps could appear in both the Plasma Mobile 
top-level group and also the relevant app group).



Nate

Re: KDE's Feel-Good Bulletin, Issue #01

[Nate Graham]

Thanks for the positivity in these trying times!

Nate


On 4/27/20 6:16 AM, Aniqa Khokhar wrote:

Dear KDE Community Members,

It's official: You are amazing.

And you don't have to take it from me -- here are some of the more positive
reactions from users we have had this week:

--
" Finally, I found the best desktop environment for me. It's modern, highly
customizable and well optimized. @kdecommunity KDE Plasma is amazing!"

-- Juan José Quiroz O. on Twitter (https://twitter.com/juanjqo/status/
1252109821559668736)
--
"Thank you for all your work."

-- Vance W. on LinkedIn 
(https://www.linkedin.com/feed/update/urn:li:activity:

6659074456079613952?
commentUrn=urn%3Ali%3Acomment%3A%28activity%3A6659074456079613952%2C6659399380723912704%29)
--
"The best desktop environment"

-- Claudio Grassi on LinkedIn (https://www.linkedin.com/feed/update/
urn:li:activity:6659074456079613952?
commentUrn=urn%3Ali%3Acomment%3A%28activity%3A6659074456079613952%2C6659864226674290688%29)
--
"Marvelous! KDE is the world's digital treasure."

-- redboygoes2town on Reddit (https://www.reddit.com/r/kde/comments/g6mbc1/
dolphin_kdes_file_manager_improvements_gestures/fob5o0r/)
--
"sudo pacman -S kdenlive 🙂"

-- Radwan Programer on Facebook (https://www.facebook.com/kde/posts/
10157555246413918)
--

Regards,

Aniqa Khokhar
--
Promotion & Communication

www:http://kde.org 
Mastodon:https://mastodon.technology/@kde
Facebook:https://www.facebook.com/kde/
Twitter:https://twitter.com/kdecommunity
LinkedIn:https://www.linkedin.com/company/kde

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

On 4/27/20 7:46 AM, Ingo Klöcker wrote:

On Montag, 27. April 2020 14:10:55 CEST Bhushan Shah wrote:

This is something which can be easily solved by Gitlab, Gitlab offers a
solution where project can be shared with another group.

So e.g. sharing kcontacts with kdepim should be possible, then all merge
requests/issues from kcontacts would show up under pim as well.


Great. So we could put all repos into an "all" group (e.g. rename kde to all)
and then have every subcommunity decide for themselves which repos they want
to see in their group.


If this is possible, it seems like the best solution to me.

Nate

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

On 4/27/20 7:52 AM, Nate Graham wrote:

On 4/27/20 7:46 AM, Ingo Klöcker wrote:

On Montag, 27. April 2020 14:10:55 CEST Bhushan Shah wrote:

This is something which can be easily solved by Gitlab, Gitlab offers a
solution where project can be shared with another group.

So e.g. sharing kcontacts with kdepim should be possible, then all merge
requests/issues from kcontacts would show up under pim as well.


Great. So we could put all repos into an "all" group (e.g. rename kde 
to all)
and then have every subcommunity decide for themselves which repos 
they want

to see in their group.


If this is possible, it seems like the best solution to me.



I've just been informed that it's possible to have a project appear in 
multiple groups such that I could find plasma-frameworks in both the 
Frameworks and Plasma top-level groups.


Therefore I rescind my objection and endorse having many top-level 
groups instead of a single flat top-level namespace, provided that we do 
put projects that are related to multiple groups into those multiple groups.


Nate

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

On 4/27/20 4:38 AM, Aleix Pol wrote:

Does this mean that to clone it we'll have to go "git clone
kde:games/knetwalk" or something along the lines?

If that's the case I'd much prefer if we didn't do this, at the moment
it's already uncomfortable for me to remember the URL for some of the
repos (e.g. is it sysadmin/ or not?), this will only increase the
problem and I personally don't see the advantage.

e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
krita graphics or its own thing?


Trying to categorize everything into a single group cannot succeed 
because many projects could logically belong to multiple groups (e.g 
plasma-framework is a framework that's a part of Plasma; Discover is an 
app that's a part of Plasma; kdenetwork-filesharing and kio-extras are 
libraries that are distributed via the apps release service). I foresee 
endless pointless arguments about the best group for something to live in.


Let's step back: do we have to put every repo inside a group in the 
first place? Is it solely so you can look at a nice list of all open 
merge requests for PIM/Frameworks/etc? If so, perhaps this workflow 
could be approximated with tags instead or group assignments instead


We create many very granular groups for the purposes of organizing teams 
and and performing code review (e.g. Plasma, KWin, Frameworks, PIM, 
Krita, Dolphin, Okular, VDG, etc.) and then every new merge request 
could receive a tag or assignee corresponding to its relevant code 
review groups (e.g. merge requests for kio and kio-extras could get get 
tagged with both "Frameworks", and "Dolphin"; plasma-frameworks MRs 
could get tagged with both "Plasma" and "Frameworks", and so on).


So +1 for a single top-level group I suppose.

Nate

Re: Akademy 2020 Online

[Nate Graham]

On 4/16/20 3:09 AM, Jens wrote:

Do you need like... ehm a wallpaper or SDDM background or maybe an avatar that
people joining get for free instead of like a T-shirt?

You know logo design and maybe some nice graphics and trying to make it in to
a "if a tshirt was in fact a wallpaper" kind of thing? I mean it doesn't
replace a physical object but it could be fun.

/Jens (who is totally psyched about an online event)


That's a fantastic idea! I love it!

Nate

Re: Update on Status of Gitlab Migration

[Nate Graham]

On 4/13/20 6:59 PM, Ben Cooksley wrote:

Why do we need to mimic them?

If you Google "KDE Gitlab" then the first hit is invent.kde.org 
.


To flip it around: why do we need to do something different? I don't 
think it's about mimicking anyone else, but rather using the most 
intuitively obvious domain name rather than some arbitrarily different one.


No matter what, we're all going to be talking about "KDE GitLab" or 
"KDE's GitLab instance". The title of the relevant documentation page is 
"GitLab" (much as the Phabricator documentation page was named 
"Phabricator"). And when the migration is complete, we're all going to 
announce that "KDE is now using GitLab!" So the cat's out of the bag on 
using the word "GitLab" and avoiding some number of people looking for 
our stuff at gitlab.com and not finding it there. invent.kde.org doesn't 
avoid that at all.


Given that, which is more confusing: explaining to people that we have a 
GitLab instance at invent.kde.org, or explaining to people that we have 
a GitLab instance at gitlab.kde.org?


I know that over the next few years I'm going to be directing hundreds 
of people towards our infrastructure, and I would rather be able to say 
"please submit a pull request at gitlab.kde.org" rather than "please 
submit a pull request at KDE's GitLab instance at invent.kde.org."


I know this probably feels like annoyingly extreme bikeshedding, but, I 
dunno, names are important.


Nate

Re: Update on Status of Gitlab Migration

[Nate Graham]

On 4/13/20 4:44 AM, Albert Vaca Cintora wrote:

Regarding this: is the subdomain going to stay invent.kde.org once we
have officially moved? I find it's a bit confusing to use that instead
of gitlab.kde.org


I agree. gitlab.kde.org would make more sense to me, mirroring 
phabricator.kde.org.


Nate

Re: Advice on setting up dev environment

[Nate Graham]

Here you go: https://community.kde.org/Get_Involved/development

Nate



On 4/12/20 7:54 PM, Ihor Antonov wrote:

Hi KDE Folks!

Can anyone share an advice/write up on how to set a productive environment for
developing KDE apps?

More specific question:
- What IDE to use?
- How to arrange files on filesystem?
- how to make sure dev KDE Apps/Plasma setup does not mix up with installed
stable KDE Apps/Frameworsk/Plasma setup? And how to switch between the two?
(I realise that there may be separate approaches for apps, frameworks, and
plasma)


Thanks in advance!


Ihor Antonov
https://useplaintext.email

Re: Qt, Open Source and corona

[Nate Graham]

On 4/8/20 9:32 AM, Christoph Cullmann wrote:

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.


I strongly agree. I think the sooner we demonstrate that we are capable 
of credibly maintaining a fork with other stakeholders in the FOSS Qt 
ecosystem, the stronger of a bargaining chip it will be in our 
negotiations with TQtC, so we don't have to. And in case the 
negotiations break down and we are forced to move forward with the fork, 
our prior preparation will ensure continuity so we won't have to 
scramble at the last minute.


It's heartening that KDAB has already indicated willingness to support 
such a thing should it become necessary. Are there other Qt-using 
companies who we could reach out to? Maybe also linux distro packagers? 
Perhaps the KDE e.V. could look into hiring people to help maintain the 
fork, given the importance of Qt's code to our software.


Nate

Re: New planet KDE

[Nate Graham]

Wow, this looks amazing! So much nicer. Great work, Carl.

Nate


On 3/12/20 8:19 AM, Carl Schwan wrote:

Hello everyone,

A new version of planet.kde.org is now available. From a technical point of 
view,
this is a migration form the rawdog planet agregator to the pluto engine and 
also
reuse the Jekyll theme used in various other KDE website.

The new Planet offers a bigger selection of language and more languages can be 
easily
added if needed. Each language also has a specific atom.xml feed: e.g.
https://planet.kde.org/ca/atom.xml/, so it's possible to follow only post in one
specific language.

Another improvement of the new version is that it's easier to read on a mobile
phone, since the videos and iframes shouldn't get larger than the screen width 
anymore.

A huge thanks for Ben for his help in deploying the new website and to Stasiek 
Michalski
for his work on planet-test.opensuse.org and helping me adapting his work for 
KDE.

The repository is now available in invent: 
https://invent.kde.org/websites/planet-kde-org
with updated instructions how to add your feed to the Planet and how to setup
a developement environment.


Regards,
Carl


PS: There are still tons of blog not using https. It's very easy to setup let's 
encrypt
nowadays for free, so I really recommand you to spend the 10 minutes to set it 
up and
then update your feed url in the planet configuration.

2020 HackIllinois hackathon: after-action report

[Nate Graham]

Greetings KDE friends!

This weekend I attended the 2020 HackIllinois event in Champaign-Urbana 
as a FOSS mentor, representing KDE. I'd like to present my after-action 
report:




*Overview*

First the good news: the KDE team won!

My students reported that the judges were impressed with their results, 
excitement, and passion, and the fact that one of the submitted patches 
(https://invent.kde.org/kde/konsole/-/merge_requests/68) has already 
been merged.


My students principally worked on building a visualizer for plasma-pa's 
microphone audio input level 
(https://bugs.kde.org/show_bug.cgi?id=411563) and managed to put 
together a pretty decent proof-of-concept: 
https://phabricator.kde.org/F8146046 (code is available at 
https://github.com/NSLeung/KDE-Neon-HackIllinois2020/commits/joey_branch). 
The code is not in a merge-worthy state, but could definitely get there 
eventually.


They also submitted some nice smaller patches: the aforementioned 
Konsole fix, and one for Dolphin too: 
https://phabricator.kde.org/D27757. They also made a thorough 
investigation of a significant Yakuake issue that has been affecting two 
of them: https://bugs.kde.org/show_bug.cgi?id=389448.


Two of the students in particular seem quite eager to continue their 
contributions.




*Promo & social observations:*

Nobody had an unkind or negative word for KDE. People who had heard of 
us really seemed to love us.


The other FOSS mentors at the event who I talked to had all heard of KDE 
and some had used Plasma in the past or still do. While most of the 
students I talked to had never heard of KDE, most of the ones who had 
were already using a Plasma-based distro (mostly KDE Neon, with some 
Manjaro)! Several GNOME-using students were impressed by what they saw 
and eager to help out, and the students already using KDE software were 
super duper enthusiastic. Most had never filed any bug reports or 
submitted patches, but eagerly jumped into this. They did not find the 
process of doing so especially difficult, so I suspect that a lack of 
outreach was principally what had kept them from doing so before.


Students were especially impressed with Yakuake, the embedded terminals 
in Dolphin and Kate, and Plasma itself. They all thought it was very 
attractive and polished-looking.




*Onboarding & technical observations:*

Overall, the process of setting up a KDE development environment from 
scratch was not a major pain point, especially for the Linux-using 
students. However a number of build failures took a lot of time to 
investigate and teach people how to work around: 
https://bugs.kde.org/show_bug.cgi?id=418328, 
https://bugs.kde.org/show_bug.cgi?id=418330, 
https://bugs.kde.org/show_bug.cgi?id=418331, 
https://phabricator.kde.org/D10041. Please help to keep the master 
branches of your projects compilable with default CMake settings, common 
compilers, and easily installable dependencies, everyone! :)


The students using Apple laptops had to set up their development 
environments in virtual machines due to a lack of macOS support in our 
current developer tooling and documentation. I had them install Neon 
Developer Edition, which worked fine overall, but it occurred to me that 
this edition would be more useful for its stated purpose if it shipped 
with a pre-generated .kdesrc-buildrc config file, plus kdesrc-build 
itself and all necessary dependencies from 
https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/Install_the_dependencies#KDE_neon.2C_Debian.2C_Ubuntu.2C_Kubuntu. 
These enhancements would have yielded been significant time savings for 
my VM-using students.




*Hardware observations:*

From my observations, at least 70% of the students attending the event 
were using Apple hardware running macOS. Most of the remaining students 
were using non-Apple hardware running some flavor of Linux, about a 
60/40 mix of Plasma and GNOME, respectively. I did not see a single 
student using a PC running any version of Windows.




Overall it felt like a worthwhile endeavor! Now time for some sleep...

Nate

Re: Regarding KDE Privacy policy

[Nate Graham]

On 2/26/20 2:32 AM, Ben Cooksley wrote:

As we're changing how we use the data (to now include a distribution
component) we would need to invalidate all existing consents given by
users (for which no mechanism exists for us to do so, as we never
expected to need to change the policy) and I think we would have to
discard all the data we have already collected as well.

Unfortunately, as the system includes no mechanism for the server to
communicate which revision of the privacy policy the user agreed to,
we would also have to come up with a way of blocking all old clients
from communicating with the system altogether (as we have no way of
telling if it is an old consent the software is relying on or a new
one) so you'd only start getting data in the system once users had
gone through a full update cycle.


That seems like an oversight we should correct regardless of whether or 
not we release any data. It is not likely that the terms will *never* 
change.


Nate

Re: Regarding KDE Privacy policy

[Nate Graham]

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.


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)

Re: Open Source Hackathon Mentorship Invitation

[Nate Graham]

I'm interested. I've sent an email to that address!

Nate


On 2/18/20 11:42 AM, Misha Patel wrote:

Hello,

My name is Misha Patel and I’m reaching out on behalf of the 
HackIllinois Outreach team. HackIllinois is a 36-hour collegiate Open 
Source hackathon that takes place annually at the University of Illinois 
Urbana-Champaign. This year, it will be from February 28th-March 1st, 
2020. Our mission is to introduce college students to Open Source, while 
giving back to the community. We strive to create a collaborative 
environment in which our attendees can learn from and work with 
developers to make their own contributions. In past years, we’ve had 
developers from prominent projects such as npm, Rust, and Apache come to 
mentor students from our pool of 900+ attendees.


We’d love it if you could pass along this message to the KDE Community 
community or any individuals you believe would be interested. We will 
provide meals throughout the event and can reimburse for travel and 
lodging up to a certain amount depending on where in the US people are 
coming from. More information on mentorship can be found at 
hackillinois.org/mentor . You can also 
visit opensource.hackillinois.org  
to see what kinds of projects were represented at our event last year.


We'd be more than happy to discuss this further. Please have any 
interested individuals contact us at opensou...@hackillinois.org 
. Looking forward to hearing back!


Best,
Misha Patel
HackIllinois 2020 Outreach Director
misha.pa...@hackillinois.org 

Re: New kde.org/hardware webpage

[Nate Graham]

On 1/26/20 9:16 AM, Ingo Klöcker wrote:

On Freitag, 24. Januar 2020 15:02:24 CET Philippe Cloutier wrote:

Ahem, wasn't that fast? The mail you quote is not phrased as a proposal,
but as a request for comments. Just a quick first look reveals at least
the following issues:

The currency units used are unclear.


Tuxedo build tailor-made hardware and all this with Linux!


I suppose s/build/builds/


All the computers and notebooks are assembled and installed in our house.


"our house"?


"in our house" means in the house/building were Tuxedo Computers resides. As
opposed to "are assembled and installed in a sweat shop in some cheap-labor-
country".

Regards,
Ingo



since the text is on KDE.org, using the word "our" makes it unclear 
whose house the laptop is being assembled in though. KDE's house?


It should probably say, "[...] assembled and installed in-house." Or 
even, "[...] assembled and installed in-house, not outsourced." to 
really drive the point home.


Sorry for not catching this during the patch review.

Nate

Re: New kde.org/hardware webpage

[Nate Graham]

I think it's fantastic! This is just what we need to close the loop for 
less-technical users who visit the webpage and want to know how they can 
get Plasma.


Nate


On 1/23/20 7:42 AM, Niccolò Venerandi wrote:

Hi!
I'm working on adding a kde.org/hardware  
webpage. You can see screenshot here: 
https://phabricator.kde.org/D26711. What do you think?

~Niccolò Venerandi