1. 1.
   Clone the repository and post it to Github/Gitlab or any other place and send me a link with the changes. The email can be found on the ABOUNT AND CONTACTS page.
2. 2.
   You can also email a patch with the changes attached (git allows to do it, but, oddly enough, I've never tried it).
3. 3.
   If you're contributing a lot and we have rapport, I'll probably add you to the Gitea instance or we'll figure out some other way to communicate and exchange code in a simpler manner.

In each case, your contributions, if accepted, will be acknowledged and credited. However, while you can freely fork this project and do any sorts of wild stuff with it, I will not be merging features I disagree with or code I think is badly written into my repository. Specifically, I think it's important to pay attention to the code already written, because I will not be outlining guidelines - I think anyone who wants to contribute must first get a sense of how the original author writes and structures their code.

That isn't to say it's perfect (especially given that I'm writing it in Bash, which I wasn't even closely familiar with up until this project), but, for instance, Tabs... Yeah, no.

Please do not be suggesting other languages other than Bash for this project or be reliant on more dependencies. The goal is to reduce them, not grow them just because we want this one small feature that Bash cannot do. Realistically speaking, though, I have not had any issues with Bash scripting capabilities. We can even add unit tests, because, at this point, it's getting a bit scary with every commit and I cannot be re-checking every image with every dock feature on every possible platform.

A NOTE ABOUT LARGE PULL REQUESTS:
To be perfectly honest, in these troubling times and with very limited funding (out of my own pocket), I do not have time to review large pull requests, so something like a bug fix would probably suffice and will even be more appreciated than a large merge request.

I might add certain users to my Gitea instance later on if there is really some community effort and/or interest around this project. This, I admit, may not happen for a while - in which case I am perfectly happy I have done it anyway, because this tool will keep saving me a lot of time and it will rid me of a lot of unpleasantry in my work on other things. Not to mention how much I've learned thanks to it.

As of the time of writing, the only base OS image I'm using dock with is Ubuntu 20.04 amd64 pulled from the Docker Hub and modified accordingly.

You can the do two therefore do two things:

1. 1.
   Use the official dock-compatible image - download or pull it as described in the ./README file and then simply add your changes. After that, you can commit the changes in the container to a new image and publish it. If it's worthy, I will link to it fro the website - be sure to email me in that case. Naming image doesn't really matter, as anyone can always rename it locally. If you publish your image and especially so - if you email me a link to it, be sure to attach a file that can be placed into the ./documentation directory describing details and changes about your particular image.
2. 2.

   The second approach is to create an dock-compliant image from scratch, because Ubuntu isn't really what many people may want (even I would prefer to have FreeBSD image and someone else might want Alpine or Arch or whatnot). However, in order to be able to work with the `dock` utilities set, these images must comply in a number of ways. There aren't many things to do to achieve compliance though.

   To understand what requires to be dock-compliant, I suggest you read the IMAGES documentation page, which not only explains the changes made to the original image Ubuntu image, but also outlines what the `dock` utility itself relies upon inside the image. Unfortunately, I don't have the time for an extended guide.

IMPLEMENTING SUPPORT FOR OTHER ENGINES

CONTRIBUTING FUNDS

CONTRIBUTING BY SPREADING THE WORD