Should there be an "urwid-contrib" project?

It seems to me the following statements are all true:

1. Urwid is in wide use in a variety of settings and on a wide variety of platforms.
2. People would like to see new and expanded functionality in Urwid.
3. Maintainer and developer resources are limited.

These factors seem to be causing people to favor implementing new things in their own projects rather than suggesting them for inclusion in Urwid. There are many widget libraries, and widgets that could be generally useful packaged with applications. There's a lot of duplication, and there have been times when folks have tried to submit PRs to Urwid, only to have them languish for a long time until someone creates a separate project. (See the discussion at the tail end of this PR for an example of this.

So here's what I'm thinking: what about an "urwid-contrib" project? This would be a new repo in the urwid organization with the same maintainers as Urwid, at least to start. The key difference would be that the bar for inclusion in urwid-contrib would be lower than with Urwid proper -- new widgets and other functionality could be added without necessarily conforming to rigid guidelines about style. There would still be a baseline expectation that things are documented and well-tested, but as long as some new functionality isn't breaking anything, PRs would be approved more quickly.

My feeling is that a quasi- official "add-ons" module under the Urwid umbrella would create a nice path for things to be integrated into Urwid over time, without having them sit in PR purgatory waiting for enough testing / code review to be accepted into the main project.

We could even call it "ourwid" to emphasize the community-oriented nature of it. :)

What say you, @wardi, @ulidtko , and others?

Begin with the discussion at the end of PR #34, then review the existing add-on and widget projects referenced by the issue. A useful outcome is a maintainer decision on whether to create an urwid-contrib repository and, if so, its ownership, inclusion, documentation, and testing expectations.