As a newcomer who only joined the forum three months ago, but has benefitted from others' help and (I hope) also made modest contributions, I'd like to add my perspective to this thread. (For info, I've been working for a design consultancy doing cross-discipline projects for >30 years, mainly in the medical devices industry, and my part has mainly been from the [usually embedded] software perspective, though of course that means having some understanding of electronic hardware, testing, risk management, UI/UX design, project management etc. We don't manufacture, but we do of course have to design
for manufacture. None of this is meant to imply I'm therefore right in everything (or indeed anything) I say, just to give you an idea of where I'm coming from
)
I joined the forum and the Teensy users' community because of an interest in the audio processing capabilities. The forum is a fantastically helpful place to be, and quite astonishingly patient at times with some queries! The fact that Paul is on here pretty regularly,
and giving clear and detailed answers, is superb. And of course the Teensy range is mature and appears stable and well thought-through (I only have direct experience of Teensy 4.1, but that's extremely positive).
However, it appears to me that the community and PJRC are at some risk of becoming the victims of their own success, combined with, as Paul notes, external problems caused by the pandemic and chip shortages. There simply isn't enough bandwidth for PJRC, and in particular Paul as an individual, to do everything that's "needed". The question then becomes, what
is needed, and who does it? Here's a quote which kind of worried me:
I've been burned many times by contributions which I didn't carefully test
I 100% understand the desire not to release contributions which haven't been carefully tested. But it's a huge bottleneck if everything is going through Paul alone, and that's just one instance. Clearly there are some things, like encrypted firmware and new hardware or library development, that can absolutely not be delegated. Others, maybe they can, at least to a degree: the
testing of the encryption clearly is.
It seems to me that at least the preliminary testing of PRs
could be delegated, at the first level to those Paul trusts to do a good job, and through them to the wider community. A quick triage through the existing ones to make a short list of those potentially worth merging, deferred until later, and already done / clearly hopeless would presumably be possible and fairly quick. A definition of "careful testing" would be helpful: maybe "a Teensyduino sketch which shows the problem in the unfixed code, the absence of the problem in the fixed code, and graceful behaviour under misuse", or similar. (I'm used to risk analysis, documentation, then unit, integration and coverage testing, but that's a sledgehammer to crack a nut, I think!) If at least basic test code could be, and
had to be, contributed with a PR, that would help. A visible effort in this direction would motivate people to contribute good quality PRs which could be more rapidly tested and merged, which benefits everyone.
Cheers
Jonathan