Change Details

=Motivation= Today KDE's technical activities are very people-powered. People perform code review, people propose formatting changes, people triage bugs, and so on. As a result, a lot of our work is labor intensive and prone to human error. It's also often done by specific individuals who have specialized knowledge, rather than teams with knowledge broadly documented. KDE already has some team-based workflows and documention, and has moved towards some greater automation with changes like pre-commit continuous integration in GitLab, running clang-format across our codebases with git hookscripts, and a bugzilla bot that can automatically close old bug reports. These tools amplify the productivity of individual contributors by reducing manual busywork. But this effort has been sporadic and we can go much further to minimize human error and turbocharge productivity! =Plan= Here are some examples of what we can do: ===Automate everything=== - Make the bugzilla bot detect more problematic bug reports and apply canned replies, to reduce the need for manual bug triaging. - Move clang-format from a git hookscript to pre-commit CI so that merge requests will show a CI failure when badly-formatted changes exist, and people can see this in a nice UI and fix them - Add CI checksfor English spellchecking. - Add CI checks for missing i18n() context markers and text. - When we make a change to our code format policy, enshrine it in clang-format; make it more opinionated so that code style arguments are avoided. - Add a QML linter to detect common errors or omissions in QML code. - Delete or fix tests that have been failing forever to increase the signal-to-noise-ratio. - Continue moving in the direction of uploading crashes to Sentry rather than making users jump through the hoops of submitting bug reports. ===Systematize everything=== - Codify and document the steps required for adequately QAing merge requests. - Create and document an "offboarding" process so that people transitioning away from KDE can hand off their work to any other interested community members, and their knowledge can be preserved. - Change the culture around QA to adopt the mindset of "it's ready when it stops failing, not when it starts working." Encourage merge requests to be thoroughly tested before they are submitted, as well as during the review process. - Create a merge request template like the Bugzilla bug report template which prompts people to do things like write testing steps and make documentation changes alongside any UI changes. - Require that all unit tests in a project pass before merge requests can be merged; tolerate no test regressions! - Expand the scope of what KUserFeedback sends for users who have opted in, so that KDE developers can make more decisions based on metrics rather than gut feelings. ===Rely more on teams and less on individual people's labor=== - Improve developer and internal process documentation to be good enough that contributors can generally answer their own questions rather than asking in real-time chatrooms. Move our specialized knowledge out of our heads! - Create a QA team on invent.kde.org that people can volunteer to join. Encourage projects to make use of the QA team for merge request review. - Create project-specific teams on invent.kde.org for large projects that span multiple repos (e.g. Plasma, KDE PIM, System Settings) and encourage people to join those teams when contributing to their projects. Contributing to KDE should feel like being a member of a group, not an individual feeding inputs into a giant machine. - Encourage people to join the volunteer [[ https://community.kde.org/Gardening | Gardening team ]] and help coordinate the efforts of volunteers and sponsored contributors. - Encourage people to join the volunteer QA team and perform QA on open merge requests to make sure they do what they say they do and don't cause regressions. - I move my "This week in KDE" blog series to KDE infrastructure and open it up to other contributors, standardizing around an open process that has a bus factor greater than 1. - Perform offboarding when you stop contributing to KDE. Don't just vanish without a word! =Risks and needs= Some of these changes are controversial and would require diplomacy and persistence to push past the finish line without upsetting people. Others are technically challenging or complicated and would require buy-in from experienced KDE contributors. =Champion= I'm Nate Graham. From 2018 to 2020, I successfully championed the Usability & Productivity goal, I write the "[[ https://pointieststick.com/category/this-week-in-kde/ | This week in KDE ]]" blog post series, I'm a member of KDE's Gardening team, and I currently perform bug triage and QA on all new Plasma-aligned bug reports and merge requests. In my day job, I'm a QA Manager at [[ https://blue-systems.com/about/ | Blue Systems ]], which is a KDE Patron. In terms of technical contributions, I hack on Elisa and Plasma a lot, [[ https://invent.kde.org/ngraham | but I also do a little bit of everything ]]. =Interest= @ognarb (Carl Schwan) @niccolove (Niccolò Venerandi) @aronkvh (Áron Kovács)

=Motivation= Today KDE's technical activities are very people-powered. People perform code review, people propose formatting changes, people triage bugs, and so on. As a result, a lot of our work is labor intensive and prone to human error. It's also often done by specific individuals who have specialized knowledge, rather than teams with knowledge broadly documented. KDE already has some team-based workflows and documention, and has moved towards some greater automation with changes like pre-commit continuous integration in GitLab, running clang-format across our codebases with git hookscripts, and a bugzilla bot that can automatically close old bug reports. These tools amplify the productivity of individual contributors by reducing manual busywork. But this effort has been sporadic and we can go much further to minimize human error and turbocharge productivity! =Plan= Here are some examples of what we can do: ===Automate everything=== - Make the bugzilla bot detect more problematic bug reports and apply canned replies, to reduce the need for manual bug triaging. - Move clang-format from a git hookscript to pre-commit CI so that merge requests will show a CI failure when badly-formatted changes exist, and people can see this in a nice UI and fix them - Add CI checks for English spellchecking. - Add CI checks for missing i18n() context markers and text. - When we make a change to our code format policy, enshrine it in clang-format; make it more opinionated so that code style arguments are avoided. - Add automatic fuzzing. - Add a QML linter to detect common errors or omissions in QML code. - Delete or fix tests that have been failing forever to increase the signal-to-noise-ratio. - Continue moving in the direction of uploading crashes to Sentry rather than making users jump through the hoops of submitting bug reports. ===Systematize everything=== - Codify and document the steps required for adequately QAing merge requests. - Create and document an "offboarding" process so that people transitioning away from KDE can hand off their work to any other interested community members, and their knowledge can be preserved. - Change the culture around QA to adopt the mindset of "it's ready when it stops failing, not when it starts working." Encourage merge requests to be thoroughly tested before they are submitted, as well as during the review process. - Create a merge request template like the Bugzilla bug report template which prompts people to do things like write testing steps and make documentation changes alongside any UI changes. - Require that all unit tests in a project pass before merge requests can be merged; tolerate no test regressions! - Expand the scope of what KUserFeedback sends for users who have opted in, so that KDE developers can make more decisions based on metrics rather than gut feelings. - Unify our release tooling so that we can have one release team with many members that is technically capable and knowledgeable about how to release anything. - Encourage apps to join KDE Gear and adopt its version numbering schema, so that they don't have to be self-released. ===Rely more on teams and less on individual people's labor=== - Improve developer and internal process documentation to be good enough that contributors can generally answer their own questions rather than asking in real-time chatrooms. Move our specialized knowledge out of our heads! - Create a QA team on invent.kde.org that people can volunteer to join. Encourage projects to make use of the QA team for merge request review. - Create project-specific teams on invent.kde.org for large projects that span multiple repos (e.g. Plasma, KDE PIM, System Settings) and encourage people to join those teams when contributing to their projects. Contributing to KDE should feel like being a member of a group, not an individual feeding inputs into a giant machine. - Encourage people to join the volunteer [[ https://community.kde.org/Gardening | Gardening team ]] and help coordinate the efforts of volunteers and sponsored contributors. - Encourage people to join the volunteer QA team and perform QA on open merge requests to make sure they do what they say they do and don't cause regressions. - I move my "This week in KDE" blog series to KDE infrastructure and open it up to other contributors, standardizing around an open process that has a bus factor greater than 1. - Perform offboarding when you stop contributing to KDE. Don't just vanish without a word! =Risks and needs= Some of these changes are controversial and would require diplomacy and persistence to push past the finish line without upsetting people. Others are technically challenging or complicated and would require buy-in from experienced KDE contributors. =Champion= I'm Nate Graham. From 2018 to 2020, I successfully championed the Usability & Productivity goal, I write the "[[ https://pointieststick.com/category/this-week-in-kde/ | This week in KDE ]]" blog post series, I'm a member of KDE's Gardening team, and I currently perform bug triage and QA on all new Plasma-aligned bug reports and merge requests. In my day job, I'm a QA Manager at [[ https://blue-systems.com/about/ | Blue Systems ]], which is a KDE Patron. In terms of technical contributions, I hack on Elisa and Plasma a lot, [[ https://invent.kde.org/ngraham | but I also do a little bit of everything ]]. =Interest= @ognarb (Carl Schwan) @niccolove (Niccolò Venerandi) @aronkvh (Áron Kovács)

=Motivation= Today KDE's technical activities are very people-powered. People perform code review, people propose formatting changes, people triage bugs, and so on. As a result, a lot of our work is labor intensive and prone to human error. It's also often done by specific individuals who have specialized knowledge, rather than teams with knowledge broadly documented. KDE already has some team-based workflows and documention, and has moved towards some greater automation with changes like pre-commit continuous integration in GitLab, running clang-format across our codebases with git hookscripts, and a bugzilla bot that can automatically close old bug reports. These tools amplify the productivity of individual contributors by reducing manual busywork. But this effort has been sporadic and we can go much further to minimize human error and turbocharge productivity! =Plan= Here are some examples of what we can do: ===Automate everything=== - Make the bugzilla bot detect more problematic bug reports and apply canned replies, to reduce the need for manual bug triaging. - Move clang-format from a git hookscript to pre-commit CI so that merge requests will show a CI failure when badly-formatted changes exist, and people can see this in a nice UI and fix them - Add CI checks for English spellchecking. - Add CI checks for missing i18n() context markers and text. - When we make a change to our code format policy, enshrine it in clang-format; make it more opinionated so that code style arguments are avoided. - Add automatic fuzzing. - Add a QML linter to detect common errors or omissions in QML code. - Delete or fix tests that have been failing forever to increase the signal-to-noise-ratio. - Continue moving in the direction of uploading crashes to Sentry rather than making users jump through the hoops of submitting bug reports. ===Systematize everything=== - Codify and document the steps required for adequately QAing merge requests. - Create and document an "offboarding" process so that people transitioning away from KDE can hand off their work to any other interested community members, and their knowledge can be preserved. - Change the culture around QA to adopt the mindset of "it's ready when it stops failing, not when it starts working." Encourage merge requests to be thoroughly tested before they are submitted, as well as during the review process. - Create a merge request template like the Bugzilla bug report template which prompts people to do things like write testing steps and make documentation changes alongside any UI changes. - Require that all unit tests in a project pass before merge requests can be merged; tolerate no test regressions! - Expand the scope of what KUserFeedback sends for users who have opted in, so that KDE developers can make more decisions based on metrics rather than gut feelings. - Unify our release tooling so that we can have one release team with many members that is technically capable and knowledgeable about how to release anything. - Encourage apps to join KDE Gear and adopt its version numbering schema, so that they don't have to be self-released. ===Rely more on teams and less on individual people's labor=== - Improve developer and internal process documentation to be good enough that contributors can generally answer their own questions rather than asking in real-time chatrooms. Move our specialized knowledge out of our heads! - Create a QA team on invent.kde.org that people can volunteer to join. Encourage projects to make use of the QA team for merge request review. - Create project-specific teams on invent.kde.org for large projects that span multiple repos (e.g. Plasma, KDE PIM, System Settings) and encourage people to join those teams when contributing to their projects. Contributing to KDE should feel like being a member of a group, not an individual feeding inputs into a giant machine. - Encourage people to join the volunteer [[ https://community.kde.org/Gardening | Gardening team ]] and help coordinate the efforts of volunteers and sponsored contributors. - Encourage people to join the volunteer QA team and perform QA on open merge requests to make sure they do what they say they do and don't cause regressions. - I move my "This week in KDE" blog series to KDE infrastructure and open it up to other contributors, standardizing around an open process that has a bus factor greater than 1. - Perform offboarding when you stop contributing to KDE. Don't just vanish without a word! =Risks and needs= Some of these changes are controversial and would require diplomacy and persistence to push past the finish line without upsetting people. Others are technically challenging or complicated and would require buy-in from experienced KDE contributors. =Champion= I'm Nate Graham. From 2018 to 2020, I successfully championed the Usability & Productivity goal, I write the "[[ https://pointieststick.com/category/this-week-in-kde/ | This week in KDE ]]" blog post series, I'm a member of KDE's Gardening team, and I currently perform bug triage and QA on all new Plasma-aligned bug reports and merge requests. In my day job, I'm a QA Manager at [[ https://blue-systems.com/about/ | Blue Systems ]], which is a KDE Patron. In terms of technical contributions, I hack on Elisa and Plasma a lot, [[ https://invent.kde.org/ngraham | but I also do a little bit of everything ]]. =Interest= @ognarb (Carl Schwan) @niccolove (Niccolò Venerandi) @aronkvh (Áron Kovács)