https://golang.org/doc/faq#x_in_std

In particular, I don't see why a third party package going unmaintained should mean that the standard library should adopt it. If that were normal, the standard library would be much larger than it currnetly is.

This seems the wrong way around. If docopt would be widely used and in need of dedicated maintenance I would assume it would have been forked and continued to be maintained.

All packages not tied to the runtime or used by the go toolchain can happily be maintained if there are developers willing to maintain them outside the std lib. This also has the advantage of not being tied to go release cycles and putting the API under the Go API compatibility rules.

@martisch @mvdan:
Points accepted. Go obviously has a much narrower notion of a std-lib than e.g Python. No need to break basic design decisions.

I'll try the plan B: Reach out to the docopt-team and see if the project is still alive or do a private fork or switch to a more actively maintained argument parser.

@soerenkoehler I'm also interested in keeping the project going, I think the consistency of PRs in docopt.go is also testament that there is a community desire to keep maintenance going.