Thanks for responding everyone!

I have no availability for travel this automn (already fully booked until Dec 17), but I could participate in a first BoF session at Akademy.

I'd be interested to attend indeed. Note that I probably won't be able to do the work post-sprint (and trust me there'll be plenty), but I can help devise a path forward during the sprint.

I think this has to be considered an "advanced" topic. We've first got to get the new people submitting patches and having them accepted. I've been banging away at patches and bugfixes for the past 8 months and have never even investigated how to package something for distribution. I'm working on a personal project that I'll want to distribute, but I've got plenty of coding before I get there.

Thanks @sandroandrade , I 'll reach out to the author and try to get some first hand insight on mozilla's procedures and experience.

Some insights that may be useful for our onboarding goal.

FWIW I may be interested in attending, i didn't add myself to the list above because I would not want to be a "voter" on the place/date but i would be interested in being notified when the place/date is chosen to see if i can join :)

FWIW I may be interested in attending, i didn't add myself to the list above because I would not want to be a "voter" on the place/date but i would be interested in being notified when the place/date is chosen to see if i can join :)

FWIW I may be interested in attending, i didn't add myself to the list above because I would not want to be a "voter" on the place/date but i would be interested in being notified when the place/date is chosen to see if i can join :)

Hello all, last year during KDE Edu sprint there was a discussion about create an "KDE Research/Science/etc" umbrella for some Edu applications more related to academia works, like Cantor, Kile, KBibTeX, RKward, and others cited in this thread. Maybe this new umbrella could be a motivation to a website or other actions related to this.

@nicolasfella that's a really major issue, yes. However, I think we should stick to the "Get Involved" page here in this task, so that we don't broaden its scope/discussion too much. Cleaning up the whole wiki could be a separate task, with subtasks for every main section that people can assign to themselves (because doing the whole thing at once might be too much for one person).

One thing I noticed in the Wiki is a huge amount of broken links. Those should be updated (if possible) or removed. Maybe one could do some kind of webcrawler that scans our whole wiki for broken links.

Thanks @lueck for pointing these applications out; I have now re-added them to my active list.

In T6832#143007, @xyquadrat wrote:

knetattach

Not able to find a repository on cgit.kde.org nor a release in Ubuntu 16.04...

plasma-desktop/knetattach/

konsolekalendar

I can find the package in Ubuntu 16.04 (from a very old version), but not a repository

pim/akonadi-calendar-tools/konsolekalendar/

korgac

Not able to find a repository on cgit.kde.org nor a release in Ubuntu 16.04...

pim/korganizer/korgac/

kwikdisk

Not able to find a repository on cgit.kde.org nor a release in Ubuntu 16.04...

kdeutils/kdf

libalkimia

I can find the package in Ubuntu 16.04 (from a very old version), but not a repository

extragear/office/alkimia/

pimsettingsexporter

I found pim-data-exporter, which might be the same thing (?)

Yes pim/pim-data-exporter/

In T6832#142931, @schweingruber wrote:

Hm, is there a compelling reason to remove obsolete products from the database? If they are marked as obsolete, no new bugs can be filed against it anyway, and those should not show up in a browsable list for the user. Of course if you have admin rights they will show, but how often does an admin have to browse a product list without a filter?

I must admit that I just realized that the list of apps you can report a bug against is not the same as the ones accessible through clicking "Browse"...
But I think we should consider hiding the obsolete products not only when reporting bugs, but also in a) the advanced search & b) in the list from Browse. It'd simplify the search process for triagers a lot. Additionally, there are some products which are obsolete but you can still file bugs against them (e.g kaveau).

In T6832#142824, @xyquadrat wrote:

I decided to do something remotely useful with my free time and sifted through all applications/libraries present on bugs.kde.org, removing most obsolete products. My guidelines to determine whether a product was deprecated were:

1. Is the product not marked as "unmaintained"/"deprecated"/"replaced"?
2. Is the product in the repositories of Ubuntu LTS?
3. Is the product on cgit.kde.org?
4. If it is on cgit.kde.org, does it have any activity in the last year?
   
   After applying this criteria to all 737 (!) products available, only 455 remained (so nearly 300 products are obsolete, and should be removed from bugs.kde.org). It is of course entirely possible that I have either missed a deprecated product or have accidentally deleted an active product... Feedback is always welcome!
   
   All products:
   kdeOldProducts41 KBDownload
   
   
   Only active ones:
   kdeProducts25 KBDownload

Ok, so it seems that you only created a list and you are asking for feedback. Fine then, sorry for the misunderstanding, the wording could be misleading.

Just to be sure, @xyquadrat : did you already remove the products? In the future, don't remove first and ask later, but do the opposite. It's a bit too late to ask whether you had accidentally deleted an active product.

Hm, is there a compelling reason to remove obsolete products from the database? If they are marked as obsolete, no new bugs can be filed against it anyway, and those should not show up in a browsable list for the user. Of course if you have admin rights they will show, but how often does an admin have to browse a product list without a filter?

Following a discussion with @bshah about T8685, we opted for revamping Plasma Mobile phabricator tasks. The status of many tasks has been changed in order to avoid offering to the potential contributor a task already done.

I decided to do something remotely useful with my free time and sifted through all applications/libraries present on bugs.kde.org, removing most obsolete products. My guidelines to determine whether a product was deprecated were:

1. Is the product not marked as "unmaintained"/"deprecated"/"replaced"?
2. Is the product in the repositories of Ubuntu LTS?
3. Is the product on cgit.kde.org?
4. If it is on cgit.kde.org, does it have any activity in the last year?

In T8712#142098, @hein wrote:

It's worth noting we have this in a non-formalized way. The Getting Involved pages have always listed mentors you can contact for 1on1 questions (I've responsed to mails due to this for many years).

I'm not a developer, so perhaps I'm missing important aspects here, but how about using a common template with the things that would interest people, so they can quickly review what's it about before going into the details?

What constitutes a "junior job" does indeed vary immensely. The maintainers or "lead" developers need to flag bugs carefully and appropriately. I've worked on junior jobs that ranged from string and icon changes, to adding a new API call to KWin. These were all referred to as JJ's, but they're definitely on different levels.

I sometimes try IRC but that does not work very well, because a developer needs to be online at the same time you are online

The link to the Mentoring page is literally the last word of the Getting involved page. I did read the getting involved page (maybe with not too much attention), but I did not reach the mentoring page and did not figured out I could contact a developer directly. Maybe this link can be highlight better somehow?

Great stuff.

even if it requires a bit of effort up front to help people get started

I don't think anyone's proposing an easy-but-broken method of brute-forcing the first commit. Rather, I think we're all discussing how to make it easier to get started the right way so that first commit is not only easier, but also conforms to KDE best practices.

In T8685#141924, @aacid wrote:

The translation teams have said various times in the past that translations from random people in the internet with no commitment usually just bring in more work than they help since they totally fail at syntax, style guide, etc. I wouldn't be sure this has changed at all.

I mean would you let people edit code form the internet and submit a patch directly without having them compile and try it whatsoever? Probably not, so why would it be different for translations?

It's worth noting we have this in a non-formalized way. The Getting Involved pages have always listed mentors you can contact for 1on1 questions (I've responsed to mails due to this for many years).

It's great to see so much valuable feedback rolling in to this thread, especially from people that are new to KDE. Many thanks for that!

As a relative newcomer (January), this is a very real and very powerful
thing. We should do whatever we can to encourage it. When my first
commit got landed (a simple plasmoid fix), it was a great feeling. Now
you'll probably never get rid of me.

I totally agree that the jobs need a better description. This task is all about discussing what should be in there

May I suggest that you don't add more jobs to this list just now but instead focus on making the existing ones really junior friendly.

In T7116#141596, @dhaumann wrote:

BTW, Akademy is nearing, registration is open. Could we send a mail to all (!) contributors who have a KDE commit account? I think this does make a lot of sense to trigger everyone (especially new contributors) to come to this event.

The translation teams have said various times in the past that translations from random people in the internet with no commitment usually just bring in more work than they help since they totally fail at syntax, style guide, etc. I wouldn't be sure this has changed at all.

TBH, my suggestion is primarily focused on the facilitation of a really fast and simple first contribution. Like the case when we learn a new programming language, almost always we try to run a "hello world" example, without having any real knowledge of the language or having read (almost) any page of the language reference. After the successful execution of the “hello world” , we feel a little bit more comfortable to continue studying. It's the "hello world" psychological effect accompanied with the feeling of membership and commitment to the KDE family that the solution tries to reproduce .

We should definitely do something during Akademy but I don't think it should and can replace the sprint.

In T8685#141599, @sharvey wrote:

If we want to create a website (even it it's something like myfirstpatch.kde.org), we should put a link on the user's desktop at installation. That's relatively inoffensive, easily removed, and requires less coding than a desktop widget.

If we want to create a website (even it it's something like myfirstpatch.kde.org), we should put a link on the user's desktop at installation. That's relatively inoffensive, easily removed, and requires less coding than a desktop widget.

Would it make sense to have this sprint as part of the BoFs and Workshops week at Akademy? Or maybe we can have a smaller session as a prep-event for the actual sprint.

BTW, Akademy is nearing, registration is open. Could we send a mail to all (!) contributors who have a KDE commit account? I think this does make a lot of sense to trigger everyone (especially new contributors) to come to this event.

Here are my 2 cents.

Another website like that is https://whatcanidoformozilla.org

One of nice example I found earlier : https://howcanihelpubuntutouch.io/

Perhaps it could also pull Junior Jobs from Bugzilla? It’s a good idea, having it readily (and semi-permanently) available. I don’t know if we could get it done in time for Plasma 5.13 (assuming the idea is approved).

We can choose any topic from the sub-tasks listed on the overarching Onboarding Goal task. I will be adding some more sub-tasks there in the following days (like improving documentation, gathering feedback etc). Feel free to leave a comment there if you came up with anything that needs to be tackled and is not mentioned already.

Definitely possible. Having never planned or attended a sprint before, I'm completely unqualified to organize one. I was just proposing things that seemed like they needed urgent fixing.

In T8621#140403, @ngraham wrote:

Maybe we need two sprints? One for Usability and one for Productivity? The thing is, they're inter-related. All the KCM porting work you guys did at the plasma sprint was more codey than designey, but definitely improved usability.

The Usability & Productivity initiative isn't just about design and user interfaces; that's only the "Usability" part. "Productivity" definitely includes efficiently accessing, saving, and streaming files from remote locations--particularly Samba shares, which are ubiquitous in the business and professional worlds. This is a major pain point that I hear about over and over and over again from our users, and experience myself.

I'm a bit confused as to the intention of this sprint. The people commenting on T6831 this is a sprint for are all designers and usability people. This list of goals is effectively an extreme very low-level KIO bug sprint.

It's usually pretty hard unfortunately :/

Any chance these could be streamed or recorded for those who can’t attend? Or is a sprint too chaotic to capture effectively?

Under the subheading of "Documentation", can we discuss code commenting? And ideally - encourage it? The API docs are good and generally well-maintained, but inside the applications themselves, the quantity and quality of code comments varies quite a bit. Some of our products are quite large and use many of the Frameworks together. It can be daunting at times to decipher how a block of code works and why it was constructed in the way it was.

In T6832#136906, @neofytosk wrote:

And more about bugzilla's usefulness here:
https://mail.kde.org/pipermail/kde-community/2018q1/004274.html