Hi Elias,
Thanks for taking the time to share your input to this! See comments inline.
On 8 Dec 2023, at 15:33, Elias Steurer via
Development<development@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.
On the positive side, these things are not mutually exclusive: we can improve
the process and the documentation while providing a better welcome-experience
and support for new people that want to contribute, but struggle with what we
have. In fact, I’d claim that hand-holding people through some personal contact
is always going to be a good idea, even if Qt would be a simple code base that
anyone could build, write tests for, and make fixes in without having to learn
anything new.
From installing a plethora of tools to dealing with the confusing repo cloning
process, Perl dependencies and Perl path issues, the barriers to entry are
high.
Yes, setting up a local development environment that can build Qt is not
trivial, esp if you want to build all submodules, and want to work on Windows
on the one hand, but on the other hand want to use something other than the
native compiler and SDK for that platform ;) And if you want to make sure that
your code compiles and that tests pass with your modifications just on the main
desktop platforms, then you’ll be busy setting things up for a while.
There is certainly room for improvement, but I think the complexity is a bit in
the nature of the beast as well (that beast being not just Qt, but C++, several
development platforms, even more cross-compile targets etc).
Can we make that fundamentally easier? Should that be our goal and what we
spend our time on? Would it make a huge difference if we didn’t require perl
(and IIRC we only need it for the init-repository script)? You need cmake,
ninja, and your compiler and platform-specific SDK (which is mostly trivial on
Windows and macOS; on Linux it’s a bit of a piece-meal). But none of that
strikes me as particular esoteric stuff. Well, unless you want to build
webengine, or check all the SQL-driver boxes.
Anyway, if you can make specific suggestions on how we can improve the build
system of Qt and reduce dependencies to tools or libraries, then please do so.
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.
If step one has to be that we simplify the entire contribution process from the
ground up, then this will get us exactly nowhere any time soon. This is not
only because there is a variety of differences in the Qt project contributor
community about what we should optimize for. Many of us consider gerrit’s code
review user experience vastly superior to github’s or gitlabs; many of us
believe that the history of a patch is a critical piece of data that is easily
lost, or hard to find, in the github/lab workflow. I don’t know if it’s
possible by now to comment on the commit message in github/lib/ea (it wasn’t
last time I checked), but not being able to do so would be a total showstopper
for me personally, and I don’t understand how projects that care about their
git history can function if reviewers cannot give structured feedback to the
most important part of any change, esp to new people.
So building consensus of what “simplification” means in practice is going to
take a while.
But even if by Christmas we all agreed that we should move things to
github/lab/ea, it will take a significant investment of time and money to
actually make that move. There exists a significant amount of tooling, process
automation, authentication structure etc that is based on the setup that we
have. From a variety of bots to CI integration and other test automation, to
releasing and packaging. That’s a ton of work to replace.
We can start the discussion and identify some specific improvements that move
us forward, and maybe even end up agreeing what the perfect workflow would look
like; but waiting for the grand simplification to arrive before we do anything
is IMHO not the answer.
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.
See above. Even if I would believe that there's a magical greener pasture for
*everyone* (not just for new contributors; we can’t optimise the process for
that group of people if it makes the process harder for people doing the vast
majority of the work, esp for the maintainers and reviewers), getting there
will take more time than we should wait.
There was also an discussion about this recently on Reddit.
Reading through that, it's a mix of
* I’m not willing to sign the CLA (can’t help you buddy)
* I couldn’t find a reviewer (that’s exactly what the buddy group is going to
help with)
* “I’m not going to learn a workflow that is not github” - sorry, but “shrug”;
I have no reason to believe that you will be willing to learn what it takes to
make your patch work on a platform you are not familiar with
* and yes, a few statements that the process is hard - with some encouraging
statement from Psychological_Ad1417 that by getting help, it isn't so difficult
(and
So, of the four main sentiments that I can identify in that discussion, two can
be addressed to some degree by a buddy group that proactively reaches out to
lower the learning curve.
Volker
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
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
