[theme-reviewers] Draft Theme Development Checklist

[chip at chipbennett.net]

> Your reasoning doesn't convince me at all.
>

Actually, it's not *my* reasoning. I've merely preserved the existing
requirement, and attempted to explain the reasoning behind it.

> If you're distributing your private theme for public use, then the
> core of that theme should be intended and made for public. All your
> private hacks or mods should go into child theme. This is how theme
> hacks and mods are done these days.
>

I don't think a lot of "private hacks or mods" exist in foobar-suffixed
template files. Most go into functions.php, style.css, or the standard
theme template PHP files.

> If a theme got rejected because of the use of prefix page-, category-,
> taxonomy- for pre-made template in theme root dir then I'm against it.
> This is totally up to theme author. If this going to stay TDC, there
> should be a small note saying something like "Not recommended but it's
> okay..."
>

Personally, I don't have a problem with that. I think themes should be as
flexible as possible. But I think the use case is fairly niche. The end
user would have to use the same category/tag names (or IDs) (or know how
to associate a given page with a specific page template). The intersection
of highly specialized, free theme and users looking for such highly
specialized, free theme has to be incredibly low.

Perhaps, if themes could integrate a readme.txt similar to that used for
plugins, then theme authors could provide custom instructions for using
such foobar-suffixed template files.

In that regard, I'm much more interested in seeing readme.txt integration
than I am in whether or not the current requirement regarding
foobar-suffixed template files is changed.