No subject
Tue Apr 20 23:23:57 UTC 2010
experienced by theme authors submitting their works to the repository and
subsequently receiving notice of their theme not meeting the criteria
currently laid out on the Theme Review page. This is truly unfortunate if
that is the case, but in no way is that the intent. I have had almost all of
my themes "rejected" at one point or another but I also recognized this was
due to the code used, not because I have long hair ... although after
shaving my head my themes automagically appeared in the repository (just
kidding) ... I re-worked them and with some help was able to get them into
the repository.
My understanding of the current Trac system and the submission process being
used essentially only allows for this method of "not-accepted" or
"suggest-approval" resolutions. Perhaps more resolution options would be
useful the "needs additional review" option was just added, I'm sure more
could be added as easily. All that is needed is the appropriate Trac
permissions.
Do we need better communication of the issues a theme is presenting in
regards to the current Theme Review guidelines and processes? Yes, I agree.
Does that mean we need to write novellas for comments on each theme that
does not initially pass to explain would could easily be 10 or more issues
not considering any minor concerns? Here I disagree, but there is always
room for improvement and now two plus months into this its nice to see
contructive criticisms being made ... and additional offers of help. I just
hope you are installing sideboards on your plate because I feel confident we
can fill it up without too much trouble (and I'm not just kidding).
If you would like to see "no rejections" then I suggest finding a way to
address themes, and their updates via the current infrastructure. Each theme
resides in its own SVN similar to the plugins repository, implement a
similar method. This will allow authors to update their themes without
submitting multiple times until they want a new specific version number
implemented. The theme review team can help sort out any issues and once the
theme reaches a point acceptable for inclusion into the repository it can be
marked "Approved" and we carry on.
Of course, the current Trac ticket system help maintain an order and queue
for review and consideration, I would expect this to be part of the "new"
methods!
I also have to comment on the continued re-submission of themes with issues
previously noted and still not corrected. We can lead the theme authors to
the Theme Review page, but we cannot make them read it. As a team we would
be more than happy to help them better address issues with their themes, but
I also believe it is only fair of the team to expect the authors to are
least read the Theme Review page and if they do not understand a section,
point, function usage et cetera then they are free to contact the mailing
list.
I also agree with the idea making sure they are aware of the IRC channel
#wp-themes for assistance as well.
I see this as an ever evolving process and always welcome input, especially
from those that can look at the system from a fresh set of eyes; and, Otto,
with access to tools, and skillsets, we can put to use.
Now as I close this reply, I did read the explanation of the "experience" by
Otto working under Matt's name and suspected that was the theme in question.
I have a better understanding of what was written (above). As much as we are
being asked to communicate to the authors we are at the same disadvantage of
the authors not communicating back to the team in most cases as well.
Your input from these emails is likely the most we have seen from anyone
(pseudo-)author, it would be a great boon to see similar input from other
authors. Also adding some way for that communication to be part of the theme
"ticket", for lack of a better term at the moment, and something going back
to the reviewer or team as a whole as well so it can be followed up on.
Most of the process at the moment has a very manual feel about it,
especially the communication part ... not that the personal touch should not
be applied but a great deal of information could be transmitted via
automated methods. For example, updating and increasing the items checked at
upload; then making sure more verbose and explanatory reasons and examples
are provided to help theme authors to understand why the theme did not pass
the upload checks would go a long way to helping the process.
Cais.
PS: A lot longer than I thought it would be, but there was a lot to read,
digest, and reply to ... if I missed something feel free to let me know. EAC
On Wed, Aug 25, 2010 at 12:52 PM, Chip Bennett <chip at chipbennett.net> wrote:
> On Wed, Aug 25, 2010 at 11:30 AM, Otto <otto at ottodestruct.com> wrote:
>
>> On Wed, Aug 25, 2010 at 11:15 AM, Chip Bennett <chip at chipbennett.net>
>> wrote:
>> > Semantics. We're not "rejecting" a Theme (or its developer); we're
>> > suggesting that a Theme *as submitted* not be approved for inclusion in
>> the
>> > repository.
>>
>> In other words, "go away, we don't want you to be a part of our
>> community".
>>
>
> 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*.
>
>>
>> Not allowing somebody into wordpress.org is rejection in every sense
>> of the term. It's a rejection of their theme, a rejection of their
>> code, and a rejection of that person.
>>
>> > We have a very limited implementation of Trac to work with.
>>
>> Just tell me what you need the tools to do in order to make this work,
>> and we'll try to work together towards making the tools do what they
>> need to do. I'm a programmer, I can do that sort of thing.
>>
>
> Probably summarized elsewhere and throughout, but I'm sure we can come up
> with a full list, if need be:
>
> 1) a way to keep a Theme associated with a given ticket, all the way
> through final approval
> 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.
> 3) more appropriate resolution options, to allow the back-and-forth to take
> place within one single ticket.
>
>>
>> > You'll have to ask Cais for exact details, but what you're asking for, I
>> > believe, would require a LOT of manual intervention in order to make it
>> > work.
>>
>> Then let's do that intervention. This process simply does not work as
>> it stands, and if we need to change it, then that's fine. But before
>> we change it, let's decide on the right way, then change it to do it
>> that way.
>>
>
> That manual intervention would probably be asking way too much (Cais?). So,
> let's focus on improving the process.
>
>>
>> > If you can have some influence in improving our ability to take
>> advantage of
>> > Trac, then I think every one of us would be supportive of and grateful
>> for
>> > that improvement.
>> > For example:
>> > 1) Find a way to link new revisions to the already open Ticket for a
>> given
>> > Theme
>> > 2) Add new options for ticket resolution, such as "needs further
>> revision"
>> > or whatever
>> > Every one of us, I believe, would LOVE such improvements.
>>
>> Done. I'll put those on the list.
>>
>> > We have to balance. I like to give very thorough reviews. But, if a
>> Theme
>> > has been submitted 2,3,4 or more times and *still* fails the review,
>> then
>> > IMO it is clear that the Theme developer isn't making the effort to
>> ensure
>> > that the Theme meets the Guidelines. We don't want to incentivize such
>> > behavior.
>>
>> Also understand that it might also be an indication that the theme
>> author is not understanding the purpose or reason for some of the
>> feedback he's being given. If we are going to be looking at themes for
>> some set of predefined things to be there, then we should have a well
>> written and highly verbose explanation of why we think it should be
>> there that should be given to the author directly, every single time.
>>
>> More than a sentence. Somebody lacking "body_class" should get three
>> or four paragraphs on why it's a good idea to use it.
>>
>
> I disagree. Link to the Codex references, and improve the Codex entries if
> need be.
>
> 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.
>
>>
>> In my experience, most people *can't* educate themselves from mere
>> documentation. You do have to hold their hand through it. Once they
>> get over that initial learning curve problem, *then* you can let them
>> go on their own. But you never get anybody to improve until you guide
>> them *really* well through those first steps.
>>
>
> 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.
>
>>
>> > But, again: Trac
>> > is a mostly foreign concept to a lot of Theme developers. Not only are
>> we
>> > having to educate them regarding new review Guidelines, but we're also
>> > having to educate on how to make use of the Trac system, and the tickets
>> > generated for their Theme submissions.
>>
>> Okay. Then let's dump trac.
>>
>> Or let's put a new face on trac to make it easier.
>>
>> Or *something*. I don't claim to know what would work, and I don't
>> claim to know all the answers. I just know that it doesn't work now,
>> and I'm willing to help in changing to make it better. Because it
>> *has* to get better, somehow.
>>
>
> 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.
>
>>
>> > As for helping Theme developers understand why certain criteria are
>> > required: we've been working very hard on improving the Theme Review
>> Codex
>> > page, to make it more clear, understandable, and concise. We've added
>> Codex
>> > cross-references for darn-near everything. It is not too much to expect
>> > Theme developers to keep abreast of the information available in the
>> Codex,
>> > especially regarding standard WordPress features, functions, tags, and
>> > hooks. We're doing everything we can to point them in the right
>> direction.
>>
>> I do appreciate and understand this, and don't want anybody to take it
>> as criticism of them. I'm being critical of the process here, not the
>> people.
>>
>> > Have you actually "experienced" it? Have you reviewed a Theme? Have you
>> > submitted a Theme for review?
>>
>> Yes. You reviewed one of them. You may not have known it was me, as it
>> wasn't under my name. :)
>>
>
> 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.
>
>>
>> > Agreed, regarding eventual approval. If we can make that process easier
>> for
>> > both the Theme developers and the review team, then by all means, let's
>> do
>> > it.
>> > But just because the *process* has issues, doesn't mean that the
>> Guidelines
>> > aren't sound.
>>
>> I think that some of the guidelines are a problem in that they are
>> being used as cause for rejection when they should not be, however I
>> also have an issue with the main idea of "rejection" itself. You may
>> not think of it as actual literal rejection, but it very much seems
>> that way to the outsider.
>
>
> 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.
>
> Chip
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
>
--0016364578dcbba79c048eab53da
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Here I am reading 12 pages of print for this thread. These digital Jenga to=
wers of replies hurt my head so I went old school and printed the whole thr=
ead (*grin*).<br><br>From what I can gather there is a perceived personal r=
ejection being experienced by theme authors submitting their works to the r=
epository and subsequently receiving notice of their theme not meeting the =
criteria currently laid out on the Theme Review page. This is truly unfortu=
nate if that is the case, but in no way is that the intent. I have had almo=
st all of my themes "rejected" at one point or another but I also=
recognized this was due to the code used, not because I have long hair ...=
although after shaving my head my themes automagically appeared in the rep=
ository (just kidding) ... I re-worked them and with some help was able to =
get them into the repository.<br>
<br>My understanding of the current Trac system and the submission process =
being used essentially only allows for this method of "not-accepted&qu=
ot; or "suggest-approval" resolutions. Perhaps more resolution op=
tions would be useful the "needs additional review" option was ju=
st added, I'm sure more could be added as easily. All that is needed is=
the appropriate Trac permissions.<br>
<br>Do we need better communication of the issues a theme is presenting in =
regards to the current Theme Review guidelines and processes? Yes, I agree.=
Does that mean we need to write novellas for comments on each theme that d=
oes not initially pass to explain would could easily be 10 or more issues n=
ot considering any minor concerns? Here I disagree, but there is always roo=
m for improvement and now two plus months into this its nice to see contruc=
tive criticisms being made ... and additional offers of help. I just hope y=
ou are installing sideboards on your plate because I feel confident we can =
fill it up without too much trouble (and I'm not just kidding).<br>
<br>If you would like to see "no rejections" then I suggest findi=
ng a way to address themes, and their updates via the current infrastructur=
e. Each theme resides in its own SVN similar to the plugins repository, imp=
lement a similar method. This will allow authors to update their themes wit=
hout submitting multiple times until they want a new specific version numbe=
r implemented. The theme review team can help sort out any issues and once =
the theme reaches a point acceptable for inclusion into the repository it c=
an be marked "Approved" and we carry on.<br>
<br>Of course, the current Trac ticket system help maintain an order and qu=
eue for review and consideration, I would expect this to be part of the &qu=
ot;new" methods!<br><br>I also have to comment on the continued re-sub=
mission of themes with issues previously noted and still not corrected. We =
can lead the theme authors to the Theme Review page, but we cannot make the=
m read it. As a team we would be more than happy to help them better addres=
s issues with their themes, but I also believe it is only fair of the team =
to expect the authors to are least read the Theme Review page and if they d=
o not understand a section, point, function usage et cetera then they are f=
ree to contact the mailing list.<br>
<br>I also agree with the idea making sure they are aware of the IRC channe=
l #wp-themes for assistance as well.<br><br>I see this as an ever evolving =
process and always welcome input, especially from those that can look at th=
e system from a fresh set of eyes; and, Otto, with access to tools, and ski=
llsets, we can put to use.<br>
<br>Now as I close this reply, I did read the explanation of the "expe=
rience" by Otto working under Matt's name and suspected that was t=
he theme in question. I have a better understanding of what was written (ab=
ove). As much as we are being asked to communicate to the authors we are at=
the same disadvantage of the authors not communicating back to the team in=
most cases as well.<br>
<br>Your input from these emails is likely the most we have seen from anyon=
e (pseudo-)author, it would be a great boon to see similar input from other=
authors. Also adding some way for that communication to be part of the the=
me "ticket", for lack of a better term at the moment, and somethi=
ng going back to the reviewer or team as a whole as well so it can be follo=
wed up on.<br>
<br>Most of the process at the moment has a very manual feel about it, espe=
cially the communication part ... not that the personal touch should not be=
applied but a great deal of information could be transmitted via automated=
methods. For example, updating and increasing the items checked at upload;=
then making sure more verbose and explanatory reasons and examples are pro=
vided to help theme authors to understand why the theme did not pass the up=
load checks would go a long way to helping the process.<br>
<br><br>Cais.<br><br>PS: A lot longer than I thought it would be, but there=
was a lot to read, digest, and reply to ... if I missed something feel fre=
e to let me know. EAC<br><br><br><br><br><div class=3D"gmail_quote">On Wed,=
Aug 25, 2010 at 12:52 PM, Chip Bennett <span dir=3D"ltr"><<a href=3D"ma=
ilto:chip at chipbennett.net">chip at chipbennett.net</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class=3D"gma=
il_quote"><div class=3D"im">On Wed, Aug 25, 2010 at 11:30 AM, Otto <span di=
r=3D"ltr"><<a href=3D"mailto:otto at ottodestruct.com" target=3D"_blank">ot=
to at ottodestruct.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>On Wed, Aug 25, 2010 at 11:15 AM, Chip Bennett <<a href=3D"mailto:c=
hip at chipbennett.net" target=3D"_blank">chip at chipbennett.net</a>> wrote:<=
br>
> Semantics. We're not "rejecting" a Theme (or its develop=
er); we're<br>
> suggesting that a Theme *as submitted* not be approved for inclusion i=
n 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><div>If you'r=
e saying that's what the Theme developer is *inferring*, then fair enou=
gh: let's fix it so that they get the proper inference. Because that=
9;s certainly not what a "not-accepted" Theme review is *implying=
*.=A0</div>
<div class=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Not allowing somebody into <a href=3D"http://wordpress.org" target=3D"_blan=
k">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><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></blockqu=
ote><div><br></div></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 upda=
te and resubmit directly to their SVN directory, rather than continually th=
rough 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.=A0</div><div class=3D"im"><blockquote=
class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px=
solid rgb(204, 204, 204); padding-left: 1ex;">
<div><br>
> You'll have to ask Cais for exact details, but what you're ask=
ing for, I<br>
> believe, would require a LOT of manual intervention in order to make i=
t<br>
> work.<br>
<br>
</div>Then let's do that intervention. This process simply does not wor=
k 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><div>That manual interventio=
n would probably be asking way too much (Cais?). So, let's focus on imp=
roving the process.=A0</div><div class=3D"im"><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 20=
4, 204); padding-left: 1ex;">
<div><br>
> If you can have some influence in improving our ability to take advant=
age 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 g=
iven<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><br>
> We have to balance. I like to give very thorough reviews. But, if a Th=
eme<br>
> has been submitted 2,3,4 or more times and *still* fails the review, t=
hen<br>
> IMO it is clear that the Theme developer isn't making the effort t=
o 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 th=
ree<br>
or four paragraphs on why it's a good idea to use it.<br></blockquote><=
div><br></div></div><div>I disagree. Link to the Codex references, and impr=
ove 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.=A0</=
div>
<div class=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); 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></di=
v></div><div>If the Codex isn't written well enough to be a useful educ=
ational 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>
<div class=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><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 ticke=
ts<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><div>So =
let's make it better! Tell us what our options are, to improve the syst=
em with which we are working. Trac is pretty powerful. Help us make better =
use of it.=A0</div>
<div class=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><br>
> As for helping Theme developers understand why certain criteria are<br=
>
> required: we've been working very hard on improving the Theme Revi=
ew Codex<br>
> page, to make it more clear, understandable, and concise. We've ad=
ded Codex<br>
> cross-references for darn-near everything. It is not too much to expec=
t<br>
> Theme developers to keep abreast of the information available in the C=
odex,<br>
> especially regarding standard WordPress features, functions, tags, and=
<br>
> hooks. We're doing everything we can to point them in the right di=
rection.<br>
<br>
</div>I do appreciate and understand this, and don't want anybody to ta=
ke it<br>
as criticism of them. I'm being critical of the process here, not the<b=
r>
people.<br>
<div><br>
> Have you actually "experienced" it? Have you reviewed a Them=
e? 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 i=
t<br>
wasn't under my name. :)<br></blockquote><div><br></div></div><div>And =
if you have any feedback or constructive criticism of my review, I'd lo=
ve 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.=A0</div>
<div class=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><br>
> Agreed, regarding eventual approval. If we can make that process easie=
r for<br>
> both the Theme developers and the review team, then by all means, let&=
#39;s do<br>
> it.<br>
> But just because the *process* has issues, doesn't mean that the G=
uidelines<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><div>So let'=
s drop the use of the term "reject" with respect to reviews of su=
bmitted Themes. Help us implement a system in which our only option is &quo=
t;suggest approval" or 'suggest not-approval" (reject). If we=
're giving the impression that we're "rejecting" communit=
y contributions, then we need to fix that impression.</div>
<div><br></div><font color=3D"#888888"><div>Chip=A0</div></font></div>
<br>_______________________________________________<br>
theme-reviewers mailing list<br>
<a href=3D"mailto:theme-reviewers at lists.wordpress.org">theme-reviewers at list=
s.wordpress.org</a><br>
<a href=3D"http://lists.wordpress.org/mailman/listinfo/theme-reviewers" tar=
get=3D"_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers<=
/a><br>
<br></blockquote></div><br>
--0016364578dcbba79c048eab53da--
More information about the theme-reviewers
mailing list