RTBC is now "reviewed & tested by the community"

Hello world,

After Daniel F. Kudwien pointed at http://drupal.org/node/
156637
(rename RTBC) in my other RTBC thread, the issue saw a
flurry of
activity and, much to my delight, I was able to rename this
status to
something which much better reflects what it actually is.

Thanks to:

* fajerstarter for the new name
* webchick for rerolling my small patch to make the issue
state
accomodate the longer name.
* hunmonk for commiting and applying it on drupal.org.

Enjoy!

Karoly Negyesi

I'm REALLY happy that, after our long "RTBC - how does
it work?"  
discussion after the D6 code freeze (http://lists.drupal.org/pipermail/development
/2007-July/thread.html 
), we will avoid such misunderstandings by "new drupal
contributors"  
after D7's code freeze.

Yay, RTBC!

   - John


On Feb 21, 2008, at 4:18 PM, Karoly Negyesi wrote:

> Hello world,
>
> After Daniel F. Kudwien pointed at http://drupal.org/node/
156637
> (rename RTBC) in my other RTBC thread, the issue saw a
flurry of
> activity and, much to my delight, I was able to rename
this status to
> something which much better reflects what it actually
is.
>
> Thanks to:
>
> * fajerstarter for the new name
> * webchick for rerolling my small patch to make the
issue state
> accomodate the longer name.
> * hunmonk for commiting and applying it on drupal.org.
>
> Enjoy!
>
> Karoly Negyesi

This new status name seems like a good idea. Let's monitor
e.g. whether the 
new status should leads to a lower threshold than RTBC did..
The new status 
still needs to meet the need for core committers to have a
meaningful list 
of fully reviewed and refined patches.

In future, if needed, we could consider e.g. additional
status options for 
expert review to cover that minority of issues that need an
extra level of 
review by a maintainer or other developer with recognized
applicable 
expertise.

Nedjo 

Quoting Earl Miles <merlinlogrus.com>:

> Simon Hobbs wrote:
>> "RTBC": truly, finally, RTBC.
>>
>> Drupal community at its finest 
>
> Please note that this only counts for core, really, and
core actually 
> only accounts for some of the issues in Drupal.
>
> I challenge you to find a contrib module where the
community actually 
> does enough reviewing and testing for this flag to
actually mean what 
> it says for the rest of the issue queue.
>
> Not that anybody in the issue queue really cares much
about non-core 
> anyway, but just thought I'd point out that contrib is,
as usual, a 
> second class citizen here.
>

Isn't this mostly true with the original wording as well? 
The biggest 
advantage to have a module moved to core is that it takes on
more 
scrutiny so that it maintains balance with core.

Earnie -- http://for-my-kids.com/
-- http://give-me-an-offer.
com/

Quoting Dries Buytaert <dries.buytaertgmail.com>:

> I'm slightly worried that 'reviewed and tested by the
community' will
> have lower quality submissions than 'ready to be
committed'.  The
> problem with 'reviewed and tested by the community' is
that people
> will set it to 'reviewed and tested by the community'
after one
> review, whereas with 'ready to be committed', we
typically had
> different people looking at a patch.
>

As was stated in the issue at least two reviewers and
testers should 
comment before setting to this status.  As for the control
of the 
setting, it operates the same as Ready To Be Committed.

> Read: I think 'ready to committed' was perfectly fine
and I don't
> understand why this was changed without my approval. 
After all, I'm
> the one reviewing and committing these patches.
>

It is a user perception thing.  Ready To Be Committed not
committed 
inflames developers.  Reviewed and Tested is implies that
some role 
level greater than the patch creator can now take his
precious time to 
look at this lowly patch.

> Also, why the 'by the community' part?  Why not just
'reviewed and
> tested'?  Please rename at least to 'reviewed and
tested'.  Everything
> we do is community-driven so 'by the community' is
completely
> redundant.  It seems to  suggest that there is a
non-community body as
> well.
>

Agreed.

Earnie -- http://for-my-kids.com/
-- http://give-me-an-offer.
com/

On Feb 22, 2008, at 11:53 PM, Dries Buytaert wrote:
> So we're choosing sub-optimal status fields to preserve
backward
> compatibility?  That is very non-Drupal ...
>
> The whole 'tested and reviewed by the community' stuff
doesn't make a
> whole lot of sense to me. I wouldn't mind to have us
switch back to
> 'ready to be committed'.

But as we discussed in July (http://lists.drupal.org/pipermail/development
/2007-July/025007.html 
), newcomers think that "ready to be committed"
means that it WILL get  
committed. So the "ready to be committed" wording
doesn't make a whole  
lot of sense to them.

 From July:
 > We need a solution [to the RTBC problem] that
naturally aligns new  
developers
 > expectations with how core development is actually
done.

'reviewed and tested by the community' is /slightly/ better
(IMO) than  
the old RTBC meaning because it doesn't imply (to newcomers)
that  
committers should commit everything that is RTBC.

BUT... I don't think any 4-5 word phrase is adequate to
explain when  
an issue should be marked RTBC.

It would be much more useful to have a #description text
below the  
Priority and Status pull-down menus that briefly describes
those  
fields and links to the full Priority and Status
definitions.
For example in the line directly below the
"Status" pull-down menu,  
place something like this:
   Descriptions of how to use Priority and Status levels can
be found  
in the
   Contributing to Development Handbook [http://drupal.org/node/1
0259].

See this feature request: http://drupal.org/node/
159457

Wouldn't that be much more useful than reverting RTBC?

  - John

On Thu, Feb 28, 2008 at 7:28 PM, John Wilkins
<drupal.useralbin.net> wrote:
>
>  On Feb 22, 2008, at 11:53 PM, Dries Buytaert wrote:
>  > So we're choosing sub-optimal status fields to
preserve backward
>  > compatibility?  That is very non-Drupal ...
>  >
>  > The whole 'tested and reviewed by the community'
stuff doesn't make a
>  > whole lot of sense to me. I wouldn't mind to have
us switch back to
>  > 'ready to be committed'.
>
>  But as we discussed in July (http://lists.drupal.org/pipermail/development
/2007-July/025007.html
>  ), newcomers think that "ready to be
committed" means that it WILL get
>  committed. So the "ready to be committed"
wording doesn't make a whole
>  lot of sense to them.
>
>   From July:
>   > We need a solution [to the RTBC problem] that
naturally aligns new
>  developers
>   > expectations with how core development is
actually done.

I agree. But I don't see why we need to preserve
"backwards
compatibility." Lets say I'm new, I go to the drupal
issue queue and
find an old issue that mentions "Marking RTBC." 
In that unlikely case
that I actually care we could have a handbook page or forum
discussion
explaining what it means. I could easily find it by
searching I'm
sure.  And likely there will be some questions but...

I think Ready for comment(RFC) or Ready for review(RFR)
have
connotations that fit in line with what RTBC really means.
IE, we're
looking to have I high level peer review or review by the
commiters.

>
>  'reviewed and tested by the community' is /slightly/
better (IMO) than
>  the old RTBC meaning because it doesn't imply (to
newcomers) that
>  committers should commit everything that is RTBC.
>
>  BUT... I don't think any 4-5 word phrase is adequate
to explain when
>  an issue should be marked RTBC.
>
>  It would be much more useful to have a #description
text below the
>  Priority and Status pull-down menus that briefly
describes those
>  fields and links to the full Priority and Status
definitions.
>  For example in the line directly below the
"Status" pull-down menu,
>  place something like this:
>    Descriptions of how to use Priority and Status
levels can be found
>  in the
>    Contributing to Development Handbook [http://drupal.org/node/1
0259].
>
>  See this feature request: http://drupal.org/node/
159457
>
>  Wouldn't that be much more useful than reverting
RTBC?

I think it would be a great place to help explain a change
or explain
what's going on.

--
James