About 💕

I am a native russian speaker, open source contributor and I am keen on administrating, scripting, creating sites and presentations. It’s my life. I like to automate routine tasks and not to do them manually. Currently I have the following skills (just the most interesting tools are mentioned):

• 💻 languages: Nushell (interactive session and scripting), Go (scripting), Hugo (generated site content), YAML (configs), JSON (configs and JSON schemas)
• 📝 ides and editors: Visual Studio Code (programming stuff), Inkscape (drawing logos)
• 🕜 vcs-tools: Git, GitHub

I support several projects and organizations such as (just the most interesting ones are mentioned):

But now I mainly focused on [C]ommand [L]ine [I]nterface [P]ages project:

which provides neat command help pages.

How do I review pull requests? 👓

For the first 2 pages less than or equal 50 lines I provide detailed mistake expanations for all issues with links to contributing guides how to fix them.

Other remaining pages are not scanned for problems.

Placeholder syntax in my CLI tools

Starting from 29 december 2023 I use the following placeholder syntax in all my tools (Go-inspired):

• {{placeholder}}: some arbitrary text with no constraints implied which should be exactly one CLI argument. If there are any they should be explicitly stated in the documentation. There is no standardized way for describing them.
• {{placeholder ...}}: almost the same thing as the previous one, but here one or more arguments are expected. If no arguments or some specific amount of them is required it should be explicitly stated in the documentation. With | ellipsis (...) can be used just ones, at the end, implying that all alternatives accept several arguments unless the opposite is stated. There is no standardized way for mentioning it.
• | can be used inside double curly braces to provide more than one alternative for what can be placed instead of placeholder. If some alternatives can be used just under certain circumstances, it should be explicitly stated in the documentation. There is no standardized way for mentioning it.

, where instead of placeholder any text can be written which explains what should be put instead of CLI argument(s), but without spaces unless it's explicitly permitted.