Most times I wouldn’t say it’s important that you go through exactly the same formal process that you’d do if you were planning to publish your own peer-reviewe

Most times I wouldn’t say it’s important that you go through exactly the same formal process that you’d do if you were planning to publish your own peer-reviewed article. However, in a software engineering context, let’s say that you’re implementing a new library to do something in a new programming language. If other, more established languages had popular libraries that did something similar, I’d systematically catalog what those libraries are, read their user docs, maybe read their source a bit, and certainly try to develop an understanding of what I thought was the right approach. In your own readme, including this information up front, along with why you chose to implement the way you did almost certainly advances the state of the practice. At a minimum you’ll have a record of what influenced your thinking so that, if you come back in the future, you’ll know what other threads may have advanced in the meantime. I’ve thought of this as a way to contribute to open source that isn’t writing code or docs after the fact. Like, imagine you’re a Racket user and you wish there were a library to do X: maybe it’s a worthy contribution just to start a github repository and document the libraries that do something similar, and what you see as good and bad about those approaches. Maybe someone with the bandwidth to write the software will see your documentation and find that it gives them a head start.