<div class="gmail_quote">On Wed, Aug 25, 2010 at 11:30 AM, Otto <span dir="ltr"><<a href="mailto:otto@ottodestruct.com">otto@ottodestruct.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wed, Aug 25, 2010 at 11:15 AM, Chip Bennett <<a href="mailto:chip@chipbennett.net">chip@chipbennett.net</a>> wrote:<br>
> Semantics. We're not "rejecting" a Theme (or its developer); we're<br>
> suggesting that a Theme *as submitted* not be approved for inclusion in the<br>
> repository.<br>
<br>
</div>In other words, "go away, we don't want you to be a part of our community".<br></blockquote><div><br></div><div>If you're saying that's what the Theme developer is *inferring*, then fair enough: let's fix it so that they get the proper inference. Because that's certainly not what a "not-accepted" Theme review is *implying*. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Not allowing somebody into <a href="http://wordpress.org" target="_blank">wordpress.org</a> is rejection in every sense<br>
of the term. It's a rejection of their theme, a rejection of their<br>
code, and a rejection of that person.<br>
<div class="im"><br>
> We have a very limited implementation of Trac to work with.<br>
<br>
</div>Just tell me what you need the tools to do in order to make this work,<br>
and we'll try to work together towards making the tools do what they<br>
need to do. I'm a programmer, I can do that sort of thing.<br></blockquote><div><br></div><div>Probably summarized elsewhere and throughout, but I'm sure we can come up with a full list, if need be:</div><div><br>
</div><div>1) a way to keep a Theme associated with a given ticket, all the way through final approval</div><div>2) a way for Theme developers to update and resubmit directly to their SVN directory, rather than continually through the uploader, for any given revision/Trac ticket.</div>
<div>3) more appropriate resolution options, to allow the back-and-forth to take place within one single ticket. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> You'll have to ask Cais for exact details, but what you're asking for, I<br>
> believe, would require a LOT of manual intervention in order to make it<br>
> work.<br>
<br>
</div>Then let's do that intervention. This process simply does not work as<br>
it stands, and if we need to change it, then that's fine. But before<br>
we change it, let's decide on the right way, then change it to do it<br>
that way.<br></blockquote><div><br></div><div>That manual intervention would probably be asking way too much (Cais?). So, let's focus on improving the process. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> If you can have some influence in improving our ability to take advantage of<br>
> Trac, then I think every one of us would be supportive of and grateful for<br>
> that improvement.<br>
> For example:<br>
> 1) Find a way to link new revisions to the already open Ticket for a given<br>
> Theme<br>
> 2) Add new options for ticket resolution, such as "needs further revision"<br>
> or whatever<br>
> Every one of us, I believe, would LOVE such improvements.<br>
<br>
</div>Done. I'll put those on the list.<br>
<div class="im"><br>
> We have to balance. I like to give very thorough reviews. But, if a Theme<br>
> has been submitted 2,3,4 or more times and *still* fails the review, then<br>
> IMO it is clear that the Theme developer isn't making the effort to ensure<br>
> that the Theme meets the Guidelines. We don't want to incentivize such<br>
> behavior.<br>
<br>
</div>Also understand that it might also be an indication that the theme<br>
author is not understanding the purpose or reason for some of the<br>
feedback he's being given. If we are going to be looking at themes for<br>
some set of predefined things to be there, then we should have a well<br>
written and highly verbose explanation of why we think it should be<br>
there that should be given to the author directly, every single time.<br>
<br>
More than a sentence. Somebody lacking "body_class" should get three<br>
or four paragraphs on why it's a good idea to use it.<br></blockquote><div><br></div><div>I disagree. Link to the Codex references, and improve the Codex entries if need be.</div><div><br></div><div>I suppose we can draft boilerplate text for each function/tag/hook, if need be, to put in a Trac ticket comment. If that is the best use of my time, for the better of the Theme developer community, then I'd be happy to work on that. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
In my experience, most people *can't* educate themselves from mere<br>
documentation. You do have to hold their hand through it. Once they<br>
get over that initial learning curve problem, *then* you can let them<br>
go on their own. But you never get anybody to improve until you guide<br>
them *really* well through those first steps.<br></blockquote><div><br></div><div>If the Codex isn't written well enough to be a useful educational tool, then we need to look at improving the Codex. But reinventing that wheel with each and every Theme review would not be useful.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> But, again: Trac<br>
> is a mostly foreign concept to a lot of Theme developers. Not only are we<br>
> having to educate them regarding new review Guidelines, but we're also<br>
> having to educate on how to make use of the Trac system, and the tickets<br>
> generated for their Theme submissions.<br>
<br>
</div>Okay. Then let's dump trac.<br>
<br>
Or let's put a new face on trac to make it easier.<br>
<br>
Or *something*. I don't claim to know what would work, and I don't<br>
claim to know all the answers. I just know that it doesn't work now,<br>
and I'm willing to help in changing to make it better. Because it<br>
*has* to get better, somehow.<br></blockquote><div><br></div><div>So let's make it better! Tell us what our options are, to improve the system with which we are working. Trac is pretty powerful. Help us make better use of it. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> As for helping Theme developers understand why certain criteria are<br>
> required: we've been working very hard on improving the Theme Review Codex<br>
> page, to make it more clear, understandable, and concise. We've added Codex<br>
> cross-references for darn-near everything. It is not too much to expect<br>
> Theme developers to keep abreast of the information available in the Codex,<br>
> especially regarding standard WordPress features, functions, tags, and<br>
> hooks. We're doing everything we can to point them in the right direction.<br>
<br>
</div>I do appreciate and understand this, and don't want anybody to take it<br>
as criticism of them. I'm being critical of the process here, not the<br>
people.<br>
<div class="im"><br>
> Have you actually "experienced" it? Have you reviewed a Theme? Have you<br>
> submitted a Theme for review?<br>
<br>
</div>Yes. You reviewed one of them. You may not have known it was me, as it<br>
wasn't under my name. :)<br></blockquote><div><br></div><div>And if you have any feedback or constructive criticism of my review, I'd love to hear it - on the mail list, or to me personally: I have no preference. I'm sure my own reviews can be improved, and others may benefit from that feedback also. So please: give me your honest opinion. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> Agreed, regarding eventual approval. If we can make that process easier for<br>
> both the Theme developers and the review team, then by all means, let's do<br>
> it.<br>
> But just because the *process* has issues, doesn't mean that the Guidelines<br>
> aren't sound.<br>
<br>
</div>I think that some of the guidelines are a problem in that they are<br>
being used as cause for rejection when they should not be, however I<br>
also have an issue with the main idea of "rejection" itself. You may<br>
not think of it as actual literal rejection, but it very much seems<br>
that way to the outsider.</blockquote><div><br></div><div>So let's drop the use of the term "reject" with respect to reviews of submitted Themes. Help us implement a system in which our only option is "suggest approval" or 'suggest not-approval" (reject). If we're giving the impression that we're "rejecting" community contributions, then we need to fix that impression.</div>
<div><br></div><div>Chip </div></div>