I was more thinking of a bug party à la Debian. Trying to squash the maximum bugs from Nim distribution. It could be simply improving the documentation of the system libraries, adding a missing feature in a frequently used library, writing test cases or for Nim experts trying to tackle some compiler bugs.
Attracting other developers to the language can be done by adding more lower quality projects or by improving the quality of existing projects. By low quality projects, I mean non-maintained or documented projects on a long term. Increasing the number of libraries for Nim is important, but personally I was never blocked because a library was not available. One of the strength of Nim is to bridge external libraries very easily.
Both ways are important. And I'm questioning what is the main reason why people who tried Nim drop it after a while. Knowing that answer would help putting the efforts to the right place. For me, coming back to Nim after a few years pause because the compiler was not mature enough, the main reason I would keep off Nim a second time is still because I encounter too many compiler bugs and lack of documentation: I spend too much time on trying to find workarounds or even to code something the Nim way.
I agree with @spip for the problem of documentation because a lot of function aren't comments but for me there is also a problem of useful small libraries. It's normal, Nim is young.
I lost a lot of time to develop some useful utils to extract/compress archive, download files from url, etc.
The Hackathon can propose to develop basics libraries to do :
For web developers, a other idea is to fix issues and improve https://nimble.directory/.
I am not a contributor so probably not entitled to give an opinion here. In any case, I would suggest improving nimterop. Right now it works really well when you try to wrap C libraries. But it could be even better, and it still misses the capability to wrap C++ libraries easily.
Improving Nimterop benefits the whole Nim ecosystem.