Thanks so much, @acrouthamel. That list looks sane to me. Anyone else wanna spot-check it?
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Sep 4 2018
Ok, I've reviewed the prior list. I've done the following for each product:
- Check Bugzilla for age of any remaining bugs
- Check Git and SVN for age of commits (not created by automated systems)
- Check KDE Wikis for information about unmaintained or obsolete status
- Check Google/DDG for information about unmaintained or obsolete status
- Closed any open bugs left lingering in an unmaintained, dead product.
- Used gut instinct on any that may still be used, removing them from the list
Aug 30 2018
In T6895#157200, @helderc wrote:@filipesaraiva Are you still here in USP/Sao Carlos? I'm PhD student here...
Ok I'll go through the lists later and get you a definitive one.
@helderc Yes, we still do mentorship programs!
We regularly participate as a mentoring organization in Google Summer of Code, and we have our own mentoring program called Season of KDE ( https://season.kde.org ).
Apart from that, I'm sure the Kile team qill alo be happy to help if you jump on their mailing list.
In T6832#157774, @colomar wrote:I'm not sure about removing them from Advanced Search, because then people could not find old bugs from them if they are looking for them e.g. for hints towards fixing a similar bug.
In T6832#157770, @ngraham wrote:Beyond that, it might be a useful change to have products that are closed for new bugs also be invisible on the Advanced Search and Browse lists. This isn't something I can do, and would probably be a sysadmin request. Can you contact sysadmins about that?
I have bugzilla admin powers and can make some of these changes. However I'd prefer to take it slowly and conservatively, so we can avoid any issues.
This would probably have to be done by the KDE Sysadmin team, so we should probably forward this list to them. Right now I am a bit concerned that not everybody might be content with the decision to simply remove all of those from Bugzilla... But then again, all products that would be deleted are unmaintained and the big majority does not have a single bug reported against the product.
Do we have any traction on moving forward with removing these products? Or at least closing them out? What's the next steps?
Aug 27 2018
Aug 16 2018
I would stepup for planing such a sprint.
I've a place in mind in France near Grange Neuve, but I have to find the flyer with the correct name...
I think about doing the print next spring.
Aug 7 2018
Hi @dkazakov, it's great that you are interested and I'm sure your experience would be valuable.
I cannot attend the Akademy this year, but I would really like to join the Autumn sprint. I work on Krita project and I could make a short talk about my experience in working with a university and trying make students involved into our project.
Aug 2 2018
Thanks for responding everyone!
Aug 1 2018
Jul 26 2018
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.
Jul 25 2018
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.
Jul 9 2018
Jul 3 2018
Thanks @sandroandrade , I 'll reach out to the author and try to get some first hand insight on mozilla's procedures and experience.
Jun 28 2018
Some insights that may be useful for our onboarding goal.
Jun 13 2018
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 :)
Jun 11 2018
Jun 9 2018
Jun 8 2018
Jun 3 2018
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.
May 27 2018
May 25 2018
@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.
May 24 2018
May 23 2018
May 21 2018
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/
May 20 2018
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:
- Is the product not marked as "unmaintained"/"deprecated"/"replaced"?
- Is the product in the repositories of Ubuntu LTS?
- Is the product on cgit.kde.org?
- 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?
May 19 2018
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:
- Is the product not marked as "unmaintained"/"deprecated"/"replaced"?
- Is the product in the repositories of Ubuntu LTS?
- Is the product on cgit.kde.org?
- 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?
May 17 2018
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.
May 16 2018
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.
May 15 2018
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!
May 14 2018
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 .
May 13 2018
We should definitely do something during Akademy but I don't think it should and can replace the sprint.
May 12 2018
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).