Re: (Contributing)
On 07/15/20 00:47, 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. Hello Ayush, thank you for considering to contribute! I suggest to start here: https://community.kde.org/Get_Involved If you indeed want to help with C++ coding, your first steps would be to learn Qt and how to compile KDE applications. If you are familiar with Java's Swing, then Qt will be very easy to learn. https://community.kde.org/Get_Involved/development Please also set a subject next time you a writing a mail. Christoph Feck
Beginner-friendly projects
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. -- Christoph Feck
Re: Issues with the issue tracking system
Hello Philippe, let me only correct one of your claims: On 11/04/19 02:11, Philippe Cloutier wrote: As for the more delicate issue, many reports I filed recently against bugs.kde.org were mishandled. In fact, most of them were, and that is all due to one individual's actions. This can be seen below: The bug triaging team has several individuals. Myself, I can only spent some hours per week to go through bugzilla mails, and cannot comment on all new tickets filed. But I do read all mails that are incoming. When a bug triager resolves an issue, I quickly review their actions, and if there is anything wrong with it, I try to correct it, or add a comment. I can imagine that I am not the only triager that reads those conversations. If anyone in the community would disagree with the actions by bug triagers, I would expect them to intervene. This has happened in the past, and will also happen in the future. So please don't finger-point to individual members in the community unless you were talking to them only in private. With the open discussion threads we have on bugzilla, you can be sure that many others in the community will follow the discussion and review the actions made there. If there was anything wrong with the actions made by individuals from the bug triaging team, be assured that others would join the discussion or correct the actions. Additionally, you might have noticed that system administrators have removed themself from most of the discussion threads you referenced, because they don't see the need (or don't have the resources) to address the issues you described, if they can be seen as issues at all. -- Christoph Feck KDE Bug Triaging Team
Re: Invent/gitlab, issues and bugzilla
On 07/03/19 07:31, Jean-Baptiste Mardelle wrote: Having used gitlab issues quiet a lot in the last months for Kdenlive, I think it would be sad to completely disable them. Making them accessible to project members/developers only seems like a good compromise. I like to use them as a development coordination tool, and for us it's a good replacement for phabricator's boards. I also find them more intuitive to use than phabricator, referencing an issue in a commit is as simple as putting #issue_number, while I never manage to reference or close phabricator tasks/diffs from commit messages despite checking the online doc (but that's probably my fault so not a real argument)... Do our hook recognize a keyword to automatically close github issues? It would be nice if developers used a standard notation that is parsable by our scripts for automated change logs. -- Christoph Feck KDE Bug Triaging Team
Re: Shutdown of paste.kde.org
On 03.02.2019 18:10, Ben Cooksley wrote: Pastebins are generally regarded as transient / temporary, so depending on the settings specified by the users the pastes in question are likely already gone. How long are pastes on phabricator or invent kept? paste has a combobox to choose, but I did not see it on the other sites. Christoph
Re: Closing NEEDSINFO bugs after 30 days
On 16.11.2018 14:31, Alexander Potashev wrote: You only considered to case when human sets NEEDSINFO. If NEEDSINFO is set by a script, we may have the same problem, would you suggest implementing the same behaviour? How would a script know what information is needed to further investigate an issue?
Re: Policy on stale bugs (was Re: Closing NEEDSINFO bugs after 30 days)
On 16.11.2018 12:50, Boudewijn Rempt wrote: -- and worse, it makes me hesitate to put bugs in the NEEDINFO state. Worse. Bugs that never have been in NEEDSINFO seem to automatically get this state after some time of inactivity now.
Re: CI System Reorganisation
On 09.09.2018 10:59, Ben Cooksley wrote: As a followup to my earlier mail sent about 3 weeks ago, i've now transitioned all builds on the CI system over to the folder layout previously described. Builds can now be found in folders following the following structure on Jenkins: / How I can view all of "stable" Applications on a single page? I remember I asked if it would still be possible after the change, but I cannot see a filter or link to get an overview of all builds. Christoph Feck
Re: Improving Bugzilla Status Names
On 05.09.2018 04:28, Andrew Crouthamel wrote: Hello, As part of the "Streamlined onboarding of new contributors" goal from 2017 (https://phabricator.kde.org/T7116), Nate, myself, Julian, and others have been working on ways to clean up Bugzilla, as well as the bug reporting and triaging system in the "Improvements to Bugzilla - Making it easier and simpler" sub-task (https://phabricator.kde.org/T6832). The next item on the list we would like to address is changing some of the names of the Status fields and Resolved sub-fields. This is something that has come up numerous times, but seems to fizzle out without a consensus. The last major discussion regarding it was held early in the year, here: https://mail.kde.org/pipermail/kde-community/2018q1/004395.html. And before that, in this Bug report from Nate (https://bugs.kde.org/show_bug.cgi?id=383753). I've read through these, merging the feedback from everyone and with the team working on T6832 we'd like to propose the following name changes: UNCONFIRMED -> NEW WONTFIX -> ASDESIGNED INVALID -> NOTABUG I still oppose to name a status NEW (again). It only attracts "how is this NEW? this is already [random timespan here] OLD!" comments. There will always be products/components that have no active maintainer to look for bugs in a limited timeframe. My suggestions are OPEN, REPORTED, or UNRESOLVED. -- Christoph Feck
Re: Upcoming reorganisation of the CI system
On 14.08.2018 15:03, Ben Cooksley wrote: Currently CI jobs are all created within a flat namespace, meaning that it is quite difficult to view the overall status of an individual project. Additionally, it creates the issue that the main default view can take a significant amount of time to load. To resolve this we intend to shift everything within Folders in Jenkins. These folders will be structured in the form of Product / Project / Will we still be able to see the status of all Applications (or all Frameworks) without clicking hundreds of subfolders? This is useful to get an overview before doing releases. Christoph Feck
