I think that's the current idea: to have developers propose a niche-Theme idea here in the mail-list, and then have that theme-slug white-listed, so that it won't get rejected by the Theme Uploader.<div><br></div><div>
That means, essentially, that a developer needs nothing more than a use-case idea and a Theme Name (from which to derive theme-slug) at the time of proposal. (Or, even more minimally: just a use-case idea, which can be approved, or not, before the Theme Name is determined. Of course, we'll need to know the theme-slug before the developer tries to upload the Theme.)</div>
<div><br></div><div>But also keep in mind: this isn't a one-idea-to-one-Theme, or a first-come, first-served, situation. I see it more as the *special use case* being approved, and then Themes that claim that use case get white-listed. Once the WPTRT has green-lighted a "niche", as many developers as want to create/submit a Theme for that niche may do so. (Why limit the repository to ONE landing-page Theme, when we could have ten, or fifty?)</div>
<div><br></div><div>So, to reiterate: it will be the *ideas* that will be limited, NOT the number of *Themes* designed toward a given idea.</div><div><br></div><div>Chip<br><br><div class="gmail_quote">On Sat, Oct 29, 2011 at 11:46 AM, Ryan Frankel <span dir="ltr"><<a href="mailto:ryan.frankel@gmail.com">ryan.frankel@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">It would be REALLY nice to have a pre-approval process here also that let's developers know whether their theme idea would be considered for the special cases. It takes quite a bunch of work to make these special themes and it really sucks to go through all of that just to have it not approved (which happened with my ticket system theme). If there is going to be a limited amount of 'unique' or 'special' themes how will the decision making process go? I can understand that the first one to propose it might be the one who gets it (like Quality Control) but there can be a lot of improvement made and a natural progression of themes stemming off from an original idea. Also, a lot of times these ideas are generated and worked on in parallel. The beauty of WP to me is its extensibility and the power of being in the theme repo is a huge advantage to any theme.<br>
<br>
Hopefully, whatever mechanism is put in place will take into account that many developers will be working on similar ideas.<br>
<font color="#888888"><br>
Ryan<br>
</font><div><div></div><div class="h5"><br>
<br>
On Oct 29, 2011, at 12:32 PM, Chip Bennett wrote:<br>
<br>
> One special/extraordinary use case, yes - but also, a use case that is demonstrably useful and/or unique/innovative.<br>
><br>
> Landing-page Themes are obviously useful. A support-ticket-system Theme is IMHO both unique and innovative.<br>
><br>
> I'd love to hear other ideas/examples of such "niche" Themes!<br>
><br>
> Chip<br>
><br>
> On Sat, Oct 29, 2011 at 11:18 AM, Angelo Bertolli <<a href="mailto:angelo.bertolli@gmail.com">angelo.bertolli@gmail.com</a>> wrote:<br>
> So what you're talking about is allowing some themes to cover only one use case, whereas the themes currently cover all use cases, right?<br>
><br>
><br>
> On Sat, Oct 29, 2011 at 11:19 AM, Chip Bennett <<a href="mailto:chip@chipbennett.net">chip@chipbennett.net</a>> wrote:<br>
> I don't agree. A site that doesn't have a blog doesn't constitute a "niche"; rather, it is a use-case that is built-in to core. Using WordPress "as a CMS" (nb: I detest this phrase; WordPress IS a CMS, no matter *how* it is used - and it is almost always intended to mean "without a blog") requires nothing more than creating a static Page to serve as the Front Page, changing the "Front Page Displays" setting to "static page", assigning the appropriate static page, and then NOT assigning a posts page. Easy peasy.<br>
><br>
> We don't need special handling for this use-case. Every Theme in the repository should handle it without problem. By default, repository-hosted Themes are expected to handle this use case; that's why we have Guidelines related to display of post metadata and "no comments" type text on static pages.<br>
><br>
> I see no practical reason for a publicly distributed Theme NOT to account for the blog use-case. If we've not adequately covered the non-blog use case in the Guidelines, we can always revisit them.<br>
><br>
> As for the definition of "niche" Themes: they really do need to be an extraordinary use. At this point, it's probably a "know it when we see it" kind of thing. I think the "landing page" use case and the "ticket system" use case are good, instructive examples.<br>
><br>
> Chip<br>
><br>
> On Sat, Oct 29, 2011 at 9:42 AM, Kirk Wight <<a href="mailto:kwight@kwight.ca">kwight@kwight.ca</a>> wrote:<br>
> What distinguishes "niche" themes from "regular" themes is often one thing: only partial or no implementation of blog functionality. As far as I can tell, most of the checks from Theme Check and the uploader rely on the theme being usable as a blog.<br>
><br>
> This summer, we found out from the user survey that a lot of developers use WordPress for sites that don't even have a blog component (just a "CMS", for lack of a better term) . To me, niche themes are simply themes that, for whatever reason, choose not to implement full blog functionality.<br>
><br>
> We could add a tag filter under Features that is just "blog". If this tag exists, the uploader and Theme Check plugins check according to the current criteria. If not, a simpler context can be used (presence of readme.txt, etc). Obviously this would require rewriting the uploader and theme eval plugins to react conditionally, but it would seem simpler and more elegant to me than getting in to theme slugs, white-listing specific users, and trying to create specific tag filters for each non-standard use-case.<br>
><br>
> _______________________________________________<br>
> theme-reviewers mailing list<br>
> <a href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a><br>
> <a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> theme-reviewers mailing list<br>
> <a href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a><br>
> <a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> theme-reviewers mailing list<br>
> <a href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a><br>
> <a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
><br>
><br>
> _______________________________________________<br>
> theme-reviewers mailing list<br>
> <a href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a><br>
> <a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
<br>
_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
</div></div></blockquote></div><br></div>