First commit, made easy
Open, Needs TriagePublic

Description

Contributing just a simple commit to a community project facilitates the engagement to this project significantly, since it builds a spirit of membership/commitment/engagement. So, providing a way for such a commit to happen is very important, because of its psychological effects.

Since there are many happy KDE users out there that may want to contribute but they think that they do not have the time, the capacity or they are afraid of the burden that implies “being a KDE contributor” I suggest something like the below in order to facilitate the “first commit engagement”. The scope of the proposal is to automatically offer to the KDE user a simple -easy to complete- task.

My suggestion is to create a Plasma app, web app or desktop widget (preferably a widget, since it will always be in the panel of the user). In the first page, the widget will provide a set of options with the possible “first commit” contribution areas, like:

  1. Translation
  2. Quality Assurance
  3. Documentation
  4. Promotion

Clicking to Translation, a set of languages will be presented. After the user has selected the language, the below options may be offered:

1.1 User guide translation
1.2 Program translation

If the user selects 1.1, the system will randomly select a userbase guide with incomplete translations and will provide the relative link to the user alongside with some tips.
If the user selects 1.2, the system will output a random incomplete .po file and also provide the mailing list of the relative translations' team (we need to coordinate with translation teams so as to treat such commits in a specific manner)

  1. Clicking to Quality Assurance, the user will have to choose between:

2.1.Find duplicate
2.2 Reproduce

Then, the KDE bugzilla products will be presented. The user will select the product of its choice. The system will randomly select a recent bug and let the user proceed providing a small set of tips.

  1. Clicking to Documentation, the KDE application categories will be presented, e.g. ,

3.1 Desktop
3.2 Internet & Networking
3.3. Graphics & Imaging
3.4 Multimedia
...

Let’s say that the user has selected 3.1. Then the below options will be offered:
3.1.1 KRunner
3.1.2 Kate
3.1.3 Konsole
3.1.4 Dolphin
...

If the user selects 3.1.1, the link of the user base guide of Krunner will be displayed and the user will be encouraged to review and/or add missing content.

  1. Clicking to Promotion, the widget will provide a set of options, like:

4.1. Share your ideas
4.2 Boost KDE work

If the users selects 4.1, a random promo phabricator task will be chosen and the system will let the user to provide her/his ideas and comment on the task

If the users selects 4.2 a recent social media post of kdecommunity will be offered for sharing

The suggestion has no intention to substitute the current workflows of each team leading to low quality, occasional or simplistic contributions. My drive to suggest this is that the first commit makes you feel “committed”. Then, you will likely (or hopefully...) look for the proper way of contributing and offer high quality work in the long term.

Perhaps it could also pull Junior Jobs from Bugzilla? It’s a good idea, having it readily (and semi-permanently) available. I don’t know if we could get it done in time for Plasma 5.13 (assuming the idea is approved).

+1 from me

bshah added a subscriber: bshah.May 12 2018, 4:06 PM

One of nice example I found earlier : https://howcanihelpubuntutouch.io/

If we want to create a website (even it it's something like myfirstpatch.kde.org), we should put a link on the user's desktop at installation. That's relatively inoffensive, easily removed, and requires less coding than a desktop widget.

If we want to create a website (even it it's something like myfirstpatch.kde.org), we should put a link on the user's desktop at installation. That's relatively inoffensive, easily removed, and requires less coding than a desktop widget.

+1

TBH, my suggestion is primarily focused on the facilitation of a really fast and simple first contribution. Like the case when we learn a new programming language, almost always we try to run a "hello world" example, without having any real knowledge of the language or having read (almost) any page of the language reference. After the successful execution of the “hello world” , we feel a little bit more comfortable to continue studying. It's the "hello world" psychological effect accompanied with the feeling of membership and commitment to the KDE family that the solution tries to reproduce .

Nevertheless, following the example of the sites suggested, the solution may be extended with an extra initial page. In this page, the widget/web page will ask sth like "Time available" and provide a set of options, e.g.:
1 15-30 minutes
2 No time limit

If the user selects option 1, the flow already suggested will be presented.
Otherwise, a set of questions like the ones included to the web sites https://howcanihelpubuntutouch.io, https://whatcanidoformozilla.org will guide the user to a different community.kde.org page.

aacid added a comment.May 14 2018, 6:29 PM

The translation teams have said various times in the past that translations from random people in the internet with no commitment usually just bring in more work than they help since they totally fail at syntax, style guide, etc. I wouldn't be sure this has changed at all.

I mean would you let people edit code form the internet and submit a patch directly without having them compile and try it whatsoever? Probably not, so why would it be different for translations?

As a relative newcomer (January), this is a very real and very powerful
thing. We should do whatever we can to encourage it. When my first
commit got landed (a simple plasmoid fix), it was a great feeling. Now
you'll probably never get rid of me.

There's still the slightly nasty (and so far, unsolved) problem of
getting a functional development environment set up. Even a simple
string or icon change needs a bunch of dependencies installed for the
product to build & test. The list of prerequisite packages is dauntingly
long - assuming your package manager installs them all without error or
further confusion. And then tracking down any extras added to the git
master since the wiki page was last updated.

In T8685#141924, @aacid wrote:

The translation teams have said various times in the past that translations from random people in the internet with no commitment usually just bring in more work than they help since they totally fail at syntax, style guide, etc. I wouldn't be sure this has changed at all.

I mean would you let people edit code form the internet and submit a patch directly without having them compile and try it whatsoever? Probably not, so why would it be different for translations?

Before adopting the suggested “first-commit solution” (or any alternative) I think that it is important to consider a set of things.

At first, the solution is based on the assumption that the first commit is different from the rest, since it assumes that the distance from 0 to 1 is not equal to the distance from N to N+1 (in term of commits) and it is of significant psychological importance. If we disagree with this, we should reject the solution.

In case that we agree with the assumption, it would be useful to try to respond to the following:

  • Introducing such a “fast and simple” way for the first commit will confuse future contributors? Will it prevent them from adopting the proper contribution workflow after the first commit and lead to poor contribution quality?
  • The same applies to existing contributors or/and mentors. Are we able/willing/ready to support such an alternative for the first commit?
  • In general, adding new members to a team, induces effort by the existing members (in the beginning). Adding members via such a kind of onboarding procedure means extra effort (heavy? light?) Is it worth it? Should we avoid increasing the burden on existing members?
  • Is this solution suitable for all/some/none of KDE projects/teams?

I don't think anyone's proposing an easy-but-broken method of brute-forcing the first commit. Rather, I think we're all discussing how to make it easier to get started the right way so that first commit is not only easier, but also conforms to KDE best practices.

It's indisputable that the first success in a complicated new venture is both a formidable gate, and also acts as a psychological hook for future contributions. As mentioned earlier, that's why "Hello World" programs exist.

Also the whole premise of this onboarding goal is that adding more members is a net win, eve if it requires a bit of effort up front to help people get started.

even if it requires a bit of effort up front to help people get started

Besides, overcoming a challenge makes the success feel more worthwhile... Or that is what they taught me at teacher training school.

That said, a process is only insurmountable if it is not adequately documented. So maybe look at documentation, create easy to follow walkthoughs and tutorials first, before changing anything in the current process? This would also server to work out kinks in the process, find steps that may be redundant or can be simplified.