[theme-reviewers] Submitting a One-Page Placeholder Theme

Sat Oct 29 17:00:05 UTC 2011

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.

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.)

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?)

So, to reiterate: it will be the *ideas* that will be limited, NOT the
number of *Themes* designed toward a given idea.

Chip

On Sat, Oct 29, 2011 at 11:46 AM, Ryan Frankel <ryan.frankel at gmail.com>wrote:

> 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.
>
> Hopefully, whatever mechanism is put in place will take into account that
> many developers will be working on similar ideas.
>
> Ryan
>
>
> On Oct 29, 2011, at 12:32 PM, Chip Bennett wrote:
>
> > One special/extraordinary use case, yes - but also, a use case that is
> demonstrably useful and/or unique/innovative.
> >
> > Landing-page Themes are obviously useful. A support-ticket-system Theme
> is IMHO both unique and innovative.
> >
> > I'd love to hear other ideas/examples of such "niche" Themes!
> >
> > Chip
> >
> > On Sat, Oct 29, 2011 at 11:18 AM, Angelo Bertolli <
> angelo.bertolli at gmail.com> wrote:
> > 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?
> >
> >
> > On Sat, Oct 29, 2011 at 11:19 AM, Chip Bennett <chip at chipbennett.net>
> wrote:
> > 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.
> >
> >  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.
> >
> > 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.
> >
> > 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.
> >
> > Chip
> >
> > On Sat, Oct 29, 2011 at 9:42 AM, Kirk Wight <kwight at kwight.ca> wrote:
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > _______________________________________________
> > theme-reviewers mailing list
> > theme-reviewers at lists.wordpress.org
> > http://lists.wordpress.org/mailman/listinfo/theme-reviewers
> >
> >
> >
> > _______________________________________________
> > theme-reviewers mailing list
> > theme-reviewers at lists.wordpress.org
> > http://lists.wordpress.org/mailman/listinfo/theme-reviewers
> >
> >
> >
> > _______________________________________________
> > theme-reviewers mailing list
> > theme-reviewers at lists.wordpress.org
> > http://lists.wordpress.org/mailman/listinfo/theme-reviewers
> >
> >
> > _______________________________________________
> > theme-reviewers mailing list
> > theme-reviewers at lists.wordpress.org
> > http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20111029/f3a11250/attachment.htm>