[Development] Buddy group to help new contributors

[Edward Welbourne]

Volker Hilsheimer (8 December 2023 23:55) wrote (inter alia):
>>> Would it make a huge difference if we didn’t require perl (and IIRC
>>> we only need it for the init-repository script)?

Our post-commit hook also invokes sanitize-commit, which is a perl
script.

Of course, it would not be beyond the wit of developers to rewrite both
into python; and doing so might well be an opportunity to study each
closely and think about what we really want from these scripts and how
to do it better.  But we'd have to set aside some suitable developer's
time to do all of that.

Elias Steurer (9 December 2023 15:21) wrote (among diverse good points):
>> In the current state the wiki is a mix of outdated and redundant
>> information.

This is a common problem with wikis.
(See also Mike's comment, below, about "written by software engineers".)

It is easy to write a page that says things that are true at the time of
writing.  It takes some extra effort to actually make that page
discoverable - link it from the right other places, add it to the right
categories, make sure it'll match search terms those who need the
information are going to actually ask about.  As ever with writing, it's
important also to think about what you're so used to taking for granted
that you might not realise the reader needs help with; and to link
relevant parts of the page to where the reader can find more material.

And that's just creating a good page.  Then there's the era of bit-rot:
eventually the page shall be out of date, but how can the reader whose
search has taken them to it discover that ?  I fear the Qt wiki has more
dead pages (that don't know they're dead) than usable live ones.

A wiki lives or dies like a garden, by having enough gardeners giving it
enough of their time to keep it vibrant.

Mike Trahearn (10 December 2023 00:11) wrote (inter alia):
> The entry learning curve is definitely very hard and tricky to set up
> and the wiki looks like it was written by software engineers (that's
> not a good thing). That would be my first point of change.

I distinctly remember, eight and a bit years back, that there was a lot
to sort out and it wasn't easy to find all the details I needed in the
jumble of out-dated pages - and that was with an office-mate who already
knew the ropes to help me out when I hit problems.

> It took me an entire week to get one commit over the line which in
> comparison to what I'm used to is unacceptably slow.

I managed to fix my first bug within my first week - and my boss was
astonished; so yes, I think everyone in the project knows the overhead
is a significant issue.  The problem is devising a process that deals
with all the complexities of this huge [*] project in good ways that we
can make work efficiently for regular high-throughput contributors while
also being learnable for beginners.  That's a tricky problem, so don't
expect an easy answer any time soon; but, yes, we do need to listen to
feedback, particularly from newcomers.

[*] Qt is huge in several ways: the amount built on it, the number of
folk involved in it, the diversity of ways it's used, the range of
platforms on which it works and, of course, the vast amount of code.

One thing I do with new recruits is encourage them to make a note of any
problems they hit, so that we can come back later to sort them out.
There are surely other ways to get feedback from newcomers.
If we don't know about a problem, it's hard to fix,

	Eddy.