What made you step and and decide to contribute to KDE?

• Besides enjoying the DE, it appeared to be a community that was making smart decisions (2017 Goals for example) and was growing.

What was your point of entry to KDE?

• Nate's blog posts basically, and Nate himself.

In what area are you contributing to (development, translation, documentation etc.)?

• Right now a mix of development and bug triaging, with maybe documentation later.

How did you decide where to contribute?

• I decided to work in areas that will help in the 2017 Goals. I like the productivity goal to polish the DE, and I like the onboarding goal to make the project easier to join. Helping a long-time FLOSS project grow is something I'd like to do. Right now my development efforts are small patches, since I'm not much of a programmer right now. Just things I know I can handle. So I'm now focusing on bug triaging, to hopefully assist those who do know how to program well.

What steps did you follow to get involved?

• I started out talking with Nate, he helped me through the 1-2-3 of getting signed up with my various accounts and a dev evironment. He and Henrik recommended some Phabricator Tasks and bugs/feature requests to tackle. Mostly icon fixes, menu edits, stuff like that. From there, I just spent time browsing randomly through Phabricator, finding Tasks and Projects that were interesting. Watching the Activity feed on the right is also helpful to see what cool things are happening and might be worth looking at to offer comments or assistance.

What did you enjoy most in the process of joining KDE?

• The friendliness of everyone, and the ease of joining. There were no trials or tests to go through.

What where the difficulties you came across?

• The introductory process of reading Wiki pages. Even with the improvements to Get Involved, there is no easy 1-2-3, here is how you get started. For example, to get started as a developer, you are pointed to an article, which has lots of information, sure, but is not a set procedure really. I was looking for something like:
  1. Create a Bugzilla account, do this.
  2. Create a KDE Identity account, do this.
  3. Create a Phabricator account, do this.
  4. Get your dev environment setup, follow these steps.
  5. Pull down this Git repo (say, a tutorial repo), create a branch
  6. Edit this file, commit it, and create a diff via Arcanist.
  7. Once approved, land your commit like this.
  8. You have now followed the basic process and can contribute!

That information is there in the Wikis, but it's disjointed. You end up like how you read the Arch Wiki and find yourself 15 tabs later down some black hole. There are also duplicate instructions on TechBase vs Community (looking at you Git Configuration page), some of it is outdated, etc.

Do you still face any issues today in regards to contributing more?

• Not really, I think most of it is documentation (procedural) as mentioned. Which I know is a bit difficult, since KDE is decentralized... but it's my feelings on it.

What do you believe would help in making the getting involved process easier?

• I think the above would help a lot. I also believe the Newcomer Welcome Team would be a big help, such as with the above. Or even just introducing you to the "leaders" of the groups you are interested in. Same goes with the Mentors idea. I know I needed more hand holding, since I was not a seasoned developer to start.

Migrating a comment from @schampailler that was posted at T8484#154505:

Just 2 cents : I'm in the middle of committing my first patch to KDE (and I'll tell my experience before I forget it, 'cos once the patcfh will be done, eveything will lokk simple I guess).

My experience is this. Following some community page, I tried to use kdssrcbuild on a platform that is not well supported (Debian Stable). As (not expected), the build didn't go well and unfortunately kdesrcbuild didn't warn me. Result 4 full days of desperately trying to fix all cmake related quirks. It would have been so cool to have a proper warning saying "you're trying to build on a system we don't support, be ready for problems" (without that, all build issues looks like something you can fix, except you can't).

Later on @ngraham suggested to use a Neon image in VirtualBox (as explained here too). Result : up and running in an hour or so. Downside : that requires a good computer to run (mine is 8 years old, 4 gigs of memory, that's barely sufficient).

Other things:

• the page explaining how to submit a patch doesn't explain what will happen after submitting to Phabricator.
• you don't know how much time you have to wait.
• Phabricator ask for reviewers which you don't know about.
• Phabricator also complains about "lint" and "test" that were not run and you don't know what it means ("Lint was skipped when generating these changes". "Unit tests were skipped when generating these changes")

FWIW, all four items in the bulleted list are now resolved.

I'm still working on my Neon VM workflow. Before I document it, I want to make sure it's pretty well polished and user-friendly. I recently tried sharing my source repos across the host and guest in a Virtualbox shared folder but ran into too many bugs, design limitations, and performance problems to make it worthwhile. I'm going to try the Docker workflow soon too to see if that might be more appropriate to formally document.

In T8711#159319, @acrouthamel wrote:

What where the difficulties you came across?

• The introductory process of reading Wiki pages. Even with the improvements to Get Involved, there is no easy 1-2-3, here is how you get started. For example, to get started as a developer, you are pointed to an article, which has lots of information, sure, but is not a set procedure really. I was looking for something like:
  1. Create a Bugzilla account, do this.
  2. Create a KDE Identity account, do this.
  3. Create a Phabricator account, do this.
  4. Get your dev environment setup, follow these steps.
  5. Pull down this Git repo (say, a tutorial repo), create a branch
  6. Edit this file, commit it, and create a diff via Arcanist.
  7. Once approved, land your commit like this.
  8. You have now followed the basic process and can contribute!

Thanks, this is hugely helpful. I think I can work with this to centralize information a bit more.

About #5, what do you think about recommending that newcomers submit a patch to add their name to the relicensecheck script? This thingy: https://cgit.kde.org/kde-dev-scripts.git/tree/relicensecheck.pl

Or maybe not that file/repo exactly, but something like that, because this process involves cloning a repo, creating a branch, editing a file, using arc to submit a patch, etc. It's all simple stuff, and we can write really tight documentation for the exact process so that everyone can succeed at it and get a taste of how easy it is to contribute to other repos/projects.

Thoughts?

Yeah exactly, something like that. Where they can git clone (making sure their gitconfig is correct, like how mine wasn't recently), make a branch (and track master), mess it up (lol I've never done that!), submit it via arc diff, tell them how their Git commit is too wordy and needs to break at 80 chars (*ehm* again, never done that before), have someone (newcomer group?) review it and accept it, and then have them arc land it.

That way there is a concise example procedure to follow to get them ready for future patches. They get familiar with the tools we use, without worrying they are botching their first submission. Most of that is learned somewhat haphazardly now. (Such as right now, I'm finally getting around to playing with kdesrc-build).

Hi Nate,

Regarding :

FWIW, all four items in the bulleted list are now resolved.

I've checked that https://community.kde.org/Infrastructure/Phabricator page and I've seen a very good explanation regarding the first 3 bullets. The latter (linting/test messages a bit out of context) is not obvious to me. But that's a very good progress !

Thank you so much for taking the time to respond here @acrouthamel . Hopefully as we gather more responses we will be able distinguish some common themes among newcomers' feedback.

In your case, I note the importance of having a person and an idea to inspire you, and having a go-to person through your first steps (junior jobs) that quickly and proactively got you involved and mentored you through the process.

Having a centralized page on Get Involved that is more than just a Wiki is indeed important, I will start another task soon so we can work on that. Also if you feel there are further questions we should be asking, do continue sharing them here.

And once again, thank you @ngraham for all your quick responses and help! I would urge you to get @acrouthamel involved in documenting and reviewing somewhere the step by step instructions he identified, it would be a great way to contribute to the onboarding effort. We desperately need this kind of feedback and involvement from newcomers.

Oh, maybe I'm stating the obvious, but the whole patch submission process is absolutely bearable. Nothing fancy. The problem lies more in the way it is explained. Once you have Neon and arc running, it's a breeze.

What made you step and and decide to contribute to KDE?
I've always wanted to contribute to something. I was very happy with what is going on in KDE lately (Plasma in particular but also the more common apps) and Nate's blog made it seem very approachable, even for someone new to KDE/Qt/C++.

What was your point of entry to KDE?
I've used KDE on an off since the KDE3 days but came back to using it day to day in the last year.

In what area are you contributing to (development, translation, documentation etc.)?
Development so far. Picking off small bugs and requests mostly.

How did you decide where to contribute?
I found good documentation on how to get started (https://community.kde.org/Get_Involved/development#Get_the_code mostly), picked an application that seemed small enough to understand, and jumped in. Nate's blog provided the initial motivation.

What steps did you follow to get involved?
Mostly just https://community.kde.org/Get_Involved/development#Get_the_code then a little help from some reviewers in phabricator.

What did you enjoy most in the process of joining KDE?
I didn't completely realize I joined KDE... but pretty much everything so far. Everyone has been helpful.

What were the difficulties you came across?
It took me a bit to feel comfortable in phabricator. There is probably lots of other phabricator functionality I haven't even found yet. Feeling like I know 'enough' about KDE/Qt/C++ is still an issue but I just found https://techbase.kde.org/Development/Tutorials to maybe help. Is there a document with broader information on basic functionality, code style, or overall project 'governance structure?' Who is in charge? How are 'big' decisions made? How are things coordinate within the KDE community? I also had to piece together information on how to use git 'correctly' at first, but then I found the following which includes clear recommendations: https://community.kde.org/Infrastructure/Phabricator#Workflow.

Do you still face any issues today in regards to contributing more?
No, besides time and increasing comfort with making good contributions.

What do you believe would help in making the getting involved process easier?

• Making some of the links I listed above easier to find might help. They are out there but wikis are big and not always the best to search. When I use external search engines I think they often point me to old KDE documentation. That is anothr issue I guess.
• Nate's blog helped a lot. I think that I heard about it on the Ubuntu podcast a few months ago. If nothing else it lets people see how much activity is going on within the project. It feels easier to join an active group.
• I would like to see something about the best way for 1:1 communication for new contributors. IRC feels like a very public place to ask questions, especially novice questions (like why did they do something that way?, how does this work in C++/Qt?, what did I do wrong in git? etc) Is email preferred? IRC private messages? Phabricator? Something else?

• What made you step and decide to contribute to KDE?

I wanted since some time starting contributing to an open source project and found kde a good fit for this.

• What was your point of entry to KDE?

A kde user since 2 years. Before, I was using a macbook.

• In what area are you contributing to (development, translation, documentation etc.)?

Development (I wrote some patch in korganizer and elisa) and documentation (I am updating the screenshot in userbase)

• How did you decide where to contribute?

Just started to contribute on the application I use and love.

• What steps did you follow to get involved?

Create a kde account on phabricator and Bugzilla. And set my development environment.

• What did you enjoy most in the process of joining KDE?

The community.

• What where the difficulties you came across?

Setting my development environment. With elisa I hadn't any problem, just clone and build. With kde-pim, setting the development environment is more painful. I first tried clone and build (didn't work), then setting a docker environment, but wasn't able to set the x driver with docker using nouveau, then using kdesrc-build on my machine without docker I was able to build most of the dependencies (libkleo and some other dependencies didn't work) and I could finally start write code. But because of some instability on arch, I moved to openSuSe and for the moment I unable to compile korganizer with kdesrc-build.

• What do you believe would help in making the getting involved process easier?

I don't know how to make setting the environment easier could be done. Virtual machine are too slow, but docker image could work if were is instruction for settings x with nouveau and amd.