Re: Plasma 6 new logo poll

[Ilya Bizyaev]

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
>-- 
>Promotion & Communication
>
>www: https://kde.org
>Mastodon: https://floss.social/@kde
>Facebook: https://www.facebook.com/kde/
>Twitter: https://twitter.com/kdecommunity
>LinkedIn: https://www.linkedin.com/company/kde
>
>

Re: Today is Promo's Monthly Data Day

[Ilya Bizyaev]

Hello Paul,

The Phabricator link is not accessible.

Best regards,
Ilya

On 4 October 2023 09:24:52 CEST, Paul Brown  wrote:
>Dear Community,
>
>Today is our monthly data day.
>
>(We also have a quarterly data day for FB, which is today too; and we also 
>have a weekly data day, but that is tomorrow, and happens every Thursday).
>
>On the fourth of each month, we collect tables of data from the likes of  
>Xitter, LinkedIn. These tables contain information about how each post we push 
>out has behaved, how many people read it, clicked on it, liked it, etc.
>
>We have also added Mastodon recently with a homegrown solution that 
>automatically downloads the toots from the prior month to  a CSV file on 
>Collaborate:
>
>https://invent.kde.org/paulb/toot_collector
>
>It ran solo for the first time last night and worked great!
>
>Unfortunately, Mastodon does not provide information regarding impressions 
>(the number of people who actually saw the toot) or the number of clicks on 
>the links within the posts. But the information regarding replies, shares and 
>likes is still valuable.
>
>All the information from social media is available raw at
>
>https://collaborate.kde.org/s/8cqZD54ibCkkQmK
>
>under the Social Media/ directory.
>
>If you have write permission to those folders, please be careful!  A lot of 
>the information in there is generated automatically and is not meant to be 
>edited by hand. Make local copies (most of the files are very small) and work 
>with those.
>
>We are now working on collecting download data so we can see how promotional 
>activities affect download rates:
>
>https://phabricator.kde.org/T16930
>
>Currently, thanks to Justin Z., we have made progress with FlatHub, but any 
>help in this area would be greatly appreciated.
>
>Cheers
>
>Paul & Aniqa
>-- 
>Promotion & Communication
>
>www: https://kde.org
>Mastodon: https://floss.social/@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

[Ilya Bizyaev]

Hello Bhushan!



Thank you for you work on the Gitlab migration!



The lists look good! Here are some ideas that I have, in case you think they 
can be considered before we transition:

• The "applications" category is somewhat misleading to me: it does not include 
all KDE applications, and not all repositories in that category are 
applications either. Looking through the list of projects in there, I think 
they can be safely distributed across other categories. Most complicated there 
are IMO kate, dolphin, klook, konqueror, konsole and yakuake. Somehow terminal 
emulators, file managers and text editors feel like they belong to the same 
category, but I don't know how to call it; maybe "files"?

• Tentative, but I think a category called "science" might make sense creating. 
Since KDE regularly attempts to promote usage of our software in scientific 
institutions, that wouldn't hurt either. E.g. Mark (an app for data science) 
doesn't really belong in "education", and I think is also true for labplot and 
rkward.

• I see a category named "others". Looking at its contents, maybe it can be 
renamed to "community"?



Looking forward to the move!



Cheers,

Ilya.





 Дата: Пн, 27 апр 2020 04:40:01 +0300 Bhushan Shah  
написал(а) 



[Please keep mailto:sysad...@kde.org list or mailto:bs...@kde.org in the CC for 
replies] 
 
Hello Community members, 
 
In view of upcoming Gitlab migration, we sysadmin team wants to share 
the recommended structuring for the repositories on Gitlab. 
 
We had multiple options, 
 
- Flat structure: In this option we would have everything under one 
 single namespace/group: https://invent.kde.org/kde/knetwalk 
- Subgroups under top-level group: In this option we would have a groups 
 under KDE namespace: https://invent.kde.org/kde/games/knetwalk 
- Groups at top level: In this option we would establish a series of 
 groups at the top level, e.g. https://invent.kde.org/games/knetwalk 
 
We have discussed this with small but representative group of 
contributors or maintainers, and based on their suggestions, we 
recommend that we go with option 3. Having sub-groups at top level will 
allow us to, 
 
- Provides good visibility on all reviews, tasks and other items within 
 the groups/modules we define 
- Provides improvements to discoverability of projects 
- Makes it possible for groups of projects to establish a group level 
 task board should it fit their needs (for tracking a release for 
 instance) 
- Makes the most semantic sense, as the ‘KDE’ top level group suggested 
 in option 2 is duplicative considering the Gitlab instance is under 
 kde.org. 
- The discoverability of projects is maximised, as there is no need to 
 open the top level ‘KDE’ group before going into the subgroup. 
 
I've worked on draft "move" of the current set of the repositories in 
their respective subgroups at the repo-metadata project's branch [1]. 
You can browse the directory structure to get idea of how final 
structure on Gitlab would look like. 
 
If we don't have any objections we would like to implement this next 
week and move projects to https://invent.kde.org. 
 
Thanks! 
Bhushan for sysadmin team 
 
[1] 
https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
 
 
-- 
Bhushan Shah 
http://blog.bshah.in 
IRC Nick : bshah on Freenode 
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D

Re: Sysadmin Load Reduction: Subversion Infrastructure

[Ilya Bizyaev]

A task shows this attitude much better as it is something that will be 
completed eventually. "[WIP] Migrate translations from SVN to Git" to me sounds 
like a clear intention.



Docs, in contrast, are static and do not display any motivation for migration. 
"Top 10 Reasons Why We Can't Use Git".



Best regards,

Ilya.



 Дата: Вт, 12 ноя 2019 14:12:28 +0300 Luigi Toscano 
 написал(а) 



Ben Cooksley ha scritto: 
> On Tue, Nov 12, 2019 at 10:00 AM Alexander Potashev 
>  wrote: 
>> 
>> пн, 11 нояб. 2019 г. в 17:02, Luigi Toscano 
>> : 
>>> 
>>> Alexander Potashev ha scritto: 
 вс, 10 нояб. 2019 г. в 18:09, Luigi Toscano 
 : 
> Most of translators are not so technical as the developers. And even 
> developers can shoot them in the foot with git, I see many issues coming 
> from 
> unwanted merges. 
 
 We can block unwanted merged on the server with a Git hook like this: 
 https://github.com/FabreFrederic/git-hook-pre-receive-reject-merge-commit 
>>> 
>>> When I talk about local merges, I foresee a bit of mess when resolving a 
>>> merge 
>>> locally, which may result in proper commits whose content has an invalid 
>>> syntax. 
>> 
>> I don't get it. 
>> 
>> If you have conflicting changes, either with SVN or Git, you have to 
>> resolve the conflict manually. Of course it's easy to break the syntax 
>> while doing so, however SVN does not make it any easier than Git. 
>> 
 Cloning the whole repo would be too much for some translators, however 
 the new Git feature "git clone --filter" might be a solution: 
 https://unix.stackexchange.com/a/468182 
>>> 
>>> Documentation does not seem to help (or at least I don't seem to find it in 
>>> the man pages for git 2.24). Do you know how it could filter just some 
>>> directories? It seems more focused on filtering by object type. 
>> 
>> OK, I now tried this approach with Git 2.23 (see attached log) and 
>> found horrible problems that make it basically unusable: 
>> 
>>  1. git-checkout downloads each file in a new SSH connection. It make 
>> the download really slow: less than 1 file per second in my setup. 
>> That means downloading of translations into one language would take 
>> more than an hour. 
>> 
>>  2. git-status silently tries to download to whole Git repository. 
>> 
>>  3. git-commit tries to download some files one by one again. 
>> 
 Shall I create a new Phabricator task "[WIP] Migrate translations from 
 SVN to Git" so we can put relevant ideas in one place? 
>>> 
>>> I don't know. For me having a board and tasks (it's not just a single task, 
>>> it's an entire project) sounds like there is something that can be 
>>> implemented, and I don't think it's the case. 
>> 
>> The tag [WIP] would hint that we are not sure if it can be 
>> implemented. We can even name it "Reasons why translations cannot 
>> migrate to Git", if necessary. 
> 
> Sorry, but if you proceed with using a title such as that one, then 
> you are not being constructive or helpful towards this conversation. 
> 
> That title would indicate to me that the translation community is 
> completely unwilling to consider change of any form. 
 
That's why it shouldn't be a task at this point, but a document showing why we 
can't migrate. 
It's not a matter that we are unwilling to consider. The problem is that the 
current state makes it almost impossible to migrate. The document would 
explain why. 
 
 
-- 
Luigi

New KDE.ru website

[Ilya Bizyaev]

Today the Russian-speaking KDE community proudly launches its updated website, 
KDE.ru. The new website serves as the main page for the Russian-speaking 
community. It provides localized information about KDE, product download links 
and the list of social network pages we maintain. It is also meant to help new 
members get involved in KDE’s projects, particularly in our translation and 
promotion efforts. The website was created by me and Alexander Potashev on top 
of Jonah Brüchert‘s work for plasma-mobile.org. It uses Jekyll and is now 
hosted on official KDE servers. It replaces the old forum that has 
significantly lost its users in the past years. Also, our localization 
documentation has been moved from a self-hosted wiki at l10n.lrn.ru to 
https://community.kde.org/RU. We would like to thank Ben Cooksley for his help 
with website deployment, all the users who participated in beta testing, and 
everyone who helped polish the content. If you have any comments or 
suggestions, don't hesitate to reply to this message or contact us directly. 
Source code: https://cgit.kde.org/websites/kde-ru.git/ Announcement in VK: 
https://vk.com/kde_ru?w=wall-33239_2123 Cheers, Ilya.

Re: Improving our integration with KDE application teams, and supporting companies

[Ilya Bizyaev]

Agreed wholeheartedly, more companies doing KDE is the way to go!

Cheers,
Ilya.
 On Чт, 16 авг 2018 12:21:58 +0300 h...@kde.org  wrote 


On 8/11/18 7:34 PM, Valorie Zimmerman wrote: 
> Am I the only one who thinks of our future in this way? 

A most hearty no! 


> Valorie 

Cheers, 
Eike 

Re: do you need www.kde.org write access?

[Ilya Bizyaev]

Glad to hear it's not planned :)

As I said, they currently seem to not be integrated at all, as I failed to find 
a switch (per-page or global).

 On Fri, 09 Mar 2018 20:07:52 +0300 aleix...@kde.org wrote 

On Fri, Mar 9, 2018 at 5:57 PM, Ilya Bizyaev <bizy...@zoho.com> wrote: 
>  On Thu, 08 Mar 2018 11:23:08 +0300 Sebastian Kügler <se...@kde.org> 
> wrote  
> 
> That's part of what we need to review: is the new site missing relevant 
> things which need to be migrated? It's something we can surely fix. 
> -- 
> 
> The part I am personally concerned about is translations. I see that 
> announcements got imported, but there seems to be no way to view 
> announcements in a different language. 
> 
> Compare: 
> https://www.kde.org/announcements/plasma-5.12.0.php?site_locale=ru 
> https://www-backstage.kde.org/2018/02/06/plasma-5-12-0/ 
> 
> Will the translation history be preserved and used? 
> 
> Cheers, 
> Ilya. 
> 

There's no intention to remove translations. Texts will possibly 
change, especially if the promo team starts working on the website 
again. 
If you really are concerned, I suggest you step forward and help make 
sure it's integrated as it should. 

Aleix 

Re: do you need www.kde.org write access?

[Ilya Bizyaev]

 On Thu, 08 Mar 2018 11:23:08 +0300 Sebastian Kügler se...@kde.org 
wrote 

 

That's part of what we need to review: is the new site missing relevant 

things which need to be migrated? It's something we can surely fix. 

-- 



The part I am personally concerned about is translations. I see that 
announcements got imported, but there seems to be no way to view announcements 
in a different language.



Compare:

https://www.kde.org/announcements/plasma-5.12.0.php?site_locale=ru

https://www-backstage.kde.org/2018/02/06/plasma-5-12-0/



Will the translation history be preserved and used?



Cheers,

Ilya.

Re: Regarding KDE Chat Solution

[Ilya Bizyaev]

Hello Severino! :)



I am glad you mentioned XMPP, and in fact I also see it and 
https://kdetalk.net/ as an alternative.



I am participating in a project that aims to develop a cross-platform XMPP 
client, Kaidan: https://github.com/kaidanim/kaidan

It uses Kirigami as a UI toolkit and libgloox for the backend.

It is still very basic, but we already have some users, so there clearly is 
interest.



Best regards,

Ilya.





 On Вс, 18 фев 2018 23:56:18 +0300 Severino Ferrer de la Peñita 
s...@mailbox.org wrote 




Hello everyone.



When I was at FOSDEM this year, I was told about KDE moving away from IRC and 
looking for something else.

I'm not involved in KDE as an active contributor or developer, but I'm a happy 
KDE software user, so this felt really close to me.





After trying to follow the discussions on the mailing list, I was hugely 
surprised that XMPP was not being mentioned.

That encouraged me to send this email.



I don't know if someone else already asked for the same thing. I apologise if 
that's the case.





I have created this table: 
https://github.com/SeveFP/KDE_IM_Requirements/wiki/XMPP-Table



based on the one at https://community.kde.org/IM_Survey_Results



I was not sure if I was allowed to modify the current table at 
https://community.kde.org, that's why I started creating one by myself first, 
to let you check it.



It has been a long time, trying to check all emails and blog posts. If there's 
any requirement empty it's probably because I didn't understand what it means.





Let me point out that XMPP is a safe bet for years to come, as it's a widely 
deployed living standard.

Being this such an important move, I would like you to think about XMPP as an 
option.



Personally, KDE has been doing awesome work with KTP and I would love to see 
more work in this direction with XMPP.



Also, a mention to https://kdetalk.net/ is well deserved.



The XMPP community is really great, welcoming and active. Don't hesitate to 
approach it, you won't be disappointed!





Thank you for your time,





Severino Ferrer de la Peñita.