//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 probably key here, particularly those that recently joined, to gain a better insight and overview of the situation.
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.
=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
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.
==//Specifically on new coding contributors and bugzilla//==
Our new contributor experience is not as accessible as it could be. Documentation is often out of date, phabricator can be intimidating, bugzilla doesn't offer any guidance on how to file good bugs or direct people to put patches on Phabricator.
As a result, users file a lot of un-actionable bugs that waste our time and frustrate them when they are closed; many enthusiastic and competent programmers don't contribute; and patches on bugzilla frequently languish forever. We should work on guiding new potential contributors.
==What it will take=
- Improve documentation regarding how to check out and compile sources, how to set up a good dev environment, etc.
- Add project-specific templates to the description field for new Bugzilla bugs that gives users information they need to solve their own issue or provide the information necessary for us to actually triage the bug (see https://bugs.kde.org/show_bug.cgi?id=383169)
- Collapse the UNCONFIRMED and CONFIRMED statuses into NEW to avoid confusion
- Change the WONTFIX and INVALID statuses to something a bit softer so that users who have their bugs closed with these statuses don't feel negative emotions toward it and us
- Change the attachments page to notify users that patches should be submitted to Phabricator instead, along with a link to a how-to page
==How we know we succeeded=
- Bugzilla bugs won't have patches in them that fall by the wsyside
- The volume of un-actionable bugs will slow dramatically and there will be less back-and-forth between developers and users, freeing up bug-triaging resources and turning them into development resources. Bugs will be more valid, better tracked, and not pile up forever
- More bugs will be accompanies by patches on Phabricator
- We'll get more new contributors submitting patches on Phabricator
- Bugzilla should use a standard template: https://bugs.kde.org/show_bug.cgi?id=383169
- KDE Bugzilla should use resolution statuses little softer than INVALID and WONTFIX: https://bugs.kde.org/show_bug.cgi?id=383753
=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)
==I am interested==
Adrián Chaves (@adrianchavesfernandez)
Jeff Huang (@s8321414)
Gregor Mi (@gregormi)