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. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development