//Merged with T6832 authored by @ngraham//
Getting people involved is vital for the long term sustainability of a project and its continuous development and growth. Of equal importance is for new contributors to find an environment in which they can thrive and a community and project which they can be part of for a long time.
KDE is a big organization of hundreds of contributors working on dozens of projects. Even though documentation exists on the basics of getting involved, this is sometimes incomplete, outdated, or impersonal. It can be difficult and overwhelming for a newcomer to feel comfortable and confident enough to step up and get more involved without knowing the related context, balances, relationships etc.
The KDE Community can do more to facilitate this, by motivating and nurturing involvement. We can be more proactive and effective, both in attracting new contributors, as well as in making them feel welcome and valued in the community and the projects they show interest in working on.
=What it will take=
We will need to form a team that will try and understand the current status of the requirements and expectations for getting involved and gain a good overview of the processes in play. This team will have to hold or acquire good knowledge of KDE’s community and projects, as well as of how current contributors are intra- and inter-connected among them.
Holding discussions/interviews with current contributors is key here, both with people that recently joined as well as with individuals that have been around for a while , to gain a better insight and overview of the situation. Surveys could also prove useful.
Questions that we should be aiming at answering may include:
- What are the possibilities for involvement (teams and projects, tools used, skills required)?
- What are the available resources in terms of people and time that can be invested in this effort?
- Are we making the most out of available potential of people interested in contributing?
- Can some onboarding procedures be identified as essential?
- Can we direct contributors towards areas that KDE could use more contributors in?
- Are all the possibilities and pathways for getting involved properly documented and visible/reachable on the website?
- To what extend are valuable resources spent on helping/training people that end up not joining the project or not making long term contributions?
- What are the feelings of both new and older contributors in regards to the procedures of getting involved? What did they enjoy, what did they not like, what kept them around, what could we improve?
The next step is to propose a plan for attracting and integrating newcomers into the community. This will largely depend on the outcome of the research.
I assume that the forming of a dedicated team of contributors might be needed, which would be responsible for:
- Welcoming and introducing newcomers to the community and procedures, by taking in mind their skills, interests and experience.
- Actively supporting newcomers’ involvement until they are fully engaged with their projects and integrated with the community in both a micro and macro level.
- Monitoring new contributors’ progress and satisfaction.
- Identifying contributors within each KDE team that are willing to act as the first port of call and mentor newcomers. Provide these mentors with guidelines on getting people involved based on KDEs principles, values and workflows.
- Holding events (could very well be online) targeted at newcomers where they can be informed, ask questions, participate in discussions, or even get a chance to get their hands dirty with some tasks.
- Collapse the UNCONFIRMED and CONFIRMED statuses into a new status "NEW" to avoid user confusion ("Why isn't this confirmed after 7 years and 5 duplicate reports!?").
- Mine other projects' Bugzillas for ideas regarding additional or replacement statuses we can add, particularly for closed tickets. Examples from other projects include NOTABUG, NOTOURBUG, NOTGNOME, ASDESIGNED, CANTFIX. https://bugs.kde.org/show_bug.cgi?id=383753
- New Bugzilla tickets should have a default template explaining how to file a good bug, what kind of information is required, and mentioning that patches should be submitted to Phabricator and not attached to the bug. https://bugs.kde.org/show_bug.cgi?id=383169
- Each project can override the standard template with a project-specific one that can list additional information needed, and even offer information about common bugs that don't need to be re-reported and workarounds for common issues.
- Change the attachments page to notify users that patches should be submitted to Phabricator instead, along with a link to a how-to page
- Bug screeners who identify reporters of above-average technical competence should encourage them to dig into the code and submit patches on Phabricator.
- Make sure that the "how to contribute" pages on the top-level of kde.org are fully up-to-date
- Closely document a "minimum viable product" approach to producing a user's first patch. We should aim for this process to be as painless as possible.
- Improve documentation regarding how to check out and compile sources, how to set up a good repeatable dev environment, etc.
- Document the process of becoming a KDE bug screener, along with helpful information
- Improve documentation for how to translate strings
=How we know we succeeded=
//Quantitative statistics and qualitative feedback can act as indicators.//
An increase should be observed over time in the number of:
- People showing initial interest
- People ending up getting involved
- New contributors that stay around for the long-term
- Actionable bugzilla tickets
- Phabricator patches from first-time submitters
New contributors and mentors should report higher levels of satisfaction with the related procedures and acknowledge a positive effect as a result of our efforts.
The sense of community should increase between the first days someone gets involved and after some time has passed.
=What are the risks?=
The obvious risk here is spending valuable resources of current contributors without any tangible outcome for the KDE community and its projects.
Yet, even if we fail to deliver changes, KDE will have gathered a lot of useful feedback about the current status of the community and its procedures.
==//For Application Developers//==
At Akademy 2017, @ervin and @dfaure talked about making it easy for newcomers to build and test Applications. They discussed removing the need for make install and implementing solutions around conan.io and flatpak.org. Detailed summary, video and slides can be found here:
==//For financial contributors//==
Consider the use of Patreon/Liberapay
=I am willing to put work into this=
Neofytos Kolokotronis (@neofytosk)
Nate Graham (@ngraham) - writing and deploying documentation and the new Bugzilla template and statuses
Ivana Isadora Devcic (@skadinna)
Vijay Krishnavanshi (@vijaykrishnavanshi)
Łukasz Sawicki (@Lucas)
Elvis Angelaccio (@elvisangelaccio) - writing/updating docs (Wiki/Apidox)
John Samuel (@jsamuel) - writing/updating docs (Wiki) and updating external sites like Wikidata
Paul Brown (@paulb) - writing/updating docs, working on upgrading usability and friendliness of sites and protocols.
Adrián Chaves (@adrianchavesfernandez)
Matija Šuklje (@hook) - anything FLA, contributor agreement or licensing related
==I am interested==
Jeff Huang (@s8321414)
Gregor Mi (@gregormi)