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

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to