Streamlined onboarding of new contributors
Open, Needs TriagePublic


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.

Specific ideas:


  • 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.
  • 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.
  • 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 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.

Related Links

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 and 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.
Matija Šuklje (@hook) - anything FLA, contributor agreement or licensing related
Aleix Pol (@apol)

I am interested

Jeff Huang (@s8321414)
Gregor Mi (@gregormi)
Adrián Chaves (@adrianchavesfernandez)
Ken Plaha (@Kalpha)

There are a very large number of changes, so older changes are hidden. Show Older Changes

@colomar Thank you for the link! This is sounds like a plan! Communicating this information - when ready - should be done using the methods mentioned in #114484

+1 for Patreon/Liberapay page.

KDE looses contributors because of large gap between joining the community and making any actual contribution. To overcome this situation we can do two things

  • Reduce this gap by improving the documentation and resources ( this will take more time and more contributors and discussed already in better way )
  • Break down this gap in levels like making challenges with increasing skill requirements that can help new contributors to evolve and develop. It will eventually lead them to make contributions to projects and explore them in a better way after they are familiar with the infrastructure. This will also give goals to new contributors to achieve thus making their learning non monotonous which it currently is in most cases. Yes we will need team to handle it and more research.

Another place where we can focus our efforts is on encouraging other fields other than development to make contributions like by design sprints or awareness sprint. This is the point by which we can preserve the diversity of KDE or eventually get more contributors.

neofytosk updated the task description. (Show Details)Oct 23 2017, 4:11 PM
neofytosk updated the task description. (Show Details)Oct 23 2017, 11:05 PM

Lots of great suggestions here, I will try to add the ideas from the comments and the video asap. Of course, feel free to edit the initial post directly and include them yourself. =)

januz added a subscriber: januz.Oct 24 2017, 1:18 AM

Some ideas from a n00b contributor:

  • Why not use phabricator for bugs? You can make custom forms to make sure users add the right info (link). Phab can be complicated, but it's a lot more user-friendly than bugzilla (at least IMO!)
  • Promote Kdevelop as "the standard KDE IDE" (or something like that). I know you might want to keep things open and not push for K apps, but it's very useful to have a reference IDE or application to get started. Kdev supports all languages and build systems used in KDE, and it can fetch projects just by clicking them from a list. I recently worked on a patch for Syntax Highlighting in Frameworks and kdev made it really easy. The _fetch project_ option downloaded the repo and setup the project for me, all I had to do is make my changes and click _Build_ to start testing.
  • Put things together in one place. Eh, I know it sounds vague :), but what I mean is that documentation, resources, links, etc. for a certain project should be grouped in at least one single place. For instance: you can find a mockup kit in the VDG forums, links to the telegram groups in the wiki, some more (outdated) info in, the current projects somewhat scattered here in phab and the HIG also in the wiki. Keeping up with the current projects, what to contribute, how to communicate is all kind of involved when information is spread like this.
  • Step by step, complete and up-to-date information on the technical parts of contributing. This could be organized like a book, with different chapters: "How to add translations", "How to contribute code", etc.
  • Some documentation on community customs. This can be a loose page, or a pinned forum post. I'm talking about things like who to tag when contributing a patch, where to ask for feedback, or little bits like how adding "BUG: ###" in a diff summary closes a bug in bugzilla.
  • Liven up the forums. There are lots of great ideas there but they often get no replies or a few "+1"s. I think Improving the usability of the forums and having discussions (for development and design) there would bring in a lot of contributors.

Sorry if this is too specific for this task!

gregormi added a comment.EditedOct 27 2017, 4:51 PM

For me as an occasional code contributor, I notice that I find it especially tedious to get a proven local runtime environment ready for local testing of non-trivial programs. For example, this tutorial describes which environment variables should be set for this purpose. Quite a few and I am not sure if all entries are still valid. I guess every developer ends up with his/her own script or scripts to handle this issue (including having some convenience message on the bash prompt showing if the correct variables are set). Maybe this could be extracted to a maintained and standardized script that can be used anywhere where Qt/KF5 based-programs are developed. The script and a guide how one would use it in combination with Kdevelop (or automatic integration with the Launch > Environments) could facilitate getting started.

Lucas updated the task description. (Show Details)Oct 27 2017, 7:16 PM
Lucas added a subscriber: Lucas.
neofytosk updated the task description. (Show Details)Oct 29 2017, 9:53 PM
neofytosk added a subscriber: dfaure.

Hope it's OK if I slide in with some last-minute suggestions.

All the points raised so far are great and worth discussing. I'll highlight a few that I find particularly important.

To improve onboarding of new contributors, we need to:

  • provide centralized, up-to-date information on how to contribute. We already have the wiki, so there's no need to look for another platform. We just need to dedicate some time to collecting, updating, and organizing the resources.
  • put together a list of people that new contributors can contact when they need help. Basically, a list that defines "who is who", or rather, who does what in the community. This list should also include mentors/"Onboarding Officers".
  • be very straightforward and clear with what we expect from new contributors. If there are some unwritten rules or implicit expectations in the community, they need to be made explicit and known to new contributors. For example, if there's a person who needs to be notified of new pull requests, or if things need to be done in a certain order. Long-term contributors know these things and might take them for granted, but newcomers have no way of knowing this. They can inadvertently "do things wrong", which can cause resentment and create a rift between the "elders" and the "newbies".

More things we could do:

+ if there is enough interest and support, maybe we can organize live workshops and sprints in different countries where mentors can work more closely with one another and with new contributors. Fedora does a great job with Flock, which is something we could take inspiration from.

+ revive Junior Jobs, or start something similar. There's a page for this on the wiki, but it mostly seems dead. Every project that needs new contributors should have an easily accessible list of simple tasks for first-timers.

+ highlight the benefits of contributing to KDE. This is important as it can help attract those potential contributors who are still hesitant about investing their time because of that eternal question "what's in it for me?". This is connected with the next point, which is...

+ promote opportunities for new contributors. This is something that KDE Promo can help with, whether it's by writing stories on how to start contributing, or sharing the benefits and experiences of new contributors on social media.

+ create different contributor personas based on research/interviews to predict and build diverse and inclusive contributor paths. For example, Kim is a second-year UX/UI student who wants to help improve KDE's websites. Sena is a full-time Python developer who wants to help build educational software for children with disabilities.

We can then come up with a flowchart for each persona - where they should start, who they need to contact first, how to introduce themselves, which tools to use and how to set them up, etc. - and put those flowcharts into a guidebook for mentors. That way, the mentors will always have a consistent, standardized resource to rely on when helping new contributors.

In the end, the way I see it is that every new contributor should be able to:
1) easily and quickly find all the resources,
2) understand who to contact when they need help,
and 3) feel welcomed and supported by the community members.

We achieve 1) by updating and creating high-quality, reliable documentation, 2) by maintaining a list of people and their responsibilities, and 3) by assigning mentors and clearly stating our expectations and "rules" for new contributors, as well as the benefits of contributing to KDE.

ervin added a comment.Oct 30 2017, 6:53 AM

I'll sound like a broken record but: if we don't solve the "how difficult it is to build something and patch it" *first* all the nice things mentioned here with mentoring etc. (which require people we don't have BTW) won't get us far. People will try, fail immediately because it's too hard and leave again.
Seen that enough with my students the past few years.

In T7116#116225, @ervin wrote:

I'll sound like a broken record but: if we don't solve the "how difficult it is to build something and patch it" *first* all the nice things mentioned here with mentoring etc. (which require people we don't have BTW) won't get us far. People will try, fail immediately because it's too hard and leave again.
Seen that enough with my students the past few years.

I was writing from the perspective of a non-coding contributor (we want to attract those too, right? They also matter.), as I don't have a lot of insight into the actual coding and development processes.
But I agree that the problem you mentioned is a huge one, and I understand it should have priority.

ervin added a comment.Oct 31 2017, 6:58 AM

Ah my apologies, I thought the goal here was to capture the whole spectrum of contributors. Of course if the goal was to focus on non-coding contributors then this is fine.

Perhaps it should just be made clearer where the focus is or perhaps I should learn to read better if I missed the info (very likely it's about the latter). :-)

neofytosk added a comment.EditedOct 31 2017, 12:17 PM

The ambitious goal here is to improve the onboarding process for all types of contributors. If we succeed, everyone interested in contributing to KDE should have a clear and supportive path to follow. Of course coders are at the heart of KDE and what it does and lots of this work will inevitably go into that. The way I see it, "making it easy to build something and patch it" should be the case/aim for all types of contributions. =)

Problems like attracting/maintaining new contributors might have many aspects

  • Lack of awareness/popularity?
  • Complicated procedures involved?
  • Inefficient treatment/mentoring of people?
  • Failure to make the most of the available resources?

Depending on the problem identified for each path (developers, documentation, translation, marketing etc), we can then work towards a solution.

neofytosk updated the task description. (Show Details)Oct 31 2017, 12:20 PM
neofytosk updated the task description. (Show Details)
ngraham updated the task description. (Show Details)Nov 3 2017, 1:07 AM
elvisangelaccio added a subscriber: elvisangelaccio.
jsamuel updated the task description. (Show Details)Nov 6 2017, 6:50 PM

Thanks everyone for helping draft this proposal. The voting has started. If you are an active KDE contributor and have not received an invitation to the vote please send me an email to

lydia added a comment.Nov 27 2017, 7:56 PM

Congratulations! This task is among the 3 selected ones to focus on for the next 3 to 4 years. It will need all hands on deck to make it reality. If you can help please add yourself to the list in the goal description.

One thing that i have noticed from my project is that non kde people try to often help via the github fork . We should maybe find a way to work with PRs made via Github. Submiting a Pr then having it autoclose and told go make an account here and get anarchist and do your commit this way , then your github name (or email) is not ok because it usually just a nickname this now creates a git configuration burden to fix before contrubiting.

es20490446e added a subscriber: es20490446e.EditedNov 28 2017, 10:15 PM

This is the goal that will have the best positive outcome: easy for everybody, powerful on request.

And this is the technique for that:
"Show only what's used right now, or constantly, hide everything else."

Reducing inventory exposes problems. So lest have only as little as possible by default, only what most people would be using, and let freely add when requested.

paulb updated the task description. (Show Details)Nov 29 2017, 12:24 PM
paulb added a subscriber: paulb.

There is now one item on Wikidata that documents and links all KDE applications on Wikidata. Click on any KDE application (especially if you are the developer) and contribute by improving it. Several key information has already been added. Thanks.

There is now one item on Wikidata that documents and links all KDE applications on Wikidata. Click on any KDE application (especially if you are the developer) and contribute by improving it. Several key information has already been added. Thanks.

It should be fixed and make it more clear though. The wikipedia article associated to that item is about the "KDE Applications" bundle, not *all* applications by KDE.

So only applications part of the bundle should be linked from that object, and not others outside the bundle (like Krita, partitionmanager, Calligra, etc).

There is now one item on Wikidata that documents and links all KDE applications on Wikidata. Click on any KDE application (especially if you are the developer) and contribute by improving it. Several key information has already been added. Thanks.

It should be fixed and make it more clear though. The wikipedia article associated to that item is about the "KDE Applications" bundle, not *all* applications by KDE.

So only applications part of the bundle should be linked from that object, and not others outside the bundle (like Krita, partitionmanager, Calligra, etc).

Thanks @ltoscano. But is there a way to check whether an application is part of the bundle or not? Reference: includes Krita, Calligra.

Thanks @ltoscano. But is there a way to check whether an application is part of the bundle or not? Reference: includes Krita, Calligra. is the list of all applications by KDE, and I just removed as reference from that wikidata object. Check the release notes of each release of KDE Applications.
I took the liberty of removing the link to the "List of KDE applications" page too and update the description of the wikidata object.

aacid added a subscriber: aacid.Dec 3 2017, 11:30 AM
hook updated the task description. (Show Details)Jan 2 2018, 8:45 PM
hook added a subscriber: hook.
apol updated the task description. (Show Details)Jan 3 2018, 2:55 PM
apol added a subscriber: apol.

+1 for Junior Jobs!

Doing simple tasks is an enjoyable way to start contributing to a project, we should take advantage of people who want to help but struggle with how to start.

I suggest a deeper integration then just a wiki page ( which is indeed dead:

  1. Top-priority beginner tasks listed in a special block on project pages. Stimulates maintainers to update the lists with up-to-date tasks and get them complete
  2. Blocks are widgets from a dedicated * website that is easily accessible from developer infrastructure and community home. This website contains tasks that can be sorted by difficulty and filtered by projects and required knowledge. If it is possible to have tasks automatically displayed from Phabricator, that's definitely the best (simplifies workflow for everyone).
  3. "Tasks" are not just actions, they also contain contact information and links to docs (luckily, those don't have to be filled per task).

This way newcomers can just pick a task they like and start working on it with all necessary resources at hand :)

matheusm removed a subscriber: matheusm.Jan 3 2018, 4:48 PM

I'm to excited I found this that I'm commenting before having completly read this thread. This topic is very close to an idea I woke up with this morning.

I am a newbie (joined 5 days ago).

Here is a list of things I want/have to learn:

  • C++ as language
  • IDE (KDevelop in my case)
  • Setting up a build environment
  • Fetching code (that's easy, but dependencies are not)
  • Libraries Qt etc.
  • KDE infrastructure
  • git
  • arc
  • communicating (e.g. getting konversation to do what I want)


  • Communicating with people I don't know.
  • Etiquette/Finding the right tone

Human language-wise:

  • Expressing myself concise and precise in a foreign language

I believe my lack of knowledge may be valuable in this context. I'm willing, or better *eager* to help and serve as a "Unit of analysis". Better do that soon before the memory of the pitfalls I fell in fades away.

Going to read this thread fully now.

@michaelh With your goals in mind, you could go to, and see how you manage to get directions from there for what you want to do, and write down what you think is missing, needs improvement, or is awesome as it is, and then provide such feedback here.

Only the next goal matters.

This comment was removed by dkardarakos.
This comment was removed by dkardarakos.
This comment was removed by dkardarakos.
This comment was removed by dkardarakos.

Find below the merged version of previous comments, as requested.

The structure of “how to achieve the goal” as introduced by neofytosk, contains Research, Implementation and Assessment phases, similar to the phases of a software project . In my opinion, a new phase, “Maintenance”, should be added as well. In the past, many similar initiatives started, worked somehow for a limited period of time and stopped (e.g. kde junior jobs, techbase/community documentation sites’ review, bug triaging, etc). Thus, during researching and implementation phases, we need to find and, afterwards, implement the tools needed by maintenance phases so as to make the process durable and well maintained.

From my viewpoint, in terms of streamlined onboarding, we may add an “education” process as well. Manifesto, vision and mission of KDE statements are invaluable resources for such a task. KDE people should by no means act as “teachers” and impose their ideas. Nevertheless, newcomers should feel that they are part of a free software community, a community with certain values about free, open, collaboration, commoning, user rights etc. In software teams, the technical way of thinking as well as outcome/product orientation act as “traps”, letting us forget that great part of the value of a collaborative work is the collaboration itself. We may implement a process to avoid such traps.

KDE is community, it is people. In order to create robust, durable relationships between people, Local Communities may play a significant role. Face to face communication, work on KDE projects together at the same place, disagreeing, fighting, changing our mind and reconciling, improve the quality of a social relationship. In addition, collaborating with and, why not, contributing to other communities that may work on projects at the same place (town, hacker-space, etc) is a perfect antidote to fanboyism.

When a newcomer decides to contribute to a foss project as large as KDE, she/he may have not found out which part of the project fits her/his needs. They may have a strong willing to contribute, but they may not know which team does exactly what, which project is active or obsolete, the technological prerequisites, etc. We may leverage “big data” to serve our purpose. Using software like Apache Solr, Lucene, Mahout (added just as a reference, better may exist or with more compatible licenses) against our valuable data resources (techbase, community, userbase, phabricator, bugzilla, mailing lists, etc) we may index, classify or cluster our content and let the newcomer find out via a google/amazon like search engine (but powered by 100% open source tools) the task she/he likes to work on. Moreover, KDE contributors may be somehow “flagged” as “happy to help newcomer”. So, alongside the project-to-contribute information, search engine may output a list of ready-to-reach KDE people relative to the project. E.g. newcomers may set a search spec like "education c++ language learn" and engine output would be sth like "project: parley, project links: ...., contact points: ....),

I would like to add another todo item to the list: All new contributors (e.g. the ones who committed a patch for the first time within the last year) should get a personal email, asking them to please attend the KDE conference. I think Akademy is an integral part of holding people together. As such, we need to push those a bit who are unsure (I was in this situation myself in 2004).

I think we could obtain the relevant list of contributors from the sysadmins: all accounts that were created since last Akademy.

I think we could obtain the relevant list of contributors from the sysadmins: all accounts that were created since last Akademy.

You don't need sysadmin for that.

svn diff svn:// -r{2017-07-22}:HEAD | grep ^+

mmustac added a subscriber: mmustac.EditedJan 28 2018, 4:39 PM

What about editing the "Get involved" page on as first step?
I am missing an up2date step by step guide to get a working development environment.
Because I really would like to get started.

@mmustac Yup, I've proposed that and already gotten buy-in and permission to do it. Just working on getting my access to change the page.

Is it going to be a redirect to the existing pages? The example of page shown is a bit too much developer-oriented compared to

@ngraham Great to hear that. I will be one of the first to test your explanations if they are also ready for noobs like me :-D And provide my feedback of course.

@mmustac this is done now!

Hi everyone, I feel bad for being quiet over the last couple of weeks. Lots of changes happening in Jan-Feb for me, and also FOSDEM and the KDE Promo sprint are coming up. I'll try to push this goal forward in a consistent way once all these have passed.

I do follow everything related and I've already organized some ideas and plan to start dedicated tasks for each.

My current plan is to hold a sprint for this goal in May, but we need to check what suits most, so I'll open another task for that later on.

I also posted a introductory blog post regarding this goal a month ago which I never shared here:

Do keep the comments and ideas coming, and kudos to those already putting work into this!

Recently, I tried to find out KDE best practices to work with Docbook.

Two findings:

In search of general information for developers I found:

On thing we could use is an official policy regarding whether the stable or master branch is more appropriate for any given patch. Right now it's often not clear for edge cases such as D10651: Fix thumbnail hover icon show-in-fullscreen action. In that patch, a bug was fixed that led to a behavior change. Stable or master? We committed to master to be safe, but it wasn't as clear as we would have preferred.

Kalpha updated the task description. (Show Details)Tue, Mar 13, 6:50 AM
Kalpha added a subscriber: Kalpha.
rkflx added a subscriber: rkflx.Tue, Mar 13, 8:33 PM

As a newcomer and junior-jobs guy, I'm happy to see this initiative being pushed forward by the Top People(tm) of the KDE organization. I've been stumbling my way through a few patches with the help of @rkflx and @ngraham, the latter of which agreed to mentor me in the ways of KDE. Henrik has been patient with me as I learn C++ and has given me a few assignments for Spectacle bugfixing. Nate has been a good guide to the environment and community. I'm sure there are many more like these two out there. Busy people, but willing to share their knowledge and expertise.

If there's more I can do as a newcomer, please ask. If nothing else, I can share what's it been like for me so far, where I've found things easy, and where I've found things difficult, confusing, or intimidating. I'm not young (49 next month), and I'm just learning C++, but I've been a techie and programmer since I was small. I've always wanted to contribute to something open-source, and when I fixed my first bug here at KDE, the feeling was enormous. Knowing my minor fix for the Media Frame plasmoid will ship as part of Plasma 5.13 feels awesome.

But I spent at least a day or two asking around on mailing lists and IRC for "permission" to work on the bug. Someone finally told me I was free to work on anything I wanted. I think that bit of "documentation" is missing, or needs more emphasis. Submitting my code through Phabricator was also a nail-biting experience. I had limited exposure to what a "diff" was, and it was a disconcerting feeling to pull a copy of a KDE project from the official repository and boldly make changes and corrections. @davidedmundson reviewed the patch and pointed out a few missteps. But I got them fixed and he pushed my patch into the real code stream. That was really cool.

I'm looking for more things to fix and more patches to contribute. My goal is to progress far enough to be granted a developer account, a badge I'd wear proudly (but carefully).

Overall, my experiences as a newcomer have been very positive. But they've also been a bit vague and come with some searching and exploration. I'm still not sure what I "can" or "should" do with some of my ideas. I know all positive suggestions are welcome, and I enjoy that, but the specifics are elusive. For example, I've got something I volunteered for on various mailing lists - updating the CafePress KDE merchandise store - but I don't know how to proceed. I think it should be a Phabricator task, but again, I don't know if I'm allowed to or supposed to create those on my own.

In the mean time, I'm learning the KDE infrastructure and community, happily writing my own code again, even blogging about my experiences ( with KDE and other et ceteras.

Thanks for this. I hope I can help.