FAQ
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

Search Discussions

  • John Wilkins at Feb 21, 2008 at 11:41 pm
    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
  • Nedjo Rogers at Feb 21, 2008 at 11:58 pm
    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
  • Simon Hobbs at Feb 23, 2008 at 5:40 am
    "RTBC": truly, finally, RTBC.

    Drupal community at its finest :)
  • Earl Miles at Feb 23, 2008 at 8:23 am

    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.
  • Earnie Boyd at Feb 23, 2008 at 6:40 pm

    Quoting Earl Miles <merlin at logrus.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/
  • Dries Buytaert at Feb 23, 2008 at 6:11 am
    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.

    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.

    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.
    On Fri, Feb 22, 2008 at 12:18 AM, 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


    --
    Dries Buytaert :: http://buytaert.net/
  • Khalid Baheyeldin at Feb 23, 2008 at 6:32 am

    On Sat, Feb 23, 2008 at 1:11 AM, Dries Buytaert wrote:
    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.
    Dries,

    The reason is backward compatibility for the acronym, so that newcomers
    would check old issues and see "RTBC" and the new words would match it
    same with the old words.

    Personally, we break backward compatibility all the time in Drupal, and
    saw what the heck, it is worth it. So why not do the same with issue status
    and documentation too? Yeah, some inconvenience for sure, but better in
    the long term.
    --
    Khalid M. Baheyeldin
    2bits.com, Inc.
    http://2bits.com
    Drupal optimization, development, customization and consulting.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.drupal.org/pipermail/development/attachments/20080223/2219c4d3/attachment.htm
  • Dries Buytaert at Feb 23, 2008 at 6:53 am

    The reason is backward compatibility for the acronym, so that newcomers
    would check old issues and see "RTBC" and the new words would match it
    same with the old words.

    Personally, we break backward compatibility all the time in Drupal, and
    saw what the heck, it is worth it. So why not do the same with issue status
    and documentation too? Yeah, some inconvenience for sure, but better in
    the long term.
    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'.

    --
    Dries Buytaert :: http://buytaert.net/
  • Morbus Iff at Feb 23, 2008 at 2:11 pm

    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'.
    Not I.

    --
    Morbus Iff ( relax have a happy meal )
    Technical: http://www.oreillynet.com/pub/au/779
    Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/
    aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus
  • Morbus Iff at Feb 23, 2008 at 2:12 pm

    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'.
    Nor I.

    --
    Morbus Iff ( relax have a happy meal )
    Technical: http://www.oreillynet.com/pub/au/779
    Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/
    aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus
  • Morbus Iff at Feb 23, 2008 at 2:13 pm

    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'.
    Nor I.
    /me sighs. THIS was the right message, not my typo of "Not I". I coulda
    swore I had canceled that message in time. Curse critical typos!

    --
    Morbus Iff ( relax have a happy meal )
    Technical: http://www.oreillynet.com/pub/au/779
    Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/
    aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus
  • John Wilkins at Feb 29, 2008 at 12:28 am

    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/10259].

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

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

    - John
  • James Gilliland at Mar 3, 2008 at 11:57 am

    On Thu, Feb 28, 2008 at 7:28 PM, John Wilkins 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/10259].

    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
  • Earnie Boyd at Feb 23, 2008 at 7:06 pm

    Quoting Dries Buytaert <dries.buytaert at gmail.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/
  • Catch at Feb 23, 2008 at 7:16 pm

    Dries:
    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.
    When I saw that, I thought it was mainly about being more than one
    person. But "Reviewed and tested by more than one person" doesn't sound
    too good either.

    The main issue here of course isn't so much the number of people setting
    things to RTBC without properly reviewing. It's the lack of people
    reviewing full stop.
  • Robin Monks at Feb 23, 2008 at 7:14 pm
    Very nice!

    Congrats!

    Robin
    On Thu, Feb 21, 2008 at 7: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


    --
    Robin Monks
    @ www.robinmonks.com
    @ www.gmking.org
    @ www.multimediachurches.org

    Fax: (419) 791-8076

    "Finally, my brethren, be strong in the Lord, and in the power of his
    might." ~ Ephesians 6:10
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.drupal.org/pipermail/development/attachments/20080223/ae2e8199/attachment.htm

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdevelopment @
categoriesdrupal
postedFeb 21, '08 at 11:18p
activeMar 3, '08 at 11:57a
posts17
users12
websitedrupal.org
irc#drupal

People

Translate

site design / logo © 2022 Grokbase