Description
There seem to be some features that are broken and other many important problems for productivity that remains unresolved for years. Many underlying questions must be assessed to move forward in a efficient way that both empowers users to submit bug and features request as well as pooling the KDE community to address those.
This is not about how to do prioritizing, it's more about the relation between the user community and the developers. This proposal is about exploring the process of how to organize the information so the developers can have a global vision of what are the needs of the users as well as which bugs are affecting them and if possible in what proportion and gravity. The objective is to optimize the process of bug submitting, tracking (& summarizing), discussing and solving.
Examples
- This is an unsolved problem since 2004 (https://bugs.kde.org/show_bug.cgi?id=75324) and today, 2019, is still not solved. so still is a headache for any Linux user to work everyday in a LAN easily, with flexibility and without issues.
- Something working perfectly that have been broken when Plasma arrived (https://bugs.kde.org/show_bug.cgi?id=351175). The issue is notified en 2015. Still the functionality is not fixed.
What it will take
- Reorganize KDE ecosystem T11051
- Provide good documentation T11096
- Provide up to date tutorials on setting a KDE development environment and some examples of bug fixing that a beginner programmer can rely on to debug/fix his problems
- Have a section to monitor and centralize KDE development and road-maps
- Add a road-map with bugs and features for individual applications and KDE general goals
- Have blogs.kde.org promote different stories of bug fixing for users and developers to share their experience and the critical thinking behind the choices made
- Provide ways to put bounty for certain fix/features requested by users to encourage developers
- Provide ways for developers to request help planning fix/features from more senior colleagues so they can work in an efficient way and coordinate with other projects
Reflect on :
The multiple levels of implications for the statement Solve important long term problems better than add new features
- Are the LT problems well documented ? Where/how are they documented ?
- Do the well documented problems reach the developers/maintainers/community coders ?
- Is there sufficient gravity/coverage of the problem to have it solved quickly ?
- Is there a screening mechanism to prevent flooding developers with low gravity or unreal problems so they can put their energy at the right place ?
- Is there sufficient documentation/standardization to empower users to make their own fix and submit it ?
- Is there a standardized way to submit bugs/features/code shared by all KDE applications ?
- Are there solutions/code submitted that don't make it to the master and why would that happen ?
- Are the coding guidelines generalized for all KDE applications, simple and well publicized for new contributors ?
- Is the problem easy to solve or requires a rethinking of major parts of the application ?
- How is it addressed ? Does the main developer have the technical skills and knowledge to address it and/or is it outside of his work (ex: external library, KDE framework) ?
- Does the problem require collaboration with other KDE application or external projects ?
- How/where should communication be done for those situations ? How to keep track and backlog for future reference ?
- Are there other KDE application that could benefit of this work ? How should the collaboration be established in that case or even let known to others KDE developers ?
- Is there a way to follow what is being worked on and mark what's to be done ?
- Can the complicated marked problems be noted down and queued for solving in the next big iteration of the application ?
- Is there sufficient motivation/workforce to solve the problems ?
- Are the new features addressing a real need, fixing old problems or just adding new whisles and bells ?
How we know we succeeded
- Better communication between user community and development community
- Better tracking of problems, features, their priority and their current status
- Provide a road-map for features and bug fixing for each KDE application
- Integrate road-map of single application with other applications and KDE goals like T11093
Relevant links
<any links that will help people find more information and understand the goal better>
I am willing to put work into this
- add your name
I am interested
- add your name