[Development] Buddy group to help new contributors

[Ilya Fedin]

On Fri, 8 Dec 2023 15:33:04 +0100
Elias Steurer via Development <development at qt-project.org> wrote:

> Hi Volker,
> 
> Thanks for the update on the Qt Contributors Summit. It's great to
> hear about the initiatives to make the contribution process smoother, 
> especially for newcomers.
> 
> However, while setting up a Gerrit group for hand-holding new 
> contributors is a step in the right direction, I believe we might be 
> missing a crucial point. The core issue isn't just about guiding new 
> contributors through the existing process; it's about the inherent 
> complexity and user-unfriendliness of the current workflow.
> 
>  From installing a plethora of tools to dealing with the confusing
> repo cloning process, Perl dependencies and Perl path issues 
> <https://user-images.githubusercontent.com/3586205/166160892-461dbcb0-81c2-4ca4-8a66-d11aaa2c2bbb.png>,
> the barriers to entry are high. Then, there's the challenge of 
> navigating the Gerrit setup, which is far from straightforward. The 
> documentation is inconsistent and sometimes contradictory, adding to
> the confusion. And that's before even getting into the complexities
> of submitting patches and managing code reviews. If you want I can
> send you my personal notes, that I have written down recently while
> setting up Qt locally for the first time in years. Most of it is
> about my frustration why a solved problem, like contributing to an
> open source project, is so unnecessary complicated.
> 
> In essence, the current workflow is daunting, even with a support
> group. I suggest we consider moving towards a more streamlined and
> "sane" workflow. Simplifying the entire contribution process from the
> ground up will make Qt more accessible to everyone. Once a more
> intuitive and welcoming workflow is establish, guiding new
> contributors will be much more effective. *After all, the best
> hand-holding is the one you don't need because the path is clear and
> easy to follow. *
> 
> It might be worth considering a migration to GitLab, which has been a 
> successful move for other open-source projects like KDE and Arch.
> Given that Qt already uses an internal GitLab instance, this could be
> a good platform for future collaboration. Alternatively, adopting
> Gitea, as used by the Blender Foundation, could also be a viable
> option if Gitlab licensing is a no-go.
> 
> I strongly believe the focus should be on overhauling the workflow 
> first. Everything else, including smoother onboarding of new 
> contributors, will naturally follow.
> 
> There was also an discussion about this recently on Reddit. 
> <https://www.reddit.com/r/QtFramework/comments/17jnbsr/have_you_ever_tried_to_contribute_to_qt_directly/>
> 
> Best,
> 
> Eli
> 
> On 12/5/2023 9:57 AM, Volker Hilsheimer via Development wrote:
> > At the Qt Contributors Summit in Berlin last week, we discussed
> > various ideas around improving the contribution experience, esp for
> > new people.
> >
> > One action that came out of that was setting up a gerrit group of
> > people that are able and willing to hand-hold new contributors
> > through the process. This includes setting up your local
> > development environment, gerrit configuration and workflow, and
> > finding out what to work on from e.g. Jira. The basic idea is that
> > we establish a (gerrit, probably) group with buddies; we can
> > already identify “first gerrit reviews" for a new user, and then we
> > can proactively reach out with a welcome message, and add the group
> > of buddies as a reviewer.
> >
> > A few people raised their hand at the event, but I don’t think
> > anyone took down the names, and I was busy juggling microphones.
> > And either way, this is of course open to anyone! So please reply
> > to this, either to all or privately to me, if you want to be part
> > of that group.
> >
> > Cheers,
> > Volker
> >  

I believe the bug reporting rules make things even more harder. I have
a lot of crash traces received via breakpad I can't report upstream as
they crash deep inside Qt and I have no idea how to make an example for
that. I also have a lot of end user reports I can't reproduce myself
(maybe hardware-specific, idk) and therefore make a minimal
reproducible example. Those users don't know Qt to make a minimal
reproducible example as well what blocks them to report upstream as
well but they usually can reproduce issues on other real world Qt
applications. Sometimes they can't reproduce with other applications
(perhaps edges of Qt that are not so widely used) but the issues feel
low-level enough to think it's Qt for sure (e.g. clipboard, font
rendering or text input problems).

Once upon a time I tried to upstream a patch I made to fix a crash from
a crash trace but I've got a resistance from reviewers requiring me to
create a bug report (which I can't do due to the minimal reproducible
example rule as I had no idea how to make one for the trace in
question). This made me feel disappointed and I perhaps won't send such
fixes upstream anymore. God knows how much people workaround bugs or
patch them downstream due to these complications.