<div dir="ltr"><div dir="ltr"><div>
<p>Hello all,</p><p>I am excited to see the first replies, even if some seem to be private messages. Thank you all! :)</p><p><br></p><p>In the following case, I think the raised question pertains to many contributors on this list, so would answer publicly - and thanks for asking.<br></p><p><br></p><p>> 
There are various GitHub issues and Dev mailing list inquires, but they haven't really gone anywhere.


<br>> Can you provide some guidance on what the right way to help push these things along are and what I can do from my end to help?<br>> e.g. protocol information, testing, etc</p><p><br></p>

</div><div>First of all, thanks for what you are doing!</div><div><br></div><div>Although I have been in the core team for quite a while, I am still learning about some processes and traditions we have in the NUT project, and resources (including people) that are available. As in many projects, the active population in terms of, say, regularly available man-hours per month, is a bottleneck - sad but true.<br></div><div><br></div><div>Certainly, publishing the vendors' official protocol information to get drivers made or updated, and testing the results with varied hardware to make sure nothing begins to crash and new features do actually work, are both very important parts of the equation, so great thanks for offering and providing such help. Don't forget to PR your company and yourself into the `docs/acknowledgements.txt` file, by the way.<br></div><div><br></div><div>But in the end, what matters for code improvements are codebase changes, and things move a lot faster when everybody puts an effort into that - e.g. providing pull requests to update the documentation library with protocol data, pull requests updating or introducing drivers, reviews of changes somebody proposed, and so on. As it happens, in NUT as well as in many other projects I see, if the core team's day job is not to directly develop the product, then the central folks are overwhelmed by the commitments they already have and are rather short on time (can not pick up development ourselves).</div><div><br></div><div>We want and can help the project and its greater community move forward, by orchestrating it to happen and making sure new proposals fit well together with the existing codebase, but other people should step up and provide those new features in code. As much as it might be fun to code all that, I am too aware of the years-long backlogs I have on some efforts, and do not want to be the bottleneck on progress other people can make (by themselves, or enticing someone to) and I can just stand nearby to help them make it the best we can.<br></div><div><br></div><div>For example, on my side - I spent the past month by cleaning up the NUT code base, so it is more maintainable and passes green on many more CI setups than it did,
 against many revisions of C standard, on several compilers and operating systems, and does not spew warnings even in many pedantic cases. I hope this would help us all be more confident that new contributions (including stuff that is in the queue for way too long, such as importing one of the branches offering libusb-1.x support) do not introduce apparent regressions, while developers can run the same script as CI does to check for same test conditions locally and avoid posting bugs even in their initial commits. Modern compilers and linters do a decent job at predicting issues with code (and asking different tools on different systems gives a lot more different answers for the same question), so not all of the past month's changes were style and cosmetics ;) Even for cases that are not fully green yet, developers would not drown in the issued warnings irrelevant to *their* changes and so can focus on bringing their contribution into perfect shape, when needed.<br></div><div><br></div><div>Hope this helps,<br></div><div>Jim Klimov<br></div></div><br><br></div>