fork

[noraj]

the idea of forking docopt because it's unmaintained it's cool but the idea of docopt is to be available in tons of languages, while docopt-ng only forked the python implementation.
Do you plan to fork all others https://github.com/docopt?

[nosseb]

Jazzband is an organization focusing on python based projects, so I doubt they will fork the other implementation; but if I remember correctly they aren't the one who initiated the fork. They just enabled a bunch of peoples wanting to improve docopt by providing them with a better management.

The main issue with all docopt implementation is the lack of community. If you manage to assemble a team to maintain another implementation, please make a fork of some implementation; I'm sure many will be grateful.

[NickCrews]

I believe @nosseb is correct here. I don't think Jazzband will take on non-python projects.

This fork is a bit weird because the original forker added some features and modifications so I don't think this exactly follows the spec described at docopt.org. Now, with jazzband's sponsorship, hopefully this becomes the canonical version of docopt.

So what to do: should this fork stop adding features to try to stay true to the original spec? Should the spec be updated? Should other language's implementations have some say in how this spec is updated?

I would say if this fork becomes maybe 50% as popular as the original docopt, then we should probably revisit this more seriously. Now, just keep it in the back of our minds.

[noraj]

Personally I have only interest in the Ruby implementation. So if docopt-ng is python only I'll stay to the original docopt.

[NickCrews]

Closing because I don't see any action we can take here, please reopen or start a new issue if you need!